概念介绍

方法实例

方法缺陷

方法改进

概念介绍

DDP是Defect Detection Percentage的缩写，即缺陷探测率。DDP是衡量测试投资回报的一个重要指标，是衡量测试工作效率的软件质量成本指标之一。其计算公式如下：

DDP=Bugs(tester) / Bugs(tester)+Bugs(customer)

其中，Bugs(tester)为软件开发方测试者发现的Bugs数目，Bugs(customer)为客户方发现并反馈技术支持人员进行修复的Bugs数目。

DDP越高，说明测试者发现的Bugs数目越多，发布后客户发现的Bugs就越少，降低了外部故障不一致成本，达到了节约总成本的目的，可获得较高的测试投资回报率（ROI）。

方法实例

DDP计算的例子

测试阶段　发现的缺陷数目　DDP

集成测试　376　51.58%

系统测试　251　71.10%

验收测试　65　63.73%

产品发布（3个月之内）　37　NA

方法缺陷

采用DDP作为测试有效性的评估指标，主要存在两个问题：第一个是DDP无法在测试过程中对测试有效性进行评估，必须要等待产品发布一段时间之后才能进行，例如：产品发布之后3个月；另一个问题是DDP计算过程中只考虑了用户反馈的缺陷的数目，而没有考虑每个缺陷的严重程度；单纯的缺陷的数目，并不能正确的反映遗漏到客户的缺陷对用户造成的影响程度。而测试的有效性，要求测试人员尽早发现尽量多的严重的问题，而不仅仅是尽量多的缺陷数目。

方法改进

对于DDP的第一个问题，由于DDP本身的定义要求，无法提供好的建议来解决该指标对测试有效性评估的延后性。而对于第二个问题，可以综合考虑用户反馈的缺陷数目和严重程度，对DDP计算实现优化，从而更好的评估测试有效性。

O-DDP

O-DDP的基本原理和DDP是一样的，只是在计算过程中，同时考虑了缺陷的数目和缺陷的严重程度。根据笔者所在组织和项目的特点，其定义的缺陷严重程度如下[2]：

°严重程度1（致命的）：产品在正常的运行环境下无法给用户提供服务，并且没有其他的工作方式可以补救；或者软件失效会造成人身伤害或危及人身安全；

°严重程度2（严重的）：极大地影响系统提供给用户的服务，或者严重影响系统要求或者基本功能的实现；

°严重程度3（一般的）：系统功能需要增强或存在缺陷，但有相应的补救方法解决这个缺陷；

°严重程度4（轻微的）：细小的问题，不需要补救方法或对功能进行增强；或者操作不方便，容易使用户误操作；

不同的缺陷严重程度，其定义的权重分别为w1 = 10、w2 = 4、w3 = 2和w4 = 1，分别对应严重程度1（致命的）、严重程度2（严重的）、严重程度3（一般的）和严重程度4（轻微的）。

下面通过案例的阐述，说明DDP和O-DDP计算得到的不同结果，以及根据结果分析得到的不同结论。在该案例中，评估的目标是系统测试的有效性，因此采用的缺陷数目分别来自系统测试发现的缺陷和在产品发布3个月之内用户反馈的缺陷。表1是根据DDP得到的结果：

表1 DDP

阶段　缺陷数目　DDP

系统测试　351　89.54%

产品发布（3个月之内）　41　NA我们从表1中得到的DDP = 89.54%结果来看，系统测试的有效性应该是非常不错的，因为遗留到用户现场的缺陷数目相对比较少。但是，在我们进行具体详细的分析用户反馈的缺陷的时候，发现用户对该产品的质量严重不满意。他们所反馈的缺陷，很多都是严重影响他们正常使用的问题。因此，上表中的DDP结果并不是让人信服的。

而后我们引入O-DDP，重新进行测试有效性的评估，其计算公式和DDP的公式一样，只是其中每个参数的计算进行了优化：

O-DDP = [R1 / (R1 + R2)] * 100%

其中：

°R1是系统测试阶段发现的缺陷和它们不同严重程度权重乘积之和，具体计算公式是R1 = m1*w1 + m2*w2 + m3*w3 + m4*w4，其中m#指的是系统测试阶段不同严重程度的缺陷的数目；