軟件白盒測試是一個與黑盒測試相對的概念，是指測試者針對可見代碼進行的一種測試。白盒測試通常再劃分爲單元測試、集成測試兩大類，但依據不同的流程，對白盒測試細分的標準也不盡一致，比如在IBM的IPD流程之下，白盒測試可能劃分爲如下幾類：模塊單元測試、模塊集成測試、模塊系統測試、漸增Build集成測試、系統集成測試等。而在XP實踐中，單元測試與集成測試之間的界限並不明顯，統稱爲漸增迭代測試。
一、從一個比喻開始
爲什麼要做白盒測試？這個問題比較複雜，我們先從一個比喻開始講起。
假設有一臺的麪包機，從上面倒入麪粉與水，開動機器後從下面出來的就是烤好了的麪包，這個機器的功能比較單一，接口很清晰，輸入是麪粉與水，輸出是麪包。現在假定這個麪包機多年未用，內部都生鏽了，現在要清洗它，類似於我們開發的軟件，軟件有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。
這個問題本該在單元測試去發現，由於單元測試沒做，問題就遺留到系統測試，慶幸的是沒把它遺留到網上，否則問題就大了。我們從另一個角度去反思，這個問題是特定線路下的特定終端，按特定方式拔打特定業務才暴露，在系統測試好不容易把它揪出來，但類似的其它問題呢？如何保證在系統測試階段都能測得出來？
不同階段的測試發現問題的特點各不相同，比如：單元測試階段，容易發現邏輯問題、邊界條件（如上例“小於18”的錯誤）、變量未初始化、內存越界等問題，而集成測試容易發現接口錯誤、任務配合問題等，系統測試容易發現業務流程問題、界面操作問題等。如果某階段的測試沒做，把問題遺留後面階段，又如何能保證查錯的徹底性。比如使用非法內存，出問題是否表現出來是隨機的，如果操作非法內存當前被系統還認爲是有效的，系統並不死機，但某些情況下，操作非法內存會死機，而另一些情況，非法內存操作將不期望變化的變量改寫了，會導致其它莫名其妙的問題。類似這樣的問題，在白盒測試階段很容易發現，也容易定位解決，但遺留系統測試階段，就很難去發現、去定位。
在V模型中，軟件開發過程與測試行爲具有不同層次的對應關係，如下圖：
單元測試針對編碼階段引入的問題，集成測試與功能測試針對軟件設計中引入的問題，驗收測試針對需求與規格。單元測試不要或缺的重要原因是：編碼階段引入的問題佔很高比例，不進行單元測試就難以保證系統最終的穩定性。
我們再來看一個實際案例：有兩個產品形態接近的項目，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"