答复

将自动化测试集成到CI/CD流程中，可以在每次代码变更时尽早发现缺陷。这对于现代开发流程和产品的稳定性至关重要。

问题背景： 传统上，自动化测试是手动执行或通过单独的任务进行的。随着持续集成（CI, Continuous Integration）和持续部署（CD, Continuous Deployment）概念的出现，产生了在每次提交时自动运行所有测试的需求。目前常见的系统包括Jenkins、GitLab CI/CD、GitHub Actions、TeamCity及其类似工具。

问题： 如果没有自动化测试的集成，缺陷可能会在晚些时候被发现：开发人员可能没有注意到问题，导致它进入生产环境。手动执行测试会延迟发布，并且无法对每次变更的质量提供充分保障。

解决方案： 将自动化测试集成到CI/CD中可以：

在每次合并、拉取请求或部署时自动执行回归测试，
获取即时反馈，
快速确定导致功能故障的提交。

为此，测试通常以单独的任务形式设置在管道中：通常有用于单元测试、集成测试、用户界面测试和负载测试的阶段。以下是.gitlab-ci.yml的示例：

stages:
  - test
  - deploy

unit_test:
  stage: test
  script:
    - npm run test:unit

ui_tests:
  stage: test
  script:
    - npm run test:ui

关键特性：

每次变更时自动执行测试
根据测试类型灵活配置流程
支持报告与质量分析

隐含问题。

将自动化测试集成到CI/CD中是否会减慢开发速度？

不会，正确配置的管道利用并行性、隔离环境和触发器仅针对必要的测试，能够通过尽早发现缺陷来加快发布。

在管道的每个阶段是否都应该运行所有自动化测试？

不，通常早期阶段（例如拉取请求）使用快速检查（代码检查和单元测试），而全面的回归测试则仅在发布前或在夜间构建中运行。

是否可以只依赖CI/CD中的自动化测试，而不进行手动回归测试？

不建议这样做——自动化对于重复场景是有效的，但复杂情况和用户体验检查仍然需要手动验证。

常见错误与反模式

在每次提交时运行所有测试，而不考虑更改类型（而只是运行相关的测试）
忽视失败：对管道中失败的测试"习以为常"
测试未优化，导致构建速度减慢

生活中的实例

消极案例

在一个项目中，所有自动化测试在每次提交时都运行，管道耗时长达40分钟，开发人员不得不等待测试完成才能合并他们的分支，因此出现了冲突情况和发布延迟。

优点：

最大化测试覆盖率

缺点：

显著增加了反馈时间，“冻结”的部署
对CI/CD基础设施造成了过大负担

积极案例

设计了一个任务分隔的管道：在功能分支上只运行快速测试，完整的回归测试则在stage/prod上进行。错误和报告由机器人收集，团队收到失败通知并迅速响应。