基本介紹
- 中文名：缺陷探測率DDP
- 外文名：Defect Detection Percentage
- 即：缺陷探測率
- 意義：衡量測試投資回報的一個重要指標
概念介紹,方法實例,方法缺陷,方法改進,
概念介紹
DDP=Bugs(tester) / (Bugs(tester)+Bugs(customer))
其中，Bugs(tester)為軟體開發方測試者發現的Bugs數目，Bugs(customer)為客戶方發現並反饋技術支持人員進行修復的Bugs數目。
DDP越高，說明測試者發現的Bugs數目越多，發布後客戶發現的Bugs就越少，降低了外部故障不一致成本，達到了節約總成本的目的，可獲得較高的測試投資回報率（ROI）。
方法實例
DDP計算的例子
測試階段 | 發現的缺陷數目 | DDP |
集成測試 | 376 | 51.58%（376/(376+251+65+37)） |
系統測試 | 251 | 71.10%（251/(251+65+37)） |
驗收測試 | 65 | 63.73%（65/(65+37)） |
產品發布（3個月之內） | 37 | NA |
方法缺陷
採用DDP作為測試有效性的評估指標，主要存在兩個問題：第一個是DDP無法在測試過程中對測試有效性進行評估，必須要等待產品發布一段時間之後才能進行，例如：產品發布之後3個月；另一個問題是DDP計算過程中只考慮了用戶反饋的缺陷的數目，而沒有考慮每個缺陷的嚴重程度；單純的缺陷的數目，並不能正確的反映遺漏到客戶的缺陷對用戶造成的影響程度。而測試的有效性，要求測試人員儘早發現儘量多的嚴重的問題，而不僅僅是儘量多的缺陷數目。
方法改進
對於DDP的第一個問題，由於DDP本身的定義要求，無法提供好的建議來解決該指標對測試有效性評估的延後性。而對於第二個問題，可以綜合考慮用戶反饋的缺陷數目和嚴重程度，對DDP計算實現最佳化，從而更好的評估測試有效性。
O-DDP
O-DDP的基本原理和DDP是一樣的，只是在計算過程中，同時考慮了缺陷的數目和缺陷的嚴重程度。根據筆者所在組織和項目的特點，其定義的缺陷嚴重程度如下[2]：
°嚴重程度2（嚴重的）：極大地影響系統提供給用戶的服務，或者嚴重影響系統要求或者基本功能的實現；
°嚴重程度3（一般的）：系統功能需要增強或存在缺陷，但有相應的補救方法解決這個缺陷；
°嚴重程度4（輕微的）：細小的問題，不需要補救方法或對功能進行增強；或者操作不方便，容易使用戶誤操作；
不同的缺陷嚴重程度，其定義的權重分別為w1 = 10、w2 = 4、w3 = 2和w4 = 1，分別對應嚴重程度1（致命的）、嚴重程度2（嚴重的）、嚴重程度3（一般的）和嚴重程度4（輕微的）。
表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#指的是系統測試階段不同嚴重程度的缺陷的數目；
