自動化測試要解決的問題主要有兩個：乙個是可以重複使用的測試用例；乙個是手工測試很難實現（或是手工成本很高）的測試用例。
首先說一句，自動化測試不是神話，也不是必須的，需要手工的時候還是需要手工：實現不了自動化的就不實現，效果差的或未達預期的（需要跑多次的，還需要手工輔助和二次校驗的）。
那麼什麼情況下需要做自動化測試列？
先說一下不適合做自動化測試的幾種情況：
上層領導不支援。
專案周期短，需求變更頻繁。這種基本是一次性專案，做完交付即可，沒有後期維護（當你的自動化測試團隊建立起來開始編制自動化測試指令碼的，可能你的指令碼還沒編制完成，專案已經結束了，已經開展的工作也白做了）。
系統不穩定，主要是大版本未確定的情況下。這種時候實施自動化只會找麻煩，後期可能要做大量維護工作，還不如延後實施自動化測試工作。
多數物件無法識別（存在大量第三方控制項）或測試指令碼維護頻繁與困難，只要有一種情況發生，自動化測試注定無法繼續開展。
涉及與物理裝置互動的。測試自動化的基礎是裝置**，如果被測產品與眾多物理裝置打交道，而又缺乏恰當的軟體**或硬體工具**（缺少測試儀表或模擬器）時，自動化測試是難以為繼的。
可用性和易用性方面的測試，針對可用性與易用性測試，測試結果通不通過，大家都是見仁見智。給一幅影象，甲說它表達的是**內容，乙可能就說它沒問題。
上層領導支援，有明確的、特定的測試任務；
專案周期長，需求相對穩定且介面改動較少；
頻繁的回歸測試，有大量的重複性測試執行相同的測試用例
人工容易出錯的測試；
擁有執行測試所需的軟硬體環境，能確保多個測試執行的構建策略。
對於乙個軟體專案周期長、需求變動不頻繁、測試指令碼可重複使用的情況下就可以開展自動化測試了。
總結一下，自動化測試不是萬能的，只是測試人員工具庫里的一件利器，不可能完全取代測試工程師的地位。在不同的應用場景下，有些自動化測試目標比較容易達到，有些則比較難以達到。儘管如此，在devops、微服務、雲計算等新技術層出不窮的時代，自動化測試仍然毫無疑問地具有強大生命力，只要選擇對了發揮其功效的最佳時機及方式，就能在測試效率和測試徹底性方面使我們獲益匪淺。
測試自動化 自動化測試的定義
相關術語 automated testing test tool,automated testing test suite,automated testing test script等.具體參見 http en.wikipedia.org wiki test automation 推薦書籍 1 軟體...
自動化測試 web自動化測試
自動化 由機器裝置代替人為完成制定目標的過程 優點 提高工作效率 減少勞動力 產品規格同一標準 批量生產 自動化測試 讓程式代替人為去驗證程式功能的過程，即在預設條件下執行程式系統 流程確定 搭建自動化框架 編寫測試用例，將其轉化為soupui 介面 自動化測試指令碼 執行自動化測試指令碼 輸出執行...
測試自動化
自動化測試有兩種含義 開發過程的自動化單元測試和功能驗證階段的自動化黑盒測試。這兩者融合到daily build中，是daily build的最重要核心。daily build和自動化單元測試另文詳述，此處主要說說自動化功能測試。自動化測試的投入產出比以及實際應用效果其實不高 自動化測試作為提高測試...