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

• 測試用例執(zhí)行不一致。
• 測試環(huán)境的人工設(shè)置。
• 乏味和緩慢。
• 測試結(jié)果格式不一致。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.原生工具

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

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

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

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

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

2.第三方工具

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

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

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

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

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

結(jié)論

測試自動化和將持續(xù)集成(CI)/持續(xù)交付(CD)引入軟件開發(fā)已經(jīng)不可逆轉(zhuǎn)地改變了創(chuàng)建、測試和發(fā)布軟件的方式。盡管持續(xù)集成(CI)/持續(xù)交付(CD)領(lǐng)域仍在不斷發(fā)展和進步，但必須了解持續(xù)集成(CI)/持續(xù)交付(CD)中自動化測試的基礎(chǔ)知識，并選擇更加節(jié)省時間和提高質(zhì)量的工具。

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