白盒測試方法以及歸納

白盒測試基本概念

　　白盒測試（white-box testing）又稱透明盒測試（glass box testing）、結構測試（structural testing）等，軟件測試的主要方法之一，也稱結構測試、邏輯驅動測試或基於程序本身的測試。測試應用程序的內部結構或運作，而不是測試應用程序的功能（即黑盒測試）。在白盒測試時，以編程語言的角度來設計測試案例。測試者輸入數據驗證數據流在程序中的流動路徑，並確定適當的輸出，類似測試電路中的節點。測試者瞭解待測試程序的內部結構、算法等信息，這是從程序設計者的角度對程序進行的測試。
　　白盒測試可以應用於單元測試（unit testing）、集成測試（integration testing）和系統的軟件測試流程，可測試在集成過程中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規範。

白盒測試中的六種覆蓋方法

　　白盒測試用例設計的一個很重要的評估標準就是對代碼的覆蓋度。白盒測試中常見的覆蓋方法有六種：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。下面我們就分別看看這幾種不同的覆蓋吧。

一、語句覆蓋（Statement Coverage）

　　主要特點：語句覆蓋是最起碼的結構覆蓋要求，語句覆蓋需要選擇足夠的測試用例，使我們設計出來的測試用例要保證程序中的每一個語句至少被執行一次。
　　優點：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。
　　缺點：由於這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對於隱藏的條件和可能到達的隱 式邏輯分支，是無法測試的。
　　舉例：
　　public int foo(int a,int b)
　　{
　　　 return a/b;
　　}
　　這是一個求兩數之商的函數。如果我們設計如下的測試用例：
TestCase: a =2, b =1
此時，該函數的代碼覆蓋率達到了100%，並且設計的case可以順利通過測試。但是顯然該函數有一個很明顯的bug：當 b=0 時，會拋出異常。

二、判定覆蓋（Decision Coverage）

　　主要特點：判定覆蓋又稱爲分支覆蓋，它要求選擇足夠的測試用例，使得運行這些測試用例時，每個判定的所有可能結果至少出現一次。
　　優點：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當然也就具有比語句覆蓋更強的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。
　　缺點：往往大部分的判定語句是由多個邏輯條件組合而成（如，判定語句中包含AND、OR、CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。
　　舉例：
　　
- X Y 路徑
90 90 OAE
50 50 OBDE
90 70 OBCE

三、條件覆蓋（Condition Coverage）

　　主要特點：要求所設計的測試用例能使每個判定中的每一個條件都獲得可能的取值，即每個條件至少有一次真值、有一次假值。
　　優點：顯然條件覆蓋比判定覆蓋，增加了對符合判定情況的測試，增加了測試路徑。條件覆蓋使得判定中的每一個條件都取到了不同的結果，這一點判定覆蓋則無法保證。
　　缺點：要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋並不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次爲真，而不考慮所有的判定結果。
　　舉例：
- X Y 路徑
90 70 OBC
40 OBD

四、判定條件覆蓋（Decision/Condition Coverage）

　　判定條件覆蓋，說白了就是我們設計的測試用例可以使得判斷中每個條件所有的可能取值至少執行一次（條件覆蓋），同時每個判斷本身所有的結果也要至少執行一次（判定覆蓋）。不難發現判定條件覆蓋同時滿足判定覆蓋和條件覆蓋，彌補了兩者各自的不足，但是判定條件覆蓋並未考慮條件的組合情況。

五、組合覆蓋（Branch Condition Combination Coverage）

　　組合覆蓋也叫做條件組合覆蓋。意思是說我們設計的測試用例應該使得每個判定中的各個條件的各種可能組合都至少出現一次。顯然，滿足條件組合覆蓋的測試用例一定是滿足判定覆蓋、條件覆蓋和判定條件覆蓋的。
　　針對前文提到的流程圖，做條件組合覆蓋時我們可以設計如下用例：
TestCase1: a=1, b=1 (路徑：ab)
TestCase1: a=-1, b=-1 (路徑：acd)
TestCase1: a=-1, b=0 (路徑：ace)
TestCase1: a=1, b=-1 (路徑：ace)
條件組合覆蓋能夠同時滿足判定、條件和判定條件覆蓋，覆蓋度較高，但是組合覆蓋的測試用例數量相對來說也是比較多的。

六、路徑覆蓋

　　路徑覆蓋，意思是說我們設計的測試用例可以覆蓋程序中所有可能的執行路徑。這種覆蓋方法可以對程序進行徹底的測試用例覆蓋，比前面講的五種方法覆蓋度都要高。那麼這種方法是不是就一定最好呢？當然不能講得這麼絕對，它的缺點也是顯而易見的：由於需要對所有可能的路徑全部進行覆蓋，那麼我們需要設計數量非常巨大的而且較爲複雜的測試用例，用例數量將呈現指數級的增長。所以理論上來講路徑覆蓋是最徹底的測試用例覆蓋，但實際上很多時候路徑覆蓋的可操作性不強。

總結
　　以上簡單描述了幾種不用的邏輯覆蓋方法的原則和優劣。在實際的操作中，要正確使用白盒測試的代碼覆蓋方法，就要從代碼分析和代碼調研入手，根據調研的結果，可以選擇上述方法中的某一種，或者好幾種方法的結合，設計出高效的測試用例，儘可能全面地覆蓋到代碼中的每一個邏輯路徑。