軟體白盒測試，也稱為結構化測試、基於代碼的測試，是一種測試用例設計方法，它從程式的控制結構導出測試用例。
軟體白盒測試概述,軟體白盒測試的目的,軟體白盒測試的特點,軟體白盒測試的實施步驟,軟體白盒測試的優缺點,優點,缺點,軟體白盒測試的測試方法,靜態分析法,動態分析法,軟體白盒測試法的覆蓋標準,如何挑選軟體白盒測試工具,軟體白盒測試之基本路徑測試法,4個步驟：,工具方法：,軟體白盒測試持續改進的關鍵,初始階段一：,發展階段二：,成熟階段三：,
軟體白盒測試概述
用軟體白盒測試產生的測試用例能夠：
1)保證一個模組中的所有獨立路徑至少被使用一次;
2)對所有邏輯值均需測試true和false;
3)在上下邊界及可操作範圍內運行所有循環;
4)檢查內部數據結構以確保其有效性。
這一方法是把測試對象看作一個打開的盒子，測試人員依據程式內部邏輯結構相關信息，設計或選擇測試用例，對程式所有邏輯路徑進行測試，通過在不同點檢查程式的狀態，確定實際的狀態是否與預期的狀態一致。
採用什麼方法對軟體進行測試呢?常用的軟體測試方法有兩大類：靜態測試方法和動態測試方法。其中軟體的靜態測試不要求在計算機上實際執行所測程式，主要以一些人工的模擬技術對軟體進行分析和測試;而軟體的動態測試是通過輸入一組預先按照一定的測試準則構造的實例數據來動態運行程式，而達到發現程式錯誤的過程。
軟體白盒測試的目的
通過檢查軟體內部的邏輯結構，對軟體中的邏輯路徑進行覆蓋測試;在程式不同地方設立檢查點，檢查程式的狀態，以確定實際運行狀態與預期狀態是否一致。
軟體白盒測試的特點
軟體白盒測試的實施步驟
1. 測試計畫階段：根據需求說明書，制定測試進度。
3. 測試執行階段：輸入測試用例，得到測試結果。
4. 測試總結階段：對比測試的結果和代碼的預期結果，分析錯誤原因，找到並解決錯誤。
軟體白盒測試的優缺點
優點
· 迫使測試人員去仔細思考軟體的實現
· 可以檢測代碼中的每條分支和路徑
· 揭示隱藏在代碼中的錯誤
· 對代碼的測試比較徹底
· 最最佳化
缺點
· 昂貴
· 無法檢測代碼中遺漏的路徑和數據敏感性錯誤
· 不驗證規格的正確性
軟體白盒測試的測試方法
軟體白盒測試的測試方法總體上分為靜態方法和動態方法兩大類。
靜態分析法
是一種不通過執行程式而進行測試的技術。靜態分析的關鍵功能是檢查軟體的表示和描述是否一致 , 沒有衝突或者沒有歧義。
動態分析法
的主要特點是當軟體系統在模擬的或真實的環境中執行之前、之中和之後 , 對軟體系統行為的分析。動態分析包含了程式在受控的環境下使用特定的期望結果進行正式的運行。它顯示了一個系統在檢查狀態下是正確還是不正確。在動態分析技術中 , 最重要的技術是路徑和分支測試。下面要介紹的六種覆蓋測試方法屬於動態分析方法。
軟體白盒測試法的覆蓋標準
如何挑選軟體白盒測試工具
軟體白盒測試目前主要用在具有高可靠性要求的軟體領域，例如：軍工軟體、航天航空軟體、工業控制軟體等等。軟體白盒測試工具在選購時應當主要是對開發語言的支持、代碼覆蓋的深度、嵌入式軟體的測試、測試的可視化等。
對開發語言的支持：軟體白盒測試工具是對原始碼進行的測試，測試的主要內容包括詞法分析與語法分析、靜態錯誤分析、動態檢測等。但是對於不同的開發語言，測試工具實現的方式和內容差別是較大的。目前測試工具主要支持的開發語言包括：標準C、C++、Visual C++、Java、Visual J++等。
·語句覆蓋 為了暴露程式中的錯誤，程式中的每條語句至少應該執行一次。因此語句覆蓋(Statement Coverage)的含義是：選擇足夠多的測試數據，使被測程式中每條語句至少執行一次。語句覆蓋是很弱的邏輯覆蓋。
·判定覆蓋 比語句覆蓋稍強的覆蓋標準是判定覆蓋(Decision Coverage)。判定覆蓋的含義是：設計足夠的測試用例，使得程式中的每個判定至少都獲得一次“真值”或“假值”，或者說使得程式中的每一個取“真”分支和取“假”分支至少經歷一次，因此判定覆蓋又稱為分支覆蓋。
·條件覆蓋 在設計程式中，一個判定語句是由多個條件組合而成的複合判定。為了更徹底地實現邏輯覆蓋，可以採用條件覆蓋(Condition Coverage)的標準。條件覆蓋的含義是：構造一組測試用例，使得每一判定語句中每個邏輯條件的可能值至少滿足一次。
·多條件覆蓋 多條件覆蓋也稱條件組合覆蓋，它的含義是：設計足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
·修正條件判定覆蓋 修正條件判定覆蓋是由歐美的航空/航天製造廠商和使用單位聯合制定的“航空運輸和裝備系統軟體認證標準”，目前在國外的國防、航空航天領域套用廣泛。這個覆蓋度量需要足夠的測試用例來確定各個條件能夠影響到包含的判定的結果。它要求滿足兩個條件：首先，每一個程式模組的入口和出口點都要考慮至少要被調用一次，每個程式的判定到所有可能的結果值要至少轉換一次;其次，程式的判定被分解為通過邏輯操作符(and、or)連線的布爾條件，每個條件對於判定的結果值是獨立的。
不同的測試工具對於代碼的覆蓋能力也是不同的，通常能夠支持修正條件判定覆蓋的測試工具價格是極其昂貴的。
軟體白盒測試之基本路徑測試法
其中運用最為廣泛的是基本路徑測試法。
基本路徑測試法是在程式控制流圖的基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。
設計出的測試用例要保證在測試中程式的每個可執行語句至少執行一次。
在程式控制流圖的基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下4個步驟和一個工具方法：
4個步驟：
1. 程式的控制流圖：描述程式控制流的一種圖示方法。
2. 程式圈複雜度：McCabe複雜性度量。從程式的環路複雜性可導出程式基本路徑集合中的獨立路徑條數，這是確定程式中每個可執行語句至少執行一次所必須的測試用例數目的上界。
3. 導出測試用例：根據圈複雜度和程式結構設計用例數據輸入和預期結果。
4. 準備測試用例：確保基本路徑集中的每一條路徑的執行。
工具方法：
圖形矩陣：是在基本路徑測試中起輔助作用的軟體工具，利用它可以實現自動地確定一個基本路徑集。
程式的控制流圖：描述程式控制流的一種圖示方法。
圓圈稱為控制流圖的一個結點，表示一個或多個無分支的語句或源程式語句
流圖只有二種圖形符號：圖中的每一個圓稱為流圖的結點，代表一條或多條語句。
流圖中的箭頭稱為邊或連線，代表控制流
任何過程設計都要被翻譯成控制流圖。
如何根據程式流程圖畫出控制流程圖?
在將程式流程圖簡化成控制流圖時，應注意：
在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
邊和結點圈定的區域叫做區域，當對區域計數時，圖形外的區域也應記為一個區域。
軟體白盒測試持續改進的關鍵
初始階段一：
剛實施或從未實施軟體白盒測試的發展階段，一個企業內只有零星的單元測試或集成測試實踐，缺少成功案例。重要特點，公司成員普遍對軟體白盒測試缺少概念，大致知道代碼審查、單元測試、集成測試該怎么去做，但一涉及具體場景，對某模組實施單元測試或跨模組、跨子系統實施集成測試時，通常茫無頭緒，不知從何下手。
發展階段二：
軟體白盒測試過程也逐漸融入研發流程，典型的例子：將軟體白盒測試發現的問題納入統計，研發過程中會以缺陷密度(每千行代碼發現多少BUG)作為衡量軟體白盒測試是否充分的指標，另外還會以覆蓋率指標作為檢查個人是否充分測試的依據。個體行為難以轉化為組織行為。
開始認識到單元測試該由開發人員去做
多數尚處於混沌境界的企業會認為，單元測試應由測試人去做，可能會覺得開發人員自己編碼又自己測試會陷入慣性思維，測試效果不佳。但讓測試人員現實操作幾次，又會冒出幾個難以逾越的問題，首先是測試效率，測試人員不熟悉代碼，他上手把源碼讀懂然後想辦法做測試，要知道，單元測試面對眾多瑣碎的函式，隨意一個開發人員一天就能寫一堆新函式，所以，測試人員若把單元測試做好，通常要比開發人員自測多付10倍的精力，這一情況很致命，單元測試必然難以為繼。其次，測試人員做單元測試，經常不能斷定某種現象是不是問題，還得找相應開發人員去定位，問題定位了，修正問題又是個麻煩，測試人員不擁有給產品編碼的許可權，大量時間又浪費在反覆溝通上。
會發現只拿覆蓋率評估測試是否充分是不夠的
引入業界工具實施覆蓋率測試，當一個企業軟體白盒測試做到一定程度時，會陷入一個困惑：拿覆蓋率評估測試充分與否是否足夠?為覆蓋率而覆蓋率，目標太容易達成，運行一兩個高層次的業務調用，覆蓋率很快就上去了，也即，如果有人想作弊，他完全可以只寫很少用例就讓覆蓋率滿足要求。有人就這個問題進一步思考，又產生另一個困惑：軟體白盒測試到底測什麼?測看得到的代碼嗎?代碼覆蓋率直觀的表達了可見代碼是否跑到，但如果規格有要求又忘實現了，覆蓋率能說明什麼?
不同員工做軟體白盒測試，效果差別巨大。
這種現象是每個公司都會遇到的，在軟體白盒測試推行初期表現尤為明顯。能力強的就是很少漏測，很少遺漏問題到後續階段，能力差的，儘管他很努力的想把每件事做好，漏測總還很多。
會有軟體白盒測試無用論產生
產生軟體白盒測試無用論，多半不是從理論上反對軟體白盒測試，而是實踐走不通，做了不少單元測試，效果不佳，發現問題留於表面，深層次邏輯問題或接口問題發現不了，所以就認定軟體白盒測試沒多大用處。
軟體白盒測試能否成功很大程度上依賴於牛人經理或牛人QA
軟體白盒測試推行初期經常，執行力強一些的經理或QA，軟體白盒測試可以推行成功，執行力弱一些的就不成功。不少企業因為嘗試幾次單元測試都失敗了，就全盤放棄白盒，只做黑盒測試了。
有一些企業堅持下來，在一兩個項目組取得成功，然後針對性的最佳化組織機構，比如設定專門工作推動組，建設軟體白盒測試專家資源池，為各個項目提供測試引導人員，進一步最佳化流程，把軟體白盒測試的監控點納入流程來控制。當一個企業的組織機構與流程逐步完善，軟體白盒測試能否成功就較少依賴於個別牛人了。
階段化實施軟體白盒測試，測試用例無法維護
集中一段時間編碼，編碼完了再集中一段時間做單元測試，單元測試完了開始集成，這時又集中時間做一次集成測試，這是多數企業實施軟體白盒測試的模式。這一模式下，單元測試或集成測試只是特定時間段內(比如一個版本周期內的一兩星期中)才實施的活動，但產品修改代碼卻是時時刻都在進行的，毫無疑問的會帶來一個深刻問題：用例維護與產品代碼維護不同步!所以，大家就經常會看到，某個產品的第一個版本可以把單元測試完整實施一遍，而此後時不時為解決問題改代碼，或為追加功能改代碼，單元測試很難繼續，常導致單元測試只在V1版本做一遍，其後V2、V3等版本無法再做。
或許有人會覺得，為讓軟體白盒測試在版本周期內堅持做下去，不見非得引入持續集成吧?試想一下，從編碼到版本進入維護，開發人員獨立無干擾的編碼時間有多少?而從兩兩開始集成之後，又占去多少時間?無疑後者占去大部分時間。如果開始集成後的每次版本修改都有測試跟進，大家豈非天天寫測試用例，這不是持續集成是什麼?如果不想天天補充用例，隔周、隔月，或隔一個版本補充用例，怎知你增補的用例會覆蓋全部變動過的代碼?
依據實踐的推論，通信軟體的單元測試應在仿真環境下按純軟體的方式去做，集成測試倒是可以上單板，在真實環境下去做。
