最近的突破性创新之一是测试自动化。在采用自动化测试技术之前，大多数软件测试用例都是手动执行的。这个艰苦的过程有很多陷阱，包括：测试用例的执行不一致。手动设置测试环境。无聊又慢。测试结果格式不一致。自动化测试、持续集成(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)管道的众多优秀工具中的一小部分。一般来说，这些工具可以分为两大类：原生工具和第三方工具。1.原生工具原生工具是直接集成到存储库中的持续集成（CI）/持续交付（CD）工具。对于这些工具，会在源代码旁边创建一个配置文件，并且在进行提交时，存储库会使用该配置文件并执行定义的阶段。目前最流行的两种原生工具是：(1)GitHubActions——直接与GitHub存储库集成的自动化工作流工具。可以通过在GitHub存储库的.github/workflows/目录中创建新的YetAnotherMarkupLanguage(YAML)工作流文件来构建新管道，在GitHubActions字典中称为工作流。(2)GitLabCI/CD-GitLabCI/CD与GitHubActions类似，直接与GitLab仓库集成，允许开发者通过在GitLab仓库流程的根目录下创建.gitlab-ci.yml文件来创建新的作业。当本机工具可用时，最好使用它，因为它提供了与存储库和由存储库管理的源代码的最高级别集成。例如，如果它的代码存储在GitHub或GitLab存储库中，则应该默认分别使用GitHubActions和GitLabCI/CD，除非迫切需要使用第三方工具。2.第三方工具第三方工具是位于存储库之外的持续集成(CI)/持续交付(CD)工具。对于其中的许多工具，存储库中有一个程序用于在提交时通知第三方工具。然后这些工具检查存储库中的代码并执行配置的管道。当今可用的两个最流行的第三方工具是：(1)Jenkins——这是一个开源自动化服务器，允许开发人员自动构建、测试和部署他们的项目。Jenkins通常用作独立服务，由开发团队部署。可以直接通过JenkinsUI或通过在源代码存储库中创建Jenkins文件来配置管道。(2)CircleCI——这是一个与GitHub、GitHubEnterprise、Bitbucket集成的托管自动化服务。CircleCI的优势在于团队无需部署和维护CircleCI实例，而是可以通过circleci.com访问CircleCI。然而，它在便利性方面获得的优势是其对存储库的支持范围狭窄且缺乏灵活性。尽管使用原生工具应该是默认选项，但在某些情况下第三方工具可能是更好的选择，例如：原生工具无法提供所需的功能。第三方工具允许利用更多的计算能力（即本机工具可能只允许使用单个机器的资源或与存储库关联的资源来执行管道）。需要一个独立的选项，以便可以直接管理CI/CD管道（想要管理防火墙或公司子网内的CI/CD服务器）。结论测试自动化和持续集成(CI)/持续交付(CD)对软件开发的引入已经不可逆转地改变了软件的创建、测试和发布方式。尽管持续集成（CI）/持续交付（CD）领域仍在不断发展和进步，但了解持续集成（CI）/持续交付（CD）中自动化测试的基础知识并选择更省时的方法势在必行和提高质量的工具。原标题：ContinuousTestAutomationUsingCI/CD:HowCI/CDHaveRevolutionizedAutomatedTesting，作者：JustinAlbano
