9.3.4 贯穿始终的缺陷分析
小艾完成调查表后，就去找凯文看是否有下一步任务。看到凯文正在画花花绿绿的表格，他就很好奇地问："这是什么？"
凯文抬起头说："我正在做项目最终缺陷分析，你来得正是时候，我正想给你详细介绍一下缺陷分析，好让你做个帮手。"
在凯文图文并茂地认真讲解下，小艾对缺陷分析有了深刻的了解。
在整个项目测试过程中，会不间断地做一些缺陷分析，来帮助监控在开发和测试中是否存在问题和漏洞，并根据分析结果来调整测试范围和策略。在最终测试完成后，会系统做一次缺陷分析，并以此总结经验教训以便在今后的项目中做出改进。
不同测试类型会有不同的缺陷分析侧重点。比如安装测试和迁移测试，会专注于分析产品安装在不同操作系统及数据库上出现的问题，所以会专门分析不同操作系统，不同数据库上出现的缺陷，看是否这个问题只发生在特定系统或数据库上。
一般来讲，所有测试类型都会对以下方面进行分析。
1、有效缺陷和无效缺陷的比率
前面的章节中详细介绍了缺陷管理模型中的缺陷生命周期状态及相关信息。 简而言之，缺陷从被发现到最终解决存在下列典型状态：关闭状态，开启状态，工作状态，验证状态，退回状态，取消状态。
其中，在关闭状态和取消状态下的缺陷称为完结缺陷，除此之外状态的缺陷称为活跃缺陷。项目结束时，理论上所有缺陷都应处在关闭状态或取消状态。当然由于时间原因，还存在极少量开启状态下的缺陷被延缓到补丁版本或新版本里修复。我们把关闭状态缺陷和延缓缺陷称为有效缺陷。而把取消状态下的缺陷称为无效缺陷。在测试过程中，应尽量提高有效缺陷比率，避免开出无效缺陷。
如图9-2所示，测试过程共发现103个缺陷，其中有效缺陷85个，占总缺陷的83%，无效缺陷18个，占总缺陷的17%。一般来讲，有效缺陷在80%以上就算是比较良好的。
造成无效缺陷的原因大致有以下几点：
重复缺陷：是指在系统里相同原因的缺陷已经被其他人报告。在此缺陷被作为重复缺陷返回时，先不要立即取消。必须等到核查修复后，才在系统里取消。这是因为有些缺陷被误认为是重复缺陷，实际上是不同原因造成的问题。我们只有在核查修复代码后，才能确认这是否是无效缺陷。
用法错误：是指测试人员在测试过程中有一些操作错误或对功能的错误理解而造成测试案例失败，由此开出的缺陷是无效缺陷。
符合设计：是指测试人员在测试过程中主观上认为测试结果是有问题的，并开出缺陷。但实际上产品设计就是应该如此表现。如果测试人员也同意如此设计是有道理的，就应取消所开缺陷，并视之为无效缺陷。
产品局限性：是指所开缺陷由于产品本身设计框架等局限性而无法修复。这样的缺陷通过改动代码是无法修复的，一般来讲最好转变为修改文档，通过文档来告诉用户这些局限性。如果既不能修改代码又不能修改文档，那么只好取消缺陷，并视之为无效缺陷。
未来功能：是指所开缺陷实际上是要求产品增加新功能。如果新功能不能在当前版本里实现，就应记录在未来版本的新功能候选名单上，并取消此缺陷且视之为无效缺陷。
不可重现：是指所开缺陷无法在相同场景中重现。有时可能由于网络，机器等问题而使测试案例无法正常运行，但重新测试很多遍也无法重现当时的问题。这种情况会建议取消缺陷，一旦同样问题再次发生，就需重开缺陷。
一般应该对无效缺陷进行分析，找出导致无效缺陷比例高的原因并提出相应的改进计划。
如图9-3所示，在18个无效缺陷里，重复缺陷占比例最高，其次是用法错误。所以就要进一步了解造成重复缺陷比例高的原因并予以改进。例如，可通过一些方法来提高测试团队之间的沟通，来有效降低重复缺陷。但有些重复缺陷是很难避免的，尤其是那些显示不同错误信息，但造成问题的代码是相同的缺陷。这些缺陷在很多测试专家眼里可以认为是有效缺陷。
用法错误的无效缺陷，在测试过程中应该尽量避免。这就要求测试人员要对测试案例有正确的理解而避免不必要的用法错误。另一方面，有些用法错误的缺陷可以转换成提高实用性的有效缺陷。
例如，小艾在安装测试时安装失败，小艾认为是安装代码的问题而报告了这个缺陷。开发人员在经过调查后发现是小艾不小心输入了错误的数据库密码而导致安装失败，就认为是用法错误而返回缺陷。小艾咨询了安装测试负责人，安装负责人认为虽然是测试人员用法错误，但从使用性上来讲，客户会遇到相同问题，产品应该能够在客户输入错误密码时提示客户，并禁止进一步安装。最终，开发人员接受了安装负责人的建议并修改了代码。而小艾所开的缺陷也成为提高使用性的有效缺陷。
2、按严重性分析缺陷
缺陷按问题的严重程度分为以下几个等级。
一级严重：是指缺陷造成整个应用或功能不工作，从而导致产品不能交付。
二级严重：是指缺陷造成功能输出结果错误。
三级严重：是指缺陷造成功能没有按预期方式实现。
四级严重：是指功能上需要加强。
在测试过程中，一级和四级严重缺陷应占比例较少，二级和三级严重缺陷比例应该占大多数。这是因为大部分一级严重缺陷在开发过程的单元测试中应该被发现和解决，而不应该流入到测试流程。
如图9-4所示，一级严重缺陷占39%，二级严重缺陷占33%，三级严重缺陷占21%，四级严重缺陷占7%。在此图中，可以发现一级严重缺陷的比例偏高。需要分析一下为什么会出现这种状况，是否有些缺陷应该在开发过程的单元测试中发现。应该把分析结果反馈给相关开发人员，并共同完善单元测试的测试范围，尽量让一级严重缺陷在早期发现并修复。
3、按功能分析缺陷
我们一般会看不同功能上发现多少缺陷。有些功能逻辑比较复杂，涉及的方面较多。这种情况所发现缺陷比例就会稍大。有些功能较简单，和其他功能没有太大交集，所发现缺陷就会相应较少。
如图9-5所示，功能2所发现缺陷占总数的41%，而功能4仅为7%。这说明功能2的复杂度相对大些，可能有必要再重新看看测试范围并增加一些测试案例。
4、按修复时间分析缺陷
一般来讲，一级严重缺陷需要开发人员一天之内解决，二级严重缺陷需要两天之内解决，三级严重缺陷要在一周内解决，四级严重缺陷应在两周内解决。
所以大部分缺陷从开始报告到最终核对并确认修复的周期应在一周内。不同测试类型缺陷修复时间是会稍微有一些差别的。例如性能测试的缺陷和迁移测试的缺陷由于测试环境较为复杂，并且较难找出造成缺陷原因，所以这两个测试类型的缺陷完成周期会相应长一些。
图9-6和图9-7分别是安装测试缺陷修复时间和性能测试缺陷修复时间数据图，从图中可看出，性能测试缺陷修复在20天以上的明显增多。这是由性能问题的复杂性决定的。依照经验，解决一个复杂的性能问题，有时候需要一个月甚至两个月的时间。所以对缺陷修复时间的分析要根据不同测试类别去进行。不同测试类别的缺陷修复数据可以用来作为今后各测试团队做项目测试计划的参考数据，例如性能测试要计划出足够的时间来核查缺陷修复。
5、按所属类别分析缺陷
理想情况下，各测试团队在测试时只发现自己所测类型的缺陷。但现实情况是所有测试类型虽然测试有先后，但也存在很大程度的时间重迭。
例如，由于性能测试的环境和数据要求很复杂，性能测试的测试成本远远大于功能测试的测试成本。所以性能测试一般会在其所需要的主要功能测试基本完成的情况下开始。但主要功能测试基本完成，并不代表此功能不存在缺陷。另外，主要功能在测试成功后，也可能由于后来的某些相关代码改动而存在回归缺陷。这就造成性能测试中不可避免地发现功能方面的问题。
通过对性能测试团队所发现缺陷的分析，可以统计出功能测试缺陷所占比例，看是否功能测试缺陷比例过高，是否严重影响了性能测试的进度，从而分析在今后的测试过程中，哪些测试流程需要提高而尽量减少性能测试中的功能缺陷。例如增强和功能团队的沟通，尽量了解性能测试中，每个测试案例里所需主要功能的进展情况等。
另外，性能测试需要安装和客户相近的测试环境，所以也会不可避免地发现安装缺陷。它的测试环境的复杂度也会帮助安装团队扩大安装测试范围。
如图9-8所示，在性能测试中，功能缺陷占大约28%。这个比例稍微偏高，会对性能测试的进度有所影响。我们在分析过程中可以着重看看哪些功能缺陷是可以通过提高流程而避免的，并制定好相应计划，在今后测试中有所改进。
6、操作系统分析缺陷
如果是Java EE的应用程序，应该不会有太多操作系统相关的测试缺陷。但由于安装程序或多或少会和操作系统的设置文件有关，所以在测试中不可避免地会发现操作系统特定问题，例如某些缺陷只在Solaris上存在，在其他操作系统上没有问题。
通过缺陷分析，可以清晰地了解操作系统特定缺陷所占比例。如果比例不大，在测试中可以把大部分测试案例都放在机器资源相对充足、便宜且操作系统相对简单的环境里测试，以减少测试人员和机器资源的消耗。
如图9-9所示，安装测试中和操作系统无关的缺陷占88%，所以大部分测试案例可在一种操作系统上进行测试。但因为其他操作系统也存在特定缺陷，所以在所有其他操作系统上，也要安排一些测试案例。
7、按数据库分析缺陷
现在绝大部分软件产品会需要数据库来存储并提取数据。不同的数据库处理数据的方式会有所不同。如果一个产品同时支持多种数据库，就可能存在同样的测试案例，在一种数据库上工作正常、但在另外数据库上出现问题的情况。
在测试过程中要尽量覆盖所有支持的数据库。如果有些功能对数据库不敏感，就只需在某一数据库上集中测试，在其他数据库上做些小测试即可。如果功能对数据库极度敏感，就要考虑不同数据库都要有足够的测试范围。
按数据库分析缺陷，可以相应看到哪些功能对数据库敏感且特定缺陷多，就需要考虑是否在此功能上增加不同数据库的测试范围。
8、按可用性分析缺陷
在测试过程中，不但要测试产品功能是否正确，还要看产品是否好用，即通过用户的使用角度来评估产品。由于它反映了用户的真实使用经验，所以可以视为一种不可或缺的可用性检验过程，例如界面是否友好、是否提供在线帮助，用户在使用错误的情况下是否显示容易理解的异常信息等。测试团队应鼓励测试人员尽可能多地发现可用性缺陷来提高产品的质量，从而使用户有非常好的产品使用经历。
例如在安装产品过程中，如果操作系统不符合产品安装要求，就应该报出错误信息，并终止安装。如果测试过程中没有报错误信息，只是在安装中途失败，这就是一个可用性缺陷。在测试过程中，一定要从客户的角度来看问题。对于任何在使用时觉得不方便，不通用且容易造成用户困惑的功能，都要想想是否是可用性缺陷，是否应该进行修订而提高其易用性。
例如在网上商店注册时，会要求用户输入很多个人信息，例如姓名、年龄、职业、住址、家庭状况等。有些是必填项，有些是自愿填的。假设在输入信息时忘记填写必填的一项，在单击“完成”按钮时，如果系统只是提示你有未填项目，并要求你重填所有信息，这对于用户来讲是非常不能忍受的。这种情况就应该开出可用性缺陷。
可用性好的产品会这样处理：系统提示你有一项没填，并把未填项标志出来方便你继续填写。其他已填好信息依旧保存在页面上。这样既方便又快捷地帮客户解决了问题，从而使用户得到非常好的使用体验。
测试过程中可用性缺陷的多少能够在一定程度上衡量测试人员的专业性和产品质量的高低。一般产品可用性测试没有专门事先写好的测试案例，更多的是依靠测试人员的测试经验和对产品的熟悉程度。如果整个测试过程中，只有很少甚至没有可用性缺陷，就要好好分析一下原因，看是否是因为测试时间紧张，测试人员只是着重测试了产品的正确性，而忽略了产品使用性的测试。
9、按照其他指标分析缺陷
缺陷分析的指标多种多样，每个团队的侧重点存在一些差别。我们在前面列举了几种分析缺陷的主要方面，除此之外，还有许多指标可以用来做缺陷分析。
例如把缺陷的创始人作为指标来分析，可以看到哪些测试人员所发现的缺陷数量最多，有效性最高。一般来讲，同样的测试类型，有经验的测试人员平均比无经验的测试人员发现缺陷多且有效性高。缺陷的拥有者也可以作为指标来分析，从中可以看到哪些开发人员在整个项目中所修复的缺陷最多。
总之，缺陷分析是项目测试时和完成后都需要重视的一项任务。它既能帮助测试人员随时调整测试范围和侧重点以防患于未然，又能很好地帮助总结经验教训，以便于今后项目的提高和发展。
9.4 学习笔记--成品测试之小艾观
小艾通过成品测试及成品测试之后的经验总结学到了很多东西：
成品测试的一个主要目的是测试最终介质和包装有无缺陷，以保证客户拿到最终产品时能顺利安装并使用我们提供的光盘（CD或DVD）或网上下载的应用程序。成品测试另外一个测试目的是保证产品在前期缺陷修复过程中没有因为代码改动而产生新问题。
成品测试阶段有其独特的测试策略和灭虫方案：
在已存在的测试案例里挑5%～10%重要案例来重新测试以保障以前的代码改动没带来新的质量问题。所被挑选的回归测试案例尽量能够涵盖程序的主要功能，以确保程序的主框架没有由于前期代码改动而产生缺陷。
尽量不要在此阶段运行新的测试案例，用于保障成品测试能在合理时间内完成（一般为2～4周）并成功交付给客户或投放市场。
由于不同操作系统平台或数据库调用的安装程序和启动的包装有可能不同，所以在测试中各测试团队要协同作战，尽可能涵盖所有系统平台和数据库，以保障客户在不同系统上的正常应用。
所有测试都应基于DVD或DVD ISO文件安装的应用程序，严禁再用测试驱动来安装应用程序并进行测试。
由于成品测试是测试的最后一个环节，且周期很短，因此就要求代码改动要特别慎重，以防引起回归问题。成品测试阶段项目组一般要每天审核所发现缺陷并做缺陷综合分析，根据分析结果制定相应灭虫策略，有些缺陷可延缓到以后修复。对于要修复的缺陷，必须要有足够的回归测试，以保证代码改动没带来新的质量问题。
成品测试之后，需要把最终结果填写到质量检测报告中并通过最终审批，产品才能最终交付客户。质量检测报告是项目中需要完成并得到审批的一个重要文件，其中包括下面几个方面：
项目特征；
产品用户体验；
性能指标；
产品试用版本计划；
质量预见性指标，包括评审指标、测试指标、项目退出指标、延缓缺陷指标、源代码分析指标。
在产品交付后，需要对项目做经验总结，同时各测试团队要对所有缺陷做最终缺陷分析，以此总结经验教训，以便在今后的项目中做出改进。不同测试类型会有不同的缺陷分析侧重点。一般包括缺陷有效性分析、缺陷严重性分析、不同功能上发现的缺陷分析、按修复时间分析、按缺陷类别分析、按操作系统或数据库分析、按可用性分析等。
缺陷分析应该贯穿整个项目测试过程，而不仅仅是在测试完成后。通过不断进行缺陷分析，来监控在开发和测试中是否存在问题和漏洞，并根据分析结果来调整测试范围和策略，防患于未然。
（连载完）
相关链接：
一个软件测试工程师的成长日记（连载一）
一个软件测试工程师的成长日记（连载二）
一个软件测试工程师的成长日记（连载三）
一个软件测试工程师的成长日记（连载四）
一个软件测试工程师的成长日记（连载五）
一个软件测试工程师的成长日记（连载六）