9.2 黎明前的黑暗--漏网之虫
坐在实验室的机器前，小艾用DVD光碟按照安装指示文档安装好产品，就开始运行所分配的功能测试案例。因为所分配给的测试案例都是小艾在测试第一和第二阶段运行过的案例，小艾感觉执行起来轻车熟路。一上午就完成了快一半，小艾暗暗松口气，为自己的进度感到高兴。
9.2.1 老案例生新虫子
中午吃过饭之后，小艾又急忙回到实验室运行测试案例。接近下午3点时，小艾在运行一个案例时发现了一个较严重的问题。小艾记得自己两周前在功能测试第二阶段运行过这个案例，当时没有发现任何问题。小艾怕自己记错，赶忙到数据库里查了一下这个测试案例运行的历史，发现最后一次成功运行的确是在两周前。
小艾于是怀疑最近两周这个功能有新的代码改动，为了进一步确定，他就又查了一下和这个功能有关的最近两周的缺陷修改历史，发现一周前开发团队的姚圳曾由于修复和这个功能有关的性能缺陷而修改过相关代码。由此，小艾基本肯定他新发现的功能问题是由于最近的代码改动引起的。于是他在代码管理系统里开了一个缺陷记录，标明是回归问题，并把自己的一些初步调查结果也注明在记录里，以方便开发人员参考。
考虑到问题比较严重，时间又很紧迫，小艾立即给姚圳打了个电话，把情况说了一下，并告诉姚圳可以参考他所开的缺陷记录来得到案例步骤及错误信息等详细情况。
姚圳听后说：“好的，谢谢你及时通知我，我会立即看一下。这个问题听起来很严重，而且对客户影响很大，需要马上解决。我会争取今天找到问题原因和解决办法。不知你明天能否早一点到公司，我需要你帮忙试一下代码补丁。由于现在是成品测试阶段，项目组要求所有正式源代码改动都需要事先在测试环境里通过案例测试和相关回归案例测试，测试完成后才能得到项目经理授权集成到下一个成品测试候选驱动里。”
第二天早晨小艾早早来到办公室，就看到姚圳发来的电子邮件。从电子邮件时间上看，姚圳一定为这个问题忙到了半夜。小艾不敢耽误，马上开始安装补丁并进行相应案例测试。为了保险起见，小艾又把和这个功能有关的一些主要案例运行了一遍，以防止又产生新的回归问题。
接近中午时，小艾终于顺利完成了补丁测试，他于是兴冲冲地跑去通知了姚圳。
姚圳松了一口气，笑着对小艾说：“太好了，我们在昨天下午4点的成品测试缺陷评判例会上已讨论过你发现的这个问题及它对客户的影响，项目组让我们两天内尽快解决这个缺陷。这下好了，我们提前一天完成了任务。我会参加今天下午4点的成品测试缺陷评判例会并汇报一下最新情况。如果不出意外，这个问题的源代码改动应集成在明天的成品测试候选驱动里。”
小艾很不好意思地说：“呵呵，我可知道你昨天为了解决这个问题熬到快半夜1点，你才是劳苦功高呢。姚圳，你是公司的老员工，参加了好多项目开发工作。你能告诉我成品测试缺陷评判例会主要有哪些内容吗？”
姚圳拍了拍小艾的肩膀说：“你可问对人了！ 我参加了好多次这样的例会，的确有一些了解。这个例会主要用来及时分析所发现的缺陷并根据缺陷影响给出解决方案。一般项目经理都会要求各开发团队代表、各测试团队代表、客户支持代表甚至产品补丁版本项目经理一起参加。在会上项目经理通过听取各方意见来决定缺陷的最终解决方案。”
小艾很疑惑地问道：“难道我们不应该通过及时修订代码，在把产品交付客户之前灭掉所有发现的虫子吗？”
姚圳回答道：“你说的是理想情况。实际来讲，成品测试阶段时间有限，所有测试都已基本接近尾声。如果这时改动大量代码，又没有足够时间进行必要回归测试，就很容易造成回归缺陷不被发现。这样反而会给客户造成更大损失。所以成品测试阶段有和测试前期阶段不同的灭虫策略。我们一般需要在此期间对发现的虫子进行综合分析，并根据对客户的影响和其紧迫性提出相应解决方案。”
小艾很期盼地问道：“根据这么多年的经验，你能告诉我一般都对虫子做哪些分析，相应地都有哪些解决方案吗？”
9.2.2 艰难抉择--漏网之虫综合分析及灭虫策略
在中午吃饭时间里，姚圳给小艾详细解说了成品测试阶段缺陷综合分析及相应灭虫策略。
缺陷综合分析要点：
缺陷是如何发现的。如果不是回归问题，为什么在测试前期没有发现，是否存在其他潜在的测试漏洞。
通过对虫子漏网原因的分析，能够更清晰地明白是否存在严重测试漏洞。修复此缺陷后是否需要增加回归测试范围以防再出现同样功能的回归问题。
有几种方法可以解决缺陷，每种方法的优缺点及客户接受程度。
例如某些缺陷是可通过多种方法解决的，但每种方法对代码架构的影响、对测试成本的影响和对客户的影响都不尽相同。需要平衡时间、成本及客户接受程度等要素来决定此时最佳解决方案。
缺陷修改对当前代码架构的影响，会影响到哪些测试团队。
例如有些代码改动可能需要功能测试团队，性能测试团队和安装测试团队重新运行一些测试案例。
受影响的测试团队需要多少时间和人力来完成由于代码修改而必须运行的测试案例包括回归测试案例。
通过测试成本计算，能够清晰地知道是否能有足够时间和人力在产品交付时间之前完成缺陷修复。
如果此缺陷不在当前版本里修改，会对客户和客户技术支持团队造成什么影响。
客户影响是非常重要的一个要素。有些缺陷被叫做“禁止交付”缺陷，顾名思义就是如果产品存在这些缺陷，则产品不能交付给客户。因此所有“禁止交付”缺陷一定要在产品交付前有解决方案。
另外，客户技术支持团队需要衡量一下，如果某缺陷不在当前版本修复，在当前产品版本推向市场后如果客户遇到相同问题，客户技术支持团队会需要额外付出多少人力资源来和客户沟通并解决客户问题。
客户对此产品缺陷的最大容忍时间大约多久。
通过分析客户对修复此缺陷的紧迫性来决定是在当前产品版本修复还是将缺陷修复推延到以后的产品新版本包括补丁版本、小版本或产品下一升级版本。
根据缺陷分析结果，一般会有以下解决方案：
在当前产品版本里修改缺陷，并按时交付客户。
例如：某些缺陷对客户影响大且缺陷修改对代码构架影响较小，测试团队能按期完成测试任务。
在成品测试阶段，所有缺陷修改必须经过项目经理同意并通过案例测试和回归测试后才能集成到下一个成品测试候选驱动上。
在当前产品版本里不修订缺陷，尽快在产品补丁版本或小版本里修改缺陷，并尽快交付客户。
例如一些产品功能客户在产品上线初期不会用到，和此功能有关的一些缺陷可以在随后发布的补丁版本里修复。
在当前产品版本里不修复缺陷，在下一个产品升级版本里修改缺陷。
例如有些缺陷对客户业务影响不是很大，只是在应用上需要一些改进而使客户应用起来更方便，对于此类缺陷，如果是在测试前期当然是尽可能修复。但在测试后期，尤其是成品测试阶段，就尽量不要因为此类缺陷改代码而引起不必要的回归问题。
在当前产品版本里修改缺陷，但需要推迟交付客户。
这种情况很少见。原因可能是前期测试存在重大漏洞，而存在的缺陷是客户不能接受的，但产品开发团队又无法在原定交付时间完成缺陷修复和相关测试。当然这种情况是每个产品项目都要想方设法避免的。
注意：如果缺陷修复需要推延到以后的产品新版本包括补丁版本、小版本或产品下一升级版本，除了需要得到开发团队、测试团队和项目经理的同意外，还需要得到客户技术支持团队的同意和支持，以便客户遇到相同问题时，可以和客户沟通。如果对此问题有临时解决方案，也需要第一时间通知客户支持团队以便在客户需要时提供给客户。
小艾在姚圳的详尽介绍中受益匪浅，他开始考虑或许这些缺陷综合分析方法不只在成品测试阶段需要，也可借鉴到整个测试阶段，尤其是测试后期。
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）各测试类型团队之间没有壁垒，能够很快互相调动人力物力互相支持，以保障测试整体顺利按期完成。比如，功能测试人员帮助安装测试等。
应该在将来的项目中改进的最重要的部分：
产品功能上存在设计变动时，开发团队需要和测试团队提前沟通。测试团队需要根据新的设计来变动或添加测试案例。否则，测试团队会根据老的设计而开出无效缺陷，不但浪费了测试人员和开发人员的时间，还容易产生测试漏洞。
在产品测试阶段，任何人有需要安装产品时，也一定要严格按照安装文档来安装，如果发现文档里步骤不正确，要报告问题并要求相关团队修改文档。因为安装测试需要涵盖的范围太广，安装测试团队不可能涵盖所有情况。其他人可在力所能及的情况下，帮助安装团队发现问题。
项目组在收集到所有反馈后，会召开会议和各团队代表一起逐条讨论。对于有效反馈需要相关团队制定改进计划以便在今后的项目里实施。这些反馈里，既包括开发和测试流程的改进建议，也有对产品设计和所用开发及测试工具的改进建议。总之，给大家一个平台可以让所有人畅所欲言，总结经验教训，并以此作为参考来更好地完善今后的项目计划和实施。
（未完待续）
相关链接：
一个软件测试工程师的成长日记（连载一）
一个软件测试工程师的成长日记（连载二）
一个软件测试工程师的成长日记（连载三）
一个软件测试工程师的成长日记（连载四）
一个软件测试工程师的成长日记（连载五）