最近的突破性創新之一是自動化測試。在采用自動化測試技術之前，軟件的大部分測試用例都是人工執行的。這個艱苦的過程有很多缺陷，其中包括：

• 測試用例執行不一致。
• 測試環境的人工設置。
• 乏味和緩慢。
• 測試結果格式不一致。

自動化測試以及持續集成(CI)和持續交付(CD)的引入，改進和提高了開發人員發布軟件的質量和節奏。本文將深入研究持續集成(CI)/持續交付(CD)管道，了解如何使用自動化測試來顯著地提高軟件發布的質量和速度。此外，還將研究一些可用于創建持續集成(CI)/持續交付(CD)管道的最流行和最實用的工具。

持續集成(CI)/持續交付(CD)管道

為了發布軟件，必須滿足一些業務需求。在某些情況下，這些業務需求包括一組快速的系統測試和一套用戶界面(UI)測試，而其他版本可能需要更多涉及的需求。無論復雜程度如何，這些業務需求都可以概念化為一組串行和并行執行的步驟。在持續集成(CI)/持續交付(CD)的術語中，每個步驟稱為一個階段，有序階段的集合稱為一個管道。下面是一個示例管道：

管道中的特定階段將根據項目的業務需求而有所不同，但所有管道都將在觸發器(例如提交)被激活時執行。一旦管道的執行開始，每個階段都會一個接一個地執行;當一個階段成功完成時，執行下一個階段。

當達到一組并行階段時，例如上面示例中的用戶驗收測試、容量測試和暫存階段，所有階段都同時執行。當所有并行階段都成功完成時，管道仍將繼續運行。例如，在用戶驗收測試、容量測試和登臺成功完成之前，不會開始執行部署階段。

持續集成(CI)/持續交付(CD)管道的所有階段并不一定都必須實現自動化，在某些情況下，將自動化測試用例引入持續集成(CI)/持續交付(CD)管道可能很困難。例如：

• 不明確的業務需求和規范——在大多數情況下，定義自動化測試的困難源于對項目的業務需求(定義CI/ CD管道)和被測軟件的規范缺乏明確性。在持續集成(CI)/持續交付(CD)管道中創建階段之前，必須了解需要測試什么以及為什么要測試它。
• 用戶界面(UI)測試——由于具有可視性和波動性，用戶界面(UI)測試可能難以實現自動化。可以通過使用用戶界面(UI)測試框架來克服這個問題，例如Selenium。
• 不一致的報告——許多持續集成(CI)/持續交付(CD)管道工具包括一個測試摘要，顯示在一個階段中已經執行和成功完成的測試數量。這一摘要需要自動化測試生成一致的并且眾所周知的報告。可以通過使用報告格式廣為人知的自動化測試工具來滿足這一要求，例如JUnit(或任何xUnit框架)和Cucumber。

雖然可能存在需要人工測試的情況，但當所有測試(包括UI測試)都實現自動化時，就實現了持續集成(CI)/持續交付(CD)管道的最大優勢。

持續集成(CI)/持續交付(CD)管道中的自動化測試

在持續集成(CI)/持續交付(CD)管道中使用自動化測試的主要優勢在于，可以針對一系列測試(包括單元、集成、系統、性能和驗收測試)對單個提交進行測試，然后無需部署即可部署到生產系統中，而無需任何人工交互。例如，即使在大型項目中，也有可能讓一個工程師做出提交，這將自動導致在幾分鐘或幾小時內將功能部署到生產中。

與其相反，自動化管道可確保失敗的測試禁止將功能部署到生產中。例如，如果開發人員添加了新功能，并且單元或集成測試失敗，則管道的執行會立即停止，并且不會部署該功能。然后，開發人員會收到測試失敗的通知，并可以追蹤到觸發管道執行失敗的提交的錯誤。

除了為部署和發布帶來的好處之外，自動化測試還為代碼本身的質量帶來了許多好處：

• 記錄其預期行為。
• 減少回歸次數。
• 解耦成更小、更獨立的組件。
• 減少測試執行時間。
• 利益相關者參與測試規范的生成(即驗收測試)。

盡管持續集成(CI)/持續交付(CD)管道中的所有測試可能無法實現自動化，但為了從管道中獲得最大收益，應該努力最大限度地增加自動化階段的數量，并在可能的情況下實現管道的完全自動化。

流行的持續集成(CI)/持續交付(CD)工具

有許多工具和框架可用于創建自動化持續集成(CI)/持續交付(CD)管道。下面的例子并不全面，僅代表可用于促進持續集成(CI)/持續交付(CD)管道的眾多優秀工具中的一小部分。一般來說，這些工具可以分為兩類：原生工具和第三方工具。

1.原生工具

原生工具是直接集成到存儲庫中的持續集成(CI)/持續交付(CD)工具。對于這些工具，創建了一個與源代碼并存的配置文件，當提交時，存儲庫會使用配置文件并執行定義的階段。

目前可用的兩種最流行的原生工具是：

(1)GitHub Actions——直接與GitHub存儲庫集成的自動化工作流工具。可以通過在GitHub存儲庫的.github/workflows/目錄中創建新的另一種標記語言(YAML)工作流文件來構建新的管道，在GitHub操作詞典中稱為工作流。

(2)GitLab CI/CD——與GitHub Actions類似，GitLab CI/CD直接與GitLab存儲庫集成，允許開發人員通過在GitLab存儲庫的根目錄中創建.gitlab-ci.yml文件來創建新的工作流。

當原生工具可用時，最好使用它，因為它提供了與存儲庫和由存儲庫管理的源代碼的最高級別的集成。例如，如果其代碼存儲在GitHub或GitLab存儲庫中，應該默認分別使用GitHub Actions和GitLab CI/CD，除非迫切需要使用第三方工具。

2.第三方工具

第三方工具是駐留在存儲庫之外的持續集成(CI)/持續交付(CD)工具。對于其中許多工具，可以在存儲庫中采用一個程序用于在提交時通知第三方工具。然后這些工具從存儲庫中檢查代碼并執行配置的管道。目前可用的兩種最流行的第三方工具是：

(1)Jenkins——這是一個開源自動化服務器，允許開發人員自動構建、測試和部署他們的項目。Jenkins通常用作獨立服務，由開發團隊部署。管道可以直接通過Jenkins UI配置，也可以通過在源代碼存儲庫中創建Jenkins文件來配置。

(2)CircleCI——這是與GitHub、GitHub Enterprise、Bitbucket集成的托管自動化服務。CircleCI的優勢在于團隊不必部署和維護CircleCI實例，而是可以通過circleci.com訪問CircleCI。然而，它在便利性方面獲得的優勢在于其狹窄的存儲庫支持和缺乏靈活性。

雖然使用原生工具應該默認選項，但在某些情況下第三方工具可能是更好的選擇，例如：

• 原生工具無法提供需要的功能。
• 第三方工具允許利用更多的計算能力(即原生工具可能只允許使用單臺機器的資源或與存儲庫相關的資源來執行管道)。
• 需要一個獨立選項，以便可以直接管理持續集成(CI)/持續交付(CD)管道(希望在防火墻或公司子網內管理持續集成(CI)/持續交付(CD)服務器)。

結論

測試自動化和將持續集成(CI)/持續交付(CD)引入軟件開發已經不可逆轉地改變了創建、測試和發布軟件的方式。盡管持續集成(CI)/持續交付(CD)領域仍在不斷發展和進步，但必須了解持續集成(CI)/持續交付(CD)中自動化測試的基礎知識，并選擇更加節省時間和提高質量的工具。

原文標題：??Continuous Test Automation Using CI/CD: How CI/CD Has Revolutionized Automated Testing??，作者：Justin Albano