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〉）。
***
友藏內心獨白：白箱要代碼。