一文说尽测试金字塔的这20年

自动化测试 (AT) 并不是保护项目质量的盔甲骑士。但它是保护项目质量的一种方法。结构合理的自动化策略可确保成本效益、减轻团队负担并提高测试准确性。而测试金字塔可能是启动自动化测试的一种好方法。测试金字塔是一个框架，指导了各种测试类型在开发过程中的分布。您可以使用这个模型来组织或完善您的自动化测试。

1 测试金字塔概述

在探讨金字塔的实际应用之前，让我们先回顾一下其结构背后的逻辑。

1.1 原始测试金字塔：单元-集成-UI

测试金字塔提供了一个有组织的测试层次结构。它反映了每个层次的测试位置和数量。分为三层：

单元测试。
集成测试。
用户界面 (UI) 测试

它们代表不同的测试目标和关注领域。金字塔的形状强调了每个层级所需的测试的 “数量”：

首先进行单元测试，因为它们执行起来简单快速。您可以为它们分配很多资源，并发现后期可能更难修复的较小问题。
集成测试更为复杂且相对较慢。您应该减少这些测试的数量，但要针对相关方面进行测试。
用户界面测试是最复杂、最难运行的。只需进行少量测试，并优先考虑对用户至关重要的元素。

1.1.1 基础层：单元测试

单元测试是测试金字塔的基础层，用于检查独立的软件组件。它们的目的是验证代码的正确性和性能。将如此大量的工作投入到单元测试中，并不是为了达到100%的覆盖率，而是为了避免日后举步维艰。

想一想，当您在尽早发现许多小错误时，更大的问题就不太可能出现。金字塔的递减形式精确地体现了这种方法。

然而，并不意味着要全力进行单元测试。为了提高生产效率，单元测试并不需要检查每个元素，它们只需要执行大量的代码。换句话说，单元测试的目的是：

针对单个代码单元进行测试。
快速执行。
提供一致的结果。
具有可预测的结果。

为了确保上述目标，您可以采取以下措施：

使用描述性的测试名称。
一次只测试一个功能。
编写小而专注的测试。
检查边缘情况和边界条件。
使用”预置-执行-断言”（Arrange-Act-Assert）模式。
避免使用if-else和switch-case语句。
使用针对测试目的的断言。
测试正向和负向场景。
避免重复编写测试代码。
保持测试代码的更新。

*预置-执行-断言模式：

预置—设置前置条件和输入。
执行—执行操作。
断言—验证结果。

1.1.2 中间层：集成测试

集成测试评估内部或外部系统之间的交互和数据交换。它们验证各种元素能否顺利通信。

金字塔将集成测试放在中间较小的一层。由于集成测试比单元测试更复杂，因此不应该有太多的集成测试。相反，可以通过以下方法提高集成测试的效率：

确定测试内容和原因。
准备包括测试数据、验收标准和测试方法在内的测试计划。
定期测试。
监控结果，防止出错。

您还可以关注一些集成场景中的重点内容。例如：

用户将新产品添加到购物车。在这种情况下，您应优先确认应用程序在与电子商务数据库通信时，能正确反映更新内容。
客户尝试使用错误的凭据登录。在这种情况下，您需要评估错误处理，以防止出现可用性或安全问题。
消费者尝试支付其购买的商品。相应地，您需要评估多个服务的交互，重点关注支付、库存和运输等方面。

1.1.2 顶层: UI 测试

位于金字塔顶层的是UI测试。它们专注于用户视角，确保消费者价值。这些测试模拟用户交互，以验证UI行为的正确性。

它们占据了金字塔的顶层（最小的一层），这是因为它们在执行上具有一定的困难：

它们处理复杂的Web组件和场景。
应用程序的界面经常变化，这意味着UI测试需要经常返工。
UI测试是最难维护的测试类型，等等。

因此，通过减少处理关键用户流程的UI测试数量，您可以开发出高质量的应用程序，并节省时间和精力。以下是一些关于如何最大化利用这些测试的要点：

创建清晰且具有描述性的测试名称。
使用页面对象模型（POM）来表示用户界面交互和元素。
依靠数据工厂或生成方法，尽量减少测试数据依赖性。
实施测试自动化框架，简化脚本编写。
对UI测试进行参数化，以涵盖具有不同输入的场景。
实施数据清理程序。
审查和重构测试，使其保持最新状态。
监控测试结果，发现潜在的应用程序问题。
对测试代码使用版本控制，以便更好地协作。
实施同组评审，提高测试质量。

2 测试金字塔的迭代

测试金字塔并没有长期保持不变。它的迭代似乎是为了适应不断发展的测试领域。每个版本都对原始形式进行了调整，升级了被认为不切实际的方面。

让我们来讨论一下四个主要的改动，解释其中的变化。

2.1 单元 – 集成 — E2E

为什么现在顶层变成了端到端（E2E）测试呢？因为UI经常变化。频繁的变化会导致更多的测试，从而增加资源消耗。通过顶部的E2E测试，质量保证工程师可以检查不受视觉变化影响的面向用户的方面。因此，您可以进行深入的应用程序分析，并避免额外的工作。

E2E测试检查完整的工作流程，从开始（如用户注册）到结束（如接收到购买的商品）。它复制真实的用户交互，确保顺利的用户体验。因此，与UI不同，E2E测试提供了应用程序在真实场景中的整体视角。

2.2 单元 – 集成 – UI & API – 手工 & 探索

这个模型将API添加到中间层，因为并不总是需要UI测试。例如，您的应用程序可能没有Web用户界面或过于复杂。鉴于UI测试容易出错，您可以用 API 来代替。它们能提供适当的覆盖范围，而无需投入太多资源或做太多妥协。

探索性和手工测试位于顶层。为什么呢？因为它们优先考虑以用户为中心，并且可以发现一些遗漏的问题。例如，自动化测试对于可用性或可访问性不会有太大作用。但是手工和探索性测试却能让你更接近卓越。

2.3 单元 – 集成 – 契约 (API) – UI – E2E – 验收

在软件开发过程中，将任务分配给不同的团队是很常见的。因此，您需要确保单独创建的模块之间没有矛盾。契约测试正是着眼于这一点。该附加层可确保自主开发的部件之间的一致性。

UI测试和 E2E 测试因其范围而被分开。在某种程度上，这种划分可以让你进行选择。还记得之前的两种模型是如何添加 API 和 E2E（基本上允许跳过UI）的吗？通过这种迭代，您就可以根据项目需要调整测试结构。

验收测试验证系统是否符合业务和用户的期望。它们提供了对软件功能和价值的平衡视角。因此，现在验收测试占据了顶层，成为连接高层和低层测试（E2E 和单元测试）的纽带。

2.4 单元 – 验收 – 集成 – 监控 & 告警 – 冒烟 – 手工

在此迭代中，验收测试下降到金字塔的下部。它们将验证您正在构建正确的产品。而且您越早确保这一点，就越好。实际上，早期的验收测试就像是集成测试前的门禁。如果你已经进行了全面的单元测试，验收测试将对其进行验证，您就可以放心地继续进行其他测试。

监控和告警可以主动的发现问题。通过这些，您可以及时跟踪和解决问题，然后再进行更复杂的评估。

冒烟测试可以快速验证系统功能，强调关键用户路径。它们是非侵入性的，并且数量有限。因此，在开发早期实施有益于测试阶段和最终产品。

自动化测试以预期结果为基础，手工测试则更注重探索，以从中获得最大价值。脱离脚本可以让您充分研究系统。这一层并不重要，但它可以表明用户在实际使用中是如何与应用程序交互的。

3 实践中的测试金字塔

提到上一节，你可能会问：”为什么金字塔会发生这样的变化？这个问题的答案在于对测试过程的不切实际的看法。例如，它的原始形式没有考虑到不同项目的独特需求。

接下来，我们将从该模型的优点入手，再来谈谈它的局限性。

3.1 优点

金字塔的层次结构有助于团队组织测试工作。
鼓励测试的平衡分布，使测试覆盖范围均衡。
单元测试的快速执行使开发人员能够迅速获得有关其代码的反馈。
频繁运行单元测试和集成测试有助于及早发现问题，最大限度地减少错误堆积。
单元测试的弹性和简单性意味着减少维护和有针对性的工作。

3.2 缺点

测试金字塔夸大了单元测试的价值。虽然单元测试必不可少，但过度强调单元测试可能会导致测试覆盖率的差距。
该模型还将UI测试置于首位。但它们更加脆弱，经常会在变更时出现问题。
对技术方面的关注并没有抓住消费者的视角。现实世界的场景和用户行为需要更复杂的方法。
金字塔忽略了通过手工去测试易用性的价值。
过分简化了测试过程，可能不适用于某些项目。

4 取得合适的平衡

您可能找不到金字塔的实际应用。但它的原则可以为您提供指导。因此，更重要的是平衡测试和方法，以满足您的测试需求。

确定应用程序中需要广泛测试的区域，并将精力集中在这些区域上。
优先考虑具有更高缺陷检测价值的测试。例如，如果复杂的测试对整体质量贡献不大，则应避免使用它们。
识别高风险点，例如重要功能或安全性，并将测试集中在这些方面。
保持较快的反馈，以防止技术债务。
使用以用户为中心的方法去做自动化测试，例如可用性测试和 beta 测试。这样，您将获得积极的用户体验。

最重要的是，要考虑项目的独特性。根据这些特点调整测试策略。例如，您的团队可能更擅长一些特定的方法，在这种情况下，让他们做他们最擅长的事情，以最大限度地提高测试价值。

5 测试金字塔的演化

那么，如果您可以弯曲和扩展测试金字塔，为什么它仍然存在？很简单，它仍然有效。您可以根据其原始形状构建您的测试，并利用由此产生的模型。

5.1 菱形

在菱形测试模型中，测试体积发生了变化。它将大部分精力分配给集成层，试图平衡工作量和功能。

该模型优先考虑集成测试，因为它们可以保障关键的业务功能。单元测试和E2E测试的工作量大致相同—足够覆盖基本要素（并稍微多一些），但不会过多地陷入其中。

菱形模型最适合系统集成最重要的项目，例如数据转换、API和数据库。

5.2 冰淇淋甜筒

冰淇淋甜筒测试模型是一个倒金字塔，顶部有一个勺子。它是唯一突出手工测试的模型。该模型强调了最终用户体验的重要性，提倡以用户为中心的测试。

由于该模型鼓励采用用户视角，因此它认为单元测试最无用。它鼓励您只测试必需的部分，并在用户体验方面全力以赴。

冰淇淋甜筒测试模型适合以用户满意度和可用性为重点的项目。它还非常适合传统系统、原型、MVP 和需要依赖手工方式去做质量保证的小型项目。

5.3 奖杯

奖杯测试模型是一种全面的测试方法。它致力于优化测试所投入的资源以及对产品的价值。

最底层是静态测试，用于捕捉代码中的拼写错误。它们的成本足够低廉，可实时运行，并能消除基本错误。有了它们，应用程序就有了一个稳定的基础。

与菱形模型一样，奖杯模型也更重视集成测试。您不需要进行很多测试来发现真正的问题，而且它们的速度足够快，可以覆盖更大的代码块。

奖杯模型在成本和收益之间实现了良好的平衡。它非常灵活，适合各种项目，例如具有敏捷/DevOps 环境、复杂业务逻辑和需求不断变化的项目。

5.4 螃蟹

螃蟹测试模型引入了一种横向测试方法。它更喜欢并行的测试层次，而不是层级结构。螃蟹模型将组件、API和单元测试视为同等重要。它们支撑着主要部分—功能和视觉化的E2E 测试。

该模型促进测试工作的合理分工，以更快地发现问题。它还能激励开发人员和质量保证工程师通力合作，确保更好的质量。因为进行了视觉化的 E2E 测试，所以螃蟹模型是唯一认识到 “美观 “对用户的重要性的模型。

敏捷性高、并行测试多的项目可以从螃蟹测试模型中受益。它也非常适合用户体验至上的产品。

6 使用测试金字塔的最佳实践

您大老远跑来，不会就是为了找一堆测试金字塔的替代方案吧？别担心。正如我们之前提到的，原始模型在敏捷中也有很多用途（我们稍后会讨论）。现在，让我们来看看如何让金字塔为您服务。

6.1 采用基于风险的方法

对高风险区域进行全面的单元测试和集成测试。。例如，您希望确保关键功能或经常变动的代码的稳定性。而对像静态内容或次要功能这样的元素，只需进行少量测试或手工测试即可。

将自动化工作放在最重要的地方。

6.2 避免重复测试

不同级别的测试不应检查相同的组件。考虑一个E2E 测试，去执行单元或集成测试已涵盖的功能。您会在同一件事上花费两次时间和资源。

结构化您的测试和测试数据，以防止重复。

6.3 编写整洁的测试代码

保持测试代码简洁易懂，这样更容易发现和解决问题。您还会发现详细的测试名称和描述会减少混淆。

遵循编码规范，避免测试代码出现不必要的复杂性。

6.4 搭建快速反馈的部署流水线

搭建部署流程，以便在代码更改时自动运行测试。通过快速测试迭代，您可以更快地发现并解决错误。

应用持续集成/交付实践，简化测试和部署。

6.5 保持测试环境的一致性

维护一个与生产环境相似的测试环境。因此，要密切关注配置和软件依赖性。使用相同的数据也有助于获得一致的结果。

自动化设置和清理操作，最大限度地减少可变性。

6.6 重构优化测试

优先考虑定期重构和优化测试代码。随着应用程序的发展，您可能需要修改对应的测试用例。定期审查和更新将使它们保持相关性和准确性。

定期修改和删除多余或过时的测试。

7 敏捷中的测试金字塔

你可能会认为金字塔缺乏灵活性，与敏捷恰恰相反。但是，Mike Cohn实际上是为了支持敏捷方法而创建了这个模型。因此，测试金字塔的概念实际上增强了敏捷方法，下面是它的原因。

7.1 更好的时间管理—提高团队生产力

敏捷团队依靠高效的时间管理而蓬勃发展。而金字塔为测试工作的分配提供了一个清晰的框架。这种优化节省了时间，提高了团队的工作效率。

7.2 测试驱动开发 (TDD) – 更好的代码质量

TDD 是敏捷开发的天然伴侣。在编写代码之前编写测试，可以提高代码质量，避免回归。金字塔对单元测试的关注与这种方法不谋而合。

7.3 清晰的结构 – 更容易确定优先级

测试金字塔提供了一种基于风险的测试方法。它可以让团队根据不同测试类型的相关风险来确定测试的优先级。高风险区域会受到更多关注，而附加功能则会得到较少的校验。

7.4 自动化路线图 – 减少 QA 费用

敏捷的迭代本质意味着频繁的测试。这对持续改进非常有益，但对预算来说可能不太友好。金字塔模型暗示了通过自动化来实现成本效益。该模型清楚地列出了需要自动化的内容—以避免对资金或团队造成压力 - 需要大量时间和精力的测试。

7.5 早期缺陷检测— 缩短上市时间

测试金字塔的结构有助于及早发现缺陷。它还鼓励在开发过程中保持软件的稳定性。有了快速的问题修补和系统一致性，您就更有可能更快地交付产品。您还可以迅速适应不断变化的用户期望。在敏捷中使用测试金字塔的最大好处是您可以构建它。通过添加新的层级和重组僵化的形式，自己的需求量身定制金字塔，并最大限度地发挥其整体价值。

8 总结

测试金字塔是一个特殊的概念。当然，它并不完美。但是，为了更好地服务于质量保证工程师，有那么多专家参与了这一理念的提出和开发，这令人鼓舞。您可以使用原始金字塔来更好地组织您的测试。您还可以对其进行修改，以适应您的项目需求。