自动化测试必须快速反映实时项目状态。这个想法是：
这是我知道的最好的方法来确定你的更改是否会破坏任何东西。
起初，快速构建似乎很难，但我们设法将其保持在 100 秒左右。用于 105(!) 个项目的解决方案 (MSVS 2008 C#)。
测试似乎没有那么简单（我们使用 NUnit FW）。单元测试不是一个大问题。是集成测试杀死了我们。而不是它们更慢的事实（任何关于如何使它们更快的想法都非常感谢），而是必须设置的环境要慢得多（atm ~1000 秒）！
我们的集成测试使用需要重新部署的 web/win 服务（目前有 19 个）以反映最新的变化。这包括重新启动服务和大量 HDD R/W 活动。
任何人都可以分享如何组织/优化环境和工作流程以加快自动化测试阶段的经验。什么是“低级”瓶颈和解决方法。
欢迎 PS 书籍和广泛的文章，但更赞赏现实世界的工作解决方案。
您可以采取许多优化策略来提高测试的吞吐量，但您需要问自己这个测试的目标是什么，以及为什么它需要快速。
有些测试需要时间。这是生活中的事实。集成测试通常需要时间，并且您通常必须设置一个环境才能执行它们。如果您设置了一个环境，您将希望拥有一个尽可能接近最终生产环境的环境。
你有两个选择：
以我的经验，最好有一个正确的集成环境，发现错误，并充分代表最终的生产环境。我通常选择选项 2 (1)。
很容易说我们会一直测试所有内容，但实际上你需要一个策略。
(1) 除非有大量仅在集成中发现的错误，在这种情况下，忘记我所说的一切 :-)
我们使用 .NET 和 NUnit，它们支持类别（您可以进行测试的属性）。然后我们进行长时间运行的测试并将它们放入 NightlyCategory 中，以便它们仅在夜间构建期间运行，而不是在我们想要快速运行的连续构建中运行。
我整理了一个关于Turbo-Charged Test Suites的演示文稿。后半部分面向 Perl 开发人员，但前半部分可能对您有用。我对您的软件知之甚少，不知道它是否合适。
基本上，它涉及加速测试套件中的数据库使用和在单个进程中运行测试以避免不断重新加载库的技术。
我建议进行一些高级别的端到端测试，如果其中任何一个失败，请运行“更高分辨率”测试。
考虑通过电话进行技术支持...
你的电脑能用吗？如果是，完成。如果没有，您的计算机是否完全打开？...
对于我的单元测试，我有一些快速测试，例如“我的计算机是否工作？” 如果这些通过，我不会执行我的套件的其余部分。如果这些测试中的任何一个失败，我将执行相关的低级别测试套件，让我可以更高分辨率地查看该失败。
我的观点是，运行一套全面的顶级测试应该不到半秒。
这种方法给了我速度和细节。
事实上，必须设置慢得多的环境（atm ~1000 秒）！
好吧，至少你知道应该把重点放在哪里……你知道这些时间都花在了哪里吗？
显然，任何解决方案都将取决于这里的细节。
在这种情况下，我使用了三种解决方案：
使用更多的机器。也许您可以将您的服务划分到两台机器上？这会让你的设置时间减少 1/2 吗？
使用更快的机器？在我知道的一种情况下，团队通过升级硬件（多个 CPU、快速 RAID 存储、更多 RAM 等）将他们的集成测试执行时间从 18 小时缩短到 1 小时。当然，这花费了他们 1 万美元的订单，但这是值得的。
使用内存数据库进行集成测试。是的，我知道您也希望对真实数据库进行测试，但也许您最初可以针对内存版本运行测试以获得快速反馈。
这种情况的最佳解决方案是在重置环境之前备份环境的重影并恢复图像。这对所花费的时间更有意义。
Buildbot：http ://buildbot.net/trac 如果你正在做持续集成（自动化测试），我推荐的还不够。通过快速配置，我们所有的单元测试都会在每次提交时运行，并且较长的集成测试会在一天中定期运行（我上次检查了 3 次，但这很容易改变）。