為何進行白盒測試 從“清洗面包機”講起

軟件白盒測試是一個與黑盒測試相對的概念，是指測試者針對可見代碼進行的一種測試。白盒測試通常再劃分為單元測試、集成測試兩大類，但依據不同的流程，對白盒測試細分的標準也不盡一致，比如在IBM的IPD流程之下，白盒測試可能劃分為如下幾類：模塊單元測試、模塊集成測試、模塊系統測試、漸增Build集成測試、系統集成測試等。而在XP實踐中，單元測試與集成測試之間的界限并不明顯，統稱為漸增迭代測試。

　　一、從一個比喻開始

　　為什么要做白盒測試？這個問題比較復雜，我們先從一個比喻開始講起。

　　假設有一臺的面包機，從上面倒入面粉與水，開動機器后從下面出來的就是烤好了的面包，這個機器的功能比較單一，接口很清晰，輸入是面粉與水，輸出是面包?，F在假定這個面包機多年未用，內部都生銹了，現在要清洗它，類似于我們開發的軟件，軟件有Bug，那得通過測試來清理。

　　



　　那如何更快速的清洗這臺面包機呢？有兩種洗法，一是拿水從上往下灌，這是系統測試的方法。另一種是拆開來洗，拆開機 器后，拿抺布沾點清潔劑，把各零件的坑坑槽槽擦洗一遍，然后組裝回來，再用水從上往下沖一遍，拆開來洗是白盒方法，組裝回來用水沖是黑盒方式，相當于白盒 測試之后再追加一次系統測試。

　　無疑，上面第二種方法是正確的，我們的前提是：清洗多年未用的面包機，鐵銹夠多，如果洗不干凈，造出的面包都是致癌物質。當然，清洗面包機還只能算簡單勞動，清理軟件中的Bug要復雜得多，一個if語句有兩條分支，一個while循環判斷也是兩條分支，還有break、continue、return等，想想看，一個1萬行規模的軟件能有多少個分支！一個分支就是一條坑坑槽槽，而且軟件Bug還具備動態特性，不是靜止的明擺在哪兒。

　　所以，軟件的白盒測試不可或缺，因為遺留Bug的影響很大，就像面包機沒洗凈留鐵銹會致癌，還因為軟件系統遠比面包機復雜，不拆開來怎么能洗干凈！

　　二、白盒測試是高效測試

　　盡管白盒測試如此重要，為什么還有許多企業不愿做白盒測試，有一個很重要的原因是：認為白盒測試太低效，不值得去做。

　　實際上這種觀點有許多誤解成分，首先，決策者評估各階段測試的有效性，僅以發現問題的數量為依據，這好比銹蝕斑斑的面包機，第一次沖水下去，看到大量濁水流出就很有成就感，其實這只是表象，思維方式有不足：把發現問題與解決問題割裂開來了。

　　我們測試的目標是按既定質量標準穩定推進產品研發進度，只做系統測試的結果是：第一次沖水，很有成效，第二次沖水， 還能沖出點鐵銹，第三次就沒什么效果了。采用該手段并不能有效的達成既定質量目標。其次，研發質量改善，不只發現問題，還要定位問題、解決問題。白盒測試 是拆開來洗，發現、定位與解決問題不僅是徹底的，也是直接的，效率非常高，所以，單以發現問題數評估一個測試過程是否有效不盡準確，我們應該綜合評估一個問題從被發現，到定位、解決，以及針對它完成回歸測試的總效率。

　　下圖來源于Capers Jones與McGraw-Hill的“Applied Software Measurement”文章，從該統計數據可看出，針對一個功能點的測試，若將問題發現、定位與解決都計算進去，單元測試效率最高，是集成測試的2倍，是系統測試的3倍。

　　



　　認為白盒測試低效的另一個誤解是，決策者并未認清一個bug若遺留到下一階段須多付出多少代價。經驗數據表明，編碼階段的一個問題遺留到驗收測試去解決，所須費用將增加5倍，如下圖，一個問題越遺留到后面階段解決，付出代價就越高，而且是成倍遞增關系。




　　所以，越早測試就越能節約成本，白盒測試作為早期測試，跳過不做是得不償失的。

　　依據上述原因，我們評估白盒測試效率時，通常將發現問題總數乘上一個系數K，以此為據再與其它測試方段的發現問題效率做對比，來權衡白盒測試值不值得去做。系數K取值與產品形態相關，按照實際經驗，系數K取值區間為1.5~2.5，產品越復雜，出現問題越不容易解決的，K值要往大調。

　　三、白盒測試能徹底解決編碼階段引入的問題

　　前面我們分析了白盒測試是高效的測試，值得一做，下面我們要接著說明白盒測試必須要做，不可或缺。

　　先看一個案例，在某交換機產品的系統測試中，發現ISDN話機撥打某新業務號碼時，在特定線路上，若一位一位的撥至18位，不會有問題，但如果先撥完號碼再成組發送，會導致系統死機。這是一個導致死機的致命問題，最后定位出問題所在：呼叫處理的某段代碼判斷有誤，本應小于18的判斷，錯寫成小于等于18。

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