什麼樣的專案適合自動化測試

雖然，在你拿到這本書時已經對要測試的專案做了一些分析和考量，但筆者還是有必要在這裡囉嗦一下不是所有專案有適合實施自動化測試的，以免讀者對專案實施自動化過程中發現困難重重，浪費了大量的人力和時間而沒有得到應有的收益。

1、任務測試明確，不會頻繁變動

2、每日構建後的測試驗證

3、比較頻繁的回歸測試

4、軟體系統介面穩定，變動少

5、需要在多平台上執行的相同測試案例、組合遍歷型的測試、大量的重複任務

6、軟體維護周期長

7、專案進度壓力不太大

8、被測軟體系統開發比較規範，能夠保證系統的可測試性

9、具備大量的自動化測試平台

10、測試人員具備較強的程式設計能力

當然，並非以上10 條都具備有情況下才能開展測試工作。這裡就需要讀者做綜合的權衡。在我們普遍的經驗中，只要滿足三個條件就可以對專案開展自動化測試：

軟體需求程式設計不頻繁

測試指令碼的穩定性決定了自動化測試的維護成本。如果軟體需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試指令碼，而指令碼的維護本身就是乙個**開發的過程，需要修改、除錯，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。

專案中的某些模組相對穩定，而某些模組需求變動性很大。我們便可對相對穩定的模組進行自動化測試，而變動較大的仍是用手工測試。

專案週期較長

由於自動化測試需求的確定、自動化測試框架的設計、測試指令碼的編寫與除錯均需要相當長的時間來完成。這樣的過程本身就是乙個測試軟體的開發過程，需要較長的時間來完成。如果專案的週期比較短，沒有足夠的時間去支援這樣乙個過程，那麼自動化測試便成為笑談。

自動化測試指令碼可重複使用

自動化測試指令碼的重複使用要從三個方面來考量，一方面所測試的專案之間是否很大的差異性（如c/s 系統和b/s 系統的差異）；所選擇的測試工具是否適應這種差異；最後，測試人員是否有能力開發出適應這種差異的自動化測試框架。