首页 测试 体会 查看内容

一个软件测试工程师的成长日记(连载六)

2014-10-16 20:09| 发布者: | 查看: 665| 评论: 0

摘要:   9.3 金蛋闪亮登场   下午的测试进行得非常顺利,小艾在3点时就完成了所有案例测试和清单列表的检测,并把结果报告发给凯文。报告中也详细说明了缺陷产生的原因和缺陷修复进度,以及对姚圳所提供代码补丁的测试 ...

  9.3  金蛋闪亮登场

  下午的测试进行得非常顺利,小艾在3点时就完成了所有案例测试和清单列表的检测,并把结果报告发给凯文。报告中也详细说明了缺陷产生的原因和缺陷修复进度,以及对姚圳所提供代码补丁的测试结果。

  9.3.1  成品测试胜利退出

  5点多,凯文找到小艾说:“你报告的那个缺陷项目组已决定会在今夜的驱动里修复。明天早晨10点左右你应该就能拿到新的驱动。需要你在新驱动上重新运行和这个缺陷有关的一些案例并确保没有产生新的回归问题。”

  小艾问道:“这会是最后一个成品测试候选驱动吗?”

  凯文摇了摇头说:“很遗憾,不是最后一个。安装测试团队在卸载产品案例中发现了一个比较严重的问题,开发团队正在研究解决方案,目前来看代码改动无论如何也进不了今天晚上的驱动。最好情况是明天让安装测试团队测试一下代码补丁,确保没问题了再进下一个成品测试候选驱动。另外迁移测试团队的测试案例明天才能全部测试完成,现在不知是否会有新的缺陷产生。”

  第二天,小艾按照所定计划完成了对缺陷修复相关案例的测试,再没有发现新的问题。小艾稍稍松了口气。

  由于其他测试团队在新驱动里又发现了些问题,需要多个系统环境进行问题调查,小艾在接下来的几天里,被找去帮忙准备测试环境。凯文穿梭在不同团队之间协调人员和机器资源以加速整体测试进度,忙得不可开交。

  所有人都忙而有序地工作着,等待着最后的胜利。

  终于,凯文发出电子邮件给所有人员,计划将第四个成品测试候选驱动拟定为最终成品候选驱动,要求各测试团队按照计划对最后成品测试驱动进行最后一轮测试。

  又经过两天紧张的忙碌,所有测试最终胜利完成,所有测试团队包括性能测试团队都相继发出电子邮件正式宣布测试完成,成品测试胜利退出。

  凯文在接到成品测试胜利退出的喜讯之后,随即宣布确定第四个成品测试候选驱动即为最终成品驱动,并告知大家质量检查报告也刚已通过最终审批。按计划明天将最终ISO文件交付给生产商制造物理光碟和供网上下载的电子光碟。

  整个办公室充盈着喜悦的气氛,经过近一年的努力,终于结出了胜利的果实,捧出了沉甸甸的金蛋,小艾由衷地为自己和团队感到骄傲和自豪。高兴之余,小艾对凯文信中提到的质量检测报告有些迷惑,于是他就去找凯文请教。

  凯文一见到小艾,就拍着他的肩膀笑着说:“你在这个项目中成长了很多,表现不错。下一个项目你就是老员工,不再是菜鸟啦!”

  小艾很不好意思地说:“要学的东西太多了,我也就刚入门。接触的事情越多,觉得要学习的东西就越多。这不又来向你请教了。”

  凯文说:“你之所以能够成长很快,就是因为你有很好的求知欲。我很高兴能帮到你,有什么问题尽管说。”

  小艾于是问道:“在你的邮件里提到的质量检测报告是怎么回事?我在测试阶段并没有接触到,你能给我简单介绍一下报告内容吗?”

  凯文于是给小艾做了详尽的介绍,并把一些资料发给小艾供他参考和学习。

  9.3.2  质量检测报告之大观

  小艾认真阅读了相关材料,对质量检测报告有了很深的了解。

  质量检测报告是项目中需要完成并得到审批的一个重要文件。在项目初期,项目经理需要和各团队负责人共同制定产品质量检测计划,其中大致包括:

  1、项目特征

  其中包括产品交付日期、项目大致介绍、项目大约所需人力物力数据、项目管理所需的几个关键日期、已知或潜在的开源产品介绍、开发流程特征等。


  2、产品用户体验

  需要给所开发产品的可用性、可靠性、安全性、集成性、维护性等方面制定一些具体指标,以保证用户在使用该产品时有良好的用户体验。

  3、性能指标

  需要制定一些性能方面的指标,客户可根据这些数据来配置硬件设施以期有效地应用产品,避免超负载、运行过慢等有害现象。

  4、产品试用版本计划

  需要指明产品是否有产品试用版本计划,如果有此计划,需要列明试用版本交付日期(一般要早于产品正式交付日期)和潜在试用客户名单。最后还需列明期望客户在哪些方面(例如可用性、可靠性、功能性、维护性、安装性等方面)给予反馈信息以促进产品的改进和提高。当然在产品正式交付前,还应有个客户试用版满意度调查,以了解客户对产品的功能和质量的总体看法,从客户反馈方面看产品是否达到交付标准。

  5、质量预见性指标

  这项指标是产品质量保障的重要监测指标。通过这些指标的制定,可以对开发和测试环节的流程,方法及范围起到有效的监督作用。主要包括:

  评审指标:这项指标会通过判定相关人员是否评审了产品构架方案、设计方案、测试架构、测试方案、测试案例及程序源代码来进行质量把关。它会对每项评审列出详细评审方法。评审指标非常重要,通过专家一起评审,能够有效杜绝严重设计错误和测试漏洞。

  测试指标:这项指标会通过判定测试是否包括功能测试、全球化测试、性能测试、系统测试及回归测试来进行质量把关。

  指标还包括缺陷发现计划进度和实际进度的比较,误差越小越好,最好小于某指定百分比(例如10%),说明测试计划和实际相吻合,产品质量危险系数小。否则需要进行误差分析,看是否存有潜在的问题。

  如图9-1所示,实际和计划进度误差在上下10%之内。可以说测试基本是按计划进行的,没有太多出入。后期缺陷发现率显著下降最后趋于零,说明产品已趋于稳定,可以交付使用。

  测试指标还包括各测试类别测试案例尝试执行和测试案例成功完成的百分比。在产品质量检测报告里需要明确指出在测试计划里是否所有测试案例都能100%尝试执行,也需要明确预期在交付产品时各测试类别能最终成功完成多少测试案例。


  一般情况下,如果交付产品时缺陷修复在95%以上,所有测试案例成功率在95%以上,可以认为产品质量是有保障的,存在问题的风险系数比较低。如果交付产品时各测试类别达不到90%的测试案例成功率,这个产品的质量就会有较大隐患,以后出问题的风险比较高。

  项目退出指标:在这项指标里会要求在交付产品里,所允诺的功能都完成了开发和测试。如果是升级版本,还会要求没有回归问题产生,即老版本中的功能在新版本中依然正常工作。

  延缓缺陷指标:我们在前面提到过(请参考9.2.2节),出于时间和安全性考虑,某些缺陷修复需要推延到以后的产品新版本包括补丁版本、小版本或产品下一升级版本。在延缓缺陷指标里一般会要求交付产品时,这些延缓修复缺陷不能超过总体发现缺陷的一定百分比(例如10%),从而对产品所知缺陷率有总体控制,保证产品质量。在这项指标里一般也会硬性规定不能延缓修复任何严重缺陷。

  源代码分析指标:这项指标会评测源代码是否利用一些工具进行了静态代码分析、架构分析、代码测试覆盖度分析,用于从侧面判定产品质量是否有保障。

  质量检测计划报告通过审批后,所列项目特征和指标就不能随便改了。如需改动,需要重新审批。

  在项目测试完成后,需要把最终结果填写到报告中通过最终审批,拿到质量检测合格证书,才能交付产品。最终审批主要是看以下几个方面:

  项目最终是否和计划的项目特征相符,是否按照计划进行开发流程。

  产品用户体验的指标诸如可用性、可靠性、安全性、集成性、可维护性等方面是否达到要求。

  所定性能指标是否能达到计划的标准。

  产品试用版本的客户满意度调查结果是否达到交付标准。

  是否按照计划评审了产品构架方案、设计方案、测试架构、测试方案、测试案例及程序源代码。

  缺陷发现计划进度和实际进度误差是否小于指定百分比(例如10%)。

  各测试类别测试案例是否100%尝试执行,测试案例成功率是否能达到指定百分比(例如95%)。

  所允诺的功能是否都完成了开发和测试。如果是升级版本,是否没有回归问题产生。

  延缓修复缺陷是否小于总体发现缺陷的指定百分比(例如10%),而且无严重缺陷延缓修复。

  9.3.3  趁热打铁总结经验教训

  产品顺利交付了,各个团队都在组织讨论和总结经验教训。项目经理也发出产品调查表让大家填写,希望大家在评定产品质量如何的同时,进一步总结在开发和测试过程中好的经验和需要改进的方面,鼓励大家提出如何改进的建议以便在将来的项目中进行改善,从而使产品质量得到持续的提高。

  产品调查表包括下列几个问题。

  请选择你在项目中的角色:

  (1)产品架构师

  (2)产品开发人员


  (3)文档开发人员

  (4)测试人员

  (5)其他

  请评估项目产品质量如何:(分为1级到5级,其中1级为最差,5级为最好)

  ( )5   ( )4   ( )3   ( )2   ( )1

  请列举项目中你认为产品质量最好的部分:

  请列举项目中你认为需要提高的部分:

  请列举项目中你认为应该在将来的项目中继续执行的最重要的经验(包括影响力,相关团队,以及如何在将来的项目中执行):

  请列举项目中你认为应该在将来的项目中改进的最重要的部分(包括影响力,相关团队,潜在的问题或者原因,改进的建议):

  请列举你是否有其他的建议:

  小艾根据自己测试的部分填写了自己对产品不同功能的意见和建议。并认真回顾了一下在整个项目中的所有测试历程,给团队和项目组提出了如下反馈:

  应该在将来的项目中继续执行的最重要的经验:

  (1)各团队之间总体有很好的沟通,有问题能够很快找到相关人员解决。

  (2)测试计划和实际基本相符,开发及测试都能按计划时间完成。

  (3)各测试类型团队之间没有壁垒,能够很快互相调动人力物力互相支持,以保障测试整体顺利按期完成。比如,功能测试人员帮助安装测试等。

  应该在将来的项目中改进的最重要的部分:

  产品功能上存在设计变动时,开发团队需要和测试团队提前沟通。测试团队需要根据新的设计来变动或添加测试案例。否则,测试团队会根据老的设计而开出无效缺陷,不但浪费了测试人员和开发人员的时间,还容易产生测试漏洞。

  在产品测试阶段,任何人有需要安装产品时,也一定要严格按照安装文档来安装,如果发现文档里步骤不正确,要报告问题并要求相关团队修改文档。因为安装测试需要涵盖的范围太广,安装测试团队不可能涵盖所有情况。其他人可在力所能及的情况下,帮助安装团队发现问题。

  项目组在收集到所有反馈后,会召开会议和各团队代表一起逐条讨论。对于有效反馈需要相关团队制定改进计划以便在今后的项目里实施。这些反馈里,既包括开发和测试流程的改进建议,也有对产品设计和所用开发及测试工具的改进建议。总之,给大家一个平台可以让所有人畅所欲言,总结经验教训,并以此作为参考来更好地完善今后的项目计划和实施。

  (未完待续)

相关链接:

一个软件测试工程师的成长日记(连载一)

一个软件测试工程师的成长日记(连载二)

一个软件测试工程师的成长日记(连载三)

一个软件测试工程师的成长日记(连载四)

一个软件测试工程师的成长日记(连载五)


鲜花

握手

雷人

路过

鸡蛋

扫一扫关注最新动态

毒镜头:老镜头、摄影器材资料库、老镜头样片、摄影
爱评测 aipingce.com  
返回顶部