<返回更多

微服务的测试策略

2022-09-12    InfoQ
加入收藏

作者 | Tomas Fernandez

译者 | 平川

微服务应用程序是一组通过网络进行通信的分布式程序,有时也会与第三方服务和数据库交互。微服务是网络化的,与传统的单体应用程序相比,它的故障点更多。为此,我们需要一种不同的、涉及面更广的测试方法。那么,我们该如何测试一个微服务应用程序?测试金字塔还有效吗?当涉及到第三方服务并可能出现网络中断时,我们该如何测试?在这篇博文中,我们将尝试回答所有这些问题。

本文最初发布于 semaphore 博客。

微服务应用程序是一组通过网络进行通信的分布式程序,有时也会与第三方服务和数据库交互。微服务是网络化的,与传统的单体应用程序相比,它的故障点更多。为此,我们需要一种不同的、涉及面更广的测试方法。

那么,我们该如何测试一个微服务应用程序?测试金字塔还有效吗?当涉及到第三方服务并可能出现网络中断时,我们该如何测试?在这篇博文中,我们将尝试回答所有这些问题。

微服务测试面临的挑战

微服务架构是一种意义深远的范式变迁,我们必须重新考虑传统的测试技术。与经典的单体架构相比,微服务在许多方面都有所不同:

 

 

所有这些特点都让我们不得不考虑新的测试策略。

微服务测试金字塔

测试金字塔是自动化软件测试的规划工具。传统的金字塔包含 3 种类型的测试:

 

 

微服务金字塔新增了两种类型:组件契约测试

这是微服务测试金字塔的一个版本。其他版本可能顺序上会有所不同。有些版本可能将契约测试包含在了集成层。事实上,金字塔更多的是一份指南,而非一成不变的东西。

接下来,我们将对金字塔的每一层做进一步的介绍。

微服务的单元测试

单元测试是粒度最小(数量最多)的测试形式之一。单元由可以单独测试的类、方法或函数组成。单元测试是开发实践中不可分割的一部分,比如测试驱动开发或行为驱动开发。

与单体相比,微服务中的单元可能更需要通过网络调用来完成其功能。这时候,我们可以让代码访问外部服务——就得接受延迟和不确定性,也可以调用测试替身,因此,我们有如下两种处理微服务依赖的方法:

 

 

我们可以使用测试替身独立运行单元测试。我们也可以让要测试的代码调用其他微服务,这就是我们正在讨论的社交测试。如你所见, 可信度与稳定性之间的平衡将贯穿本文始终。模拟可以加快测试速度,降低不确定性,但模拟越多,测试结果的可信度就越低。虽然也有缺点,但社交测试更实用。因此,你要在这两种类型的测试之间做好权衡取舍。

如果你想实际看下独立测试和社交测试的例子,可以读一下 Dylan Watson 在 dev.to 上发表的那篇不错的博文。

微服务的契约测试

当两个服务通过接口耦合时,契约就形成了。契约详细列出了所有可能的输入、输出及其数据结构和副作用。服务的消费者和生产者必须遵守契约描述的规则才能进行通信。

契约测试可以保证微服务遵守契约。它们不会全面测试服务的行为;它们只确保输入和输出具备期望的特性,服务执行时间和性能都在可接受的范围内。

契约测试可以由生产者运行,也可以由消费者运行,还可以两者都运行,这取决于服务之间的关系。

 

 

契约测试可以在上游或下游运行。生产者端测试可以检查服务变更是否会给依赖它的服务造成破坏。消费者端测试使用上游生产者的模拟版本(并非真正的生产者服务)来运行消费者端组件,验证消费者是否可以发起请求,并消费生产者提供的期望响应。我们可以使用类似 wiremock 这样的工具来再现 HTTP 请求。如果两端都通过了契约测试,那么生产者和消费者就是兼容的,应该能够通信。持续集成时应该总是运行契约测试,以便在部署前发现不兼容的情况。

你可以在 Pact 的 5 分钟入门指南里在线试用契约测试。Pact 是一个基于 HTTP 的测试工具,可以编写和运行基于消费者或是生产者的契约测试。

微服务的集成测试

微服务的集成测试方式与其他架构略有不同,其目标是通过微服务交互来识别接口缺陷。与契约测试总有一端是模拟的不同,集成测试使用真实服务。

集成测试不关注服务的行为或业务逻辑。集成测试是为了确保微服务可以与其他微服务以及自己的数据库交互。我们希望通过集成测试来发现类似 HTTP 头缺失、请求 / 响应对不匹配这样的问题。因此,集成测试通常在接口层实现。

使用集成测试来检查微服务是否可以与其他服务、数据库和第三方端点通信。建议读下 Vitaly Baum 关于微服务存根的博文,看下实际的集成代码测试。

微服务的组件测试

组件是一个较大的系统中可以完成一项职责的一个微服务或一套微服务。

组件测试是验收测试的一种,使用模拟资源或 mocking 来替换服务,孤立地检查组件的行为。

组件测试比集成测试更全面,它们既会测试快乐路径,也会测试不快乐路径——例如,测试组件如何响应模拟网络中断或恶意请求。我们想知道组件是否满足其消费者的需求,很像我们在验收测试或端到端测试中所做的那样。

组件测试执行一组微服务的端到端测试。超出组件范围的服务都是模拟的。

执行组件测试的方法有两种:进程内和进程外。

进程内组件测试

在组件测试的这个子类中,测试执行器在和微服务相同的线程或进程内。我们以“离线测试模式”启动微服务,所有的依赖都是模拟的,这让我们无需网络就可以运行测试。

组件测试在和微服务相同的进程内运行。测试在适配器中注入一个模拟服务,以模拟与其他组件的交互。

进程内测试仅适用于组件是单个微服务的情况。乍看之下,组件测试和端到端测试或验收测试非常类似。唯一的区别是,组件测试只选取系统的一部分(组件),并将其与其余部分隔离开来。它会对这个组件做全面的测试,以验证它是否提供了用户或消费者需要的功能。

组件测试和端到端测试可能看上去类似。但区别在于,端到端测试在一个类生产环境中测试整个系统(所有微服务),而组件测试只隔出系统的一部分进行测试。两种测试都会从用户(或消费者)的角度来检查系统行为,模拟用户可能执行的操作。我们可以使用任何语言或框架来编写组件,但最流行的可能要数 Cucumber 和 Capybara 了。

进程外组件测试

进程外测试适用于任意大小的组件,包括由许多微服务组成的组件。在这类测试中,组件被(原封不动地)部署在一个测试环境中,所有的外部依赖都是以模拟或存根方式提供。

在这类组件测试中,测试环境会比较复杂,因为它要模拟系统的其余部分。

要全面了解契约测试的概念,建议研究下 JAVA Spring 契约测试的示例代码。此外,对于 Java 开发人员,这篇博文提供了一些在各个层面测试 Java 微服务的代码样例。

微服务的端到端测试

到目前为止,我们都是分块测试系统。单元测试用于分别测试微服务的各个部分,契约测试验证 API 兼容性,集成测试检查网络调用,组件测试用于验证子系统的行为。只有在自动化测试金字塔的最顶端,我们才是对整个系统进行测试。

端到端(E2E)测试用于确保系统可以满足用户需求并实现其业务目标。E2E 套件应该覆盖应用程序的所有微服务,并且使用与用户相同的界面——通常搭配 UI 和 API 测试。

应用程序的运行环境应尽量接近生产环境。在理想情况下,测试环境中应包含应用程序通常需要的所有第三方服务,但有时候,为了降低成本或防止滥用,也可以模拟。

端到端测试是模拟用户交互的自动化测试。只有外部第三方服务可以是模拟的。

从测试金字塔可以看出,E2E 测试数量最少,这很好,因为它们通常最难运行,也最难维护。只要专注于用户的操作过程及需求,我们就可以从少数几个 E2E 测试中获得很大的价值。

小 结

范式变了,策略也要跟着变。在微服务架构下,测试比以往任何时候都重要,但我们需要调整技术来适应新的开发模型。系统不再是由单个团队管理。取而代之,每个微服务的所有者都必须完成好自己的部分,才能保证整个应用程序的正常运行。

有些组织可能会认为,单元、契约和组件测试已经足够了。其他的则认为需要端到端和集成测试,他们可能会选择组建一支 QA 团队,以推动跨团队的测试。

想要进一步了解微服务吗?可以阅读以下几篇文章:

 

 

https://semaphoreci.com/blog/microservice-architecture

 

 

https://semaphoreci.com/blog/domain-driven-design-microservices

 

 

https://semaphoreci.com/blog/release-management-microservices

 

 

https://semaphoreci.com/blog/monolith-microservices

感谢阅读!

https://semaphoreci.com/blog/test-microservices

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>