文档介绍：测试缺陷分析
摘要：
测试活动作为IT项目和产品开发一个重要的环节，通过发现产品或组件的缺陷，并反馈给开发组修复验证这些缺陷，从而在一定程度上保证了外发产品的质量。对这些测试活动发现的缺陷进行深入的分析，可以有助于我们进行质量预测、以对相似的项目的缺陷阶段分布进行度量，形成该类型项目的缺陷分布的过程模型。它给予我们的信息是：只要是这种类型的项目，按照相似的过程方法进行研发，那么其质量表现也是相似的。
我们之所以作这样的假设，是有一个前提，就是我们研发过程是高度一致的，并且过程的表现也是稳定的。这样，我们得出的过程能力模型才具有可信度。
下面是一个如何运用测试分布模型进行质量预测的例子：
如果需求阶段发现了 10个缺陷，就可以预计到设计阶段我大概要清除 70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约 2个故障泄露到用户手中。
这种分析预测模型的建立，要求组织的测试/评审过程比较稳定。即组织整体达到 CMMI 三级成熟度，同时在VAL和VER （验证和确认）过程域的达到CMMI四级的成熟度级别，即量化管理级别。
•利用泄漏的下游缺陷回溯过程有效性
经验告诉我们，越到后端发现的缺陷，用于问题复现、问题定位和 bug 修复的时间就越多。那么我们是不是可以在项目研发的更前端发现这些缺陷呢？有什么方式让我们识别项目研发前端哪些活动没有充分投入、或者没有运用合适的工程/技术方法导致这些问题被泄露到下游呢？
其实，我们有很简便的方法可以达到这个目的。从团队的典型项目中运用一定的抽样原则抽样出某个阶段的若干个缺陷，从技术、流程、工程方法、费效比方面去分析其更适合、更经济的清除方法。然后把这些方法固化到我们日常的项目实施过程中，逐步就可以降低上游对后端的缺陷泄露。
下面以对一个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：
实际发现活动
最隹发现活动
计数
百分比
系统测试
代码评审
2
14%'r 、、
集成测试 1
50%
:设计评审
,4：.
29%.
系统测试
1
7%
从上表可以看出，真正需要遗留到系统测试阶段才能发现的故障只有 7%，大部分故障应该在集成测试和设计评审过程中就应该发现的。
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
2 、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；
这样，针对这些分析结论，我们就可以制定针对性的整改措施。如：
加强开发部的故障波及分析及波及分析验证工作；
项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
利用缺陷分类来进行缺陷的根源分析
对于测试出来的 BUG 进行缺陷分类，按照 BUG 的类型分布，找出那些关键的缺陷类型进一步分析其产生的根源，从而针对性的制定改进措施。
下面以一个项目的系统测试故障为例进行分析：