白箱測試與黑箱測試（上）

May 29 06:58~08:06

 

今天和明天這兩集來談一個老掉牙的主題：白箱測試（white-box testing）與黑箱測試（black-box testing）。白箱測試又稱為，透明箱測試（glass box testing），鄉民們可以想像一下，把待測物（程式碼）放在一個白色（透明玻璃）盒子裡面，測試者在可以看到待測物內部結構的情況之下來執行測試。因為可以看到待測物，也就是程式碼的內部結構所設計與執行的測試，因此白箱測試又稱為結構測試（structural testing）或邏輯驅動測試（logic-driven testing）--看著程式的結構與邏輯來設計與執行測試案例。

在討論要寫多少（白箱測試）測試案例才足夠的問題時（test case adequacy criteria），可以從測試案例涵蓋多少待測程式的控制流（control-flow）或資料流（data-flow）來判斷。前者衍生出敘述涵蓋率（statement coverage）、分支涵蓋率（branch coverage）等測量測試案例走過多少程式執行路徑（execution path）比例的方法。後者關注資料的定義（definition）、使用（use）與釋放（kill）之間的各種路徑，包含All-du-paths（所有定義-使用路徑）、All-uses（所有使用路徑）、All-defs（所有定義-釋放路徑）、All-c-uses（所有計算使用）、All-p-uses（所有斷言使用）、All-c-uses/some-p-uses（所有計算使用/部分斷言使用）、All-p-uses/some-c-uses（所有斷言使用/部分計算使用）等一堆奇奇怪怪的涵蓋率。

***

看到這邊要考鄉民們一個問題：「從白箱測試的角度來看，如果測試案例很難寫怎麼辦？」

因為白箱測試要想辦法涵蓋程式各種可能的執行路徑，所以測試案例很難寫，通常也就隱含著程式的複雜度（complexity）太高，例如過於複雜的控制流程（很長的if-then-else條件式、三層for迴圈、設計不良的例外處理結構等）。要讓白箱測試比較好做，首要之務就是要降低結構複雜度（structural complexity）。其次，則是要避免不可決定性（non-determinism），也就是要避免時好時壞的測試案例（請參考〈對付時好時壞的測試案例(1)：還沒痊癒，就先隔離〉、〈對付時好時壞的測試案例(2)：Lack of Isolation〉、〈對付時好時壞的測試案例(3)：Asynchronous Behavior〉、〈對付時好時壞的測試案例(4)：Remote Services〉、〈對付時好時壞的測試案例(5)：Time〉）。

***

友藏內心獨白：白箱要代碼。