在開始實施測試自動化時，應該選擇那些用例優先進行自動化？
問題來源於群里的一次聊天，在測試自動化實施中如何最大產出的問題。強調自動化覆蓋率？太片面了不太行。自動化效率？由於穩定性和可靠性不給力，這一條好像也不行。BUG比率？這項更不行。
但是第一步都是需要將測試用例自動化，那么如何選擇要自動化的測試以及將哪些測試留給手動測試？
在開始自動化測試之前，需要考慮到在自動化測試上投入的時間、精力和資源后，看看自動化測試可以帶來什么好處。以下是確定哪些手動測試應該或不應該自動化應該考慮的問題。俗話說，僅僅因為您可以使某些東西自動化並不一定意味着應該這樣做。
下面是一些觀點，給各位解決這個問題提供一些參考：
應該自動化的測試：
- 業務關鍵路徑：如果功能或用戶操作失敗，則會對業務造成損害。
- 需要針對應用程序的每個內部版本/發行版運行的測試，例如冒煙測試，健全性測試和回歸測試。
- 需要針對多種配置（不同的OS和瀏覽器組合）運行的測試。
- 執行相同工作流程的測試在每次測試運行中使用不同的數據作為輸入，例如數據驅動。
- 涉及輸入大量數據的測試，例如填寫很長的表格。
- 可用於性能測試的測試，例如壓力測試和負載測試。
- 測試需要很長時間才能執行，並且可能需要在休息時間或通宵進行。
- 測試必須捕獲圖像的過程，以證明應用程序的行為符合預期，或者檢查多個瀏覽器上的多個網頁看起來是否相同。
- 一般而言，測試運行越重復，對自動化越好。
還要記住，測試用例自動化並不是自動化的唯一選項。設置或創建用於手動探索性測試的測試數據之類的任務也是自動化展示自己價值的理想途徑。
不應該自動化的測試：
- 測試只能運行一次。該規則的唯一例外是，如果您要使用非常大的數據集執行測試（即使只有一次），則將其自動化是有意義的。
- 用戶體驗測試可用性（測試要求用戶對應用程序的易用性做出響應）。
- 需要盡快運行的測試。通常，開發的新功能需要快速反饋，因此請優先手動進行測試。
- 需要基於領域知識/專業知識進行臨時/隨機測試的測試即探索性測試。
- 間歇測試。沒有可預測結果的測試會導致更多的不確定性。為了從自動化中獲得最大價值，測試必須產生可預測且可靠的結果，以便產生嚴格通過和失敗的條件。
- 需要視覺確認的測試，但是，我們可以在自動測試過程中捕獲頁面圖像，然后手動檢查圖像。
- 不能100％自動化的測試完全不應自動化，除非這樣做會節省大量時間。
個人觀點：
- 簡單>優先級>穩定性>重復性。
- 鄭重聲明：文章禁止第三方（騰訊雲除外）轉載、發表，事情原委測試窩，首頁抄我七篇原創還拉黑，你們的良心不會痛嗎？
技術類文章精選
- java一行代碼打印心形
- Linux性能監控軟件netdata中文漢化版
- 接口測試代碼覆蓋率（jacoco）方案分享
- 性能測試框架第二版
- 如何在Linux命令行界面愉快進行性能測試
- 圖解HTTP腦圖
- 將swagger文檔自動變成測試代碼
- 五行代碼構建靜態博客
- 基於java的直線型接口測試框架初探
非技術文章精選
- 為什么選擇軟件測試作為職業道路?
- 寫給所有人的編程思維
- 成為優秀自動化測試工程師的7個步驟
- 成為自動化測試的7種技能
- 自動化測試生命周期
- 如何在DevOps引入自動化測試
- Web端自動化測試失敗原因匯總
- 如何在DevOps引入自動化測試
- 測試人員如何成為變革的推動者
- 編寫測試用例的技巧
