一、分層自動化測試

傳統的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。

為什麼要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與介面測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與介面測試階段進行。

既然UI層的自動化測試這麼勞民傷財，那我們只做單元測試與介面測試好了。NO! 因為不管什麼樣的產品，最終呈現給使用者的是UI層。所以，測試人員應該更多的精力放在UI層。那麼也正是因為測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們“部分解放”重複的勞動。

　　在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的執行失敗，那麼就需要對自動化指令碼進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都執行成功的自動化測試用例是沒有價值。 

　　至於在金字塔中三種測試的比例要根據實際的專案需求來劃分。在《google 測試之道》一書，對於

首先考考慮產品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。

 　　（1）軟體需求變動不頻繁

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

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

　　（2）專案週期較長

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

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

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