測試自動化，對于系統
性能測試、負載測試等效果是明顯的，而且我們也不得不為之。
我們知道，沒有測試工具進行負載模擬，要通過手工測試完成
系統測試任務，幾乎是不可能的。但在
功能測試中，情況就大不一樣了。
手工測試在功能測試中的優勢還是比較大的，工具本身并沒有想象力和靈活性，而人對界面美觀性、邏輯合理性，容易作出判斷。
所以功能測試自動化主要的應用 在回歸測試中，而且產品的界面（UI）和功能變化較大，自動化的腳本（Script）維護成本較大，投入和產出往往變成我們最關心的問題，在功能測試中實 現測試自動化究竟是否合算？
舉個例子：假如一個功能測試用例，手工運行需要10分鐘，而為此測試用例開發腳本需要4個小時，即240分鐘，那么意味著這個測試腳本要被運行24次收回成本，如果在加上測試腳本的維護工作量（10％），需要重復運行40－50次，才收回成本。如果在產品的一個版本中要進行2－3輪測試（一般是需要的），這個產品需要發布15－20個版本才收回成本。所以業界常說，產品發布7個版本才收回成本。
如何降低成本、可以相對增加產出或者說更快地收回成本？關鍵是提高腳本開發速度、提高腳本運行的穩定性和降低維護腳本的工作量，主要方法有：
?。?選擇較好的、更適合的測試工具
?。?選擇適宜自動化的模塊
?。?盡量將腳本寫成數據驅動的腳本，這一點很重要。
?。?多錄制腳本，然后結構化腳本。我們知道，不是所有的模塊都可以變為數據驅動方式，這時就要抽象出腳本的結構，進行有效的組合，包括分層，形成有效的層次性。
?。?測試和腳本開發合二為一，效率更明顯
下表也部分說明了這個問題。也希望得到您更好的想法。
結構 | 成本 | 收益 | 凈收益 |
No Automation | 0 | 0 | 0 |
Recording and Playback | 8.3 | 11 | 2.7 |
Data-drivenstructure using data pools | 8.4 | 18 | 9.6 |
Framework structure | 9.8 | 15 | 5.2 |
Framework / data-driven (hybrid) structure focusingon views of the application and using data pools | 11.6 | 19 | 7.4 |