夜间构建 vs. 持续集成：长时间运行的自动化测试

Question

我们面临的“问题”是一个庞大的自动化集成测试套件。虽然我们的构建时间是合理的（小于1小时），但测试通常需要超过6个小时才能完成。

虽然在我们的构建运行中测试了这么多功能很好，但它显然是实施CI的障碍，而我发现这对于保持源代码树处于“始终可构建”状态非常有帮助。

我已经查看了像这样的讨论线程，详细阐述了区别。

这引出了一些问题：

1. CI是否指定或推荐单元测试和集成测试自动化？ 我之前听说过仅限单元测试，但在快速搜索中没有找到任何这样的声明（或基础）。
2. 结合构建+自动化测试时间/比率的有效CI团队的最佳实践是什么？ 我的直觉告诉我，这应该是最坏情况下小于2小时，而可能要小于1小时才能真正有效。 理论上，我们可以将测试分解为并行运行，并且可能在不到2小时的时间内使它们运行，但这仍将是3小时的运行。
3. 从长时间运行的夜间构建+集成测试到CI的最佳方法是什么？ 我考虑使用仅包含一些骨架单元测试的CI构建，结合继续进行集成测试的每晚构建。

欢迎任何工具推荐（Windows-only C#/C++代码库）。

- holtavolt

---

更新 - 已处理1-3项，但未收到任何工具推荐。CruiseControl.NET是明显的选择 - 还有其他值得考虑的用于C#/C++仅限Windows代码库的工具吗？ - holtavolt

刚刚偶然发现这个。我们正在尝试在 Windows C# 上使用 Jenkins，并且在一天内取得了相当大的进展。同时也看看 TeamCity 和 Bamboo。 - KCD

Answer 1

然而，对于大多数项目来说，XP指南中的“十分钟构建”是完全合理的。我们现代化的大多数项目都能达到这个目标。值得集中精力使其实现，因为每减少一分钟的构建时间，每次开发人员提交代码时就可以节省一分钟。由于CI要求频繁提交，这样累加起来就会节省很多时间。 来源: http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast 为什么需要花费6小时呢？你有多少测试？单元测试和集成测试的比例是多少？你可能有更多的集成测试，或者你的单元测试不是真正的单元测试。你的单元测试是否涉及数据库？这可能是问题所在。

6小时是一个非常长的时间。上面的文章提供了一些提示。

- goenning

---

感谢提供Fowler文章的链接。是的，我们的测试平台几乎完全由集成测试组成，这显然是问题的一部分（我希望能说服团队和管理层值得投资于改变这种情况）。 - holtavolt

考虑的一个因素是测试优先级。你能否说服团队将测试分为一、二、三级，并仅在CI中运行一级测试？当然，这意味着测试团队需要定期（每天？）在特定的"blessed build"上运行其余的测试，以确保适当的覆盖率。作为指导原则，一级测试可以是一组关键场景/集成测试的小集合，如果失败，则意味着构建通常无法使用并且主要功能不可用。 - nithins

如果一个测试没有在持续集成中运行，那么当它出现问题时没有人会知道。所以，如果你不运行它，那就把它删掉，这样至少你对自己是诚实的。 - time4tea

Fowler对TestDouble测试服务器的指针很有趣。我认为Nithin关于测试优先级层次的观点也会有所帮助。我认为P1应该主要是单元测试（其中大部分都需要编写），以及一些关键且快速的集成测试。 - holtavolt

实际上，这被称为冒烟测试。它们在任何其他测试之前运行，并且如果失败则停止构建。这正是@nithins所说的。只需在谷歌上搜索 冒烟测试 就能找到相关信息。 - goenning

“Smoke test”这个术语已经在这里使用，表示初始手动测试过程。查看维基百科条目：http://en.wikipedia.org/wiki/Smoke_testing#Software_development，似乎“构建验证测试”会更加精确（并且在我们的组织中没有重载）。 - holtavolt

Answer 2

这里有几件事情。

一般来说，你会有多个构建版本，一个编译并运行单元测试的版本，一个编译并运行本地验收测试的版本，以及一个运行集成测试的版本。

你绝对不需要一个做所有事情的单一构建版本。

对我来说，你的构建时间听起来相当长 - 记住这里的重点是给出快速反馈，指出出了什么问题。我不太了解你的项目 - 但我认为你应该尽量将编译和单元测试构建时间缩短到两到三分钟以下。这是完全可行的，除非是非常大型的项目，所以如果你的单元测试需要很长时间，那么现在是时候开始问为什么了。

六个小时也是非常长的时间。你确定你的测试正在测试正确的东西吗？你有太多广泛范围的测试吗？你是否在测试代码中随处使用“sleep()”来弥补没有很好地建模异步性的事实？

你可能应该看一下Jez Humbles的书《持续交付》，以及Growing Object Oriented Software，了解如何编写单元/集成测试。GOOS使用Java作为实现语言，但所有概念都是相同的。

- time4tea

---

顺便说一句 - 单元测试应该很快！- 你应该能够在不到一分钟的时间内运行几千个单元测试。 - time4tea

是的 - 我理解这是CI的意图，并且我会强调我们目前正在运行集成测试，而不是单元测试。这些集成测试非常广泛，随着发现和修复错误，新的测试被添加以覆盖这些情况（例如混合回归测试）。 - holtavolt

当然，你有多少个？它们涵盖什么内容？有多少重复的部分？到处都有sleep()吗？为什么它们需要这么长时间？你说的bug是什么意思？如果测试人员在UAT中发现某些东西不起作用，他们只是报告一个bug吗？那不是bug，只是未完成的功能，所以编写一个更低级别的测试... - time4tea

你还问建立过程应该有多长才能“真正有效”。嗯，它们应该很短。集成构建可能最多10分钟，编译和单元测试理想情况下约30秒。 - time4tea

将测试套件拆分为多个部分可以实现灵活的策略。我们有一个策略，即代码在提交之前必须通过单元测试，但不需要通过集成测试。 - Raedwald

我相信进行增量更新/构建的CI构建将非常快（大约几分钟）。我们目前的构建是“干净的状态”，所以这不是问题。关于数量和覆盖范围，它们对应用程序套件来说是合理的（有很多数据库和网络文件活动）-在那里没有太大的收益。 - holtavolt