軟體白盒測試是乙個與黑盒測試相對的概念，是指測試者針對可見**進行的一種測試。白盒測試通常再劃分為單元測試、整合測試兩大類，但依據不同的流程，對白盒測試細分的標準也不盡一致，比如在ibm的ipd流程之下，白盒測試可能劃分為如下幾類：模組單元測試、模組整合測試、模組系統測試、漸增build整合測試、系統整合測試等。而在xp實踐中，單元測試與整合測試之間的界限並不明顯，統稱為漸增迭代測試。
一、從乙個比喻開始
為什麼要做白盒測試？這個問題比較複雜，我們先從乙個比喻開始講起。
假設有一台的麵包機，從上面倒入麵粉與水，開動機器後從下面出來的就是烤好了的麵包，這個機器的功能比較單一，介面很清晰，輸入是麵粉與水，輸出是麵包。現在假定這個麵包機多年未用，內部都生鏽了，現在要清洗它，類似於我們開發的軟體，軟體有bug，那得通過測試來清理。
認為白盒測試低效的另乙個誤解是，決策者並未認清乙個bug若遺留到下一階段須多付出多少代價。經驗資料表明，編碼階段的乙個問題遺留到驗收測試去解決，所須費用將增加5倍，如下圖，乙個問題越遺留到後面階段解決，付出代價就越高，而且是成倍遞增關係。
所以，越早測試就越能節約成本，白盒測試作為早期測試，跳過不做是得不償失的。
依據上述原因，我們評估白盒測試效率時，通常將發現問題總數乘上乙個係數k，以此為據再與其它測試方段的發現問題效率做對比，來權衡白盒測試值不值得去做。係數k取值與產品形態相關，按照實際經驗，係數k取值區間為1.5~2.5，產品越複雜，出現問題越不容易解決的，k值要往大調。
[nextpage]
三、白盒測試能徹底解決編碼階段引入的問題
前面我們分析了白盒測試是高效的測試，值得一做，下面我們要接著說明白盒測試必須要做，不可或缺。
先看乙個案例，在某交換機產品的系統測試中，發現isdn話機撥打某新業務號碼時，在特定線路上，若一位一位的撥至18位，不會有問題，但如果先撥完號碼再成組傳送，會導致系統宕機。這是乙個導致宕機的致命問題，最後定位出問題所在：呼叫處理的某段**判斷有誤，本應小於18的判斷，錯寫成小於等於18。
這個問題本該在單元測試去發現，由於單元測試沒做，問題就遺留到系統測試，慶幸的是沒把它遺留到網上，否則問題就大 了。我們從另乙個角度去反思，這個問題是特定線路下的特定終端，按特定方式拔打特定業務才暴露，在系統測試好不容易把它揪出來，但類似的其它問題呢？如何 保證在系統測試階段都能測得出來？
不同階段的測試發現問題的特點各不相同，比如：單元測試階段，容易發現邏輯問題、邊界條件（如上例「小於18」 的錯誤）、變數未初始化、記憶體越界等問題，而整合測試容易發現介面錯誤、任務配合問題等，系統測試容易發現業務流程問題、介面操作問題等。如果某階段的測 試沒做，把問題遺留後面階段，又如何能保證查錯的徹底性。比如使用非法記憶體，出問題是否表現出來是隨機的，如果操作非法記憶體當前被系統還認為是有效的，系統並不宕機，但某些情況下，操作非法記憶體會宕機，而另一些情況，非法記憶體操作將不期望變化的變數改寫了，會導致其它莫名其妙的問題。類似這樣的問題，在白 盒測試階段很容易發現，也容易定位解決，但遺留系統測試階段，就很難去發現、去定位。
在v模型中，軟體開發過程與測試行為具有不同層次的對應關係，如下圖：
單元測試針對編碼階段引入的問題，整合測試與功能測試針對軟體設計中引入的問題，驗收測試針對需求與規格。單元測試不要或缺的重要原因是：編碼階段引入的問題佔很高比例，不進行單元測試就難以保證系統最終的穩定性。
我們再來看乙個實際案例：有兩個產品形態接近的專案，a專案正式實施單元測試與整合測試，另乙個專案b專案沒正式做白盒測試（簡單的拿除錯當測試）。最後專案結束時對研發全過程的全部問題進行缺陷分析，如下圖：
a專案的缺陷型別分析
b專案的缺陷型別分析
a專案的所有問題中，應該發現問題的階段是白盒測試（單元測試與整合測試）的佔50%，而b專案所有問題中，應在白盒測試階段發現的僅佔33%，另外，a專案發現邏輯錯誤佔13%，而b專案只佔8%。由這個統計資料表明，不做白盒測試必然導致大量問題漏測。
四、白盒測試要做到什麼程度才算合適
既然白盒測試不可或缺，那麼，白盒測試應做到什麼程度才算合適呢？具體來說，白盒測試與黑盒測試應維持什麼樣的比例才算合適？
一般而言，白盒測試做多做少與產品形態有關，如果產品更多的具備軟體平台特性，白盒測試應佔總測試的80%以上，甚至接近100%，而如果產品具備複雜的業務操作，有大量gui介面，黑盒測試的份量應該更重些。根據經驗，對於大多數嵌入式產品，白盒方式展開測試（包括**走讀）應佔總測試投入的一半以上，白盒測試發現的問題數也應超過總問題數的一半。
[nextpage]
由於產品的形態不一樣，很難定乙個標準說某產品必須做百分之多少白盒測試，但依據歷史經驗，我們還可以進行定量分析的。比如，收集某產品的某歷史版本在開發與維護中發生的所有問題，對這些問題進行正交缺陷分析（orthogonal defect classification，odc），把「問題根源物件」屬於概要設計、詳細設計與編碼的問題整理出來，這些都是屬於白盒測試應發現的問題，統計這些問題佔總問題數的比例，大致就是白盒測試應投入的比例。
通過正交缺陷分析，還能推論歷史版本各階段測試的遺留缺陷率，根據「發現問題的活動」，能統計出與「問題根源物件」不相匹配的問題數，這些各階段不匹配問題的比例就是該階段的漏測率。
為何要進行白盒測試
軟體白盒測試是乙個與黑盒測試相對的概念，是指測試者針對可見 進行的一種測試。白盒測試通常再劃分為單元測試 整合測試兩大類，但依據不同的流程，對白盒測試細分的標準也不盡一致，比如在ibm的ipd流程之下，白盒測試可能劃分為如下幾類 模組單元測試 模組整合測試 模組系統測試 漸增build整合測試 系統...
python 白盒測試 白盒測試方法
白盒測試是單元測試階段常用到的測試方法，其特點有 1 可以構成測試資料，使特定程式部分得到測試 2 有一定的充分性度量手段 3 可獲得較多工具支援 4 通常只用於單元測試。下邊通過一段 來看一下白盒測試中的邏輯覆蓋 那麼為了清晰，我們畫出乙個該程式的流程圖 1 語句覆蓋 語句覆蓋是最弱的邏輯覆蓋準則...
黑盒測試 白盒測試
黑盒測試 black box testing，又稱為功能測試或資料驅動測試 是把測試物件看作乙個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測...