9
您如何扩展集成测试？
我正在研究用于扩展我们当前产品上不断增加的集成测试数量的技术和策略，以便使它们（人类）能够成为我们开发和CI流程的一部分。 在大约200多个集成测试中，我们已经达到1小时的标准以完成完整的测试运行（在台式机上运行），这对开发人员在常规推送过程中容忍运行整个套件的能力产生了负面影响。这正影响着积极地去管教他们创造良好的动机。我们只对关键的场景进行前后集成测试，并且我们使用的环境可以反映生产，该环境是在每次测试运行时从头开始构建的。 由于运行需要时间，因此无论测试运行有多集中，都会造成严重的反馈循环和许多浪费的周期，等待机器完成测试运行。别介意对流程和进度，理智和可持续性造成更大的负面影响。 我们希望在该产品开始变慢之前进行10倍以上的集成测试（虽然还不知道，但似乎还没有开始使用功能）。我认为在某些时候，我们必须合理地期望要进行几百或几千个集成测试。 明确地说，要防止这种情况成为关于单元测试和集成测试的讨论（永远不要交易）。我们正在使用TDD进行单元测试，并在该产品中进行集成测试。实际上，我们在服务体系结构的各个层进行集成测试，这对我们有意义，因为我们需要验证在将体系结构中的模式更改为其他领域时，我们在何处引入重大更改。系统。 关于我们的技术栈的一些知识。我们目前正在（CPU和内存密集型）仿真环境上进行测试，以从头到尾运行我们的测试。由组成noSql后端（ATS）的Azure REST Web服务组成。我们通过在Azure桌面模拟器+ IISExpress中运行来模拟生产环境。每台开发机仅限于一个模拟器和一个本地后端存储库。 我们也有一个基于云的CI，它可以在相同的仿真环境中运行相同的测试，并且与我们当前的CI提供程序一起在云中进行测试所花费的时间是其两倍（2小时以上）。就硬件性能而言，我们已经达到了云CI提供程序SLA的极限，并且超出了他们在测试运行时间上的允许范围。为了公平起见，他们的规格还不错，但显然是内部脏台式机的一半。 我们正在使用一种测试策略，为每个逻辑测试组重建数据存储，并预加载测试数据。在全面确保数据完整性的同时，这对每个测试增加了5-15％的影响。因此，我们认为在产品开发的这一点上优化该测试策略几乎无济于事。 总而言之，它的缺点是：尽管我们可以优化每个测试的吞吐量（即使每个测试的吞吐量提高多达30％-50％），但在不久的将来，我们仍然无法通过数百个测试有效地扩展规模。现在1小时甚至还远远超出了人类可以忍受的范围，我们需要在整个过程中进行一定程度的改进以使其可持续。 因此，我正在研究可以采用哪些技术和策略来大大减少测试时间。 编写更少的测试不是一种选择。让我们不要在这个线程中争论那个。 尽管价格昂贵，但绝对可以选择使用更快的硬件。 无疑，在并行环境中在单独的硬件上运行测试/方案组也是肯定的选择。 围绕正在开发的功能和场景创建测试分组是合理的，但最终无法证明完整的覆盖范围或对系统不受更改影响的信心。 从技术上讲，可以在云规模的暂存环境中运行而不是在台式机模拟器中运行，尽管我们开始将部署时间添加到测试运行中（在测试运行开始时每个部署时间大约20分钟以部署内容）。 将系统的组件分成独立的逻辑部分在一定程度上是合理的，但是由于组件之间的干扰预计会随着时间而增加，因此我们认为在此方面的里程有限。（即，更改是无效的，可能会以意想不到的方式影响其他人，这在系统逐步开发时经常发生） 我想看看其他人在这个领域使用什么策略（和工具）。 （我必须相信其他人在使用某些技术集时可能会遇到这种困难。） [更新：2016年12月16日：我们最终在CI并行测试上投入了更多资金，以讨论结果：http：//www.mindkin.co.nz/blog/2015/12/16/16-jobs]