架构设计内容分享(九十八)：系统质量如何保证？金字塔测试

目录

一 什么是测试自动化

二 什么是测试金字塔

01 单元测试

02 集成测试

03 端到端测试

三 为什么使用测试金字塔

四 测试金字塔的好处

五 工具及资料

六 关于测试其他考虑

---

测试金字塔是一个被广泛认可的软件测试策略，它强调跨多个层次或者层的不同类型的测试的分布。它是敏捷开发方法中常用的一个概念，用于确保有效的测试实践。测试金字塔由三个主要层或级别组成: 单元测试、集成测试和端到端测试。测试金字塔是软件测试人员策略的重要组成部分。该应用程序需要彻底的测试，以发布到世界和测试应用程序成功。它需要一个可靠的测试策略。通过在测试金字塔中映射您的测试工作，您可以使一些测试比其他测试更自动化，并将您的工作集中在特定类型的测试的特定平台上。

在这篇文章中，我们将解释到底什么是测试金字塔，为什么它是整体质量保证的重要组成部分，以及敏捷测试如何能够优化在敏捷自动化金字塔的每一层(UI 测试、服务层测试和单元测试)计划的活动上花费的时间。

一 什么是测试自动化

测试有两种形式ーー手动测试和自动测试。手工测试在某种程度上是有帮助的，但是自动化测试通常更有效。某些类型的手工测试(例如发现和可用性测试)对于您的流程可能是非常宝贵的。其他类型的测试ーー如回归测试和功能测试ーー最好使用自动化完成。

测试自动化是软件开发人员用来确保 Web 应用程序满足预定义的质量标准的一种实践。测试自动化还用于执行手动和重复的测试任务，以提供快速、准确的报告。

测试自动化通过确保自动运行所有测试，并分析测试结果以改进未来的开发周期，从而提高了软件质量。它要求业务分析师定义清晰的测试用例，开发人员编写响应这些输入的代码，DevOps 工程师管理测试数据并解释结果。

测试自动化是测试金字塔的重要组成部分，因为它允许团队快速有效地执行大量的测试。在软件开发项目中，自动化测试金字塔是一种被广泛接受的组织和优先排序测试类型的方法。

二 什么是测试金字塔

测试金字塔是一个软件开发框架，它可以减少开发人员确定更改是否影响现有代码所需的时间。通过最小化开发时间和培养更健壮的测试套件，减少这个时间可以帮助培养高质量的代码。

测试金字塔是一个模型，它为评估自动化测试套件中要执行的测试类型提供了一个结构。它还定义了此类评估的顺序和频率，以便能够提供快速反馈，确保代码更改不会影响现有功能。

测试自动化金字塔由三个层次组成:

• 单元测试

• 集成测试

• 端到端测试

单元测试

单元测试构成了测试自动化金字塔的基础。单元测试层是进行大部分测试的地方，通常由开发人员编写，以验证他们编写的代码。由于开发人员最熟悉他们的代码和应用程序，所以他们可以在很短的时间内快速提出大量的单元测试用例。

与其他测试不同，单元测试有助于揭示 bug (在单元或块级别)。开发人员从单元测试中获得的信息比从其他类型的测试中获得的信息更加广泛，因为开发人员可以获得关于补丁对不同特性(依赖于修复)的副作用的信息，以及关于问题的起源或者关于“在代码中的哪个位置”发生错误的详细信息。因此，单元测试周转时间非常快ーー因为开发人员可以在单元测试期间验证修复并检测任何问题。

测试人员倾向于在其他类型的功能测试中测试完整的产品，比如集成、系统测试、健全性测试等等。因此，验证修复和报告问题、将问题分配给开发人员并解决这些问题可能需要一段时间。另一方面，对于单元测试，测试仅限于特性或需求，可能无法定位系统级问题。

自动化单元测试的开发被认为是软件开发中的最佳实践之一，因为它可以帮助确保程序的质量。一些最常用的单元测试工具是“ xUnit 变体”，它们可用于开发语言，比如用于使用 Selenium 自动化的跨浏览器测试的 JUnit，xUnit.net for。网等。

这一层对团队敏捷测试金字塔的性能贡献高达50 ~ 60% 。因此，建议团队花足够的时间开发质量单元测试。

集成测试

集成测试对于确保软件按预期执行至关重要。单元测试检查代码的一小部分，而集成测试确保软件与外部组件(如 API 和数据库)有效地通信。集成测试可以确保按时检索数据，并确保软件与这些外部组件有效地通信。

集成测试可能比单元测试更慢，也更复杂，因为它们需要与外部源交互。除此之外，运行这些类型的测试还需要一个预生产环境，虚拟设备和实际设备的平衡也是如此。

软件应用程序依赖于其数据库的正常运行，因此测试应用程序是否在需要时与其数据库进行交互至关重要。在开始测试这种类型的集成之前，必须确保测试数据库类似于生产数据库。

集成测试不仅限于测试应用程序本身内部的代码行为。它还包括测试应用程序与外部服务(包括 API)的集成。您必须创建一个尽可能接近生产环境的预生产环境，以便与外部 Web 服务进行集成测试。但是，从集成的角度来测试每个场景可能很有挑战性，因为不可能从外部依赖项控制响应，例如，当外部服务生成错误案例时。

端对端测试

端到端测试的完成时间最长，维护成本最高。它通过使用测试环境和数据来模拟真实世界的功能，因此它的操作速度最慢。因为端到端测试检查组装好的应用程序，所以也是最难识别问题的。

端到端测试是最完整的测试形式，它可以提供关于系统随时间变化如何运行的好主意。与其他测试类型相比，它们的运行速度可能更慢，因为它们依赖于集成测试等外部依赖项，但是它们的设置通常更快。

复杂的现代应用程序由数百个组件和数千个依赖项组成，所有这些都部署在基础设施层的生态系统中，而基础设施层本身就是由多个部分共同工作组成的。所有这些复杂性造成了大量不可预测的失败。一个单独的隔离系统可以顺利和完美地工作。

端到端测试依赖于用户行为，并能够在将产品交付给最终用户之前检测问题。因为它们是作为可用性测试的一部分执行的，所以端到端测试通过确定哪些过程对于用户在现实生活中最重要，使得在待办事项列表中确定开发活动的优先顺序变得更加容易。

01 单元测试

单元测试是测试套件的基础。它们确保代码库中的每个代码单元按预期工作，这有助于确保所有部分正确地协同工作。单元测试的范围是所有测试类型中最窄的，它包含了测试套件的大部分测试总数。

• 模仿与存根

Mocking 和 Stubbing 是测试替身，用于将被测代码与其依赖项隔离开来，并在运行单元测试时控制其行为。测试双精度对象是可用于替换其他对象的对象。它们并不特定于单元测试，但是它们在单元测试中起着重要的作用。在单元测试中，您将遇到大量的模拟和存根，因为它们使得创建测试双精度组件变得非常容易。

无论您选择使用标准库还是第三方库，都有很多方法来设置模拟。甚至从头开始编写您的模拟也只是编写一个与真实类/模块/函数具有相同签名的假类/模块/函数，然后在测试中设置假类/模块/函数。

• 单元测试的测试结构

构建所有测试(而不仅仅是单元测试)的最佳方法是:

1. 建立测试数据。

2. 在测试下调用您的方法。

3. 声明返回预期的结果。

    此结构还可以应用于其他更高级的测试。在任何情况下，它们都确保您的测试保持易读性和一致性。该结构还有助于使您的测试更短、更具表现力。

02 集成测试

集成测试在测试金字塔方法中起着至关重要的作用，是确保软件系统整体质量和可靠性的重要组成部分。与单元测试不同，集成测试侧重于单独验证单个代码单元的功能，集成测试验证应用程序中各个组件、模块或服务之间的交互和集成。

集成测试通过组合多个代码单元并检查它们如何作为一个内聚系统一起工作来模拟真实的场景。这些测试识别由组件之间的交互引起的问题，例如不兼容的接口、数据不匹配、通信问题或集成失败。通过运用集成点和路径，这些测试有助于发现在单元测试期间可能仍然隐藏的缺陷。

关于测试金字塔，集成测试通常占据中间层。它们位于金字塔底部的单元测试之上，位于端到端(E2E)或顶部的系统测试之下。该发行版通过广泛定位系统中最细粒度和最孤立的部分来优化测试工作，同时仍然验证关键集成点。测试金字塔强调比集成测试更多的单元测试。

然而，设置和执行集成测试可能比单元测试更复杂和更耗时。它们通常需要额外的设置步骤，例如配置测试环境、部署服务和管理依赖关系。由于集成测试的范围更广，它们也可能更脆弱，对更改更加敏感，这使得测试维护具有挑战性。

• 数据库集成

由于集成测试的目的是验证不同组件之间的交互，因此包括验证应用程序与底层数据库集成的测试是至关重要的。

数据库集成测试确保应用程序的代码与数据库正确交互，验证数据持久性、检索和操作操作。这些测试对于验证系统的数据层是否按预期运行以及应用程序是否能够正确地从数据库读取和写入数据库至关重要。

在测试金字塔中，数据库集成测试通常位于集成测试层中，集成测试层位于单元测试层之上、端到端或系统测试层之下。这个位置承认测试应用程序代码和数据库之间的集成的重要性，同时优先考虑大量的单元测试。

在进行数据库集成测试时，建立一个受控的、可重现的测试环境是至关重要的。这包括创建一个单独的数据库实例，或者利用测试数据种子化或事务回滚等技术来隔离测试数据并防止对生产数据库的干扰。

• 与独立服务的集成

在现代软件体系结构中，应用程序通常依赖于外部服务或 API 来执行特定功能或访问必要的资源。验证应用程序与这些单独服务的交互和集成的集成测试对于确保系统的整体功能和可靠性至关重要。

当应用程序与外部服务通信时，集成测试验证应用程序与外部服务之间的集成点是否按预期工作。这些测试涉及的场景包括发出 API 请求、处理响应、处理错误以及验证应用程序和外部服务之间的正确数据流。

在测试金字塔框架中，与独立服务的集成通常属于集成测试层，位于单元测试之上，位于端到端或系统测试之下。这个位置认识到测试应用程序和外部服务之间的集成的重要性，同时为更细粒度和孤立的测试优先考虑更多的单元测试。

要有效地使用单独的服务执行集成测试，必须设置适当的测试环境。这包括创建外部服务的测试实例，或者使用诸如模拟或存根等技术来模拟它们的行为。模仿或存根允许控制响应，并避免依赖于实际的好处，使测试更加确定和可靠。

具有单独服务的集成测试应该涵盖应用程序在与这些服务交互过程中可能遇到的各种场景和边缘情况。这些测试验证不同 API 端点的正确处理、身份验证机制、数据序列化格式、错误处理以及应用程序和服务之间的正确信息流。

• 合约测试

为了扩展他们的开发工作，组织已经找到了一些方法，比如在不同的团队之间传播一个系统的开发。将系统划分为小型服务表明这些服务需要某些接口来进行通信。

一些常见的接口是:

1. REST 和 JSON 通过 HTTPS

2. 使用 gRPC 的 RPC

3. 使用队列构建事件驱动架构

每个接口涉及两方: 提供者(向使用者提供数据)和使用者(处理获得的数据)。

由于团队经常相互使用并提供服务，因此形成了一个称为契约的特定接口。现代开发人员使用自动化的契约测试来确保消费者和提供者端实现与契约保持一致。这有助于及早识别与契约的偏差，因为它是一个很好的回归测试套件。

消费者驱动的合同测试(CDC 测试)允许消费者推动合同的执行。在 CDC 的帮助下，消费者可以编写和运行测试，以检查接口中他们需要的所有数据。使用团队发布这些测试以允许发布团队轻松地获取和执行这些测试。通过运行这些 CDC 测试，提供团队可以开发他们的 API。所有测试的通过表明他们已经实现了消费团队所需的所有东西。

CDC 测试允许组织培养有效的团队沟通，确保接口在任何时候都按预期工作。CDC 测试失败是团队讨论任何即将到来的 API 变化以及如何继续前进的一个指标。

• UI 测试

几乎每一个软件应用程序都包含一个用户界面，通常以基于 Web 的应用程序的 Web 界面的形式出现。但是，必须承认用户界面也可以采用 REST API 或命令行接口的形式，这一点很重要，应该注意。

UI 测试主要关注于确保应用程序用户界面的正常运行。这些测试验证用户交互触发适当的操作，数据正确地显示给用户，用户界面按预期响应不同的输入。

您可以验证您的用户界面，而不仅仅依赖于端到端测试。方法可能因技术堆栈的不同而有所不同。例如，您可以为前端 JavaScript 代码编写单元测试，如果适用的话，还可以删除后端。

对于传统的 Web 应用程序，像 Selenium 这样的工具可以用于 UI 测试。但是，如果将 RESTAPI 视为接口，那么覆盖该 API 的全面集成测试就足够了。当涉及到网页界面时，有几个方面值得测试，比如行为、布局、可用性，以及遵守公司设计准则等等。

03 端到端测试

当彻底测试部署的应用程序时，没有什么比从头到尾检查其用户界面(UI)更好的了。实现这一点的一种方法是利用 WebDriver 驱动的 UI 测试，如前所述。这些测试是端到端测试方法的主要例子。

当涉及到获得对软件功能的最大信心时，端到端测试(有时称为宽栈测试)起着关键作用。利用 Selenium 和 WebDriver 协议，您可以自动化这些测试，以模拟与已部署服务的用户交互。通过驱动浏览器(甚至可以是无头浏览器)并执行诸如单击、数据输入和 UI 状态检查之类的操作，可以有效地验证应用程序的行为。Selenium 可以直接使用，或者您可以探索构建在它之上的工具，Nightwatch.js 就是一个例子。

诸如浏览器异常、计时问题、动画和意想不到的弹出对话框等因素可能会导致调试成为测试工作的重要组成部分。然而，必须承认端到端测试带来了挑战。它们通常以不可靠和容易发生意外故障而闻名。假阳性可能经常发生，这意味着故障可能不一定表明实际问题。特别是，当您的用户界面变得更加复杂时，测试不稳定的可能性就会增加。

意识到这些挑战并为调试和维护端到端测试套件分配足够的时间是非常重要的。通过主动地处理这些问题，您可以减少潜在的陷阱，并确保您的端到端测试提供关于软件功能的可靠和有意义的反馈。

• 用户界面 E2E 测试

用户界面(UI)端到端(E2E)测试是确保软件整体质量的重要组件。这些测试在从用户的角度验证应用程序的行为和功能方面起着至关重要的作用。

UI 端到端(E2E)测试旨在复制真实的用户与软件的交互。这些测试可以自动执行诸如单击按钮、输入数据和在屏幕上移动等操作，从而对应用程序的 UI 进行全面评估。通过 UI E2E 测试，您可以深入了解不同软件组件之间的无缝协作，并确保用户体验符合预期。

当开发人员执行端到端测试时，他们通常依赖 Selenium 和 WebDriver 协议作为他们的工具。Selenium 提供了选择首选浏览器和自动与网站交互的灵活性。它使您能够模拟用户操作，例如按钮单击、数据输入和 UI 更改的验证。

利用 Selenium 进行测试自动化需要一个兼容的浏览器来执行测试。幸运的是，不同的浏览器可以使用不同的“驱动程序”来实现这一目的。选择所需的驱动程序，并将它们包含在 build.gradle 配置中。但是，必须确保所有团队开发人员和 CI 服务器都安装了适当的浏览器版本，以保持一致性。保持这些版本的同步是一项具有挑战性的任务。幸运的是，有一个专门为 Java 设计的有用的库 webdrivermanager。这个库通过自动下载和设置正确的浏览器版本，简化了过程，使得对浏览器依赖性的管理更加流畅。

• 端到端测试

REST API 端到端测试侧重于验证构成现代 Web 应用程序骨干的 RESTful API 的行为和功能。

这些测试通过与应用程序的 API 交互来模拟真实场景，涵盖了从客户机到服务器和返回的完整流程。它们验证应用程序的各个组件和层之间的集成和协作，包括用户界面、业务逻辑和数据存储。通过执行请求和检查响应，这些测试确保 API 正确运行，处理不同的输入场景，并提供预期的结果。

为了增强测试的稳定性并实现应用程序堆栈的广泛覆盖，避免仅仅依赖于图形用户界面可能是有利的。通过采用测试金字塔方法，您可以创建比严格依赖端到端测试更健壮的测试。当通过 Web 界面测试应用程序带来重大挑战时，这种策略被证明是特别有价值的。如果您的应用程序主要使用 REST API 而不是 Web UI，那么这种方法就更合适了。通过关注较低级别的测试并使用有针对性的 API 测试来补充它们，您可以为您的应用程序建立一个可靠的测试基础。

• 验收测试

验收测试在测试金字塔的框架中扮演着重要的角色，它提供了一种方法来验证应用程序的特性是否按照用户的期望执行。这些测试作为较高级别的端到端测试与较低级别的单元测试和集成测试之间的关键链接。

然而，值得注意的是，验收测试不必仅限于测试金字塔的最高级别。根据应用程序设计和被测试的特定场景，在较低级别编写验收测试也是有利的。这种灵活性允许更全面的测试方法，确保跨应用程序堆栈的不同层彻底检查关键的面向用户的特性。

验收测试的主要目标保持不变，不管它们在测试金字塔中的位置如何。它们可以作为一种手段，从用户的角度证明应用程序的特性正确地发挥作用。这种对验证所期望的行为和用户体验的关注与测试金字塔本身的层次结构是正交的。

随着测试金字塔级别的提升，您越来越深入到评估您正在开发的功能是否按照用户的立场发挥作用的领域。验收测试的粒度可能有所不同，通常侧重于通过用户界面进行的高级评估。假设您的应用程序的体系结构和特定的场景允许编写较低级别的验收测试是有益的。选择较低级别的验收测试比选择较高级别的验收测试更可取。理解验收测试的本质是至关重要的，它从用户的角度验证特性的正确性，独立于测试金字塔框架。

• 探索性测试

尽管在测试自动化方面投入了大量的精力，但是实现完美的覆盖仍然是一个持续的挑战。忽略某些边缘情况或遇到难以通过单元测试捕获的错误并不罕见。此外，自动化测试可能无法揭示与设计或可用性相关的质量问题，因为它们缺乏人工视角。因此，在测试金字塔中合并手工测试仍然是一种有价值的实践。

特别是探索性测试，它被证明是非常有价值的，因为它允许测试人员发现在自动化测试过程中可能逃避检测的问题。与其对这些发现感到沮丧，不如将其视为对建设管道成熟度的建设性反馈。将此反馈视为采取行动和改进未来测试工作的机会。

考虑评估是否有一组特定的自动化测试需要添加到当前的测试套件中。还可能需要在后续迭代中提高测试的彻底性，解决以前自动化测试中的任何潜在缺陷。

此外，探索将新的工具或方法合并到您的管道中的可能性，以减轻未来的类似问题。通过根据这些反馈采取行动，您的管道和整个软件交付过程将稳步成熟。

拥抱测试金字塔框架可以鼓励持续改进的心态，使您能够有效地响应在手工测试期间收到的反馈。随着您实现必要的调整，您的管道将变得更加健壮，并能够交付更高质量的软件。

三 为什么使用测试金字塔

应用程序的复杂性每年都在增加。查看任何典型的现代应用程序，您都会注意到它具有多种特性、 API 用法等等。这种复杂性的增加意味着测试应用程序的复杂性也增加了。最重要的是，您需要整个测试过程快速运行，以便尽快部署应用程序。

执行手动测试时，不仅需要测试应用程序，还需要考虑进行测试的环境。这样做比自动化测试更耗时，也更不精确。您还需要在每次更新后继续测试应用程序。您可能需要多次测试相同的特性。人们很容易对重复的工作感到厌烦，这会导致粗心大意或疏忽，最终导致自己犯错。

为了处理软件开发过程中的瓶颈，我们可以使用测试金字塔作为创建高效测试和提高测试质量的指南。您需要使用一个有效的过程来处理所有的瓶颈。测试金字塔是一个非常好的方法，可以让您的测试工作更加出色。它通过帮助您自动化测试并从中获得更好的结果来实现这一点。因此，测试金字塔可以极大地改进测试过程。

四 测试金字塔的好处

现在您已经了解了组成金字塔模型的各个部分，让我们来探索一些高影响力的好处。

敏捷测试方法为测试人员提供了一个完整的产品视图，为他们提供了与项目的其他关键利益相关者进行交互的机会。团队联系更为重要，因为自动化测试用例是与开发团队协作实现的。与传统方法相比，更好的自动化代码质量和代码覆盖率更好。

关键绩效指标的“代码覆盖率”对于任何从事测试代码的开发人员来说都是至关重要的。如果您更加重视产品的用户界面层，那么验证产品的核心业务逻辑或后端功能的可能性就会更小。由于通过 UI 进行测试的周转时间(TAT)较长，因此即使通过自动化进行测试，覆盖面也会较小。敏捷测试金字塔模型可以帮助您以更少的努力更快地获得更好的覆盖率。

对项目需求的更改是正常的，即使在开发的后期阶段也是如此。对于传统的软件开发，代码维护成本可能比敏捷开发高得多。在敏捷中，用户情景被分解成测试用例，“完成/结束”被定义为工作测试用例。整体维护成本更低，而且敏捷方法的投资回报率更高。

五 工具及资料

在金字塔的底部，单元测试驻留在那里，开发人员依赖于工具和库，这些工具和库促进了单个组件的独立测试。像 JUnit、 NUnit 或 PyTest 这样的框架提供了特性和功能来简化单元测试的编写和执行。此外，像 Mockito 或 Sinon.js 这样的库可以帮助创建测试双精度类型，比如模拟或存根，以便在测试期间隔离代码单元。

沿着金字塔向上移动到集成和 API 测试层，像 Postman、 RestAssure 或 Supertest 这样的工具被证明是非常宝贵的。这些工具提供了模拟和与 API 交互的功能，使开发人员能够验证不同系统组件之间的集成和通信。它们通常包括发出 HTTP 请求、断言响应和管理测试数据的特性。

随着我们进一步提升到 UI 和验收测试级别，像 Selenium、 Cypress 或 Appium 这样的工具变得必不可少。这些框架提供了自动化浏览器和移动应用程序测试的功能，允许测试人员验证用户界面的行为和功能。它们提供了与 UI 元素交互、执行操作和对显示的内容进行断言的方法。

此外，与测试数据管理、报告和持续集成相关的工具和库也是测试金字塔的组成部分。像 TestNG、 NUnit 或 Jest 这样的工具提供了报告特性，这些特性提供了对测试结果的清晰可见性，并有助于缺陷识别。持续集成平台，如 Jenkins、 CircleCI 或 GitLab CI/CD 与测试框架无缝集成，使得测试能够在持续交付管道中执行。

关键是要选择与应用程序的特定需求和技术保持一致的工具和库。这些资源应该提高生产力，支持可维护性，并促进测试团队内部的协作。

通过在测试金字塔的每个层次利用适当的工具和库，软件开发团队可以简化他们的测试工作，促进测试自动化，并确保整个应用程序堆栈的全面测试覆盖。这些工具和库是在测试金字塔框架内实现有效测试策略不可或缺的资产。

六 关于测试其他考虑

• 将测试放入部署管道

在测试金字塔框架内实现部署管道时，必须考虑不同类型测试的放置，以确保快速和有价值的反馈。持续集成或持续交付实践通常涉及一个多阶段的管道，逐渐建立对软件生产部署准备就绪的信心。

为了在部署流水线中有效地定位测试，优先考虑快速反馈的基本价值是至关重要的，快速反馈是持续交付、极限编程和敏捷软件开发中强调的原则。等待几个小时才发现最近的一个更改破坏了简单的单元测试可能是非常低效的，特别是如果它导致反馈延迟的话。理想情况下，这些信息应该在几秒钟或几分钟内提供，以便立即采取纠正措施。因此，在管道的早期阶段放置快速运行的测试是明智的。

相反，长时间运行的测试(通常包含更广泛的范围)应该位于管道的后期阶段，以避免延迟来自更快测试的反馈。通过根据测试的速度和范围而不是其形式类型组织测试，您可以确保在整个流水线中及时和持续地提供反馈。

• 避免重复测试

了解不同测试类型的重要性，关键是要避免一个常见的陷阱，即在测试金字塔的不同层中重复测试。虽然似乎很容易相信更多的测试总是更好，但是重要的是要认识到每个测试都带有额外的开销。编写和维护测试需要时间，理解他人创建的测试也需要时间。此外，测试本身的执行会消耗宝贵的时间和资源。

与生产代码类似，在测试实现中应该寻求简单性和避免重复。建立测试金字塔时，请记住两条经验法则:

1、当高级测试标识错误而没有任何相应的低级测试失败时，它表明需要创建低级测试。

2、把你的测试推到测试金字塔尽可能远的地方。

因为较低级别的测试有助于更好地定位和隔离错误。通过将错误范围缩小到特定的组件，这些测试运行得更快，在调试期间避免了不必要的复杂性，并充当了可靠的回归测试。

在较低级别上自信地测试了所有条件，就没有必要在套件中保留冗余的较高级别测试。这些冗余测试不会增加对整个系统功能的信心。相反，当代码行为发生变化时，它们只会降低测试套件的速度并需要更多的测试修改，从而加重您的日常工作负担。

• 测试金字塔的最佳实践

1. 确定要自动化的测试用例以及自动化测试的范围。

2. 根据用例选择正确的工具。

3. 编写干净的测试代码可以使您的应用程序更容易维护，更不容易出错。

4. 优先考虑你的测试。

5. 测试用例和场景应该基于高质量的测试数据。

6. 避免不必要的测试重复。

7. 将测试集成到部署管道中。

考虑探索性测试，以确保不会出现意料之外的问题。