Translator|陈军审稿人|孙淑娟2009年，MikeCohn在他的《SucceedingwithAgile》一书中用金字塔来比喻软件测试模型。渐渐地，这个词流传开来，现在它已成为行业中的行业标准。总的来说，测试金字塔可以形象地表示测试的标准化逻辑结构。它由以下三个不同的级别组成：金字塔的底部是单元测试。该单元实际上是一小段逻辑代码。它们可以是函数、类，甚至是类中的方法。单元测试只是检查目标单元的行为是否符合开发人员的预期。开发者可以编写单元测试直接调用被测试的代码，而不依赖任何其他组件、服务或UI，然后评估其输出。金字塔的中间层是集成测试，Mike在他的书中也称之为“服务测试”，其主要目的是测试系统的不同组件如何协同工作。例如，代码中的模型是否能正确地与数据库交换数据，或者某个方法是否能从API中获取信息。同样，集成测试可以直接调用接口处的代码，无需UI交互。金字塔的顶层是端到端(E2E)测试，也称为UI测试。E2E是从最直观的角度进行测试，即通过运行应用程序来查看其效果。当然，端到端测试不一定需要人工进行，完全可以自动化。E2E测试可以模拟每个用户应该交互的动作，比如点击按钮、输入信息、捕获UI的显示内容等。可以看出，这三类测试会涉及不同的类别：单元测试只能发现最基本的逻辑错误。它们速度更快，运行所需的资源更少。集成测试主要是验证应用服务和数据库是否能够与编写的代码和类系统地协调。他们只能在两个或多个组件交互的接口处发现问题。端到端测试，重点关注完整应用能否上线。由于它是最全面的测试类型，因此它往往是计算资源最密集和运行时间最密集的。1.测试金字塔的复杂度既然我们了解了测试金字塔的基本测试级别，让我们来讨论每个测试的复杂度。单元测试由于其简单性而易于编写和维护。尽管它们只测试代码的一小部分，但它们经常被使用。我们通常可以在几秒钟内运行数千个单元测试。集成测试在复杂性和数量级上与单元测试相似，毕竟我们只对被测应用程序的“边界”部分感兴趣。但是，集成测试比单元测试需要更多的资源来运行。E2E测试编写复杂，维护困难，需要大量资源，运行缓慢。但是，由于我们可以通过各种端到端的测试工具覆盖更多的应用，所以我们需要做的测试量并不大。从金字塔的形状可以看出，每一层的宽度都会与该层的测试体积成正比。也就是说端到端的测试量比较少，集成测试的数量没有单元测试的多和广泛。如前所述，三类测试的复杂度和代码库的覆盖率都是逐层递增的。下图显示了编写、运行和维护各种测试的工作量比例。因此，您可以用更少的努力找到更多的缺陷和错误。2.如何将字符金字塔化到测试中在项目开始时编写E2E测试通常极具挑战性。除非开发团队可以采用BDD之类的框架，从头开始编写验收测试（https://semaphoreci.com/blog/the-benefits-of-acceptance-testing），否则大多数E2E测试只会在A中可用基本原型或最小可行产品已准备好编写。如下图所示，在整个开发过程中，开发者会逐渐增加编写单元测试和集成测试的工作量。我们再来看看测试的效率。众所周知，缓慢的测试往往会减慢生产环境所需要的重要信息的反馈。因此，开发者需要高效运行三个测试套件，才能稳步提升软件质量。金字塔底部的单元测试运行效率最高，因此开发人员通常很乐意编写和使用它们。相反，鉴于其复杂性，E2E测试效率最低。大型Web应用程序通常需要数千个单元测试、数百个集成测试和数十个E2E测试。而他们的时间可以从下图体现出来：3.使用测试奖杯测试前端测试金字塔的历史可以追溯到2009年，随着科技的飞速发展，人们在处理的时候可能也需要不同的测试模型具有不同的发展要求。KentC.Dodds提出的测试奖杯（https://twitter.com/kentcdodds/status/960723172591992832）是为前端开发搭建的测试模型。测试奖杯已重新确定优先级。它认为，由于大多数现代UI依赖于各种后端组件并且难以单独测试，因此集成测试才是王道。与Pyramid相比，单元测试处于次要地位，可以用ESLint和JSHInt等静态测试工具代替。通过扫描代码，他们可以发现潜在的问题，例如：使用不安全的语句，或者不遵循变量命名规则。位于奖杯顶端的是端到端测试，其在测试金字塔中的占比相近。4.测试矩阵在测试金字塔中，我们往往会忽略测试结果的可信度问题。也就是说，真正能够验证应用可行性的测试只有E2E测试。一般来说，我们认为开发者在测试上投入的精力越多（比如E2E测试），测试结果就越可靠。在这方面，GlebBahmutov和RomanSandler提出了一个测试矩阵（https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead）作为一种策略计划和测试时间工具。如上面的矩阵所示，开发人员的努力从左到右增加，而可信度从下到上增加。显然，甜蜜点在果岭区。大多数软件项目都是从低努力和低信心的黄色区域开始的。随着项目的成熟和新特性的加入，测试需求也会处于熵增状态。如果测试团队未能持续改进和维护测试计划，他们将很快滑入红色区域。对此，我们应该如何以尽可能少的投入来提高测试的可信度呢？我们需要定期重新评估以下五类测试相关方面：安装：包括安装和设置测试框架所涉及的工作。编写：这与为给定框架编写测试的复杂性以及开发人员的技能水平有关。Running：包括测试套件的运行难度，以及CI/CD的性能。调试：涉及在测试失败时发现和修复问题的难易程度。维护：包含在整个项目生命周期中维护测试所花费的努力。在这种模式下，我们往往需要在项目初期就给单元测试一些输入。但是，一旦项目功能稳定下来，开发团队需要通过增加更多的端到端测试和减少其他测试类别来平衡组合测试。因此，该团队可以有条不紊地调整其在不同类别的投资，同时测试有效性稳步提高。5.谨防教条式思维由于速度、成本和维护等问题，金字塔在一定程度上限制了我们尽早进行端到端测试。当然，也有人认为端到端测试更贴近用户的真实场景操作，团队可以通过应用提供的公共接口来进行。因此，如果改变后台的实现，甚至更换整个后端，那么E2E测试就不要再造了，只需要沿用原有的测试用例，微调测试即可。因此，其维护工作量其实不足为奇。当然，每个团队、每个项目和每个组织都是不同的。并且随着需求的变化，团队可能需要重新确定或标准化测试套件，以灵活的方式停止现有的测试模型，或者评估新的测试模型，并根据需要进行调整，以实现更快、更好、更经济检测结果。6.总结历史悠久的测试金字塔模型，为整个测试领域建立了一个典型的通用模型，方便大家参考和交流。当然，随着新技术、新实践、新理念的出现，各种改进的模式也应运而生。他们各有专长，服务于特定的发展领域。不乏服务于CI/CD管道的自动化测试套件。总之，需要根据自己的实际项目选择最合适的测试套件。原标题：https://dzone.com/articles/the-testing-pyramid-how-to-structure-your-test-sui译者简介JulianChen（朱利安陈），社区编辑，IT从业十余年项目实施经验，善于管控内外部资源和风险，注重传播网络与信息安全知识和经验；持续以博文、专题、翻译等形式分享前沿技术和新知识；经常在线和离线等信息安全培训和教学。
