傳統的自動化測試更關注的產品ui層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。
單元測試關注**的實現邏輯，例如乙個if 分支或乙個for迴圈的實現；那麼整合、介面測試關注的一是個函式、類（方法）所提供的介面是否可靠。
為什麼要畫成乙個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表示不同階段所投入自動化測試的比例。如果乙個產品從沒有做單元測試與介面測試，只做ui層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的ui層的自動化測試，那更是乙個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是ui層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與介面測試階段進行。
既然ui層的自動化測試這麼勞民傷財，那我們只做單元測試與介面測試好了。no! 因為不管什麼樣的產品，最終呈現給使用者的是ui層。所以，測試人員應該更多的精力放在ui層。那麼也正是因為測試人員在ui層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們「部分解放」重複的勞動。
在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的執行失敗，那麼就需要對自動化指令碼進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，乙份永遠都執行成功的自動化測試用例是沒有價值。
至於在金字塔中三種測試的比例要根據實際的專案需求來劃分。在《google 測試之道》一書，對於google產品，70%的投入為單元測試，20%為整合、介面測試，10% 為ui層的自動化測試。
軟體需求變動不頻繁
測試指令碼的穩定性決定了自動化測試的維護成本。如果軟體需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試指令碼，而指令碼的維護本身就是乙個**開發的過程，需要修改、除錯，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。
專案中的某些模組相對穩定，而某些模組需求變動性很大。我們便可對相對穩定的模組進行自動化測試，而變動較大的仍是用手工測試。
專案週期較長
由於自動化測試需求的確定、自動化測試框架的設計、測試指令碼的編寫與除錯均需要相當長的時間來完成。這樣的過程本身就是乙個測試軟體的開發過程，需要較長的時間來完成。如果專案的週期比較短，沒有足夠的時間去支援這樣乙個過程，那麼自動化測試便成為笑談。
自動化測試指令碼可重複使用
自動化測試指令碼的重複使用要從三個方面來考量，一方面所測試的專案之間是否很大的差異性（如c/s系統和b/s系統的差異）；所選擇的測試工具是否適應這種差異；最後，測試人員是否有能力開發出適應這種差異的自動化測試框架。
² 桌面程式的工具有：qtp、 autorunner
² web應用的工具有：qtp、autorunner、robot framework、watir、selenium
自動化測試 web自動化測試
自動化 由機器裝置代替人為完成制定目標的過程 優點 提高工作效率 減少勞動力 產品規格同一標準 批量生產 自動化測試 讓程式代替人為去驗證程式功能的過程，即在預設條件下執行程式系統 流程確定 搭建自動化框架 編寫測試用例，將其轉化為soupui 介面 自動化測試指令碼 執行自動化測試指令碼 輸出執行...
測試自動化 自動化測試的定義
相關術語 automated testing test tool,automated testing test suite,automated testing test script等.具體參見 http en.wikipedia.org wiki test automation 推薦書籍 1 軟體...
測試自動化
自動化測試有兩種含義 開發過程的自動化單元測試和功能驗證階段的自動化黑盒測試。這兩者融合到daily build中，是daily build的最重要核心。daily build和自動化單元測試另文詳述，此處主要說說自動化功能測試。自動化測試的投入產出比以及實際應用效果其實不高 自動化測試作為提高測試...