最近的突破性创新之一是自动化测试。在采用自动化测试技术之前，软件的大部分测试用例都是人工执行的。这个艰苦的过程有很多缺陷，其中包括：
- 测试用例执行不一致。
- 测试环境的人工设置。
- 乏味和缓慢。
- 测试结果格式不一致。
自动化测试以及持续集成(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
