在执行过程中，如果我们发现缺陷，通常会将缺陷记录到缺陷管理系统中，这样方便对缺陷进行跟踪和管理。但在缺陷分析过程中，仅仅对缺陷进行跟踪和管理还是不够的，还要对缺陷进行监控，监控缺陷的分布、修复等相关的属性。
通常对缺陷应该监控以下维度的内容：缺陷收敛趋势、缺陷分布、无效缺陷和缺陷修复这几方面的数据。
一、缺陷收敛趋势
在前面介绍了缺陷的一些特性，其中包括缺陷收敛性的概念，那么在测试的整个过程中，就需要去分析缺陷是否收敛。分析缺陷收敛的方法很简单，具体的步骤如下：
(1)按版本对每个版本的数据进行统计。
(2)然后将每个版本所发现的缺陷数据画成一张曲线图，类似于图9-30。
分析这张曲线图时，需要确定的每个版本所发现的缺陷数是否呈下降的趋势，如果呈下降的趋势，就说明缺陷呈收敛性，否则说明缺陷不是收敛的。如果缺陷不呈收敛性，则说明产品的研发过程存在很大的问题，主要可能表现在以下几个方面：
(1)产品质量很不稳定，系统的不稳定可能导致缺陷呈波动状态。
(2)缺陷在修复时，引入了过多的新问题。
(3)测试设计存在很多问题。
(4)测试执行的过程存在很多问题。
二、缺陷分布
在缺陷监控过程中，还需要对所发现的缺陷的分布情况进行分析。缺陷分布应该至少从两个方面进行分析：一是按功能模块的分布进行分析;二是按缺陷的严重等级的分布进行分析。
(1)功能模块分布
按功能模块分布来分析缺陷，是指按功能模块来统计每个模块所发现的缺陷数。按功能模块统计缺陷的对象主要是核心模块发现缺陷的情况，当然也可以用来分析所有功能模块的情况，但没有必要，因为客户只会使用一些核心的和基础的功能。分析的目的主要包括两个方面：一是核心模块是否处于稳定状态;二是核心模块千行缺陷率。
关于分析核心模块是否稳定，其实在四象限分析法中有详细介绍，当然这要对核心模块持续多个版本的分析才能确定，只能保证核心模块的稳定性才能保证系统的稳定性。
核心模块千行缺陷率是用来统计缺陷的密度的，这样可以用来评估开发和测试的质量，当然这就需要一个参考值，如果没有参考值，这个值本身就没有意义了，而这个参考值来源于以前历史版本或相类似功能模块的数据。
(2)按严重等级分布
按缺陷的严重等级划分，缺陷是最常见的一种缺陷分布分析方法。按严重等级划分的目的是分析每类缺陷所占的比例，项目中不同等级的缺陷应该是以一定比例来分布的，如果在缺陷分布中致命和严重的比例过高，那就必须分析具体的原因，正常我们希望一般的问题占的比例更高，这样说明系统发布后其稳定性更高。
当然某类缺陷比例过高的原因可能会有很多情况，不过这与测试的方法或策略没有关系，只与研发的过程中关系。如果需要详细分析是什么原因导致严重或致命的缺陷比例过高，那就必须对整个研发过程进行详细的分析，这也是我们常说的通过对缺陷分析来找到研发做得不好的地方，进而改进研发流程。
三、无效缺陷
在测试过程中可能会发现一些无效的缺陷，无效缺陷也是缺陷监控分析的一部分，无效缺陷是指测试工程师提交的缺陷，但开发并不认为是缺陷，并且最终审核后也确定该缺陷不是真的缺陷，这种缺陷被称之为无效缺陷。
在测试过程中发现的缺陷中，无效缺陷的比例不能过多，一般在一个项目测试过程中发现的无效缺陷应该都是低于5 个的。如果无效缺陷过多，则说明测试对需求的理解方面有问题，导致提交缺陷时出现过多无效缺陷。
那么是什么原因导致测试工程师对需求理解的偏差呢?那最主要的是在需求评审时，需求工程师在解释需求时(也可以说是唱需求)并没有表达得很清楚，导致对需求的理解出现问题。而目前很多公司在需求评审时，其实很多是没有详细解释需求的过程，而只是在评审过程中，如果评审发现需求有问题，才对有问题的需求进行详细的介绍。所以就可以发现对需求有着不一样的理解，这样就可能提交一些无效的缺陷。当提交的无效缺陷过多时，则说明我们的在解释需求和评审需求时存在很多问题，需要找到一个有效的方法来完善需求评审的过程。
四、缺陷修复
在整个测试过程上，开发修改缺陷的过程也是必须要去监控和评估的，通常缺陷修复的分析需求包括以下几个方面的内容：
(1)严重和致命类的缺陷修复的情况;
产品在发布时，不能遗留严重和致命类的缺陷，所以在产品发布之前一定要确保所有的致命和严重问题都得到解决。
(2)每个版本所修复缺陷的情况;
统计每个版所修复的缺陷趋势图，当然每个版本所修复的缺陷趋势图应该与所发现的缺陷趋势图是类似的，但主要需要分析以下问题，在所修复的缺陷中，有一些缺陷可能一次性没有修复完成，或者修复后引入了新的缺陷。这类问题就是我们主要分析的对象，因为当出现这类问题时，就必然会导致修复的缺陷成本升高。当然很少有公司具体去讨论这类未能被一次性修复的缺陷所占的百分比。但如果这个比例超过一定比例时，就必须对研发修复缺陷的过程进行详细的分析，以确定这类情况的具体原因。
閱讀更多 川石信息 的文章
