概述
白盒測試又稱結構測試,透明盒測試、邏輯驅動測試或基於
代碼的測試。白盒測試是一種
測試用例設計方法，盒子指的是被測試的
軟件，白盒指的是盒子是可視的,你清楚盒子內部的東西以及裏面是如何運做的。 "白盒"法全面瞭解
程序內部
邏輯結構、對全部邏輯
路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。
採用什麼方法對軟件進行測試呢？經常使用的
軟件測試方法有兩大類：
靜態測試方法和
動態測試方法。其中軟件的靜態測試不要求在計算機上實際執行所測程序，主要以一些人工的模擬技術對軟件進行分析和測試；而軟件的動態測試是經過輸入一組預先按照必定的
測試準則構造的實例數據來動態運行程序，而達到發現
程序錯誤的過程。在動態分析技術中,最重要的技術是路徑和分支測試。下面要介紹的六種覆蓋測試方法屬於動態分析方法。
測試方法
白盒測試的測試方法有
代碼檢查法、靜態結構分析法、靜態質量度量法、
邏輯覆蓋法、基本
路徑測試法、
域測試、符號測試、Z
路徑覆蓋、
程序變異。
白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括
語句覆蓋、
斷定覆蓋、
條件覆蓋、斷定/條件覆蓋、
條件組合覆蓋和路徑覆蓋。
六種覆蓋標準：語句覆蓋、斷定覆蓋、條件覆蓋、斷定/條件覆蓋、條件組合覆蓋和路徑覆蓋發現錯誤的能力呈由弱至強的變化。語句覆蓋每條語句至少執行一次。斷定覆蓋每一個斷定的每一個分支至少執行一次。條件覆蓋每一個斷定的每一個條件應取到各類可能的值。斷定/條件覆蓋同時知足斷定覆蓋條件覆蓋。條件組合覆蓋每一個斷定中各條件的每一種組合至少出現一次。路徑覆蓋使程序中每一條可能的路徑至少執行一次。
要求
1.保證一個模塊中的全部獨立路徑至少 被使用一次
2.對全部邏輯值均需測試 true 和 false
3.在上下邊界及可操做範圍內運行全部循環
4.檢查內部數據結構以確保其有效性
目的
經過檢查
軟件內部的
邏輯結構，對軟件中的邏輯
路徑進行覆蓋測試;在
程序不一樣地方設立檢查點，檢查程序的狀態，以肯定實際運行狀態與預期狀態是否一致。
特色
依據
軟件設計說明書進行測試、對
程序內部細節的嚴密檢驗、針對特定條件設計
測試用例、對軟件的邏輯
路徑進行覆蓋測試。
實施步驟
1.
測試計劃階段：根據需求說明書，制定測試進度。
2.測試設計階段：依據
程序設計說明書，按照必定規範化的方法進行
軟件結構劃分和設計
測試用例。
3.測試執行階段：輸入測試用例，獲得測試結果。
4.測試總結階段：對比測試的結果和
代碼的預期結果，分析錯誤緣由，找到並解決錯誤。
優缺點
1. 優勢
·迫使測試人員去仔細思考
軟件的實現
·能夠檢測
代碼中的每條分支和路徑
·揭示隱藏在代碼中的錯誤
·對代碼的測試比較完全
·最優化
2. 缺點
·昂貴 ·沒法檢測代碼中遺漏的路徑和數據敏感性錯誤
·不驗證規格的正確性
侷限
但即便每條路徑都測試了仍然可能有錯誤。第一，窮舉
路徑測試決不能查出
程序違反了設計規範，即程序自己是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
如何挑選工具
白盒測試目前主要用在具備高可靠性要求的
軟件領域，例如：軍工軟件、航天航空軟件、工業控制軟件等等。白盒測試工具在選購時應當主要是對開發語言的支持、
代碼覆蓋的深度、
嵌入式軟件的測試、測試的可視化等。
對開發語言的支持
白盒測試工具是對
源代碼進行的測試，測試的主要內容包括
詞法分析與
語法分析、
靜態
錯誤分析、動態檢測等。可是對於不一樣的開發語言，測試工具實現的方式和內容差異是較大的。目前測試工具主要支持的開發語言包括：標準C、C++、Visual C++、Java、Visual J++等。
代碼的覆蓋深度
從覆蓋源
程序語句的詳盡程度分析，
邏輯覆蓋標準包括如下不一樣的覆蓋標準：語句覆蓋、斷定覆蓋、
條件覆蓋、條件斷定組合覆蓋、多條件覆蓋和修正
斷定條件覆蓋。
·語句覆蓋 爲了暴露程序中的錯誤，程序中的每條語句至少應該執行一次。所以語句覆蓋（Statement Coverage）的含義是：選擇足夠多的測試數據，使被測程序中每條語句至少執行一次。語句覆蓋是很弱的邏輯覆蓋。
·
斷定覆蓋 比
語句覆蓋稍強的覆蓋標準是斷定覆蓋（Decision Coverage）。斷定覆蓋的含義是：設計足夠的
測試用例，使得程序中的每一個斷定至少都得到一次「真值」或「假值」，或者說使得程序中的每個取「真」分支和取「假」分支至少經歷一次，所以斷定覆蓋又稱爲
分支覆蓋。
·條件覆蓋 在
設計程序中，一個斷定語句是由多個條件組合而成的複合斷定。爲了更完全地實現邏輯覆蓋，能夠採用條件覆蓋（Condition Coverage）的標準。條件覆蓋的含義是：構造一組測試用例，使得每一斷定語句中每一個邏輯條件的可能值至少知足一次。
·多條件覆蓋 多條件覆蓋也稱
條件組合覆蓋，它的含義是：設計足夠的測試用例，使得每一個斷定中條件的各類可能組合都至少出現一次。顯然知足多條件覆蓋的測試用例是必定知足斷定覆蓋、條件覆蓋和條件斷定組合覆蓋的。
·修正條件斷定覆蓋 修正條件斷定覆蓋是由歐美的航空/航天製造廠商和使用單位聯合制定的「航空運輸和裝備系統
軟件認證標準」，目前在國外的國防、航空航天領域應用普遍。這個覆蓋度量須要足夠的測試用例來肯定各個條件可以影響到包含的斷定的結果。它要求知足兩個條件：首先，每個
程序模塊的入口和出口點都要考慮至少要被調用一次，每一個程序的斷定到全部可能的結果值要至少轉換一次；其次，程序的斷定被分解爲經過邏輯操做符（and、or）鏈接的
布爾條件，每一個條件對於斷定的結果值是獨立的。
不一樣的測試工具對於
代碼的覆蓋能力也是不一樣的，一般可以支持修正條件斷定覆蓋的測試工具價格是極其昂貴的。
嵌入式軟件的測試
對於
嵌入式軟件的測試，咱們還須要一方面進一步考慮測試工具對於
嵌入式操做系統的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另外一方面還須要考慮測試工具對於硬件平臺的支持能力，包括是否支持全部64/32/16位CPU 和 MCU，是否能夠支持 PCI/VME/CPCI 總線。
測試的可視化
白盒測試是工做量巨大而且枯燥的工做，可視化的設計對於測試來講是十分重要的。在選購白盒測試工具時，應當考慮該款測試工具的可視化是否良好，例如：
測試過程中是否能夠顯示覆蓋率的
函數分佈圖和上升趨勢圖，是否使用不一樣的顏色區分已執行和未執行的
代碼段顯示分配內存狀況實時圖表等，這些對於測試效率和測試質量的提升是具備很大的做用的。
白盒測試的測試方法中運用最爲普遍的是基本路徑測試法。
簡介
基本
路徑測試法是在程序控制流圖的基礎上，經過分析控制構造的環路複雜性，導出基本可執行
路徑集合，從而設計測試
用例的方法。
設計出的
測試用例要保證在測試中
程序的每一個可執行語句至少執行一次。
在程序控制流圖的基礎上，經過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例。包括如下4個步驟和一個工具方法：
1. 程序的
控制流圖：描述程序控制流的一種圖示方法。
2. 程序圈複雜度：McCabe複雜性度量。從程序的環路複雜性可導出程序基本路徑集合中的獨立路徑條數，這是肯定程序中每一個可執行語句至少執行一次所必須的測試用例數目的
上界。
3. 導出測試用例：根據圈複雜度和程序結構設計用例數據輸入和預期結果。
4. 準備測試用例：確保基本路徑集中的每一條路徑的執行。
工具方法
圖形
矩陣：是在基本
路徑測試中起輔助做用的
軟件工具，利用它能夠實現自動地肯定一個基本路徑集。
程序的
控制流圖：描述程序控制流的一種圖示方法。
圓圈稱爲控制流圖的一個結點，表示一個或多個無分支的語句或源
程序語句
流圖只有二種圖形符號：
圖中的每個圓稱爲流圖的結點，表明一條或多條語句。
流圖中的箭頭稱爲邊或鏈接，表明
控制流
任何過程設計都要被翻譯成控制流圖。
如何根據
程序流程圖畫出控制流程圖?
在將程序流程圖簡化成控制流圖時，應注意：
在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
邊和結點圈定的區域叫作區域，當對區域計數時，圖形外的區域也應記爲一個區域。
步驟
基本
路徑測試法的步驟：
第一步：畫出
控制流圖
流程圖用來描述程序控制結構。可將
流程圖映射到一個相應的流圖(假設流程圖的菱形決定框中不包含複合條件)。在流圖中，每個圓，稱爲流圖的結點，表明一個或多個語句。一個處理方框序列和一個菱形決測框可被映射爲一個結點，流圖中的箭頭，稱爲邊或鏈接，表明
控制流，相似於流程圖中的箭頭。一條邊必須終止於一個結點，即便該結點並不表明任何語句(例如：if-else-then結構)。由邊和結點限定的範圍稱爲區域。計算區域時應包括圖外部的範圍。
第二步：計算圈複雜度
圈複雜度是一種爲
程序邏輯複雜性提供定量測度的
軟件度量，將該度量用於計算程序的基本的獨立路徑數目，爲確保全部語句至少執行一次的測試數量的
上界。獨立路徑必須包含一條在定義以前未曾用到的邊。
有如下三種方法計算圈複雜度：
流圖中區域的數量對應於環型的複雜性;
給定流圖G的圈複雜度V(G)，定義爲V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量;
給定流圖G的圈複雜度V(G)，定義爲V(G)=P+1，P是流圖G中斷定結點的數量。
第三步：導出
測試用例 根據上面的計算方法，可得出四個獨立的路徑。(一條獨立路徑是指，和其餘的獨立路徑相比，至少引入一個新處理語句或一個新判斷的程序通路。V(G)值正好等於該程序的獨立路徑的條數。)
路徑1：4-14
路徑2：4-6-7-14
路徑3：4-6-8-10-13-4-14
路徑4：4-6-8-11-13-4-14
根據上面的獨立
路徑，去設計輸入數據，使程序分別執行到上面四條路徑。
三步法
1） 根據
代碼的功能，人工設計
測試用例進行基本
功能測試；
2） 統計白盒覆蓋率，爲未覆蓋的白盒單位設計測試用例，實現完整的白盒覆蓋，比較理想的覆蓋率是實現100%語句、條件、分支、
路徑覆蓋；
3） 自動生成大量的測試用例，捕捉"程序員未處理某些特殊輸入"造成的錯誤。
第1步的測試用例一般是現成的，由於
詳細設計文檔會規定
程序的基本功能，沒有文檔的，程序員在
編程時也要想清楚程序的功能，這些基本功能就是基本測試用例；
第2步是在第1步的基礎上，檢查未覆蓋的白盒單位，因爲未覆蓋的邏輯單位一般對應未測試的等價類，所以第2步能夠找出第1步所遺漏的測試用例；
第3步用自動
動態測試彌補第2步的固有
缺陷。
"三步法"儘可能避免重複工做，白盒方法和
黑盒方法相結合，人工方法和自動方法相補充，若是第2步的覆蓋率比較理想，那麼基本上能夠保證找出全部等價類。在開發過程容許的限度內，"三步法"已接近極限，當得起"完全測試"四個字。
與黑盒測試區別
黑盒測試
黑盒測試也稱功能測試或
數據驅動測試，它是在已知產品所應具備的功能，經過測試來檢測每一個功能是否都能正常使用，在測試時，把
程序看做一個不能打開的黑盒子，在徹底不考慮程序內部結構和內部特性的狀況下，測試者在
程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息，而且保持外部信息（如
數據庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用於
軟件
確認測試。 「黑盒」法着眼於程序外部結構、不考慮內部
邏輯結構、針對
軟件界面和軟件功能進行測試。「黑盒」法是窮舉輸入測試，只有把全部可能的輸入都做爲測試狀況使用，才能以這種方法查出程序中全部的錯誤。實際上測試狀況有無窮多個，人們不只要測試全部合法的輸入，並且還要對那些不合法可是可能的輸入進行測試。
白盒測試
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工做過程，可經過測試來檢測產品內部動做是否按照規格說明書的規定正常進行，按照
程序內部的結構
測試程序，檢驗程序中的每條通路是否都有能按預約要求正確工做，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於
軟件驗證。
「白盒」法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即便每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規範，即程序自己是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
軟件人員使用白盒測試方法，主要想對
程序模塊進行以下的檢查：
– 對程序模塊的全部獨立的執行路徑至少測試一次；
– 對全部的邏輯斷定，取 「 真 」 與取 「 假 」 的兩種狀況都至少測試一次；
– 在循環的邊界和運行界限內執行循環體；
– 測試內部
數據結構的有效性，等。
具體包含的
邏輯覆蓋有： –
語句覆蓋 –
斷定覆蓋 –
條件覆蓋 – 斷定－條件覆蓋 –
條件組合覆蓋 –
路徑覆蓋。
區別
白盒測試技術 (White Box Testing) ： 深刻到
代碼一級的測試，使用這種技術發現問題最先，效果也是最好的。該技術主要的特徵是測試
對象進入了代碼內部，根據開發人員對代碼和對
程序的熟悉程度，對有須要的部分進行在
軟件編碼階段，開發人員根據本身對代碼的理解和接觸所進行的
軟件測試叫作白盒測試。這一階段測試以
軟件開發人員爲主，在 JAVA 平臺使用 Xunit 系列工具進行測試， Xunit 測試工具是類一級的測試工具對每個類和該類的方法進行測試。
黑盒測試技術（ Black Box Testing ）：黑盒測試的內容主要有如下幾個方面，可是主要仍是功能部分。主要是覆蓋所有的功能，能夠結合兼容，
性能測試等方面進行，根據
軟件需求，設計文檔，模擬
客戶場景隨系統進行實際的測試，這種測試技術是使用最多的測試技術涵蓋了測試的方方面面，能夠考慮如下方面
c正確性 (Correctness) ：計算結果，命名等方面。
d可用性 (Usability) ：是否能夠知足
軟件的需求說明。
e邊界條件 (Boundary Condition) ：輸入部分的邊界值，就是使用通常書中說的等價類劃分，試試最大最小和非法數據等等。
f性能 (Performance) ： 正常使用的時間內系統完成一個任務須要的時間，多人同時使用的時候響應時間在能夠接受範圍內。 J2EE 技術實現的系統在性能方面更是須要照顧的，通常原則是 3 秒如下接受， 3-5 秒能夠接受， 5 秒以上就影響易用性了。若是在
測試過程中發現性能問題，修復起來是很是艱難的，由於這經常意味着程序的算法很差，結構很差，或者設計有問題。所以在產品開發的開始階段，就要考慮到軟件的性能問題
g
壓力測試 (Stress) ： 多用戶狀況能夠考慮使用壓力測試工具，建議將壓力和性能測試結合起來進行。若是有負載平衡的話還要在服務器端打開監測工具 , 查看服務器 CPU
使用率，內存佔用狀況，若是有必要能夠模擬大量數據輸入，對硬盤的影響等等信息。若是有必要的話必須進行
性能優化 ( 軟硬件均可以 ) 。這裏的壓力測試針對的是某幾項功能。
h錯誤恢復 (Error Recovery) ：錯誤處理，頁面
數據驗證，包括忽然間斷電，輸入
髒數據等。
i安全性測試 (Security) ：這個領域正在研究中，
防火牆、補丁包、
殺毒軟件等的就沒必要說了，不過能夠考慮。破壞性測試時任意看了一些
資料後得知 , 這裏面涉及到的知識、內容能夠寫本書了 , 不是一兩句能夠說清的，特別是一些商務網站，或者跟錢有關，或者和公司祕密有關的 web 更是須要這方面的測試，在外國有一種專門幹這一行的人叫安全顧問，能夠審覈代碼，提出安全建議，出現
緊急事件時的處理辦法等，在國內沒有據說哪裏有專門搞安全技術測試的內容。
j
兼容性 (Compatibility) ：不一樣
瀏覽器，不一樣應用程序版本在實現功能時的表現不一樣的上網方式，若是你測試的是一個公共網站的話。