【问题标题】:How to keep automated tests fast?如何快速保持自动化测试?
【发布时间】:2008-10-08 20:14:50
【问题描述】:

自动化测试必须快速反映实时项目状态。这个想法是:

  1. 在执行对存储库自动构建的任何提交之后(尽可能快地完成)。
  2. 如果构建成功,则启动自动化测试。必须很快。

这是我知道的最好的方法来确定你的更改是否会破坏任何东西。

起初,快速构建似乎很难,但我们设法将其保持在 100 秒左右。 105(!) 个项目的解决方案 (MSVS 2008 C#)。

测试似乎没有那么简单(我们使用 NUnit FW)。单元测试不是一个大问题。是集成测试杀死了我们。而不是它们更慢的事实(非常感谢任何关于如何使它们更快的想法),而是必须设置的环境要慢得多(atm ~1000 秒)!

我们的集成测试使用需要重新部署的 web/win 服务(目前有 19 个)以反映最新的变化。这包括重新启动服务和大量 HDD R/W 活动。

任何人都可以分享关于应该/可以如何组织/优化环境和工作流程以加快自动化测试阶段的经验。什么是“低级”瓶颈和解决方法。

附:欢迎书籍和广泛的文章,但更感谢现实世界的工作解决方案。

【问题讨论】:

    标签: performance testing continuous-integration automated-tests


    【解决方案1】:

    您可以采取多种优化策略来提高测试的吞吐量,但您需要问问自己此测试的目标是什么,以及为什么需要快速测试。

    有些测试需要时间。这是生活中的事实。集成测试通常需要时间,并且您通常必须设置一个环境才能执行它们。如果您设置了一个环境,您将希望拥有一个尽可能接近最终生产环境的环境。

    你有两个选择:

    1. 优化测试或测试部署。
    2. 不要经常这样做。

    根据我的经验,最好有一个正确的集成环境,可以发现错误,并充分代表最终的生产环境。我通常选择选项 2 (1)。

    说我们会一直测试所有东西是很有诱惑力的,但实际上你需要一个策略。

    (1) 除非存在大量仅在集成中发现的错误,在这种情况下,忘记我所说的一切:-)

    【讨论】:

    • 我们处于一个状态,集成测试不需要太长时间,但部署它们是一个杀手。因此,我们现在尝试(1)。
    【解决方案2】:

    我们使用 .NET 和 NUnit,它们支持类别(您可以在测试中使用的属性)。然后我们进行长时间运行的测试并将它们放在一个 NightlyCategory 中,以便它们仅在夜间构建期间运行,而不是在我们想要快速运行的连续构建中运行。

    【讨论】:

    • 有很多方法可以避免运行耗时的测试。目前,我们首先尝试执行任何可能的优化,然后才开始延迟测试,因为这样您就失去了“我的更改是否阻碍了任何事情”的答案。
    • 这就是我们所做的。超过 30 秒的测试类别(经验法则)属于“NightBuildTest”类别。其他人一直处于活动状态。
    【解决方案3】:

    我在Turbo-Charged Test Suites 上整理了一个演示文稿。后半部分面向 Perl 开发人员,但前半部分可能对您有用。我对您的软件了解得不够多,不知道它是否合适。

    基本上,它涉及加速测试套件中的数据库使用和在单个进程中运行测试以避免不断重新加载库的技术。

    【讨论】:

      【解决方案4】:

      我建议进行几个高级别的端到端测试,如果其中任何一个失败,请运行“更高分辨率”测试。

      考虑通过电话提供技术支持...

      你的电脑能用吗? 如果是,完成。 如果没有,您的计算机是否完全打开? ...

      对于我的单元测试,我有一些快速测试,例如“我的计算机可以工作吗?”如果这些通过,我不会执行我的套件的其余部分。如果其中任何一个测试失败,我会执行相关的较低级别测试套件,让我更清晰地了解该失败。

      我的观点是,运行一套全面的顶级测试应该不到半秒。

      这种方法给了我速度和细节。

      【讨论】:

      • 当然,问题在于如果您的顶级测试错过了一些可能导致测试失败的条件。用你的比喻来说,“你的电脑工作了吗?完成了”——如果鼠标坏了怎么办——它应该通过测试,但“电脑工作正常”
      • 我同意,请谨慎选择端到端测试,并在睡觉时运行所有详细测试。如果您的详细测试显示了端到端测试没有的错误,请查看如何改进您的端到端测试。从某个地方开始,然后改进。
      【解决方案5】:

      环境必须是 设置慢得多(atm ~1000 秒)!

      好吧,至少你知道应该把重点放在哪里……你知道这些时间都花在了哪里吗?

      显然,任何解决方案都将取决于此处的具体情况。

      在这种情况下,我使用了三种解决方案:

      1. 使用更多机器。也许您可以将您的服务划分到两台机器上?这会让您将设置时间缩短 1/2 吗?

      2. 使用更快的机器?在我知道的一种情况下,团队通过升级硬件(多个 CPU、快速 RAID 存储、更多 RAM 等)将他们的集成测试执行时间从 18 小时缩短到 1 小时。当然,他们花了 10,000 美元,但这是值得的。

      3. 使用内存数据库进行集成测试。是的,我知道您也希望针对真实数据库进行测试,但也许您可以先针对内存版本运行测试以获得快速反馈。

      【讨论】:

        【解决方案6】:

        这种情况的最佳解决方案是在重置环境之前备份环境的重影并恢复图像。这对花费的时间更有意义。

        【讨论】:

          【解决方案7】:

          构建机器人:http://buildbot.net/trac 如果您正在进行持续集成(自动测试),我推荐的再多不过了。通过快速配置,我们所有的单元测试都会在每次提交时运行,并且较长的集成测试会在一天中定期运行(我上次检查了 3 次,但这很容易改变)。

          【讨论】:

          • 我们使用 CC.net,但我会看看 buildbot
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2016-09-04
          • 2011-06-11
          • 2014-07-18
          • 1970-01-01
          • 2020-03-02
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多