摘要：
测试活动作为IT项目和产品开发一个重要的环节，通过发现产品或组件的缺陷，并反馈给开发组修复验证这些缺陷，从而在一定程度上保证了外发产品的质量。对这些测试活动发现的缺陷进行深入的分析，可以有助于我们进行质量预测、进行过程改进、量化的衡量产品质量。
关键词：
测试分析、过程改进、质量预测、过程能力、缺陷
正文：
项目研发过程中，我们通过单元测试、集成测试、系统测试发现了大量的缺陷。我们把这些Bug输入到Excel或者其他测试管理系统中，跟踪其解决。一旦Bug fix完成后，大多数情况下我们就把这份bug list束之高阁，偶尔能想到的用途就是拿出来衡量测试组的绩效，或者用来评估开发组的质量表现。
一般来说质量分析有以下几中情况
缺陷有发现阶段和引入阶段两个重要指标，发现阶段和引入阶段可以是软件生命周期的各个阶段，根据这两个阶段可以绘制出一个矩阵，从而分析出软件开发各个环节的开展质量，找到最需要改进的环节。
开始例子分析之前先解释一下缺陷引入-发现矩阵的一些概念。
矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动引入的缺陷泄露到后续各环节的缺陷数。
缺陷移除率定义为：缺陷移除率=(本阶段发现的缺陷数/本阶段引入的缺陷数)*100%。如需求阶段一共引入了15个缺陷，需求评审时候只发现了2个，设计过程中发现了10个，编码和单元测试阶段发现了两个，还有一个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率=2/15*100%=13%。它反映的是该活动阶段的缺陷清除能力。
反过来还有一个概念，缺陷泄露率，就是有多少本阶段引入的缺陷没有在本阶段发现而是被泄露到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%。显然，它等于[1-缺陷移除率]。它反映的是本阶段质量控制措施落实的成效。
下面是一个分析例子：
从上表可以看到，编码过程的缺陷大部分依赖系统测试发现。单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。详细见“四、利用泄漏的下游缺陷回溯过程有效性”
另外，我们看到，需求阶段引入的缺陷绝大部分是在设计阶段发现的。这可能是我们大部分项目的一个现实，需求不稳定、需求不明确，很多东西需要在设计过程中才能明确下来。也许从这个分析结果中给我们一个启示，我们在设计评审时候，也需要重新审视我们的需求规格说明书，必要时候利用需求追踪矩阵这样的规矩方法来辅助我们发现上游需求的缺陷。把这样的机制固化起来，作为我们标准研发过程的一个要素或者过程指导书。
当然，实际规划“缺陷引入-发现矩阵”时，可以依据自己的管理要求，对缺陷的发现活动和引入阶段进行细分或初分，并且在Bug系统中提交时，需要准确的填写这些属性字段。
可以选某个阶段的测试缺陷进行分析，按照这些缺陷对应的产品组成部分来汇总这些数据。利用这样的分布，可以找出我们产品/项目的高危模块来。这些模块导致了我们产品的主要缺陷。主要用到的分析手段是数据透视表和柏拉图。让我们看看下面的例子：
这是一个简单的OA系统，它只有5个子系统。我们把这些子系统各有多少缺陷列出来，找到了改善质量的关键模块是后台交易模块。
像上图，这是一个较为复杂的MIS系统，有近20个功能块。这个时候，可以利用柏拉图识别出占80%问题的那少数模块，针对其采取强于其它产品组成部分的质量控制措施。
需要指出的是：采用缺陷分布只是分析的第一步。它只不过提供了你分析影响产品质量的那些重点模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进行进一步的分析，识别缺陷的产生根源。
当然，也有人认为绝对数去衡量缺陷的分布并不合适，所以有些人也会把缺陷按照严重程度对应一定的权重系数折算成分析意义上的标准故障。如上表，折算系数为，严重*10，关键*5，一般*3，次要*1，优化*0。
这种分析需要我们的bug系统建立产品组件的概念，使得缺陷填报人能够正确的填报每个缺陷的产品组件位置。
假设我们为bug管理系统建立了“一、利用缺陷引入-发现矩阵分析”中描述的缺陷引入-缺陷发现阶段信息，那么我们可以对相似的项目的缺陷阶段分布进行度量，形成该类型项目的缺陷分布的过程模型。它给予我们的信息是：只要是这种类型的项目，按照相似的过程方法进行研发，那么其质量表现也是相似的。
我们之所以作这样的假设，是有一个前提，就是我们研发过程是高度一致的，并且过程的表现也是稳定的。这样，我们得出的过程能力模型才具有可信度。
下面是一个如何运用测试分布模型进行质量预测的例子：
如果需求阶段发现了10个缺陷，就可以预计到设计阶段我大概要清除70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约2个故障泄露到用户手中。
这种分析预测模型的建立，要求组织的测试/评审过程比较稳定。即组织整体达到CMMI三级**度，同时在VAL和VER（验证和确认）过程域的达到CMMI四级的**度级别，即量化管理级别。
经验告诉我们，越到后端发现的缺陷，用于问题复现、问题定位和bug修复的时间就越多。那么我们是不是可以在项目研发的更前端发现这些缺陷呢？有什么方式让我们识别项目研发前端哪些活动没有充分投入、或者没有运用合适的工程/技术方法导致这些问题被泄露到下游呢？
其实，我们有很简便的方法可以达到这个目的。从团队的典型项目中运用一定的抽样原则抽样出某个阶段的若干个缺陷，从技术、流程、工程方法、费效比方面去分析其更适合、更经济的清除方法。然后把这些方法固化到我们日常的项目实施过程中，逐步就可以降低上游对后端的缺陷泄露。
下面以对一个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：
从上表可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障应该在集成测试和设计评审过程中就应该发现的。
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
2、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；
这样，针对这些分析结论，我们就可以制定针对性的整改措施。如：
- 加强开发部的故障波及分析及波及分析验证工作；
- 项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
- 每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
- 利用缺陷分类来进行缺陷的根源分析
对于测试出来的BUG进行缺陷分类，按照BUG的类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。
下面以一个项目的系统测试故障为例进行分析：
从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因：
1、跨项目间的接口，接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时候才暴露出来；
2、部门内部跨子系统的接口，由于本项目设计文档按功能规划编写的，而不是按照产品组件，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；
3、系统设计基线化后，更改系统接口，没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗漏下来；
那么我们可以针对性的制定改进建议：
1、对接口文档的评审一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；
2、对基线化的接口设计文档的变更一定要提交变更单给ＣＣＢ决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；
3、概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审协调接口设计；
以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。实际定义缺陷分类可能有很多个维度，如发现活动、引入活动、缺陷来源、缺陷类型、严重程度等。只要满足自己的缺陷管理、缺陷分析需求即可。
项目管理中一项非常重要但也十分困难的工作是衡量项目的进度、质量、成本等，统称为项目的状态，以确定项目是否能按期保质完成。这方面，测试提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。（注：此节所说的测试均指代系统测试）
缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升；而发现缺陷数曲线应总体趋于下降；同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。如：
项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目测试缺陷趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点，发现的故障数反而呈上升趋势，那么，这些点往往有一些特殊事件的发生。如：
- 在该时间段送测的回归版本增加了新的功能，导致缺陷引入；
- 该回归版本开发部没有进行集成测试就直接送测？等等。
当然，这个统计周期也可以根据我们的项目实施情况进行。如按照回归版本的版本号进行统计、按周进行统计等。也有公司把缺陷收敛情况当作判断版本是否可以最终外发的一个标志。
小结：
通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
当然，这种分析来源于一个前提，我们需要规划一个好的Bug管理系统，满足我们这些分析的信息需要。另外，我们的研发过程是稳定的，其质量表现大体是一致的，这样数据反映的趋势才具备可信度。
缺陷管理之缺陷收敛趋势分析
发表于：2010-1-19 13:52 作者：jx9747 来源：51Testing软件测试博客
字体：大 中 小 | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签： 软件测试管理 缺陷管理 测试管理
缺陷趋势，个人的理解是在一定周期时间或者一定阶段内，缺陷的按照一个或者多个维度的动态分布。周期可以是天，周，月。阶段可以是版本，例如1.2，1.3，1.3。
先来张图，有个直观的认识。
先对上图中出现的术语解释一下。
发现缺陷：测试人员在某一测试周期内新发现的缺陷总数。
修复缺陷：测试人员在某一测试周期内，对开发人员修复的缺陷验证并通过并缺陷总数。
遗留缺陷：在某一测试周期结束时刻，未关闭的缺陷总数。
收敛趋势：表示在一定周期内，遗留缺陷的变化情况。
收敛趋势曲线走势能反映被测试目标的质量变化情况，可以辅助管理人员决策，也可以做为产品的发布的一个重要参考。收敛趋势曲线往下跌的时候，表示产品质量在持续改善。收敛趋势曲线往上扬，表示产品质量在持续恶化，如果在开发阶段前期，这种情况也正常；如果在开发阶段的后期或者临近发布点，那么这种情况要引起注意了。收敛趋势曲线越趋近于水平（横轴），产品质量越好。
蓝色缺陷越趋近于近于水平（横轴），表示产品质量比较稳定，但不代表质量好。另外，蓝色和红色两条曲线可以辅助分析收敛趋势的变化情况，如果发现缺陷数目大于修复缺陷数，那么收敛趋势曲线就上扬，反之则下跌。
缺陷管理之缺陷收敛趋势分析（续）
发表于：2010-2-20 15:43 作者：jx9747 来源：51Testing软件测试博客
字体：大 中 小 | 上一篇 | 下一篇 | 打印 |我要投稿 | 推荐标签： 缺陷管理 测试管理
上篇文章对收敛趋势的一些基本概念做了讲解，本文就不再罗嗦了，没看过的同学请先看上一篇文章《缺陷管理之缺陷收敛趋势分析》，如果不看，我不保证你能看懂。本文将缺陷收敛趋势分析另外一种计算和表现方法，比上一种简单。
看图说话：
当前发现：在一个测试周期内发现的缺陷数目，也可以说是新增缺陷数目。
累计发现：截止到一个测试周期结束，所有发现的缺陷数目。
当前解决：在一个测试周期内，经过测试人员验证并关闭的缺陷数目。
累计解决：戒子到一个测试周期技术，多有关闭的缺陷数目。
如果用N1,N2...Nn表示每个测试周期发现的缺陷数目，那么N1表示第一个“当前发现”的数目，Nn表示第n个“当前发现”数目。于是：
累计发现n = N1 + N2 + ... + Nn
如果用C1,C2...Cn表示每个测试周期关闭的缺陷数目，那么C1表示第一个“当前解决”的数目，Cn表示第n个“当前解决”数目。于是：
累计解决n = C1 + C2 + ... + CN
统计都比较简单，累计发现和累计解决两天曲线表现出来是一致上扬。如果累计解决曲线越接近累计曲线，说明缺陷收敛情况比较好。理论上，当所有缺陷都关闭的时候，累计发现和累计解决就重合，但在实际情况中较少。
（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自jx9747的51Testing软件测试博客：http://www.51testing.com/?249369
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
http://www.doc88.com/p-1754771180967.html缺陷收敛决定技术
