停止使用CI/CD工具运行测试

了解成功测试自动化策略的六个具体需求，以及依赖 CI/CD 工具如何让你陷入永无止境的测试泥潭。

译自 Stop Running Tests With Your CI/CD Tool，作者 Ole Lensmar。

为云原生应用程序实施一致的测试基础设施和工作流具有挑战性。不同的利益相关者对测试/质量保证有不同的需求，测试工具堆栈会随着新技术和要求不断演变，CI/CD/GitOps 管道正在改变我们交付软件的方式，并且需要维护对传统和前沿组件的测试，以确保向最终用户交付高质量的应用程序。

随着 CI/CD 工具和工作流的出现，使用 CI/CD 来运行测试也变得很自然。毕竟，测试是软件交付生命周期的一部分，并且在构建和部署中将测试执行自动化在概念层面上是有意义的。不幸的是，许多 CI/CD 工具很少重视测试和质量保证的特定需求。对他们来说，测试只是在管道中运行的另一项任务，这通常会让 CI/CD 工具中的额外测试支持感觉更像是事后诸葛亮，而不是主要目标。

在同一组织中使用多个 CI/CD 工具的常见情况下添加：Jenkins 用于构建 Java 微服务后端，GitHub 操作用于构建（和部署？）前端应用程序，甚至可能是 Argo 之类的东西，用于采用 GitOps 方法将应用程序部署到 Kubernetes。测试不仅经常被事后考虑，而且这种事后考虑现在分散在多个工具中！可能出什么问题？

让我们深入探讨成功测试自动化策略的六个具体需求，以及依赖 CI/CD 工具通常会如何将你带入永无止境的测试沼泽（TSONR——这是你第一次读到它！）。

1. 一致的测试工具支持

无论你如何在 CI/CD 管道和工具中设置测试运行，维护对传统工具、现代工具、版本更改和传统测试的一致支持都是一项挑战。

一天结束时你最不想听到的是“我们的 CI/CD 工具不支持你的测试框架”或“我们无法在管道中运行 [测试工具] 的多个版本。你必须将所有脚本升级为与版本 X 兼容。”

许多 CI/CD 工具依赖插件来支持特定的测试工具/版本——这并不能保证一致性。它们的后备通常是某种脚本环境，这可能会完成这项工作，但会增加复杂性和维护开销，从而难以扩展和多样化测试工作。

2. 一致的测试执行环境

“在我的机器上运行。”当你精心设计的测试在一个环境中运行时没有给出所需的结果，而在另一个（更重要的）环境中运行时却给出所需的结果时，你肯定听说过或说过这句话，并且对此表示怀疑。

显然，运行同一组测试应该给出一致的结果。不幸的是，在多 CI/CD 工具环境中运行测试通常会导致结果因运行位置（和方式）而异。不同的 CI/CD 工具具有不同的运行时、环境和基础设施，这使得难以预测测试工作的稳定性，尤其是在涉及性能、安全性和合规性测试等非功能测试时。此外，在开发过程中本地运行的测试通常使用相应的测试工具直接“手动”运行，这通常远非测试或生产环境。

3. 根据需要运行测试

将自动化测试作为 CI/CD 管道的一部分运行是一种常见做法，但在管道外运行这些测试很困难，并且你不想重新运行整个构建只是为了针对开发环境重新运行一些更新的测试。

在 CI/CD 管道之外运行测试的可能性，无论是手动（例如，负载测试）还是响应其他系统事件（例如，Kubernetes 事件），在分布式和多样化的基础设施中都是必须的，以确保 DevOps 和质量保证团队可以（重新）运行测试根据需要。

4. 大规模运行测试

大规模运行自动化测试包含两个向量：

扩展负载测试以生成大量负载，以模拟应用程序或 API 的峰值使用场景。
扩展端到端 (E2E)/功能测试以涵盖执行场景矩阵，包括不同的浏览器、操作系统、用户等。

CI/CD 工具通常缺乏专门的功能来满足测试执行的特定需求。虽然它们可能允许启动不同的“工作进程”，但与测试工具相关的逻辑必须通过自定义脚本和/或第三方解决方案来管理。

5. 测试结果的单一控制面板

获得所有 CI/CD 管道中使用的测试工具的一致测试结果和工件对于故障排除和对整体测试工作的理解至关重要。

然而，大多数 CI/CD 工具对高级别的测试结果了解甚少。它们可能提供查看每个单独测试的日志/工件输出，但汇总质量指标（如通过/失败率和执行次数）并不是它们的重点。访问特定测试执行结果和工件以深入故障排除通常需要编写大量脚本或将它们导出到外部工具进行进一步分析。

6. 将控制权交给 QA

更新管道中运行的测试工具的参数或版本需要向 DevOps 团队提交工单，并希望他们有时间处理。

将测试自动化移交给管理 CI/CD 管道的团队后，QA 通常对自动化几乎没有控制权或洞察力，这会减缓测试的演进。

CI/CD 工具很少具有授予测试人员仅访问构建管道测试方面的角色所需的基于角色的访问控制粒度。因此，与测试执行相关的 QA 发起的改进/更改通常需要经过一个繁琐的过程才能实施，导致挫败感和测试覆盖率不足。

或者，QA 被授予他们不应该访问的构建基础设施区域，这可能会在受监管更严格的组织中引发安全问题。

好吧，现在怎么办？

好的，你已经听取了这些论点，希望在将来要求你的 DevOps 团队在你管道中自动化你的 Playwright 脚本或 Postman 集合之前你会三思而后行。

但是，如何在不牺牲 CI/CD 中测试本身价值的情况下，解决所有这些挑战并让你 CI/CD 管道中的测试执行解耦呢？

解决方案 1：测试编排平台

Testkube 是一个专门为 CI/CD 构建的测试编排平台，用于解决上述问题：

支持执行任何测试工具/版本的测试，无需大量脚本编写。
使用 Kubernetes 运行所有测试，提供一致且可扩展的执行环境。
允许在需要时运行测试，包括作为 CI/CD 的一部分、手动运行、通过外部触发器运行等。
内置扩展任何测试工具的支持，用于负载生成或多场景 E2E/功能测试。
提供所有测试结果和工件的单一仪表板，确保一致的故障排除方法和运营/质量见解的收集。
将测试自动化编排与 CI/CD 工具分离，使 QA 重新控制测试执行活动。

Testkube 在自己的基础设施中运行测试，帮助管理成本和安全方面。仪表板可以托管在云中或本地运行（如果需要，可以断网），提供易于启动且符合安全性的替代方案。

选项 2：手动脚本编写和管道粘合

如果 Testkube 不适合您，您有哪些选择来规避上述部分挑战？

如果您在组织中至少使用一种 CI/CD 工具，您可以考虑针对测试创建微管道，然后从现有的构建管道调用/复用这些管道。这可能有助于您实现上述第 3、5 和 6 点。

这些管道可以在需要时运行，但单个测试不能运行。
所有测试结果都可以在这些管道的输出中找到，但如果使用多个测试工具，它们仍然会断开连接。
可以确保测试人员/QA 有权管理这些管道，而无需触及构建配置的其余部分。

很遗憾，对其他要点提供的支持水平将根据您使用的 CI/CD 工具以及您愿意投入到自定义脚本编写/维护中的精力/时间而有很大差异。

摘要

自动化测试执行是大规模 CI/CD 管道中的强制性实践，但它带来了许多 CI/CD 工具未解决的挑战。CI/CD 工具在这方面的不足阻碍了可以在团队、项目和测试工具之间扩展的成功测试策略。

Testkube 为这些挑战提供了一个整体解决方案，同时保持与组织中已部署的任何测试工具、工作流或管道兼容。提供了一个开源版本。在 testkube.io/get-started 尝试一下，将您的自动化测试执行提升到一个新的水平。