從軟件開發角度看全對偶測試法

今天在InfoQ上看到一篇文章：組合測試法中的全對偶測試法，受教之餘，想從單元測試的角度談談我的看法。

原文寫道：

现在我们假设存在3个变量：V1、V2、V3，V1变量存在3个值：A、B、C；V2变量存在2个值：D、E；V3变量存在2个值：F、G。按照组合测试法，可以组合出3*2*2 = 12种情况，也就是可以设计出12个测试用例。如果3个变量都存在5个不同的值的话，那就可以组合出5*5*5 = 125种情况，也就是需要设计出125个测试用例。测试专家James Bach使用全对偶测试法(All Pairs)将这125个测试用例压缩成25个测试用例，从理论上来覆盖变量组合的测试覆盖率，全对偶测试法有个基本的原则是每个变量的每个取值都要与至少一个用例中的每个其他变量的每个取值配对。

我的第一個反應是：“這怎麼可能？”。既然是排列組合，那麼每一種組合都具備了獨特的信息，總信息量一定的話，又如何能壓縮呢？

看了後邊的示例，我才明白，原文的測試方法做了一個小小的假設：測試僅僅考慮任意兩個參數組合後導致的故障，不存在由於三個或更多的參數組合後引發的故障。以前述的例子說，就是V1=A, V2=D要是會引發故障的話，那麼V3隨便取哪個值都不重要。如果通過特定的排列組合使得V1=A, V2=D的測試只進行一次的話，那麼整個測試過程就被壓縮了。

嗯，看來這不是我會感興趣的測試方法。

原以為可以學到關於軟件測試尤其是單元測試的新觀點，結果發現這是個可能僅僅適用於（I could be wrong.）硬件後期測試和軟件的集成、系統測試。

在單元測試中，不要使用全對偶測試法

原因很簡單：對於從邏輯上符合“僅存在任意兩個參數組合後導致的故障，不存在由於三個或更多的參數組合後引發的故障”這樣的前提的話，那麼應該對任意兩個參數分別進行組合式測試。否則，日後重構的時候很可能就對為什麼三個參數放在一起感到迷惑。而對於不滿足該前提的組合測試案例，全對偶測試將遺漏數以千萬計的組合情況，還不如不測試。

PS. 其實寫程序不會用到太多組合測試，因為通常問題都是界樁錯誤，邊界檢驗更為合適

PS II. 所以想想其實硬件測試真的是非常辛苦，讓我來做，可能是在硬件崩潰前我就會宕機了吧。