1. 引言：缺陷分析现状

目前我们测试人员是如何利用缺陷的呢？

多数中小型企业对于缺陷的控制和管理处于一种混乱的状态，对测试前期的设计和后期的缺陷数据统计分析的重视程度严重不足。

一种典型的情况就是测试人员在将 bug 提交后，仅做 bug 的修复验证，而没有进一步的工作。
也有一些公司的测试人员，会在测试报告中对 bug 做一些数据统计，以此评估当前软件的质量状况，并作为判定软件是否能发布或交付的依据。可能会再提一提由 bug 所反映出来的问题，但也止步于此，没有进一步的工作。
只有极少数的公司会做一些 bug 的分析工作，通过 bug 分析来改进产品质量、优化研发流程和项目管理方式。很多时候项目开发周期难以控制，原因之一就是缺乏缺陷数据的统计与分析，及缺陷的预防机制。

现在市场上有很多缺陷管理系工具，不过这些缺陷管理工具在特性上基本上都大同小异，对于缺陷的分类方法没有一个统一的标准，并且在缺陷分析方面普遍比较薄弱，通常只是提供一些缺陷数量的简单统计功能，用户不得不借助一些其它的统计分析软件或自行开发缺陷分析工具来进行缺陷数据的分析。

2. 什么是缺陷分析？

讨论这个问题，首先要明确什么是缺陷？

通常意义上的缺陷：程序中存在的错误，俗称 bug。
广义上的缺陷：项目计划、需求规格说明书、设计文档、测试用例、用户手册等存在的错误或问题。可以说在软件工程整个生命周期中，任何导致无法满足用户所要求的的功能活导致系统失败的问题都都属于缺陷的范畴。

再说说什么是缺陷分析？

通常意义上的缺陷分析：包含两个阶段，一是发现 bug 后进行 bug 定位和排查原因的活动；二是系统测试结束前后对软件开发各个阶段产生的缺陷进行分类、分析和汇总统计、改进缺陷度量和分析的模型、编写分析报告的活动。这个活动中可能会伴随着其他活动，比如输出缺陷预防的方案。毕竟我们做分析的最终目的是为了提高产品质量和优化项目管理流程。
广义上的缺陷分析：对应“广义缺陷”的定义，对项目开发的整个生命周期中出现的各类问题（不局限于 bug）进行分类和分析，进而改进项目管理流程的活动。

3. 为什么要做缺陷分析？

广义上的缺陷分析比较复杂，本文只讨论通常意义上的缺陷分析。

发现 bug 后进行缺陷分析可以帮助我们：

排查是否有遗漏的同类缺陷：比如我们发现某个 bug 产生的根源是因为开发修改了某个接口，我们会推测其他调用该接口的模块可能也存在风险。这种情况我们就可以更好的保障测试范围没有遗漏。
验证代码逻辑的合理性：开发人员水平参差不齐，对于同一个功能可能有多种实现方式，年轻的程序员非常可能选择较差的实现方式，他们的修复可能不但更复杂，也可能会引入新的 bug。而有经验的测试员可以指导程序员更简单高效的方式。这个过程中的分析经历，无论是对测试员还是程序员都是一种经验的积累。
有助于确定开发人员是否真正修复了 bug：如果不了解 bug 产生的原因，很多时候测试人员无法确定 bug 是否被正确修复。比如有 N 种情况都可能导致 bug 的出现，但程序员只修复了其中一种情况；有时候对于一些偶发性的 bug，如果不清楚原因，就很可能无法设计出正确的测试方式，进而导致不能保证 bug 被真正修复（这种情况中，程序员没有提交本地的修复代码到主干，测试人员可能都不清楚）。
改善缺陷分类：通过缺陷分析结果的反馈，改进缺陷度量分类标准和分析目标，提高缺陷分析结果的准确性。
有助于项目结束后的分析：出现 bug 时不做分析，项目结束后想做分析可能都做不到了。

系统测试结束前后的缺陷分析可能帮助我们：

确定当前产品的质量状况。
指导后期工作重点，明确产品上线前回归测试以及上线后重点关注的模块：比如上线前一般需要再重点测试缺陷集中的区域。
明确缺陷发展趋势，确定是否可以结束测试：我们都知道 bug 是找不完的，缺陷发展趋势是作为判断是否可以结束测试的重要标志。如果发现趋势不正常，那缺陷分析可以帮助我们制定出遏制缺陷发生的措施、降低缺陷数量。
发现测试员工作技能上的不足，提升人员能力。测试经理经常需要通过测试员提交的 bug，来分析每个测试员存在的弱项，从而判断产品测试的质量，以及制定测试员的培训方案。
提升开发和测试人员的素质以及责任心。
改进测试流程，优化测试方式。有经验的测试经理对于一个项目可能出现的 bug 总数量，对于每个模块可能隐藏的 bug 数量，以及每天测试人员应该发现的 bug 数量会有一个估计。如果实际情况偏离了预估，测试经理需要做的其中一项工作就是考虑是否目前的测试流程和测试方式存在不足。
改善项目管理流程。质量是生产出来的，不是检验出来的。软件产品的生产过程决定了所开发出的软件的质量，提高软件质量是软件生产过程中各项活动的共同目标。可以通过 bug 中反映出来的问题，优化项目管理过程，促进对软件生产过程的质量控制与管理。
预防缺陷发生。目前多数测试人员都是在项目送测后进行检测，这是一种“事后检测”行为，我们希望找到一些方式来“事前控制”，来提高开发和测试效率，保证项目成功率。时间成本是衡量项目成功的一个重要因素，而项目无法如期交付的原因之一就是花费过多的时间在修改 bug 上，做好缺陷预防，可以在很大程度上缩短项目周期。
CMMI4 认证的需要，或者改善组织的软件能力成熟度。认证 CMMI4 要求在项目中定量管理，建立组织级过程性能，构成完整的量化管理，采用统计或其它定量方法管理软件过程，并通过对过程中出现的方法，技术等问题进行因果分析和寻找解决方案。

4. 开展缺陷分析工作的难点

缺陷产生原因复杂：运行环境（操作系统、数据库等）、第三方工具或软件、网络、用户操作习惯等都可能导致缺陷的产生，这会直接导致定位缺陷原因成本的上升。
公司或项目团队的不支持：有时候是不帮助测试人员做 bug 分析工作；有时候是制定了 bug 预防方案却因为公司或团队的不支持而难以推进。
程序员的不配合：比如我们希望程序员在 bug 修复时顺便备注 bug 的根源和修复方式，这个要求很可能导致程序员的抵触。
测试人员不懂如何分析。
团队人员没有质量管理的意识。
缺陷分析工作完成后，后续工作难以落地。
其他。

5. 谁来做缺陷分析？

开发团队中的所有干系人，以测试人员为主导，最重要是需要高层领导支持。

6. 什么时候进行缺陷分析？

前文有提到，发现 bug 时和测试结束前后都需要进行 bug 分析。另外，可以在开发过程中做一些阶段性的 bug 分析，也可以在测试阶段每天都做一次 bug 分析。

最好让团队同意使用 bug 管理工具来管理 bug，否则会大大增加这项工作的难度（很多中小型企业仍然用 word 来管理 bug）。

7. 对哪些 bug 进行分析？

在前文提到，软件缺陷的范围很广，不仅仅指在测试过程中发现的缺陷，而是指在整个软件生命周期中发现的所有缺陷。但是否所有的缺陷都需要分析呢？显然不是。

做分析之前首先要明确我们的目的，目的的不同也决定了分析内容的不同。

比如有的团队，可能只需要对上线后发现的漏测 bug 进行分析；有的团队需要对上线后暴露的 bug 以及测试阶段发现的典型 bug 进行分析。

总之，需要根据团队需要进行确定。

8. 如何进行缺陷分析？

如何进行缺陷分析，前提还是要想清楚自己做缺陷分析的目的是什么，有了方向，再考虑如何开展后续工作。

比如产品上线后质量较差，频繁出现线上 bug。那我们可以联合其他部门针对线上 bug 进行分析，排查每一个线上 bug 产生的原因，确定是否是测试人员漏测导致，如果是，那我们再分析一下之前是怎么测试的（需要保留之前的测试记录），当时为什么没有测试出来，以后怎么改进工作。这项工作需要长期进行，才能真正提高测试人员的“bug检出率”。
比如我们希望做一做 bug 预防的工作。不过这项工作的难点在于执行和落地。换句话说，当我们已经得到了 bug 根源和预防措施后，后续怎么让工作落地？
比如感觉目前的软件开发过程混乱，也可以通过缺陷分析来进行优化。例如通过优化缺陷分类方式、增减缺陷属性等，再根据缺陷的统计属性来确定软件开发的哪个环境问题较多；通过缺陷流转中出现的问题来优化缺陷管理流程等。

可以读一读《探索式测试》这本书，了解更多的缺陷分析方式。

缺陷描述属性是指：缺陷信息描述、缺陷处理时间、缺陷引入原因分析、缺陷处理结果、缺陷调查分析等。

缺陷统计属性是指：缺陷生命周期状态、缺陷流出的开发阶段、缺陷流出的部门、缺陷流出的功能模块、缺陷表现类型、缺陷的严重等级等基于缺陷数量统计其分布的属性。

缺陷控制属性是指：处理缺陷的角色、缺陷的分配、处理缺陷的时间、缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。

缺陷分析