软件开发争分夺秒已不是什么秘密了。软件公司的兴衰取决于他们能否快速发布有价值的性能。敏捷的发布周期缩短了产品上市的时间，产品更新速度远超竞争对手，质量提升，进一步巩固企业市场份额。这种竞争也驱使着发行周期不断加速，让行业陷入一个无休止的竞速循环。
高质量的代码也需要耗费时间成本。“速度和质量不可兼得”这个铁律同样适用于软件行业。相比于质量好但上市晚的产品，低质量上市早的产品获得的市场份额较少，如果发布周期中途不幸出现故障，还要花费高昂的成本进行修复。
为了解决速度和质量的矛盾，DevOps 用户通常依赖于精细型基础架构（构建、工作流或管道），或扩展型基础架构。这些是什么意思？在本文中，我将深入研究每种方法如何应用于测试，以及两种方法如何取长补短，加速测试和整个管道流程。
什么是精细型测试？
精准化测试方法就是 “精细型”的一个典型例子。
为了降低左移情况下的总体测试负担，通常需要手动检查正在运行的所有测试，并找出哪些测试经常失败。针对这些频繁失败的测试，专门构建一个测试的子集，供开发人员在提交代码之前运行。这样做的目的在于，开发人员可以在提交代码之前发现测试失败，将错误 “定位在特定区域中”，而不用等到 CI/CD 构建才知道测试失败。这个方法也大大降低了 CI/CD 构建的失败率，等待时间减少，发布经理也有更多时间揪出“是谁破坏了构建”。
这种精细化的方式创建了一个人工反馈的循环，但问题在于它的局限性。由于门类细分，它只能盯准某种类型的测试，从而忽视了其他的测试。测试范围有限，可能只涵盖了 20% 的失败构建。
另外，这种精细化需要大量的劳动力，且效率不高。要选择测试的子集，我们必须检查并了解所有的测试，挑选出那些经常失败的测试，然后随着软件的发展不断修改这些测试集。测试门类可以不断细分，永远没有尽头，因此成本只增不减，也没有折中的选择。因为归根结底，单靠精细化，我们只能专注于测试的一个子集，而忽略了很多未被触及、未经检验的区域。
什么是测试中的扩展型基础架构？
另一种方法是 “扩展型基础架构”。这包括云端扩展、硬件扩展、分布式系统、规避和缓存技术、自动化等等。
当我们扩展基础架构时，对精细分类的需求就不那么迫切了。无论是通过硬件升级、扩展还是分布式计算，都能为开发人员提供数百个额外的内核，确保在提交代码之前运行完整的测试套件，而不用在特定的子集上妥协。
当然，这种方式所检测的错误更多，反馈更快，上下文也能及时得到维护。扩展型基础架构适用于任何类型的测试——单元测试、集成测试、API 测试、回归测试、浸泡测试、负载测试等等。这类的测试自动化能加速发布周期，提升竞争力、质量、生产效率，以及最终的胜利——加速上市。
扩展基础架构是一项战略性举措。然而，每一种战略都包含具体战术——这就是精细化的价值所在。不过，即使考虑扩展型基础架构和测试自动化，我们也从专业细分中可以学到一些经验。
最佳方案：强强联合加速发布
当我们从整体的角度来看待开发优化时，混合使用两种方法意义不凡。对于测试，扩展型基础架构是一种更方便的解决方案，可以快速完善测试方法，进行更多更好的测试。这是战略性的变化，目标在于提升测试效率，增加测试类型，这也将成为未来的标准。
首先扩展基础架构，让测试人员能够更有效地集中精力。这也是一次性的投资，扩展效果清晰明了。一旦我们扩展了基础架构，我们就用我们所取得的成果和学到的知识，来更好地专注于精细化的工作。
例如，基础架构扩展后，我们可能会发现测试的一个子集由于依赖关系而不得不按顺序运行，因此也不能利用额外扩展的计算能力优化进程。对于这个子集，我们可以对症下药，删除不必要的依赖项，以便从弹性的基础架构中获益。
重中之重
当发布高价值功能时，速度才是出奇制胜的绝招！开发团队需要寻找新的方法来缩短发布周期，加快产品上市。有时，新方法可能是常用方法的混合，要知道解决方案并不总是非黑即白。取长补短，完美联合精细型和扩展型基础架构，是战略创新和战术敏锐的一个最佳例子。
