我们大家都见过测试金字塔，这一图表告诉我们，从比例上讲，我们应该减少大型测试的数量，转而增加小型测试。然而，我们看到许多团队仍然主要依赖大型的端到端测试，这是为什么呢？更重要的是，这是否是个问题？

端到端测试是什么？

端到端测试是我们用来检查整个代码库是否能够协同工作的一种方式，字面意思就是从一端到另一端。这些测试通常以用户旅程的形式编写，模拟最终用户可能在应用中执行的操作，一路锻炼不同的代码部分。

​​

图 1. 一场驱魔仪式，与锻炼代码完全不同！

在 CI/CD 管道中，这些测试实际上并不是用来证明我们构建的东西是正确的（或好的）。与其说是功能测试，不如说这些测试通常只是为我们 staging 和生产环境提供健康检查。它们是跨应用问题的早期预警，并且让我们对所有内容是否部署到环境中充满信心。

​​

图 2. 显示测试级别的信息图

在上述信息图中，我展示了如何使用端到端测试来覆盖健康检查，而功能验证和代码逻辑则由其他较小的测试来完成。这表明 “我们构建的东西正确吗？” 这一问题的测试并没有丢失，只是在其他地方进行了测试。

为什么团队会创建许多端到端测试？

我们都见过测试金字塔，并被告知要尽量减少创建的端到端测试数量，但不少团队仍在这一层面创建大量测试。我观察到以下几种可能的原因：

• 先入为主 ：对于很多人来说，端到端测试是我们第一次接触自动化测试，因此我们把它当作 “自动化测试”。这可能导致我们试图用它来满足超出其应有的范围的测试需求，比如用于功能测试和验收测试。

即使我们了解到并看到了其他可以使用的测试形式，我们也会很自然地回到最初学到的东西上。这是我们的大脑对使用新事物的自然抵制，而不是依赖于过去经验中那些经过验证、可靠的方法。

• 易于理解 ：用户在系统中的旅程比服务交互和代码更容易被更多人可视化。对于不熟悉与整个堆栈代码交互的测试人员或思维方式更侧重于客户旅程的产品经理来说，他们会在用户旅程层面思考如何验证功能的正确性。

有时我们会认为自动化测试就是 “把我们手动测试的内容自动化”。当我们理解为需要复制手动测试中所做的工作时，就很容易明白为什么要创建端到端测试。当不同类型的测试人员相互合作，手动测试人员为自动化测试人员提供步骤脚本时，这种情况就会变得普遍。

• 易于实现 ：好吧，现在说点有争议的观点…… 并非每个负责自动化测试的人都能像软件工程师那样流利地阅读和编写代码。这没问题，但这会导致需要更简单（或低代码）的方式来实现自动化测试。这时，记录和回放、AI 生成和低代码测试自动化工具就派上用场了！这些工具帮助那些不是原生编码人员的人能够创建和维护测试套件并运行自动化测试。

由于这些工具通常是基于浏览器的，并且从 UI 驱动端到端测试，我们最终会创建大量端到端测试来覆盖系统的全部行为。

为什么我们可能不希望有很多端到端测试？

当我们谈到减少端到端测试的数量时，通常有一些特定的原因促使我们这样做。以下是一些我们希望减少端到端测试，转而采用其他测试类型的例子：

• 因为管道和更快的交付 ：如果我们的团队正通过 CI/CD 管道对代码进行大量更改，那么我们希望有较短的反馈循环，能够拒绝不工作的代码，并且有很多快速运行的测试来验证行为。我们可以通过以下方式实现：

使用带有模拟的较小测试来覆盖上游和下游的内容，比如数据集的建立。

在管道中运行的测试，即运行比完整部署更少的组件。

在管道早期（或本地）运行的测试，而不是在 staging 或生产环境中运行。

可以并行运行的测试，因为它们不会独占环境。

这就是为什么我们倾向于使用基于代码的单元和验收测试来验证代码逻辑和开发行为。这些测试更适合管道，使我们能够频繁验证代码更改并进行多次部署。

• 更接近代码便于调试 ：那些对修复周转时间有较短服务等级协议（SLA），需要维护大型代码库或面临大量复杂性的团队，希望能够快速定位问题以便更容易修复。测试越接近代码，使用它们诊断问题就越容易。

​​

图 3. 一位医生正在做出非常准确的诊断。

如果一个端到端测试失败，你知道用户旅程出了问题，所以问题可能出在该旅程中使用的任何服务中。而验收测试失败时，你更清楚哪些具体行为或功能出现了问题。至于单元测试失败，则可以开始准确定位到底是哪个服务的逻辑不正确了。

当然…… 这前提是你的测试覆盖率支持这种调试方式。

• 易于维护和支持 ：众所周知，端到端测试通常比其他类型的测试更容易出现故障，它们会随机失败，这意味着你不得不花几个小时来调试它们。通常，基于代码的测试较少出现故障，这意味着较少的虚假失败和被忽视的测试。

模拟数据输入意味着对数据处于正确状态的依赖性降低。

测试较小的部分意味着需要准备的内容更少。

服务响应更及时意味着等待时间错误更少。

此外，较小的基于代码的测试往往更精确和聚焦，因此很容易弄清楚它们应该做什么并让它们做到；需要更少的变通方法来让测试工作，这也可能引发失败。

• 关于支持 AI 和低代码端到端测试的注意事项 ：我发现，基于浏览器的记录和回放测试通常很难让其正常工作，而且当它们停止工作时，修复起来也很痛苦。通常页面加载时间的微小变化可能会导致测试失败，或者它们会间歇性地决定不工作，而可用工具（或缺乏工具）使得很难找出原因。

当使用 AI 生成测试时，由于测试不是以你习惯的编码风格编写的，可能会更难更改和维护。生成的测试代码也可能包含需要重构的低效部分，因此请确保你的团队具备相应的技能来完成这项工作。

• 因为我们已经覆盖了 ：如果团队已经有了足够的其他测试覆盖，比如单元测试、验收测试和部署后手动测试，再加上健壮的可观测性或用户测试，你的团队可能会认为端到端测试的代价太高了，不值得去做。

当然，没人说你必须通过端到端自动化测试来解决生产环境和部署后测试的健康检查问题。解决问题的方法有很多！

​​

图 4. 穿靴子的猫恳求你不要剥猫皮！

实用主义：我们可能需要更多端到端测试的情况

许多文章、博客、传统观念和人们都会指向测试自动化金字塔，并满怀信心地说一定要减少端到端测试！但你知道吗？有时候你做不到，你需要更多的端到端测试，而我在这里告诉你何时以及为什么会出现这种情况：

• 代码无法接受小型测试 ：有些代码写得无法测试，因此无法接受单元或验收测试。在这种情况下，除非你打算重构所有内容，否则你可能不得不依赖端到端测试作为你的主要测试方法来覆盖尽可能多的内容。
• 我们工作在孤岛中 ：有些组织在开发人员和自动化测试人员之间设有隔离，并且不鼓励他们交流或合作。在这些情况下，关于验收和功能测试的思考可能被抛给测试人员，而你所能做的就是尝试实施端到端测试来覆盖这些内容。

或者，开发人员可能有 “测试不是我的工作” 的心态，你无法让他们添加更接近代码的测试。那么你就得尽你所能添加任何类型的测试，这可能最终就是端到端测试。

• 我们不是程序员 ：如上所述，负责自动化测试的人可能不是原生程序员，不太适合创建更接近代码的测试。那么我们可能希望使用低代码、基于浏览器的记录和回放解决方案，甚至开始用 Selenium 或 Cypress 编写端到端测试，因为有很多相关的指南，而且对我们来说更容易上手。
• 我们一直这样做 ：有些测试人员（和团队）一直以某种特定的方式进行测试，使用端到端测试。他们不想学习其他方法，也不想倡导改变，因为这很难，或者他们看不到其中的价值。也许他们有一种偏好的测试方法和 / 或工具，因为他们一直使用它并取得了结果，这让他们感到舒适…… 他们会倾向于创建更多的端到端测试。
• 管理层这样说 ：有时候，只是因为你的老板希望你以某种方式工作。这种方式更便宜、更容易让他们理解和管理，或者因为他们是一个无法以不同方式思考的控制狂。你会怎么做？

这可能与 “因为审计人员这样说” 有关，即你的组织的审计机构只接受端到端测试覆盖作为一种证明系统质量的方式。

在这些情况下，我们可能会有更多端到端测试，这没问题，我们正在尽我们所能进行测试，不让完美成为好的敌人。也许这效率不高，但希望它能完成任务，并帮助我们更好地了解我们所构建内容的质量。

所以，是的，尽管有时减少端到端测试并沿着测试金字塔向下移动更好，但在某些情况下，可能让这种模式继续下去，继续使用端到端测试会更好（或更实用）。