缺陷密度的用途——软件质量管理实践（连载三十四）

核心提示：7.6.4缺陷密度的用途缺陷密度是软件缺陷的基本度量，可用于设定产品质量目标，缺陷密度的用途——软件质量管理实践（连载三十四），支持软件可靠性模型（如Rayleigh模型）预测潜伏的软件缺陷，进而对软件质量进行跟踪和管理，增加的缺陷总数不应该多于上个版本的36个，所以缺陷率目标需要控制在36/40=0.9或者更低，支持

7.6.4　　缺陷密度的用途

缺陷密度是软件缺陷的基本度量，可用于设定产品质量目标，支持软件可靠性模型（如Rayleigh模型）预测潜伏的软件缺陷，进而对软件质量进行跟踪和管理，支持基于缺陷计数的软件可靠性增长模型（如Musa-Okumoto模型），对软件质量目标进行跟踪并评判能否结束软件测试。

如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？如果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。　

如果缺陷密度比上一个版本高，那么就应该考虑在此之前是否为显著提高测试效率进行了有效的策划，并在本次测试中得到实施？如果是，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化，质量很难得到保证。这时，要保证质量，就必须延长开发周期或投入更多的资源。　

当软件产品或者项目首次发布，并规定使用LOC计数时，可以比较容易地说出它的计划或者实际的质量等级，如“本产品共有83KLOC，在今后的3年时间里，潜在的缺陷率是2.0个缺陷/KLOC”。但当进行了修改、增强后进行产品的后续发布时，问题就会越来越复杂。

缺陷跟踪：缺陷必须被跟踪到版本源头，其中包含此缺陷的代码段，以及在哪个版本中加入、修改或增强的。当计算整个产品的缺陷率时，要用到所有缺陷；当计算新的和更改代码的缺陷率时，则只需要包含新的和更改代码的版本源头中的缺陷即可。

缺陷率度量在每个单位的基础上度量代码质量。

从用户的角度来看，缺陷率远没有缺陷总数那么重要，对他们来说，产品应该确保缺陷总数与发布版本大小无关，而随着发布版本下降。如果一个新发布版本的大小比它的前一版本大很多，则需要新的和更改代码的缺陷率应该明显地好于以往版本。

我们可以考虑如下假设的例子：

产品A最初发布时代码总量为50KLOC，估计残留缺陷总数是100个，平均有2个缺陷/KLOC。

发布第二版时，新增代码行为20KLOC，包括修改原来的4KLOC行代码（需要剔除，避免重复计算），可以计算出该版本代码总数为50+20-4=66KLOC，该版本对上一版本的缺陷率有10%的改进，估计当前版本残留缺陷新增总数可以控制在36个以内，则平均残留缺陷数为1.8个/KLOC。此时，由于此次发布版本较小，在缺陷率有10%的改进的同时，用户在缺陷数方面经历了(100-36)/100=64%的明显下降。

如果进行第三版的发布时，新增代码行为40KLOC，这比第二次发布大得多，其中包括修改原来的10KLOC行代码，则该版本代码总数为66+40-10=96KLOC，为了使用户的缺陷体验不至于失望，增加的缺陷总数不应该多于上个版本的36个，所以缺陷率目标需要控制在36/40=0.9或者更低，即该版本的缺陷率必须比第二版的好50%。