持续集成和自动化测试策略

Question

我在一家使用持续集成（TeamCity）的公司工作。每次有人检查CI软件时，都会启动构建并运行所有单元/自动测试。问题是我们有超过7000个单元测试+ 756个自动测试（用于测试JavaScript，因为我们有一个非常复杂的UI逻辑来进行计算等）。因为你可以在每次有人检查所有过程时进行成像需要2个多小时才能完成所有步骤（build-unitest-automated test），所以我需要等待那么多才能得到结果才能理解我的办理登机手续可能打破了自动测试或单元测试。最糟糕的情况是，当不止一个人检查某些内容以便TeamCity开始排队时，在我获得有效结果之前（过时）我可以等半天！我们应采取什么策略来加快这个过程？这是一种最佳实践，即使只是稍微改变，也可以运行所有自动化测试吗？

Answer 1

我会考虑以两种方式分解您的测试套件 - 目标是让您和您的团队可以办理登机手续，获取一杯咖啡，并在您返回时获得团队城市的一些有意义的反馈你的办公桌。

1. 决定你真正想要在每次提交时测试什么，将剩余的测试移动到按预定时间间隔运行的套件（每小时，每晚 - 对你有用）。

2. 如果同意运行的一组测试仍然很大 - 打破设置并分布在多个并行运行的节点上。

您可能还想加强CI计算机，具体取决于您的内容的性质，测试的工作目录位于tmpfs（RAM磁盘）中。

Answer 2

我将在理论上谈论，我还没有付诸实践，但CI在我的目标是在夏天结束时起床和哼唱。

从我在开发人员中得到最多尊重的人们所看到的陈述中，我在测试策略方面看到的CI最常见的元素是将测试分为长跑和短跑

然后，您需要配置标准检查以启动短期运行测试，以便对解决方案进行基本验证。然后在每晚构建中，对于部署构建，您是唯一需要运行完整测试套件以验证回归测试的时间。

---

Aside / Alternate回答：看到我还没有为自己设置CI，我从未理解TeamCity的商业模式，他们根据构建代理进行定价。现在我明白了为什么多个构建代理真的开始重要，如果你的测试套件需要那么长时间，能够一次运行5个构建变得更加重要。因此，现在有一个选择就是花更多的钱在弹孔上贴上创可贴。

Answer 3

持续集成最适用于Git或Mercurial等分布式版本控制系统。

每个开发人员都可以经常登录到他们的本地存储库，而不会一直触发整个集成和UI测试仪式。

在本地完成功能后，可以将其签入中央存储库。因此，只有在添加了新功能和/或修复程序时，CI服务器才会运行所有耗时的测试。

Answer 4

您是否考虑过使用预先测试的提交？如果你运行远程运行构建（没有提交到VCS），你可以确定你没有破坏VCS中的任何东西（只是因为你还没有提交）。你可以毫无问题地继续工作。如果构建成功，您可以提交更改（即使您在相同的文件中进行了其他更改） - 如果您通过TeamCity的插件提交，它将完全提交您发送到服务器进行测试的代码。

这样，您不必等到TeamCity的构建完成后才能继续使用它。

免责声明：我是TeamCity开发人员。