概念介紹
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 |
而後我們引入O-DDP，重新進行測試有效性的評估，其計算公式和DDP的公式一樣，只是其中每個參數的計算進行了最佳化：
O-DDP = [R1 / (R1 + R2)] * 100%
其中：
°R1是系統測試階段發現的缺陷和它們不同嚴重程度權重乘積之和，具體計算公式是R1 = m1*w1 + m2*w2 + m3*w3 + m4*w4，其中m#指的是系統測試階段不同嚴重程度的缺陷的數目；
