持续集成（CI）/持续交付（CD）如何彻底改变自动化测试

2024-12-02 03:19

短信预约 -IT技能 免费直播动态提醒

测试用例执行不一致。
测试环境的人工设置。
乏味和缓慢。
测试结果格式不一致。

自动化测试以及持续集成(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。然而，它在便利性方面获得的优势在于其狭窄的存储库支持和缺乏灵活性。

虽然使用原生工具应该默认选项，但在某些情况下第三方工具可能是更好的选择，例如：