白盒測試：為什么要做白盒測試
2016-08-25
1 預備知識
2 白盒測試的認識誤區
2.1 從一個比喻開始
2.2 誤區之一：白盒測試太耗時間，不值得一做
2.3 誤區之二：系統測試可以發現所有問題，不必做白盒測試
2.4 誤區之三：白盒測試必須在真實環境下進行
2.5 誤區之四：個人能力強的不必做白盒測試
2.6 誤區之五：白盒測試僅證明該怎么跑的代碼是這樣跑了，測不出什么問題！
3 參考
1 預備知識
軟件測試技術不同分類：
- 按是否關注軟件結構和算法可分為：黑盒測試、白盒測試
- 按測試過程中軟件是否被執行可分為：為靜態測試、動態測試
- 按測試階段可分為：單元測試、集成測試、系統測試、驗收測試
- 按目標/特性客分為：功能測試、安全性測試、兼容性測試、可靠性測試、性能測試、易用性測試等。
白盒測試包含靜態測試和動態測試。白盒測試也常在單元測試與集成測試階段進行，但這是相對的，與當前項目遵循的研發流程有關，某些流程把白盒測試划分為單元測試與集成測試，而另一些流程，把白盒測試划分為模塊單元測試、模塊系統測試、多模塊集成測試，還有一些流程把單元測試與集成測試混為一體，統稱為持續集成測試。
2 白盒測試的認識誤區
白盒測試作為軟件質量保證中的重要一環，但由於以下認識誤區，導致白盒測試被忽視：
- 誤區之一：白盒測試太耗時間，不值得一做
- 誤區之二：系統測試可以發現所有問題，不必做白盒測試
- 誤區之三：白盒測試必須在真實環境下進行
- 誤區之四：個人能力強的不必做白盒測試
- 誤區之五：白盒測試僅證明該怎么跑的代碼是這樣跑了
本篇總結實施白盒測試的幾個主要誤區，我們先從認識上端正對白盒測試的看法：
2.1 從一個比喻開始
前兩個認識誤區可以從從一個比喻開始講起。
假設有一台的面包機，從上面倒入面粉與水，開動機器后從下面出來的就是烤好了的面包，這個機器的功能比較單一，接口很清晰，輸入是面粉與水，輸出是面包。現在假定這個面包機多年未用，內部都生銹了，現在要清洗它，類似於我們開發的軟件，軟件有Bug，那得通過測試來清理。
圖1 面包機
那如何更快速的清洗這台面包機呢？有兩種洗法：
- 一種是拿水從上往下灌，這是系統測試的方法；
- 另一種是拆開來洗，拆開機器后，拿抺布沾點清潔劑，把各零件的坑坑槽槽擦洗一遍。
無疑，上面第二種方法是正確的，我們的前提是：清洗多年未用的面包機，鐵銹夠多，如果洗不干凈，造出的面包都是致癌物質。當然，清洗面包機還只能算簡單勞動，清理軟件中的Bug要復雜得多，一個if語句有兩條分支，一個while循環判斷也是兩條分支，還有break、continue、return等，想想看，一個1萬行規模的軟件能有多少個分支！一個分支就是一條坑坑槽槽，而且軟件Bug還具備動態特性，不是靜止的明擺在哪兒。
所以，軟件的白盒測試不可或缺，因為遺留Bug的影響很大，就像面包機沒洗凈留鐵銹會致癌，還因為軟件系統遠比面包機復雜，不拆開來怎么能洗干凈！
2.2 誤區之一：白盒測試太耗時間，不值得一做
白盒測試是高效測試
盡管白盒測試如此重要，為什么還有許多企業不願做白盒測試，有一個很重要的原因是：認為白盒測試太低效，不值得去做。
這種觀點主要有兩種誤解導致：
- 決策者評估各階段測試的有效性，往往僅以發現問題的數量為依據，這好比銹蝕斑斑的面包機，第一次沖水下去，看到大量濁水流出就很有成就感，其實這只是表象。
- 把發現問題與解決問題割裂開來了
實際上：
- 只做系統測試的結果是：第一次沖水，很有成效，第二次沖水，還能沖出點鐵銹，第三次就沒什么效果了。采用該手段並不能有效的達成既定質量目標。
- 研發質量改善，不只發現問題，還要定位問題、解決問題。白盒測試是拆開來洗，發現、定位與解決問題不僅是徹底的，也是直接的，效率非常高，所以，單以發現問題數評估一個測試過程是否有效不盡准確，我們應該綜合評估一個問題從被發現，到定位、解決，以及針對它完成回歸測試的總效率。
下圖來源於Capers Jones與McGraw-Hill的“Applied Software Measurement”文章，從該統計數據可看出，針對一個功能點的測試，若將問題發現、定位與解決都計算進去，單元測試效率最高，是集成測試的2倍，是系統測試的3倍。
圖2 各階段測試效率
而且，經驗數據表明，編碼階段的一個問題遺留到驗收測試去解決，所須費用將增加5倍，如下圖，一個問題越遺留到后面階段解決，付出代價就越高，而且是成倍遞增關系。
圖3 各階段解決問題代價
依據上述原因，我們評估白盒測試效率時，通常將發現問題總數乘上一個系數K，以此為據再與其它測試方段的發現問題效率做對比，來權衡白盒測試值不值得去做。系數K取值與產品形態相關，按照實際經驗，系數K取值區間為1.5~2.5，產品越復雜，出現問題越不容易解決的，K值要往大調。
2.3 誤區之二：系統測試可以發現所有問題，不必做白盒測試
白盒測試能徹底解決編碼階段引入的問題
不同階段的測試發現問題的特點各不相同，比如：
- 單元測試階段，容易發現邏輯問題、邊界條件、變量未初始化、內存越界等問題，
- 集成測試容易發現接口錯誤、任務配合問題等，
- 系統測試容易發現業務流程問題、界面操作問題等。
如果某階段的測試沒做，把問題遺留后面階段，又如何能保證查錯的徹底性。比如使用非法內存，出問題是否表現出來是隨機的，如果操作非法內存當前被系統還認為是有效的，系統並不死機，但某些情況下，操作非法內存會死機，而另一些情況，非法內存操作將不期望變化的變量改寫了，會導致其它莫名其妙的問題。類似這樣的問題，在白盒測試階段很容易發現，也容易定位解決，但遺留系統測試階段，就很難去發現、去定位。
在V模型中，軟件開發過程與測試行為具有不同層次的對應關系，如下圖：
圖4 V模型
單元測試針對編碼階段引入的問題，集成測試與功能測試針對軟件設計中引入的問題，驗收測試針對需求與規格。
單元測試不要或缺的重要原因是：編碼階段引入的問題占很高比例，不進行單元測試就難以保證系統最終的穩定性。
2.4 誤區之三：白盒測試必須在真實環境下進行
有的時候真實環境很難搭建，或搭建了也很難測試，這導致測試無法順利進行。
近代量子力學有一個海森堡測不准原理，講的是某個粒子的位置與動量不能同時被測量出來，由測量存在干擾，對其中一個參數測量越准確，另一個參數就越不准確。測不准原理在我們日常生活中很常見，比如要測試某物質的導電性，我們串聯接上一個安培計來觀察電流，但是，安培計本身也帶電阻，導致測不准，測量值會偏小。
在軟件測試領域也存在類似情況，比如要測試系統的CPU占用，於是添加代碼統計CPU占用率，但添加的代碼運行時，它本身也會消耗CPU。再如，為了實施白盒測試，必然追加測試代碼，比如：構造特定運行環境、替換樁函數使之在特定情況下返回特定值，這些都改變了被測對象自身的特性，追求完全准確的測試非常困難。
所以，我們並不是一定要追求在真實環境下做測試，而是要評估非真實環境（或仿真環境）下的測試對最終結果能產生多大偏離。
2.5 誤區之四：個人能力強的不必做白盒測試
能力強者不必做白盒測試，這顯然是謬論。一個人能力再強，軟件開發中都會犯錯誤，只不過能力強的，犯錯誤少些而已。
2.6 誤區之五：白盒測試僅證明該怎么跑的代碼是這樣跑了，測不出什么問題！
白盒測試針對的是規格，而非可見代碼，通過可見代碼做測試只是手段，最終目的是要測規格，所以我們白盒測試不僅要測可見代碼，也測試不可見代碼，如缺失的else分支、default分支，甚至漏寫的處理過程都在測試范圍之內。
3 參考