什麼是自動化測試

編寫程式碼（指令碼），也就是把手工測試用例的操作步驟和校驗轉化成指令碼實現，然後批量執行程式碼（指令碼）實現測試的目的， 就是自動化測試

從自動化測試的概念推匯出，自動化測試用例編寫的根據是我們的手工測試用例

自動化測試的分類

介面自動化測試， 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、實現難度

功能重要的， 實現容易的肯定優先實現， 如果功能重要的都不好實現，那麼先從功能次重要的，容易實現的開始