您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

微服务的测试策略

时间:2022-09-12 14:11:13  来源:  作者:InfoQ

作者 | Tomas Fernandez

译者 | 平川

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

本文最初发布于 semaphore 博客。

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

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

微服务测试面临的挑战

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

 

  •  

    分布式:微服务部署在多台服务器上,地理位置可能也不一样,这会增加延迟,而且会受网络中断所影响。测试要依赖网络,即使代码没问题,也可能会失败,导致 CI/CD 管道中断,开发受阻。

     

  •  

    自治:只要不破坏 API 兼容性,开发团队就可以随时部署他们的微服务。

     

  •  

    测试区域扩大:每个微服务都至少会暴露数个 API 端点,因此,测试覆盖面要更大。

     

  •  

    多语言:开发团队可以选择最适合其微服务的语言。在一个大型系统中,可能无法找到一个适用于所有组件的测试框架

     

  •  

    产品是一个活动目标:由于微服务是由自治团队单独部署和构建,所以需要额外的检查和边界,以确保它们部署后仍然可以正常运行。

     

 

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

微服务测试金字塔

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

 

  •  

    单元测试

     

  •  

    集成测试

     

  •  

    端到端测试。

     

 

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

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

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

微服务的单元测试

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

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

 

  •  

    独立单元测试(Solitary unit tests):如果我们需要测试结果始终是确定的,就应该使用这种方法,通过模拟(mocking)或存根(stubbing)来隔离要测试的代码和外部依赖。

     

  •  

    社交单元测试(Sociable unit tests):社交测试允许调用其他服务。在这种模式下,我们把测试的复杂性推到了测试或过渡环境。社交测试是非确定性的,但如果测试通过,我们对结果会更有信心。

     

 

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

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

微服务的契约测试

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

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

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

 

  •  

    消费者端契约测试由下游团队编写并执行。测试时,微服务连接到生产者服务的模拟版本,检查它是否可以消费其 API。

     

  •  

    生产者端契约测试在上游服务中运行。这类测试会模拟客户端可以发起的各种请求,验证生产者是否符合契约。生产者端测试让开发人员可以知道他们什么时候会破坏消费者兼容性。

     

 

契约测试可以在上游或下游运行。生产者端测试可以检查服务变更是否会给依赖它的服务造成破坏。消费者端测试使用上游生产者的模拟版本(并非真正的生产者服务)来运行消费者端组件,验证消费者是否可以发起请求,并消费生产者提供的期望响应。我们可以使用类似 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

 

  •  

    转向微服务之前要了解的 12 种单体架构优化方法

     

 

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

感谢阅读!

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



Tags:微服务   点击:( )  评论:( )
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:[email protected]),我们将及时更正、删除,谢谢。
▌相关推荐
作者 | Tomas Fernandez译者 | 平川微服务应用程序是一组通过网络进行通信的分布式程序,有时也会与第三方服务和数据库交互。微服务是网络化的,与传统的单体应用程序相比,它的...【详细内容】
2022-09-12  Tags: 微服务  点击:(0)  评论:(0)  加入收藏
一、微服务架构的由来在微服务架构出现之前,最常用的架构就是单体架构,俗称"一个jar(war)包打天下"。在一个jar包工程中,采用MVC架构,分为表现层,业务层,数据访问层,所有的业务模块...【详细内容】
2022-09-12  Tags: 微服务  点击:(0)  评论:(0)  加入收藏
Part1序 随着互联网业务复杂性慢慢提高,单机服务的架构慢慢出现了生产效率问题 微服务架构带来的有优点也有缺点,使用前需要调研清楚 微服务架构的网关设计、服务注册/发现、...【详细内容】
2022-09-06  Tags: 微服务  点击:(18)  评论:(0)  加入收藏
Kubernetes 为开发者们带来了巨大的微服务部署便利,但同时也将可观测性建设的重要性提升到了前所未有的程度:大量微服务之间错综复杂的调用关系难以梳理,应用性能瓶颈链路难以...【详细内容】
2022-08-29  Tags: 微服务  点击:(30)  评论:(0)  加入收藏
同步通讯发送方发出数据后,等接收方发回响应以后才发下一个数据包的通讯方式同步调用的时效性强,可以立即获取结果同步调用的问题我们以前在使用Feign或OpenFeign时,就是使用的...【详细内容】
2022-08-26  Tags: 微服务  点击:(40)  评论:(0)  加入收藏
可观察性是一把覆盖多个移动部件的宽伞。服务网格覆盖了很多领域,无需我们编写一行代码。服务网格和可观察性是微服务社区中的热门话题。在本趋势报告中,我们将详细探讨服务网...【详细内容】
2022-08-26  Tags: 微服务  点击:(29)  评论:(0)  加入收藏
微服务能够对企业产生积极影响。因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的。下面是在微服务架构方案中...【详细内容】
2022-08-16  Tags: 微服务  点击:(34)  评论:(0)  加入收藏
CQRS 是一种 微服务 架构模式 ,它代表命令和查询责任分离。这种模式背后的基本思想是将写操作与读操作分开。不是使用一个数据存储来执行 CRUD 操作,而是在一个数据存储上执行...【详细内容】
2022-08-14  Tags: 微服务  点击:(37)  评论:(0)  加入收藏
目前,业界最常见的软件范例有:单体(Monolith)和微服务架构两种类型。两者的逻辑结构如下图所示。...【详细内容】
2022-08-05  Tags: 微服务  点击:(44)  评论:(0)  加入收藏
随着微服务的流行,越来越多应用采用微服务架构开发。如何简单高效地在微服务中完成数据处理成为大家不得不面对的问题。以往单体应用架构下,我们可以借助数据库实施计算,SQL 是...【详细内容】
2022-08-01  Tags: 微服务  点击:(64)  评论:(0)  加入收藏
▌哈哈电竞推荐
技术传播的价值,不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径,加速业务的上线速率,也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方...【详细内容】
2022-09-13  dbaplus社群  搜狐号  Tags:架构   点击:(4)  评论:(0)  加入收藏
作者 | Tomas Fernandez译者 | 平川微服务应用程序是一组通过网络进行通信的分布式程序,有时也会与第三方服务和数据库交互。微服务是网络化的,与传统的单体应用程序相比,它的...【详细内容】
2022-09-12  InfoQ     Tags:微服务   点击:(0)  评论:(0)  加入收藏
一、微服务架构的由来在微服务架构出现之前,最常用的架构就是单体架构,俗称"一个jar(war)包打天下"。在一个jar包工程中,采用MVC架构,分为表现层,业务层,数据访问层,所有的业务模块...【详细内容】
2022-09-12  互联共商   网易号  Tags:架构   点击:(0)  评论:(0)  加入收藏
在介绍QP前先简单介绍一下有赞搜索平台的整体设计,方便大家快速了解QP在搜索平台中的作用。下图简单展示了一个搜索请求开始到结束的全部流程。业务通过简洁的api接入los,管理员在搜索平台新建配置并下发,完成整个搜索接...【详细内容】
2022-09-07  有赞coder  微信公众号  Tags:架构设计   点击:(9)  评论:(0)  加入收藏
环境搭建// maven <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId>...【详细内容】
2022-09-07  陈三岁98  今日头条  Tags:RabbitMQ   点击:(20)  评论:(0)  加入收藏
前言 在文章《小谈Springcloud中的几个主流熔断器》,我们介绍了SpingCloud架构中的几个主流熔断器,其中SpringCloud官方推荐的Resilience4j作为2020.x以后的新秀,远远没有hystr...【详细内容】
2022-09-07  程序员紫龙  今日头条  Tags:SpringCloud   点击:(17)  评论:(0)  加入收藏
Part1序 随着互联网业务复杂性慢慢提高,单机服务的架构慢慢出现了生产效率问题 微服务架构带来的有优点也有缺点,使用前需要调研清楚 微服务架构的网关设计、服务注册/发现、...【详细内容】
2022-09-06  二哥学Java  今日头条  Tags:微服务   点击:(18)  评论:(0)  加入收藏
背景kubeasz是一个利用ansible-playbook基于二进制方式自动化部署和运维k8s集群的开源项目,目前该项目最新发布版本为3.3.0,基于该版本我们可以快速实现部署最高版本为1.24.1...【详细内容】
2022-09-05  Java小文  今日头条  Tags:kubeasz   点击:(20)  评论:(0)  加入收藏
Apache Kafka 中用于错误处理的死信队列:来自 Uber 和 Crowdstrike 的替代方案、最佳实践和案例研究。识别和处理错误对于任何可靠的数据流管道都是必不可少的。这篇博文探讨...【详细内容】
2022-09-04  qaseven     Tags:Kafka   点击:(19)  评论:(0)  加入收藏
Spring Cloud 的配置服务器功能使跨系统更新微服务变得轻而易举。让我们一步一步地设置和更改属性。 使用微服务,我们创建了一个中央配置服务器,其中微服务的所有可配置参数都...【详细内容】
2022-09-04  qaseven     Tags:Microservices   点击:(14)  评论:(0)  加入收藏
站内最新
站内热门
站内头条