什麼是自動化測試
編寫代碼（腳本），也就是把手工測試用例的操作步驟和校驗轉化成腳本實現，然後批量執行代碼（腳本）實現測試的目的， 就是自動化測試
從自動化測試的概念推導出，自動化測試用例編寫的根據是我們的手工測試用例
自動化測試的分類
接口自動化測試， web UI自動化測試， app 自動化測試， 性能自動化測試等
爲什麼要做自動化測試
優點：
1、把人從重複的測試活動中解放出來（比如在迭代1版本實現了測試點A的自動化腳本， 在迭代2 ，迭代3 迭代N的版本中都可以使用自動化腳本覆蓋這個測試點，把人解放出來），讓人多手工測試哪些自動化不能覆蓋的點，提升測試質量
2、主要用於迴歸測試(迴歸之前迭代做的功能)，縮短迴歸時間，提升測試效率
怎麼理解自動化測試主要用於迴歸測試：
1、比如在A迭代實現了設備管理員模塊， A迭代的測試完成後間歇期寫設備管理員模塊的自動化腳本
2、B迭代測試的時候， 可能還需要測試設備管理員模塊，這個時候可以用自動化腳本去覆蓋， 可以縮短測試周期，提升測試覆蓋度， 保證質量
3、對於web系統，平均的話每個人每天大概可以執行70個左右的測試用例， 那1000個測試用例需要， 14人天左右才能執行完， 但是如果把這1000個測試用例轉化成自動化腳本，那麼可能就僅僅需要10-20個小時就測試完成，然後加上半天左右的結果分析， 就把1000個測試點給測試完成了
缺點：
1、自動化測試的腳本需要達到一定的數量才能見到測試效果，但是前期需要搭建自動化框架，所以自動化測試有前期投入大，後期收益高的特點， 這個特點也說明自動化測試適合長期迭代的軟件，不適合項目型的軟件。
2、UI自動化測試發現問題的效率沒有人手工執行發現問題的效率高，畢竟ui自動化測試用例的測試點有限， 所以在做測試的時候，測試點第一次測試的時候最好是手工去覆蓋， 後面迴歸的時候可以用自動化腳本覆蓋
3、ui自動化腳本執行比較慢， 不是特別穩定，需要比較多的等待時間， 一般情況下一個UI自動化腳本執行時間是20秒-45秒， 1000個自動化測試用例， 如果一個機器執行，時間需要5-10個小時， 這個時候可能就需要分佈到多個機器跑，比如說分佈到3個機器， 那麼只需要2-3個小時就可以出結果。
自動化測試的誤區
1.自動化測試會完全取代手工測試
2.自動化測試一定比手工測試牛X，更加高達上
3.自動化可以發掘更多BUG（ui自動化測試發現bug佔總bug 的比例可能在5% ）， 自動化更多的時候是保障系統功能沒有問題
4.所有用例都適合自動化， 和硬件相關的，和第三方系統相關的功能， 很多時候這些功能我們要通過手工測試去覆蓋
5.並非所有的項目都適合自動化測試
什麼項目適合自動化測試
①需求穩定，不會頻繁變更
自動化測試最大的挑戰就是需求的變化，而自動化腳本本身就需要修改、擴展、debug，去適應新的功能，如果投入產出比太低，那麼自動化測試也失去了其價值和意義；
折中的做法是選擇相對穩定的模塊和功能進行自動化測試，變動較大、需求變更較頻繁的部分用手工測試；
②多平臺運行，組合遍歷型、大量的重複任務
測試數據、測試用例、自動化腳本的重用性和移植性較強，降低成本，提高效率和價值；
③軟件維護週期長，有生命力
自動化測試的需求穩定性要求、自動化框架的設計、腳本開發與調試均需要時間，這其實也是一個軟件開發過程，如果項目週期較短，沒有足夠的時間去支持這一過程，那自動化測試也就不需要了；
自動化測試的工具
Web自動化測試工具：selenium(web強烈推薦）
接口自動化測試工具：SoapUI、postman，jmeter，也可以通過python/java等語言。
手機自動化測試工具：appium、robotium。
編寫自動化腳本的人和時間
一個項目中的自動化框架一般有專人（這個人可能就不做手工測試啦）維護，編寫自動化腳本可能是全員
全員編寫自動化腳本的時間是迭代的間歇期， 專人是維護完框架一直寫
執行自動化的時間、人、流程
時間：迭代的每個輪次轉測試後
人：專人負責，一般和項目自動化框架專人是同一人
流程：批量執行自動化腳本，分析自動化結果， 發自動化測試報告（相關產品，研發，測試）
挑選哪些測試用例編寫自動化腳本
從自動化測試的概念推導出，自動化測試用例編寫的根據是我們的手工測試用例
從這幾個維度來挑選，1、功能重要性 2、實現難度
功能重要的， 實現容易的肯定優先實現， 如果功能重要的都不好實現，那麼先從功能次重要的，容易實現的開始