一、分層自動化測試
傳統的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。
爲什麼要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是爲了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因爲越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。
既然UI層的自動化測試這麼勞民傷財，那我們只做單元測試與接口測試好了。NO! 因爲不管什麼樣的產品，最終呈現給用戶的是UI層。所以，測試人員應該更多的精力放在UI層。那麼也正是因爲測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們“部分解放”重複的勞動。
在自動化測試中最怕的是變化，因爲變化的直接結果就是導致測試用例的運行失敗，那麼就需要對自動化腳本進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都運行成功的自動化測試用例是沒有價值。
至於在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google 測試之道》一書，對於google產品，70%的投入爲單元測試，20%爲集成、接口測試，10% 爲UI層的自動化測試。
二、什麼項目適合做自動化測試首先考考慮產品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。
（1）軟件需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟件需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。
項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。
（2）項目週期較長
由於自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成。這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的週期比較短，沒有足夠的時間去支持這樣一個過程，那麼自動化測試便成爲笑談。
（3）自動化測試腳本可重複使用
自動化測試腳本的重複使用要從三個方面來考量，一方面所測試的項目之間是否很大的差異性（如C/S系統和B/S系統的差異）；所選擇的測試工具是否適應這種差異；最後，測試人員是否有能力開發出適應這種差異的自動化測試框架。
本文參考：http://www.cnblogs.com/fnng/p/3653793.html
