testing - 回归测试如何最适合 CI/CD 工作流？

Question

我正在编写一个由多个微服务组成的 API。我在私有(private) Gitlab 仓库中有代码。我有一个自定义的 CI/CD 管道，配置为在每次提交到 master 时自动运行几个不同的步骤(例如构建、测试、部署到开发环境)。部署到产品是手动的。

我已经围绕这段代码编写了一些单元测试，它们自然只测试代码的小单元。当然，这些在每次提交时都会运行，因为如果它们失败，则意味着代码中的某些内容已损坏。

我还有部署后运行的回归测试。其中之一实际上是一个 bash 脚本，它使用 curl 通过某些参数访问我的生产端点并检查以确保我收到 200 个响应。我已经参数化了这个脚本，所以我可以轻松地将它指向我的开发环境(而不是生产环境)。

我使用此回归测试(以及其他类似测试)来检查我已部署的服务是否正常运行。我在部署后立即运行它，作为最后的复核以确认一切正常。但我想将其自动化。

我的问题是这在 CI/CD 工作流中适合什么地方？在提交上运行这种回归测试没有意义，因为该提交不一定与部署相结合。并且由于有许多原因导致服务可能关闭，而这些原因与最近提交的任何代码更改无关。换句话说，管道不应因外部环境而失败。

是否有运行和自动化回归测试的最佳实践？

Answer 1

好问题。这里有几个有趣的点。

1. 何时在您的 CI/CD 环境中运行回归测试(目前存在)。

对此的明显答案是作为部署后步骤运行。使用您当前用于将部署步骤限制为仅主分支的相同方法，您可以将此部署后步骤仅限制为主分支。

如果您添加有关您的环境的更多详细信息。例如，您正在使用的 CI/CD 系统和您当前的配置我很乐意提供有关如何实现这一目标的更多具体细节。

1. 在提交上运行这种回归测试没有意义

我见过几次的有趣方法。使用云服务(AWS/GCloud 等)在每次 CI 运行时启动一个环境。这意味着可以为每次提交运行完整的管道。虽然它需要更多资源，但这意味着您可以在合并到 master 之前发现问题。当然，投资返回率是否在您的环境中增加取决于您。