為何要進行白盒測試[3]

　　為何要進行白盒測試[3]  軟件測試

　　我們再來看一個實際案例：有兩個產品形態接近的項目，A項目正式實施單元測試與集成測試，另一個項目B項目沒正式做白盒測試(簡單的拿調試當測試)。最后項目結束時對研發全過程的全部問題進行缺陷分析，如下圖：

　　A項目的缺陷類型分析

　　B項目的缺陷類型分析

　　A項目的所有問題中，應該發現問題的階段是白盒測試(單元測試與集成測試)的占50%，而B項目所有問題中，應在白盒測試階段發現的僅占33%，另外，A項目發現邏輯錯誤占13%，而B項目只占8%。由這個統計數據表明，不做白盒測試必然導致大量問題漏測。

　　四、白盒測試要做到什么程度才算合適

　　既然白盒測試不可或缺，那么，白盒測試應做到什么程度才算合適呢?具體來說，白盒測試與黑盒測試應維持什么樣的比例才算合適?

　　一般而言，白盒測試做多做少與產品形態有關，如果產品更多的具備軟件平臺特性，白盒測試應占總測試的80%以上，甚至接近100%，而如果產品具備復雜的業務操作，有大量GUI界面，黑盒測試的份量應該更重些。根據經驗，對于大多數嵌入式產品，白盒方式展開測試(包括代碼走讀)應占總測試投入的一半以上，白盒測試發現的問題數也應超過總問題數的一半。

　　由于產品的形態不一樣，很難定一個標準說某產品必須做百分之多少白盒測試，但依據歷史經驗，我們還可以進行定量分析的。比如，收集某產品的某歷史版本在開發與維護中發生的所有問題，對這些問題進行正交缺陷分析(Orthogonal Defect Classification，ODC)，把“問題根源對象”屬于概要設計、詳細設計與編碼的問題整理出來，這些都是屬于白盒測試應發現的問題，統計這些問題占總問題數的比例，大致就是白盒測試應投入的比例。

　　通過正交缺陷分析，還能推論歷史版本各階段測試的遺留缺陷率，根據“發現問題的活動”，能統計出與“問題根源對象”不相匹配的問題數，這些各階段不匹配問題的比例就是該階段的漏測率。

　　參考文獻：

　　1. IPL, "Why Bother to Unit Test? "

　　2. Wayne Chan, 《第4代白盒測試方法介紹》

　　3. Yang Gu, from IBM, "Adopting ODC to improve software quality: A case study"

原文轉自：http://www.kjueaiud.com