通過上篇文章，可以意識到自動化的重要性和優勢，必須確定可以自動化的用例。為此，必須考慮所追求的目標，以及這個目標在測試金字塔中處於什麼層次。

嘗試回答以下問題：

目標是什麼？

需要確認的第一件事是始終以更高水平的軟體質量為目標，並分析自動化是否適合專案。
要回答這個問題，建議對目標進行可行性分析。
以下是最有可能實現自動化的一些場景：

• 有技術債務需要消除；
• 迴歸測試非常耗時；
• 該專案非常複雜且長期。

應該自動化哪些測試用例？

並不是所有的事情都可以在上下文中自動化，這就是了解哪些案例符合我們的目的的相關原因。從程式碼級別和開發人員方面考慮，單元測試是最容易編寫指令碼的。在測試人員方面，我們通常致力於在 UI 和 API 級別自動化迴歸案例，首先考慮最關鍵和最複雜的流程。
以下是可自動化的測試用例：

迴歸測試

鑑於我們已經有了一個必須在每次產品釋出後定期執行測試套件，手動執行這些套件的工作變得重複，此外還需要從其他不可自動化的任務中抽出時間，可以在這些任務中獲得更多價值。這些迴歸測試用例高度自動化，特別便於整合到CI/CD模型中。這增加了執行其他任務所需的成本和時間，因為在執行其他活動時，指令碼可以在無人蔘與的情況下執行。

高風險測試

這些案例通常由利益相關者商定，重點放在檢查高優先順序和關鍵功能上，如果它們失敗，將極大地影響商業模式。這就是為什麼這種方法被稱為“基於風險的測試”。
自動化測試這些功能的案例有助於在每次釋出後立即發現可能阻止釋出、或必須迅速處理的風險性事件。

複雜或耗時的測試

在一個專案中，可能會有一些複雜的情況需要手動複製，所以如果我們將其轉換為指令碼，那麼以自動化的方式執行它們會更容易。如果是一個包含大量資料的表單，那麼測試人員可能更容易出錯，尤其是當必須使用多種資料變體測試同一表單時。這時就可以通過自動化來降低出錯的概率。

重複測試用例

正如迴歸測試成為一項重複性任務一樣，在某些一些特殊情況下，可以方便地實現自動化。例如，手動測試同一流程的大量資料，需要花費大量的時間，必須重複測試則讓過程更加乏味。然而，通過自動化這個流程，我們可以引數化這些資料，而無需手動測試每個值。這也被稱為資料驅動測試，其中自動化測試被引數化，並從資料來源（如檔案或資料庫）獲取資料。

工具選擇

既然我們知道了要自動化什麼，我們就可以繼續選擇要使用的工具了。在給定可用工具數量的情況下，該活動可能是最複雜的分析之一，該決策將不得不考慮涉及的專案、預算、知識和經驗。
有幾種開源、商業和定製工具，它們的侷限性和可用性各不相同。要選擇正確的工具，你必須清楚必須滿足哪些要求才能繼續對其使用進行成本效益分析。

以下是一些測試自動化工具的簡要概述：

• Selenium：一種開源工具，在世界範圍內被廣泛接受，用於在不同瀏覽器和平臺上測試 Web 應用程式。
• Appium：另一個開源框架（基於 Selenium），主要用在 iOS 和 Android 的移動裝置上實現測試自動化。
• Cucumber：這個工具是 BDD（行為驅動開發）方法的一部分。Cucumber 的主要優點是它的易用性，因為它非常直觀，提供了廣泛的功能，而且還是開源的。
• ZTF：Zentao Testing Framework，是一款開源自動化測試管理框架，聚焦於自動化測試的管理功能，可以解決用例資訊管理、測試指令碼執行、測試結果比對、缺陷Bug提交等問題。
• ZenData：ZenData是一款使用方便的通用資料生成工具，主要擁有兩大功能：資料生成和資料解析。支援一鍵生成海量資料用於效能和壓力測試，適用於大規模、工程化的自動化測試。

需要注意的是，沒有適用於所有情況的最佳工具。根據被測應用程式和決策制定標準，可以更靈活地在不同軟體之間進行選擇。