《軟體測試52講》讀書筆記 —— 為什麼要做自動化測試

代替手工重複操作，測試工程師可以花更多時間在設計全面的測試用例和新功能測試上 【代替手工重複】 

提升回歸測試的效率，适合靈活開發過程 【提升回歸效率】 

更好的利用非工作時間執行測試，工作時間分析失敗用例 【利用非工作時間測試】 

高效實作某些手工測試無法完成或代價巨大的測試類型，比如：關鍵業務7*24小時持續運作的系統穩定性測試和高并發場景的壓力測試 【代替複雜手工測試和長時間測試】 

還可以保證每次測試執行的步驟以及驗證的一緻性和可重複性，避免人為的遺漏或疏忽 【保證操作一緻性，結果可溯源】 

 不能完全取代手工測試，隻能替代手工測試中執行頻率高、機械化的重複步驟 【不能替代手工測試】 

無法應對被測系統的變化，自動化測試用例的維護成本高；因為自動化測試隻是執行事先定義好的測試步驟并驗證測試結果，對于執行過程中出現的明顯錯誤和意外事件，自動化測試沒有任何處理能力 【維護成本高，無法應對系統變化和緊急事件】 

自動化測試用例的開發工作量遠大于單詞的手工測試，是以隻有當開發完成的測試用例的有效執行次數≥5時，才能收回成本 【用例開發量大，投入産出比難以提高】 

手工測試發現的缺陷數量更多，自動化測試僅僅能發現回歸測試範圍的缺陷 【隻能發現回歸缺陷】 

自動化測試的效率很大程度依賴自動化測試用例的設計以及實作品質，不穩定的自動化測試用例比沒有自動化更糟糕 【自動化測試用例強依賴開發品質】 

實行自動化測試的初期，用例開發效率都很低，在體系成熟以及測試工程師熟練後一般都要重構初期用例 【後期需要重構不成熟的初期用例】 

懂業務的人+懂自動化技術的人結合一起才能高效開展自動化測試 【不僅懂技術還得懂業務】 

自動化測試開發人員必須具備程式設計能力 【必備程式設計】 

過高的需求變更頻率會導緻自動化測試用例的維護成本直線上升

首先，軟體産品的生命周期比較長，會有持續性疊代，每次版本釋出都會有回歸測試需求

其次，自動化測試用例的執行比高于1:5，自動化測試的優勢才可以被更好地展現

短期項目：不建議實施自動化，就算技術可行性很高，但 投入産出比（ROI） 不高；應該選擇 手工探索式測試 ，以發現缺陷為第一要務

中長期項目：對比較穩定的功能進行自動化測試，對改動較大or需求不明确的功能進行手工測試，最終目标是用20%的精力去覆寫80%的回歸測試

對于所有的性能和壓力測試，很難通過手工方式實作，如：

一萬并發使用者的基準性能測試

7*24小時的穩定性測試

這個時候必須借助機器來模拟大量使用者反複操作被測軟體的場景

要實作穩定的自動化測試，被測軟體的開發過程必須規範，比如：GUI上的控件命名如果沒有任何規則可尋，就會造成GUI自動化的控件識别與定位不穩定，影響效率

另外，某些用例的自動化必須要求開發人員在産品中預留可測試性接口，否則後續的自動化會很難開展。

比如，使用者登入操作可能需要圖檔驗證碼，需要開發提供繞開圖檔驗證碼的路徑，否則需要自己借助 光學字元識别（OCR）技術 來對圖檔驗證碼識别，但它的識别率會很低，直接影響用例的穩定性