白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法,盒子指的是被測試的軟體,白盒指的是盒子是可視的,你清楚盒子內部的東西以及裡面是如何運作的。"白盒"法全面了解程式內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時,測試者必須檢查程式的內部結構,從檢查程式的邏輯著手,得出測試數據。貫穿程式的獨立路徑數是天文數字。
採用什麼方法對軟體進行測試呢?常用的軟體測試方法有兩大類:靜態測試方法和動態測試方法。其中軟體的靜態測試不要求在計算機上實際執行所測程式,主要以一些人工的模擬技術對軟體進行分析和測試;而軟體的動態測試是通過輸入一組預先按照一定的測試準則構造的實例數據來動態運行程式,而達到發現程式錯誤的過程。在動態分析技術中,最重要的技術是路徑和分支測試。下面要介紹的六種覆蓋測試方法屬於動態分析方法。
基本介紹
- 中文名:白盒測試
- 外文名:white-box testing
- 別稱:結構測試、透明盒測試
- 主要類別:測試
- 釋義:一種測試用例設計方法
測試方法,要求,目的,特點,實施步驟,優缺點,優點,缺點,局限,工具挑選,語言支持,覆蓋深度,嵌入式測試,可視化,測試方法,工具方法,步驟,相關區別,黑盒測試概述,區別,三步法,
測試方法
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。
要求
1.保證一個模組中的所有獨立路徑至少被使用一次。
2.對所有邏輯值均需測試 true 和 false。
3.在上下邊界及可操作範圍內運行所有循環。
4.檢查內部數據結構以確保其有效性。
目的
通過檢查軟體內部的邏輯結構,對軟體中的邏輯路徑進行覆蓋測試;在程式不同地方設立檢查點,檢查程式的狀態,以確定實際運行狀態與預期狀態是否一致。
特點
依據軟體設計說明書進行測試、對程式內部細節的嚴密檢驗、針對特定條件設計測試用例、對軟體的邏輯路徑進行覆蓋測試。
實施步驟
1.測試計畫階段:根據需求說明書,制定測試進度。
2.測試設計階段:依據程式設計說明書,按照一定規範化的方法進行軟體結構劃分和設計測試用例。
3.測試執行階段:輸入測試用例,得到測試結果。
4.測試總結階段:對比測試的結果和代碼的預期結果,分析錯誤原因,找到並解決錯誤。
優缺點
優點
1.迫使測試人員去仔細思考軟體的實現
2.可以檢測代碼中的每條分支和路徑
3.揭示隱藏在代碼中的錯誤
4.對代碼的測試比較徹底
5.最最佳化
缺點
1.昂貴
2.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
3.不驗證規格的正確性
局限
但即使每條路徑都測試了仍然可能有錯誤。可能出現的情況如下:
- 窮舉路徑測試決不能查出程式違反了設計規範,即程式本身是個錯誤的程式。
- 窮舉路徑測試不可能查出程式中因遺漏路徑而出錯。
- 窮舉路徑測試可能發現不了一些與數據相關的錯誤。
工具挑選
白盒測試主要用在具有高可靠性要求的軟體領域,例如:軍工軟體、航天航空軟體、工業控制軟體等等。白盒測試工具在選購時應當主要是對開發語言的支持、代碼覆蓋的深度、嵌入式軟體的測試和測試的可視化等。
語言支持
白盒測試工具是對原始碼進行的測試,測試的主要內容包括詞法分析與語法分析、靜態錯誤分析、動態檢測等。但是對於不同的開發語言,測試工具實現的方式和內容差別是較大的。測試工具主要支持的開發語言包括:標準C、C++、Visual C++、Java和Visual J++等。
覆蓋深度
1.語句覆蓋 為了暴露程式中的錯誤,程式中的每條語句至少應該執行一次。因此語句覆蓋(Statement Coverage)的含義是:選擇足夠多的測試數據,使被測程式中每條語句至少執行一次。語句覆蓋是很弱的邏輯覆蓋。
2.判定覆蓋比語句覆蓋稍強的覆蓋標準是判定覆蓋(Decision Coverage)。判定覆蓋的含義是:設計足夠的測試用例,使得程式中的每個判定至少都獲得一次“真值”或“假值”,或者說使得程式中的每一個取“真”分支和取“假”分支至少經歷一次,因此判定覆蓋又稱為分支覆蓋。
3.條件覆蓋在設計程式中,一個判定語句是由多個條件組合而成的複合判定。為了更徹底地實現邏輯覆蓋,可以採用條件覆蓋(Condition Coverage)的標準。條件覆蓋的含義是:構造一組測試用例,使得每一判定語句中每個邏輯條件的可能值至少滿足一次。
4.多條件覆蓋。多條件覆蓋也稱條件組合覆蓋,它的含義是:設計足夠的測試用例,使得每個判定中條件的各種可能組合都至少出現一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
嵌入式測試
對於嵌入式軟體的測試,我們還需要一方面進一步考慮測試工具對於嵌入式作業系統的支持能力,例如DOS、Vxworks、Neculeus、Linux和Windows CE等;另一方面還需要考慮測試工具對於硬體平台的支持能力,包括是否支持所有64/32/16位CPU 和 MCU,是否可以支持 PCI/VME/CPCI 匯流排。
可視化
白盒測試是工作量巨大並且枯燥的工作,可視化的設計對於測試來說是十分重要的。在選購白盒測試工具時,應當考慮該款測試工具的可視化是否良好,例如:測試過程中是否可以顯示覆蓋率的函式分布圖和上升趨勢圖,是否使用不同的顏色區分已執行和未執行的代碼段顯示分配記憶體情況實時圖表等,這些對於測試效率和測試質量的提高是具有很大的作用的。
測試方法
白盒測試的測試方法中運用最為廣泛的是基本路徑測試法。
工具方法
2.程式的控制流圖:描述程式控制流的一種圖示方法。
流圖只有二種圖形符號:
1.圖中的每一個圓稱為流圖的結點,代表一條或多條語句。
1.在選擇或多分支結構中,分支的匯聚處應有一個匯聚結點。
2.邊和結點圈定的區域叫做區域,當對區域計數時,圖形外的區域也應記為一個區域。
步驟
基本路徑測試法的步驟:
第一步:畫出控制流圖
第二步:計算圈複雜度
有以下三種方法計算圈複雜度:
流圖中區域的數量對應於環型的複雜性;
給定流圖G的圈複雜度V(G),定義為V(G)=E-N+2,E是流圖中邊的數量,N是流圖中結點的數量;
給定流圖G的圈複雜度V(G),定義為V(G)=P+1,P是流圖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.對所有的邏輯判定,取 “ 真 ” 與取 “ 假 ” 的兩種情況都至少測試一次;
3.在循環的邊界和運行界限內執行循環體;
4.測試內部數據結構的有效性,等。
具體包含的邏輯覆蓋有: –語句覆蓋–判定覆蓋–條件覆蓋– 判定-條件覆蓋 –條件組合覆蓋–路徑覆蓋。
區別
白盒測試技術 (White Box Testing) : 深入到代碼一級的測試,使用這種技術發現問題最早,效果也是最好的。該技術主要的特徵是測試對象進入了代碼內部,根據開發人員對代碼和對程式的熟悉程度,對有需要的部分進行在軟體編碼階段,開發人員根據自己對代碼的理解和接觸所進行的軟體測試叫做白盒測試。這一階段測試以軟體開發人員為主,在 JAVA 平台使用 Xunit 系列工具進行測試, Xunit 測試工具是類一級的測試工具對每一個類和該類的方法進行測試。
黑盒測試技術( Black Box Testing ):黑盒測試的內容主要有以下幾個方面,但是主要還是功能部分。主要是覆蓋全部的功能,可以結合兼容,性能測試等方面進行,根據軟體需求,設計文檔,模擬客戶場景隨系統進行實際的測試,這種測試技術是使用最多的測試技術涵蓋了測試的方方面面,可以考慮以下方面:
1.正確性 (Correctness) :計算結果,命名等方面。
2.可用性 (Usability) :是否可以滿足軟體的需求說明。
3.邊界條件 (Boundary Condition) :輸入部分的邊界值,就是使用一般書中說的等價類劃分,試試最大最小和非法數據等等。
4.性能 (Performance) : 正常使用的時間內系統完成一個任務需要的時間,多人同時使用的時候回響時間在可以接受範圍內。 J2EE 技術實現的系統在性能方面更是需要照顧的,一般原則是 3 秒以下接受, 3-5 秒可以接受, 5 秒以上就影響易用性了。如果在測試過程中發現性能問題,修復起來是非常艱難的,因為這常常意味著程式的算法不好,結構不好,或者設計有問題。因此在產品開發的開始階段,就要考慮到軟體的性能問題
5.壓力測試(Stress) : 多用戶情況可以考慮使用壓力測試工具,建議將壓力和性能測試結合起來進行。如果有負載平衡的話還要在伺服器端打開監測工具 , 查看伺服器 CPU使用率,記憶體占用情況,如果有必要可以模擬大量數據輸入,對硬碟的影響等等信息。如果有必要的話必須進行性能最佳化( 軟硬體都可以 ) 。這裡的壓力測試針對的是某幾項功能。
7.安全性測試 (Security) :這個領域正在研究中,防火牆、補丁包、防毒軟體等的就不必說了,不過可以考慮。破壞性測試時任意看了一些資料後得知 , 這裡面涉及到的知識、內容可以寫本書了 , 不是一兩句可以說清的,特別是一些商務網站,或者跟錢有關,或者和公司秘密有關的 web 更是需要這方面的測試,在外國有一種專門幹這一行的人叫安全顧問,可以審核代碼,提出安全建議,出現緊急事件時的處理辦法等,在國內沒有聽說哪裡有專門搞安全技術測試的內容。
8.兼容性(Compatibility) :不同瀏覽器,不同應用程式版本在實現功能時的表現不同的上網方式,如果你測試的是一個公共網站的話。
三步法
3. 自動生成大量的測試用例,捕捉"程式設計師未處理某些特殊輸入"形成的錯誤。
第2步是在第1步的基礎上,檢查未覆蓋的白盒單位,由於未覆蓋的邏輯單位通常對應未測試的等價類,因此第2步可以找出第1步所遺漏的測試用例;
"三步法"儘量避免重複工作,白盒方法和黑盒方法相結合,人工方法和自動方法相補充,如果第2步的覆蓋率比較理想,那么基本上可以保證找出所有等價類。在開發過程允許的限度內,"三步法"已接近極限,當得起"徹底測試"四個字。