海量測試用例如何優化:用狀態矩陣解決有序操作的case爆炸問題(2)

　　說白了，上面狀態圖里的各種可能組合，都可以發生，用戶可以沿著箭頭所指的方向，不停的走下去。如果我們有某種組合沒有測到，可能發生一些異常。

　　為了避免異常的發生，我們要測試盡量多的組合。組合的覆蓋率要達到怎樣的程度?

　　根據pairwise[3]的理論，90%以上的bug都是由兩兩成對的操作導致的。而在網站ajax頁面測試中，可能這個數值會稍低一些。依據經驗，我們發現大于兩步操作的bug還是有一定數量，但是一定要大于三步操作才能發現的bug則很少。

　　因此我們暫時將覆蓋率“拍”為“覆蓋所有的三步操作組合”。如果測試設計能夠達到這個覆蓋率，那應當是非常全面了。

　　我們先制定這樣一個覆蓋率目標，事實上這個三步可以理解為N步，只是一個宏定義，再看怎么能簡化。

　　3. 怎樣達到這個覆蓋率?

　　目標是“覆蓋所有三步操作”，有了上面的狀態圖，通過遍歷狀態圖，就可以做到了。畫狀態圖，是不是有點麻煩?

　　進一步，將狀態圖抽象一下，用狀態矩陣來表示，遍歷這個狀態矩陣，就可以窮盡三步操作。

　　那首先要完成狀態矩陣這個體力活，根據上面的狀態圖，圖中的頁面用0-9來表示，從行號到列號，可以轉換為1，不可以轉換為0。

　　我們可以得出如下的矩陣：

　　接下來用程序遍歷這個矩陣，找出所有2步及3步的操作，可以得到162個組合case：

　　0 1

　　0 2

　　0 3

　　0 4

　　0 2 1

　　0 2 3

　　0 2 4

　　0 2 6

　　0 3 1

　　0 3 2

　　0 3 4

　　0 3 7

　　0 4 1

　　0 4 2

　　0 4 3

　　0 4 7

　　2 1

　　2 3

　　2 4

　　2 6

　　。。。。

　　有了這些case，覆蓋率一定很全了。

　　4. 如何縮減這些case

　　覆蓋率目標達到了，但是有162個case，除了單個頁面的功能驗證，我們還要進行這么多的組合case測試，工作量太大。那么如何縮減這些case?

　　觀察這些case，如果我們挨個做，很多步驟是重復的。例如，上面有這樣4個case：

　　0 3 2

　　3 2 4

　　2 4 7

　　4 7 4

　　這4個case可以首尾相接，變成 0 3 2 4 7 4。把case中有重復的步驟合起來，4個case變成了一個case。

　　這個思路不錯!按照這個思路，我們可以將case合并起來，4合1，case數量大大縮減。

　　當然，不會那么巧，所有的case都能4合1、3合1，我們還會有些疑問：

　　1. 是不是所有的case都可以合并? 還是上面的例子只是個特例?

　　2. 合并到什么程度?是否需要把10多個三步操作都合并起來，得到一個20多步的操作? 這個問題經過討論，一般認為操作步驟在6~8步比較合理，組合的case不是很大，所能驗證的內容也比較多，對于測試人員來講是最“舒服”的。

　　這個思路是不是可行，我們先合并一下試試看!

　　5. 合并后的結果

　　有了思路就開始做。

　　先嘗試一下把這162個小于3步的操作合并成一些6步的操作。我們采用這樣的算法：

　　1. 先算出所有6步操作，記為集合A; 將所有小于等于3步操作的集合記為B;集合C為最終結果集合，目前是空集;

　　2. 算出每一個6步操作能夠包含幾個2-3步的case，并將包含最大值記為max;

　　3. 如果max>1，則將能夠取得max值的那個6步操作，加入集合C;把這個6步操作和其所包含的2-3步操作從各自的集合中刪除;返回2繼續;

　　4. 如果max=1，則將集合B中剩余的元素全部加入C中，得到結果集合C，退出

　　簡言之，算法會從所有6步操作的集合中選出能夠包含這162個case的最小集合，其中可能有部分case無法合并，無法合并的case直接進入結果集。這個算法可能不是最優的，但是已經盡可能找到了那個最小集。

　　經過算法合并以后，得出了如下結果：

　　用多步操作來合成3步操作，需要 35個case，這35個case覆蓋了162個case中的151個：

　　0 2 3 2 3 4

　　0 3 7 2 4 1

　　0 4 2 6 2 1

　　4 7 5 8 4 3

　　2 6 5 9 5 1

　　5 2 6 3 7 1

　　5 3 7 3 7 4

　　5 4 3 2 6 1

　　。。。。。。

　　剩余11個case無法組合：

　　0 1

　　0 2 1

　　0 3 1

　　0 4 1

　　8 2 3

　　8 2 4

　　8 3 1

　　8 3 4

　　8 4 1

　　8 4 2

　　9 5 2

　　這些無法組合的case，是因為有的狀態沒有出路，走到這里就會終結了。

　　于是，我們用35個6步的case，覆蓋了原來162個case中的151個，剩余11個case，需要再單獨驗證一下?？俢ase數為35+11=46個，在可以接受的范圍內。

　　我們同樣可以嘗試用5步操作或7步操作來覆蓋2-3步的操作，這里的2-3步也好，6步也好，都可以看作是宏定義，效果相似，case數稍有變化。我們可以嘗試幾個參數，找到覆蓋率和工作量的最佳組合。

　　6. 人力成本分析

　　在整個過程中，需要人力投入的工作只有最初的狀態矩陣，對于某個網站來說，這個狀態矩陣相對穩定，變化不大，后期維護代價也比較小。

　　將狀態矩陣拷貝為txt格式，即可作為程序的輸入，執行程序即可得到操作序列。將矩陣的title也讀入，直接把序列號替換為title，就可以直接當做case來用了。

　　有了這樣的一組case，我們就可以避免依賴經驗的測試或隨機測試，又能保證覆蓋率了。

　　五、 總結

　　如上所述，我們用遍歷狀態矩陣的方法，首先得到了所有2-3步操作組合。這一個“爆炸”的case集包括162個用例。通過case組合的方式，將162個測試用例變成了35+11=46個測試用例，在保證case覆蓋率的同時，縮減case數到一個可測試的范圍內。

原文轉自：http://www.kjueaiud.com