功能測試自動化的投入和產出

領測軟件測試網    測試自動化，對于系統性能測試、負載測試等效果是明顯的，而且我們也不得不為之。我們知道，沒有測試工具進行負載模擬，要通過手工測試完成系統測試任務，幾乎是不可能的。但在功能測試中，情況就大不一樣了。

    手工測試在功能測試中的優勢還是比較大的，我在“測試方法的辯證統一（之二）”已做了討論，工具本身并沒有想象力和靈活性，而人對界面美觀性、邏輯合理性，容易作出判斷。所以功能測試自動化主要的應用在回歸測試中，而且產品的界面(UI)和功能變化較大，自動化的腳本（Script）維護成本較大，投入和產出往往變成我們最關心的問題，在功能測試中實現測試自動化究竟是否合算？

舉個例子：假如一個功能測試用例，手工運行需要10分鐘，而為此測試用例開發腳本需要4個小時，即240分鐘，那么意味著這個測試腳本要被運行24次收回成本，如果在加上測試腳本的維護工作量（10％），需要重復運行40－50次，才收回成本。如果在產品的一個版本中要進行2－3輪測試（一般是需要的），這個產品需要發布15－20個版本才收回成本。所以業界常說，產品發布7個版本才收回成本。

    如何降低成本、可以相對增加產出或者說更快地收回成本？關鍵是提高腳本開發速度、提高腳本運行的穩定性和降低維護腳本的工作量，主要方法有：
    － 選擇較好的、更適合的測試工具
    － 選擇適宜自動化的模塊
    － 盡量將腳本寫成數據驅動的腳本，這一點很重要。
    － 多錄制腳本，然后結構化腳本。我們知道，不是所有的模塊都可以變為數據驅動方式，這時就要抽象出腳本的結構，進行有效的組合，包括分層，形成有效的層次性。
    － 測試和腳本開發合二為一，效率更明顯

下表也部分說明了這個問題。也希望得到您更好的想法。

MILY: 宋體">結構	成本	收益	凈收益
No Automation	0	0	0
Recording and Playback	8.3	11	2.7
Data-driven structure using data pools	8.4	18	9.6
Framework structure	9.8	15	5.2
Framework / data-driven (hybrid) structure focusing on views of the application and using data pools	11.6	19	7.4

文章來源于領測軟件測試網 http://www.kjueaiud.com/