白盒測試(邏輯驅動測試)

白盒測試

邏輯驅動測試一般指本詞條

白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法,盒子指的是被測試的軟體,白盒指的是盒子是可視的,即清楚盒子內部的東西以及裡面是如何運作的。“白盒”法全面了解程式內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這一方案時,測試者必須檢查程式的內部結構,從檢查程式的邏輯著手,得出測試數據。貫穿程式的獨立路徑數是天文數字。

基本介紹

  • 中文名:白盒測試
  • 外文名:white-box testing
  • 別名:結構測試、透明盒測試
  • 主要類別測試
  • 釋義:一種測試用例設計方法
簡介,目的,原則,實施階段,分類,三步法,工具挑選,語言支持,覆蓋深度,嵌入式測試,可視化,測試方法,優缺點,優點,缺點,與黑盒測試區別,

簡介

白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程式變異。
白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋判定覆蓋條件覆蓋、判定/條件覆蓋、條件組合覆蓋修改條件判斷覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化:
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.修改條件判斷覆蓋每一個判斷的所有可能結果都出現過、每一個判斷中所有條件的所有可能結果都出現過、每一個進入點及結束點都執行過、判斷中每一個條件都可以獨立的影響判斷的結果。

目的

通過檢查軟體內部的邏輯結構,對軟體中的邏輯路徑進行覆蓋測試。在程式不同地方設立檢查點,檢查程式的狀態,以確定實際運行狀態與預期狀態是否一致。

原則

(1)一個模組中的所有獨立路徑至少被測試一次。
(2)所有邏輯值均需測試true和false兩種情況。
(3)檢查程式的內部數據結構,保證其結構的有效性。
(4)在取值的上、下邊界及可操作範圍內運行所有循環。

實施階段

1.測試計畫階段:根據需求說明書,制定測試進度。
2.測試設計階段:依據程式設計說明書,按照一定規範化的方法進行軟體結構劃分和設計測試用例。
3.測試執行階段:輸入測試用例,得到測試結果。
4.測試總結階段:對比測試的結果和代碼的預期結果,分析錯誤原因,找到並解決錯誤。

分類

白盒測試的方法總體上分為靜態分析方法和動態分析方法兩大類。
靜態分析是一種不通過執行程式而進行測試的技術。靜態分析的關鍵功能是檢查軟體的表示和描述是否一致,有無衝突或者歧義。
動態分析是當軟體系統在模擬的或真實的環境中執行之前、之中和之後,對軟體系統行為的分析。動態分析包含了程式在受控的環境下使用特定的期望結果進行正式的運行。它顯示了一個系統在檢查狀態下是正確還是不正確。在動態分析技術中,最重要的技術是路徑和分支測試。

三步法

1. 根據代碼的功能,人工設計測試用例進行基本功能測試
2. 統計白盒覆蓋率,為未覆蓋的白盒單位設計測試用例,實現完整的白盒覆蓋,比較理想的覆蓋率是實現100%語句、條件、分支、路徑覆蓋
3. 自動生成大量的測試用例,捕捉“程式設計師未處理某些特殊輸入”形成的錯誤。
第1步的測試用例通常是現成的,因為詳細設計文檔會規定程式的基本功能,沒有文檔的,程式設計師在編程時也要想清楚程式的功能,這些基本功能就是基本測試用例;
第2步是在第1步的基礎上,檢查未覆蓋的白盒單位,由於未覆蓋的邏輯單位通常對應未測試的等價類,因此第2步可以找出第1步所遺漏的測試用例
第3步用自動動態測試彌補第2步的固有缺陷
“三步法”儘量避免重複工作,白盒方法和黑盒方法相結合,人工方法和自動方法相補充,如果第2步的覆蓋率比較理想,那么基本上可以保證找出所有等價類。在開發過程允許的限度內,“三步法”已接近極限,當得起“徹底測試”四個字。

工具挑選

白盒測試主要用在具有高可靠性要求的軟體領域,例如:軍工軟體、航天航空軟體、工業控制軟體等等。白盒測試工具在選購時應當主要是對開發語言的支持、代碼覆蓋的深度、嵌入式軟體的測試和測試的可視化等。

語言支持

白盒測試工具是對原始碼進行的測試,測試的主要內容包括詞法分析語法分析靜態錯誤分析、動態檢測等。但是對於不同的開發語言,測試工具實現的方式和內容差別是較大的。測試工具主要支持的開發語言包括:標準C、C++、Visual C++、Java和Visual J++等。

覆蓋深度

從覆蓋源程式語句的詳盡程度分析,邏輯覆蓋標準包括以下不同的覆蓋標準:語句覆蓋判定覆蓋條件覆蓋、條件判定組合覆蓋、多條件覆蓋和修正判定條件覆蓋
1.語句覆蓋 為了暴露程式中的錯誤,程式中的每條語句至少應該執行一次。因此語句覆蓋(Statement Coverage)的含義是:選擇足夠多的測試數據,使被測程式中每條語句至少執行一次。語句覆蓋是很弱的邏輯覆蓋
2.判定覆蓋語句覆蓋稍強的覆蓋標準是判定覆蓋(Decision Coverage)。判定覆蓋的含義是:設計足夠的測試用例,使得程式中的每個判定至少都獲得一次“真值”或“假值”,或者說使得程式中的每一個取“真”分支和取“假”分支至少經歷一次,因此判定覆蓋又稱為分支覆蓋
3.條件覆蓋設計程式中,一個判定語句是由多個條件組合而成的複合判定。為了更徹底地實現邏輯覆蓋,可以採用條件覆蓋(Condition Coverage)的標準。條件覆蓋的含義是:構造一組測試用例,使得每一判定語句中每個邏輯條件的可能值至少滿足一次。
4.多條件覆蓋。多條件覆蓋也稱條件組合覆蓋,它的含義是:設計足夠的測試用例,使得每個判定中條件的各種可能組合都至少出現一次。顯然滿足多條件覆蓋測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
5.修正條件判定覆蓋。修正條件判定覆蓋是由歐美的航空/航天製造廠商和使用單位聯合制定的“航空運輸和裝備系統軟體認證標準”,在國外的國防、航空航天領域套用廣泛。這個覆蓋度量需要足夠的測試用例來確定各個條件能夠影響到包含的判定的結果。它要求滿足兩個條件:首先,每一個程式模組的入口和出口點都要考慮至少要被調用一次,每個程式的判定到所有可能的結果值要至少轉換一次;其次,程式的判定被分解為通過邏輯操作符(and、or)連線的布爾條件,每個條件對於判定的結果值是獨立的。
不同的測試工具對於代碼的覆蓋能力也是不同的,通常能夠支持修正條件判定覆蓋的測試工具價格是極其昂貴的。

嵌入式測試

對於嵌入式軟體的測試,我們還需要一方面進一步考慮測試工具對於嵌入式作業系統的支持能力,例如DOS、Vxworks、Neculeus、Linux和Windows CE等;另一方面還需要考慮測試工具對於硬體平台的支持能力,包括是否支持所有64/32/16位CPU 和 MCU,是否可以支持 PCI/VME/CPCI 匯流排。

可視化

白盒測試是工作量巨大並且枯燥的工作,可視化的設計對於測試來說是十分重要的。在選購白盒測試工具時,應當考慮該款測試工具的可視化是否良好,例如:測試過程中是否可以顯示覆蓋率的函式分布圖和上升趨勢圖,是否使用不同的顏色區分已執行和未執行的代碼段顯示分配記憶體情況實時圖表等,這些對於測試效率和測試質量的提高是具有很大的作用的。

測試方法

白盒測試的測試方法中運用最為廣泛的是基本路徑測試法。
基本路徑測試法是在程式控制流圖的基礎上,通過分析控制構造的環路複雜性,導出基本可執行路徑集合,從而設計測試用例的方法。設計出的測試用例要保證在測試中程式的每個可執行語句至少執行一次。
程式控制流圖的基礎上,通過分析控制構造的環路複雜性,導出基本可執行路徑集合,從而設計測試用例。包括以下4個步驟和一個工具方法:
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)可以檢測代碼中的每條分支和路徑
(3)揭示隱藏在代碼中的錯誤。
(4)對代碼的測試比較徹底。
(5)讓軟體最最佳化。

缺點

(1)昂貴。
(2)無法檢測代碼中遺漏的路徑和數據敏感性錯誤。
(3)不驗證規格的正確性。

與黑盒測試區別

白盒測試技術(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使用率,記憶體占用情況,如果有必要可以模擬大量數據輸入,對硬碟的影響等等信息。如果有必要的話必須進行性能最佳化(軟硬體都可以)。這裡的壓力測試針對的是某幾項功能。
6.錯誤恢復(Error Recovery):錯誤處理,頁面數據驗證,包括突然間斷電,輸入髒數據等。
7.安全性測試(Security):這個領域正在研究中,防火牆、補丁包、防毒軟體等的就不必說了,不過可以考慮。破壞性測試時任意看了一些資料後得知 , 這裡面涉及到的知識、內容可以寫本書了 , 不是一兩句可以說清的,特別是一些商務網站,或者跟錢有關,或者和公司秘密有關的web更是需要這方面的測試,在外國有一種專門幹這一行的人叫安全顧問,可以審核代碼,提出安全建議,出現緊急事件時的處理辦法等,在國內沒有聽說哪裡有專門搞安全技術測試的內容。
8.兼容性(Compatibility):不同瀏覽器,不同應用程式版本在實現功能時的表現不同的上網方式,如果你測試的是一個公共網站的話。

熱門詞條

聯絡我們