测试缺陷分析务实篇[2]

• 利用缺陷的阶段分布模型进行质量预测

    假设我们为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管理系统，满足我们这些分析的信息需要。另外，我们的研发过程是稳定的，其质量表现大体是一致的，这样数据反映的趋势才具备可信度。