為什么需要自動化測試？
- 代替手工重復操作，測試工程師可以花更多時間在設計全面的測試用例和新功能測試上 【代替手工重復】
- 提升回歸測試的效率，適合敏捷開發過程 【提升回歸效率】
- 更好的利用非工作時間執行測試，工作時間分析失敗用例 【利用非工作時間測試】
- 高效實現某些手工測試無法完成或代價巨大的測試類型，比如：關鍵業務7*24小時持續運行的系統穩定性測試和高並發場景的壓力測試 【代替復雜手工測試和長時間測試】
- 還可以保證每次測試執行的步驟以及驗證的一致性和可重復性，避免人為的遺漏或疏忽 【保證操作一致性，結果可溯源】
自動化測試的一些劣勢
- 不能完全取代手工測試，只能替代手工測試中執行頻率高、機械化的重復步驟 【不能替代手工測試】
- 無法應對被測系統的變化，自動化測試用例的維護成本高；因為自動化測試只是執行事先定義好的測試步驟並驗證測試結果，對於執行過程中出現的明顯錯誤和意外事件，自動化測試沒有任何處理能力 【維護成本高，無法應對系統變化和緊急事件】
- 自動化測試用例的開發工作量遠大於單詞的手工測試，所以只有當開發完成的測試用例的有效執行次數≥5時，才能收回成本 【用例開發量大，投入產出比難以提高】
- 手工測試發現的缺陷數量更多，自動化測試僅僅能發現回歸測試范圍的缺陷 【只能發現回歸缺陷】
- 自動化測試的效率很大程度依賴自動化測試用例的設計以及實現質量，不穩定的自動化測試用例比沒有自動化更糟糕 【自動化測試用例強依賴開發質量】
- 實行自動化測試的初期，用例開發效率都很低，在體系成熟以及測試工程師熟練后一般都要重構初期用例 【后期需要重構不成熟的初期用例】
- 懂業務的人+懂自動化技術的人結合一起才能高效開展自動化測試 【不僅懂技術還得懂業務】
- 自動化測試開發人員必須具備編程能力 【必備編程】
什么樣的項目適合自動化測試？
第一：需求穩定，不會頻繁變更
過高的需求變更頻率會導致自動化測試用例的維護成本直線上升
第二：研發和維護周期長，需要頻繁執行回歸測試
軟件產品比軟件項目更適合做自動化測試
- 首先，軟件產品的生命周期比較長，會有持續性迭代，每次版本發布都會有回歸測試需求
- 其次，自動化測試用例的執行比高於1:5，自動化測試的優勢才可以被更好地體現
對軟件項目的自動化測試，需要分情況
- 短期項目：不建議實施自動化，就算技術可行性很高，但 投入產出比（ROI） 不高；應該選擇 手工探索式測試 ，以發現缺陷為第一要務
- 中長期項目：對比較穩定的功能進行自動化測試，對改動較大or需求不明確的功能進行手工測試，最終目標是用20%的精力去覆蓋80%的回歸測試
第三：需要在多平台上重復運行相同測試的場景
第四：某些測試項目通過手工測試無法實現，或者手工成本太高
對於所有的性能和壓力測試，很難通過手工方式實現，如：
- 一萬並發用戶的基准性能測試
- 7*24小時的穩定性測試
這個時候必須借助機器來模擬大量用戶反復操作被測軟件的場景
第五：被測軟件的開發較為規范，能夠保證系統的可靠性
要實現穩定的自動化測試，被測軟件的開發過程必須規范，比如：GUI上的控件命名如果沒有任何規則可尋，就會造成GUI自動化的控件識別與定位不穩定，影響效率
另外，某些用例的自動化必須要求開發人員在產品中預留可測試性接口，否則后續的自動化會很難開展。
比如，用戶登錄操作可能需要圖片驗證碼，需要開發提供繞開圖片驗證碼的路徑，否則需要自己借助 光學字符識別（OCR）技術 來對圖片驗證碼識別，但它的識別率會很低，直接影響用例的穩定性