測試自動化，對於系統效能測試、負載測試等效果是明顯的，而且我們也不得不為之。我們知道，沒有測試工具
進行負載模擬，要通過手工測試完成系統測試任務，幾乎是不可能的。但在功能測試中，情況就大不一樣了。
手工測試在功能測試中的優勢還是比較大的，我在「測試方法的辯證統一（之二）」已做了討論，工具本身並沒有想象力和靈活性，而人對介面美觀性、邏輯合理性，容易作出判斷。所以功能測試自動化主要的應用在回歸測試中，而且產品的介面(ui)和功能變化較大，自動化的指令碼（script）維護成本較大，投入和產出往往變成我們最關心的問題，在功能測試中實現測試自動化究竟是否合算？
舉個例子：假如乙個功能測試用例，手工執行需要
10分鐘，而為此測試用例開發指令碼需要4個小時，即240分鐘，那麼意味著這個測試指令碼要被執行24次收回成本，如果在加上測試指令碼的維護工作量（10％），需要重複執行40－50次，才收回成本。如果在產品的乙個版本中要進行2－3輪測試（一般是需要的），這個產品需要發布15－20個版本才收回成本。所以業界常說，產品發布7
個版本才收回成本。
如何降低成本、可以相對增加產出或者說更快地收回成本？關鍵是提高指令碼開發速度、提高指令碼執行的穩定性和降低維護指令碼的工作量，主要方法有：
－ 選擇較好的、更適合的測試工具
－ 選擇適宜自動化的模組
－ 盡量將指令碼寫成資料驅動的指令碼，這一點很重要。
－ 多錄製指令碼，然後結構化指令碼。我們知道，不是所有的模組都可以變為資料驅動方式，這時就要抽象出指令碼的結構，進行有效的組合，包括分層，形成有效的層次性。
－ 測試和指令碼開發合二為一，效率更明顯
下表也部分說明了這個問題。也希望得到您更好的想法。
結構
成本
收益
淨收益
no automation00
0recording and playback
8.311
2.7data-driven
structure using data pools
8.418
9.6framework structure
9.815
5.2framework / data-driven (hybrid) structure focusing
11.6
197.4
功能測試自動化的投入和產出
測試自動化，對於系統效能測試 負載測試等效果是明顯的，而且我們也不得不為之。我們知道，沒有測試工具進行負載模擬，要通過手工測試完成系統測試任務，幾乎是不可能的。但在功能測試中，情況就大不一樣了。手工測試在功能測試中的優勢還是比較大的，我在 測試方法的辯證統一 之二 已做了討論，工具本身並沒有想象力和...
自動化測試的目標和投入產出比
通用自動化測試目標 1.提高測試人員的工作成就感和幸福感，減少手工測試中部的重複性工作 2.提高測試用例的執行效率，實現快速的自動化回歸測試，快速地給開發團隊質量反饋 3.減少測試人員數量，提高開發和測試的比例，節省企業的人力成本 5.插入大量測試資料 從以下幾個方面考慮自動化測試的成本投入 1.專...
功能測試自動化
重複性測試 準確性問題 效率問題等。測試用例的設計 介面和使用者體驗測試 正確性的檢查。1.在進行專案的自動化測試之前，先要考慮以下5個方面 1 功能測試自動化類類似軟體開發過程 2 功能自動化測試是個長期過程 3 確保功能測試自動化的資源，包括人員和技能 4 循序漸進的開展自動化測試 5 確保功能...