自動化測試的另外一個想法

傳統的 ，都是先編寫 、編寫測試指令碼，然後做引數化、檢查點，透過批次執行來發現問題。

 

傳統方式的問題在於：

1，對測試工程師要求比較高。大多數的測試工程師並不會編寫測試指令碼，從而導致 開展比較困難；

2，測試的投入很大。我們需要搭建 ，一次執行海量的自動化測試用例，才會比較有效果。但是這樣做會導致投入很大。

3，測試用例的覆蓋率不足。由於編寫測試用例的代價比較高，因此導致自動化測試的用例相對比較少，造成覆蓋率不足。從實踐的情況來看，往往只能夠覆蓋到主要的、正確的流程，對於比較少的分支，比較難以覆蓋。

 

有沒有其他的方法，來提升自動化測試的範圍？

我們知道，自動化測試的優勢在於：1）執行的代價小，執行速度快；2）適合海量執行用例，比較能夠覆蓋到各個分支。但是，由於測試用例設計的問題，以及執行方式的問題，從而導致自動化測試使用的效果不佳。

 

因此，我們是否可以參照appscan等 的做法，來解決以上的問題？大概的想法是：

1，測試指令碼仍然需要，因為沒有測試指令碼，就無法進行自動化執行；

2，引數化，以及在引數化之後，對各個輸入欄位的輸入範圍進行描述和約束；

3，允許使用者定義各種規則，用來生成海量的測試用例；

4，海量執行。生成的測試用例，可能達到幾萬到幾十萬條。如果使用介面測試，可能需要執行幾個小時，甚至十幾個小時，執行所有的自動生成的測試用例；

5，能夠自動判定是否執行失敗。這就需要預先定義規則，對執行的結果，使用規則進行判定，來決定測試用例是否執行失敗。

6，人工複核。人工來篩選和檢視測試用例，看是否存在漏測、誤報的情況。

 

我們希望透過這樣的方法，來單個的執行，生成海量的 ，並且同步進行執行。當執行完成，我們也可以從中篩選出有效的、典型的測試用例，加入到常用的測試用例庫中，用來執行迴歸測試。

推薦閱讀：