当涉及到测试时,微服务需要一种不同的方法。微服务测试金字塔更加复杂。以下是使用方法

每天‬分享‬最新‬软件‬开发‬,Devops,敏捷‬,测试‬以及‬项目‬管理‬最新‬,最热门‬的‬文章‬,每天‬花‬3分钟‬学习‬何乐而不为‬,希望‬大家‬点赞‬,评论,加‬关注‬,你的‬支持‬是我‬最大‬的‬动力‬。下方抖音有我介绍自动化测试,以及google cloud 相关视频课程,欢迎观看。

微服务应用程序是一组分布式程序,它们通过网络进行通信,偶尔与第三方服务和数据库接口。微服务由于其网络化的特性,比传统的庞然大物提供了更多的失败点。因此,我们需要一种不同的、更广泛的测试方法。

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

测试微服务的挑战

微服务体系结构是一个范式转变,其影响如此深远,以至于我们必须重新考虑传统的测试技术。微服务在许多方面不同于传统的单一结构:

所有这些特点迫使我们思考新的测试策略。

微服务测试金字塔

测试金字塔是自动化软件测试的计划工具。在传统形式下,金字塔使用三种测试:

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

微服务用了哪些组件(微服务测试策略)(1)

这是微服务测试金字塔的一个版本。在其他情况下,顺序可能会有所不同。有些可能包括集成层中的契约测试。事实是,金字塔更多的是一个指导方针,而不是什么写在石头上

让我们更详细地了解一下每个金字塔层是如何工作的

微服务的单元测试

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

与整体相比,微服务中的单元更有可能需要网络调用来完成其功能。当这种情况发生时,我们可以让代码访问外部服务ーー接受一些延迟和不确定性ーー或者用一个 test double 替换调用,这给了我们两种处理微服务依赖性的方法:

微服务用了哪些组件(微服务测试策略)(2)

我们可以使用测试双精度来单独运行单元测试。或者,我们可以允许测试代码调用其他微服务,在这种情况下,我们讨论的是sociable测试

正如你将看到的,平衡自信与稳定将是贯穿整篇文章的主题。嘲笑会让事情变得更快,减少不确定性,但是你嘲笑的越多,你就越不能相信结果。sociable测试尽管有缺点,但更现实。因此,您可能需要在这两种类型之间取得良好的平衡。

Contract Testing

每当两个服务通过一个接口耦合时,就会形成一个契约。合同规定了所有可能的输入和输出及其数据结构和副作用。服务的使用者和生产者必须遵守合同中规定的规则,才能进行通信。

契约测试确保微服务遵守契约。它们不会彻底测试服务的行为; 它们只是确保输入和输出具有预期的特征,并且服务在可接受的时间和性能限制内执行。

根据服务之间的关系,契约测试可以由生产者、使用者或两者运行。

微服务用了哪些组件(微服务测试策略)(3)

Contract tests 可以运行在上游或下游。生产者测试检查服务是否实现了根据服务而中断的更改。消费者测试针对上游生产者(而非真正的生产者服务)的模拟版本运行消费者端组件,以验证消费者可以发出请求并使用生产者的预期响应。我们可以使用诸如 WireMock 之类的工具来重现 HTTP 请求

如果合同双方都通过了测试,那么生产者和消费者是兼容的,应该能够进行通信。契约测试应该始终在持续集成中运行,以便在部署前检测不兼容性

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

微服务集成测试

微服务的集成测试与其他体系结构的工作方式略有不同。目标是通过使微服务交互来识别接口缺陷。不像契约测试(其中一方总是受到嘲笑) ,集成测试使用真正的服务。

集成测试对评估服务的行为或业务逻辑不感兴趣。相反,我们希望确保微服务之间以及它们自己的数据库之间可以进行通信。我们正在寻找丢失的 HTTP 头和不匹配的请求/响应配对之类的东西。因此,集成测试通常是在接口级别实现的。

微服务用了哪些组件(微服务测试策略)(4)

使用集成测试来检查微服务是否可以与其他服务、数据库和第三方端点通信

看看这个Vitaly Baum's 关于微服务的帖子 查看集成代码的实际测试

https://articles.Microservices.com/practical-microservices-integration-tests-and-stub-services-80749ce01050

微服务的组件测试

组件是一个微服务或一组微服务,它们在较大的系统中完成一个角色。

组件测试是一种验收测试,其中我们通过用模拟资源或模拟代替服务来隔离地检查组件的行为。

组件测试比集成测试更彻底,因为它们走的是快乐和不快乐的道路ーー例如,组件如何响应模拟的网络中断或错误的请求。我们想知道组件是否满足其消费者的需求,就像我们在验收或端到端测试中所做的那样。

微服务用了哪些组件(微服务测试策略)(5)

组件测试对一组微服务执行端到端测试。模拟组件范围外的服务

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

进程内组件测试

在这个组件测试的子类中,测试运行程序与微服务存在于同一个线程或进程中。我们以“离线测试模式”启动微服务,在这种模式下,它的所有依赖项都被模拟,这样我们就可以在没有网络的情况下运行测试。

微服务用了哪些组件(微服务测试策略)(6)

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

只有当组件是单个微服务时,进程内测试才能工作。乍一看,组件测试与端到端或验收测试非常相似。唯一的区别是组件测试挑选系统的一个部分(组件)并将其与其他部分隔离开来。对组件进行了彻底的测试,以验证它是否执行了用户或消费者所需的功能

微服务用了哪些组件(微服务测试策略)(7)

组件和端到端测试可能看起来相似。但区别在于,端到端测试是在类生产环境中测试整个系统(所有微服务) ,而组件是在整个系统的一个独立部分上进行测试的。这两种类型的测试都从用户(或消费者)的角度检查系统的行为,跟踪用户将要执行的行程

我们可以使用任何语言或框架编写组件测试,但是最流行的可能是 Cucumber 和 Capybara

进程外组件测试

进程外测试适用于任何大小的组件,包括那些由许多微服务组成的组件。在这种类型的测试中,组件部署在一个测试环境中,在该环境中所有外部依赖项都被模拟或删除。

微服务用了哪些组件(微服务测试策略)(8)

在这种类型的组件测试中,复杂性被推到测试环境中,而测试环境应该复制系统的其余部分

为了完善契约测试的概念,您可以探索 JavaSpring 契约测试的示例代码.

https://dzone.com/articles/component-tests-for-spring-cloud-microservices

另外,如果你是一个 Java 开发人员,本文提供了在各个级别测试 Java 微服务的代码示例.

https://phoenixnap.com/blog/microservices-continuous-testing

Microservices 的端到端测试

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

端到端(E2E)测试确保系统满足用户的需求并实现他们的业务目标。E2E 套件应该使用与用户相同的接口来覆盖应用程序中的所有微服务——通常是 UI 和 API 测试的组合。

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

微服务用了哪些组件(微服务测试策略)(9)

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

正如测试金字塔所描述的,E2E 测试是数量最少的,这很好,因为它们通常是最难运行和维护的。只要我们关注用户的旅程和他们的需求,我们就可以通过少量的 E2E 测试获得大量的价值

结论

一个不同的范式要求改变策略。在微服务体系结构中进行测试比以往任何时候都重要,但是我们需要调整我们的技术以适应新的开发模型。该系统不再由单个团队管理。相反,每个微服务所有者都必须尽自己的一份力量来确保应用程序作为一个整体工作。

有些组织可能认为单元、契约和组件测试就足够了。其他人,不满足于没有端到端和集成测试,可能会选择建立一个 QA 团队来促进跨团队测试覆盖。

感谢您的阅读!

微服务用了哪些组件(微服务测试策略)(10)

,