缺陷分析与度量：处理能力及改进建议

有了系统之后，统计方便多了。老Q拿了一堆报表给小M看，说这是统计出来的缺陷分布和缺陷处理能力指标。小M看得头昏脑涨，也不明就里。于是向老Q请教这些报表是什么意思。

老Q耐心地画了张缺陷分布的分析矩阵给小M（见表6-9）。这个矩阵其实是一个缺陷分析的指标集。横向是缺陷数量、严重性等级、缺陷类型、缺陷状态和缺陷密度等指标；纵向则是需要查看这些指标的维度，交叉点就是某个维度上的缺陷分布指标。其中，缺陷状态指处于等待修改、已经修改、已经关闭和暂缓修改等状态的缺陷比例，缺陷密度在测试阶段则是指每千行代码中发现的缺陷数。

例如，“总体”和“严重性等级”的交叉点代表“总体严重性等级”指标，这个指标的含义是整个系统中不同严重性缺陷各有多少；“模块”和“缺陷状态”的交叉点代表“模块缺陷状态”指标，这个指标的含义是不同模块中处于不同状态的缺陷各有多少。

表6-9 缺陷分布

（续）

看着小M还是不太明白，老Q说这些指标可以说明哪个子系统问题多，哪些人特别善于找问题，哪个阶段出的问题多，哪个阶段找出的问题多。现在手工查找缺陷制造者还挺麻烦的，但以后假如跟配置管理系统联系起来，就可以很容易地知道哪些人容易出问题。(www.xing528.com)

这么解释小M听明白了，也感兴趣了，对着老Q提供的表格看了几个实际的例子。平时觉得让人放心的开发人员果然是缺陷密度低，而几个“手快”的开发人员虽然产量高，但缺陷更多，所以缺陷密度大。小M啧啧称赞，以前是凭感觉判断，现在有数据基础了。

随后，老Q又拿了一张表，说是统计了项目组整体的几个重要指标，反映了项目组的处理缺陷的能力，见表6-10。

表6-10 处理缺陷能力指标

最后，老Q根据分析结果，提出了一些改进建议。例如，一些手快的开发人员要降低其产量，让他们自己增加单元测试案例。对于常出现严重性错误的子系统，请架构师进入帮助审核架构设计。有的开发人员缺陷平均驻留时间比较长，请小M注意一下能否帮助他们改进查错和修改的方法。还有几个缺陷的驻留时间特别长，是几个重要问题始终得不到确认造成的，建议小M出面与客户沟通。

看到平时乱七八糟的各种表单经过老Q这么一整理，就得到这么多有用信息，可以直接指导工作，这次小M对于老Q彻底信服了。