deployment - 将慢速 UI 测试集成到 CI 部署管道中

Question

我们在 Teamcity 中使用相当标准的 CI 部署管道来打包我们的应用程序。我们从以下管道开始。下面的每个步骤都代表构建必须通过才能进入下一步的门：

1. 编译
2. 单元测试
3. 后端组件集成测试
4. 前端验收测试（基于 Selenium）
5. 包裹

当前端测试套件较小且相对较快（<2 分钟）时，这在项目开始时工作得很好。然而，随着套房的规模和长度不断扩大（15:00 分钟并且还在不断增长），在每次办理入住手续时将其解雇很快就变得站不住脚了。此后，我们从主管道中删除了该套件，并在一个独立的管道上每天启动四次：

1. 编译
2. 单元测试
3. 后端组件集成测试
4. 包裹

这种方法的问题很明显，因为即使它导致前端测试套件中的回归，构建很可能会一直到打包阶段。我想如果前端测试套件失败，我可以使已经创建的包无效，但这似乎很笨重。我们已经研究过进一步优化测试套件，但我认为这是一个死胡同，除非我们可以并行运行测试，这是 TeamCity 不支持的。

欢迎提出建议/批评。

Answer 1

不确定您在这里工作的是什么开发平台，但我看到了两个通用选项。

1. 使用 selenium 网格或类似 testNG 的东西
2. 利用您拥有的任何 teamcity 构建代理，并将测试分段以在这些代理阵列上并行运行。我过去有专门的构建代理运行测试，但即便如此，如果你的测试集增加太多，这种方法最终还是会失败。

您的目标应该是减少直接通过 UI 进行的测试量。看看如何将更多的重点放在更底层的测试代码上可以减少你的直接 UI 测试负担。在最近的一个项目中，我们重构了应用程序中的 javascript 以使其可测试。这些运行速度更快的测试意味着我们可以删除大量运行速度较慢的 webdriver 测试。它有点投入时间和精力，但它造成的痛苦比你目前的情况要少得多。

应尽可能避免计划构建，就像您提到的那样，您最终可能会得到包含捆绑缺陷的打包软件，而且反馈时间会大量增加。