如何扩展集成测试？

Question

我正在研究技术和策略，以扩展我们对当前产品的越来越多的集成测试，这样它们就可以(从人的角度来说)成为我们开发和CI过程的一部分。

关于200+集成测试，我们已经达到了1小时的目标来完成完整的测试运行(在aa桌面开发机器上)，这对开发人员容忍将整个套件作为常规推送过程的一部分的能力产生了负面影响。这就影响了人们对良好创造他们的自律的动机。我们只对关键场景进行前前后后的集成测试，我们使用的是一个反映生产的环境，该环境是从零开始构建的，每次测试运行。

由于运行所需的时间，它造成了一个糟糕的反馈循环，许多浪费的周期等待着机器完成测试运行，不管测试运行有多集中。不要在意对流动和进步、理智和可持续性的代价更高的负面影响。

在这个产品开始减速之前，我们希望有10倍多的集成测试(不知道是真的，但我们甚至还没有从特性上开始)。我认为，在某个时候，我们必须进行数以百计或几千次的集成测试。

要明确的是，要防止这成为单元测试与集成测试的讨论(这是不应该进行交易的)。我们正在用TDD进行单元测试，并在此产品中进行集成测试。事实上，我们在我们所拥有的服务体系结构中的各个层进行集成测试，这对我们来说是有意义的，因为我们需要验证当我们将体系结构中的模式更改到系统的其他区域时，我们在哪里引入了破坏性的更改。

关于我们的技术栈。我们目前正在一个(CPU和内存密集型)仿真环境上进行测试，以便从端到端运行我们的测试。它由面向noSql后端(ATS)的Azure REST web服务组成。我们通过在Azure桌面模拟器+ IISExpress中运行来模拟我们的生产环境。我们仅限于每个开发机器一个模拟器和一个本地后端存储库。

我们也有一个基于云的CI，它在相同的模拟环境中运行相同的测试，并且测试运行所花费的时间是当前CI提供商在云中的两倍(2hrs+)。在硬件性能方面，我们已经达到了云CI提供商SLA的极限，并且在测试运行时超出了他们的允许范围。公平地说，他们的规格并不差，但质量只有一台内部肮脏的台式机的一半。

我们正在使用一种测试策略，为每个逻辑测试组重新构建数据存储，并使用测试数据进行预加载。在全面确保数据完整性的同时，这会给每个测试增加5-15%的影响.因此，我们认为，在产品开发的这一点上，对测试策略进行优化是没有什么好处的。

它的长短在于:虽然我们可以优化每个测试的吞吐量(即使每个测试的吞吐量达到30%-50% )，但在不久的将来，我们仍然不会对数百个测试进行有效的扩展。1人力资源现在仍然远远超过了人类所能容忍的程度，我们需要在整个过程中进行一个数量级的改进，以使其持续下去。

因此，我正在研究我们可以使用哪些技术和策略来大幅度减少测试时间。

• 编写更少的测试不是一种选择。请不要在这条线上争论这一条。
• 使用更快的硬件无疑是一种选择，尽管非常昂贵。
• 在不同的硬件上以并行方式运行测试/场景组也肯定是首选选项。
• 围绕开发中的特性和场景创建测试分组是合理的，但最终不可靠地证明完全覆盖范围或系统不受更改影响的信心。
• 在云规模的阶段环境中运行而不是在桌面模拟器中运行在技术上是可行的，尽管我们开始增加部署时间来测试运行(在测试运行开始时，每个大约20分钟来部署这些东西)。
• 将系统的组件划分为独立的logial片段在一定程度上是可行的，但我们预计在这方面的里程有限，因为组件之间的交织预计会随着时间的推移而增加。(也就是说，变化可能会以意想不到的方式影响其他人-就像系统逐步开发时所发生的那样)

我想看看其他人在这个领域里使用了什么策略(和工具)。

(我不得不相信，其他人可能看到了使用某些技术装置的这种困难。)

https://web.archive.org/web/20200114101702/http://www.mindkin.co.nz/blog/2015/12/16/16-jobs :更新:2016年年12月16日:我们对CI并行测试进行了更多的投资，以讨论结果：

Answer 1

我在一个地方工作，花了5个小时(跨越30台机器)来运行集成测试。我对代码库进行了重构，并对新内容进行了单元测试。单元测试花费了30秒(跨越一台机器)。哦，虫子也掉下来了。以及开发时间，因为我们确切地知道了什么打破了粒状测试。

长话短说，没有。完整的集成测试随着代码库的增长呈指数增长(更多代码意味着更多测试，而更多代码意味着所有测试都需要更长时间才能运行，因为有更多的“集成”需要完成)。我认为“小时”范围内的任何东西都会失去持续集成的大部分好处，因为反馈循环并不存在。即使是一个数量级的改进也不足以让你变得更好--而且它也远不能让你变得可伸缩。

因此，我建议将集成测试缩减到最广泛、最重要的烟雾测试。然后，它们可以在夜间或一些不连续的时间间隔内运行，从而减少了对性能的大量需求。单元测试，只有在添加更多代码时才线性增长(测试增加，每个测试运行时不增加)是进行扩展的方法。

Answer 2

集成测试总是长时间运行的，因为它们应该模拟真实的用户。出于这个原因，您不应该同步运行它们！

考虑到您已经在云中运行内容，在我看来，您似乎处于在多台机器上扩展测试的首要位置。

在极端情况下，每个测试创建一个新环境，并同时运行它们。然后，您的集成测试将只需要运行时间最长的测试。

Answer 3

听起来你有太多的集成测试了。回想一下试验金字塔。集成测试属于中间。

例如，使用方法set(key,object)，get(key)的存储库。这个存储库在整个代码库中得到了广泛的使用。依赖于此存储库的所有方法都将使用假存储库进行测试。现在您只需要两个集成测试，一个用于set，另一个用于get。

其中一些集成测试可能被转换为单元测试。例如，在我的观点中，端到端测试应该只测试站点是否使用正确的连接字符串和正确的域正确配置。

集成测试应该测试ORM、存储库和队列抽象是否正确。经验法则是，集成测试不需要任何域代码，只需要抽象。

几乎所有其他东西都可以用存根/模拟/伪造/在-mem-实现中测试依赖项。