微服务下的契约测试(CDC)解读

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 微服务下的契约测试(CDC)解读

微信图片_20220523094916.png


1. 前言



        有近两周没有在公众号中发表文章了,看过我之前公众号的读者都知道,公众号中近期在连载《RobotFramework接口自动化系列课程》,原本计划每周更新一篇,最近由于博主在带一个新项目,实在是没空抽出时间来,所以向公众号中对连载课程一直期待的读者说声抱歉。


     由于最近带微服务的项目,而对于微服务其实也是近从14年才流行起来,对于这块目前网上的干货内容还是较少,借着机会,小结一下知识点。所以今天也先不打算连载《RobotFramework接口自动化系列课程》,如果读者对连载的课程比较热衷的话,可以在留言板下面给笔者留言,如果读者反馈较多的话,博主也会适当加快调整课程分享节奏。


下面就给大家浅聊一下微服务架构下的契约测试。




2.  微服务特点




Microservice微服务是一种架构风格,我们可以把每一个微服务视做一个用一组API提供业务功能的组件,且服务之间会有很多依赖关系,如下图所示:

微信图片_20220523095102.png

这些服务之间可能由一个团队或者相互独立的团队开发和维护,并且它们在系统内部相互依赖,在这种情况下,接口的开发和维护可能会带来一些问题,例如服务端调整架构或接口调整而对消费者不透明,导致接口调用失败。



注:关于微服务的基本组件组成及介绍,后面考虑单独抽离一篇文章进行介绍,本文就不过多说了~



3. 微服务下的测试现状




例如, 我们想测试某微服务架构中的某一个服务时,比如下图第一排中间的服务,如: 微信图片_20220523095144.png


因为它和其他服务都存在交互,一般我们有两种方式:

  • 部署所有的服务来实现端到端测试。
  • 在集成测试中Mock其他服务。


下面分析一下这两种方式优缺点:

对比分析 优点 缺点
第一种方式:部署所有服务 1、模拟生成环境
2、可以真实地测试服务交互
1、测试其中一个服务,不是不布署全部服务,包括各基础设施
2、要运行很长时间
3、不能及时给予测试反馈
4、测试环境被一个测试服务锁定,别人无法同时使用。
第二种方式:Mock其它服务 1、测试反馈快
2、没有基础服务依赖要求
1、服务的实现方创建的Stubs,可能实现与这个无关
2、无法模拟真实数据交互环境




4、微服务下的开发现状




常规我们开发的项目主要由服务提供方约定接口,虽然提供方架构调整或改变接口之前通常会通知消费者,但可能还是会存在遗漏。

当一个Service已经同时被多个使用者调用用的时候,怎么保证service的修改对其它所有使用者造成影响都被感知到呢?


那么契约测试的引出就是为了解决这类问题的最佳方案!


5、什么是契约测试(CDC)




    契约测试 ,又称之为 消费者驱动的契约测试(Consumer-Driven Contracts,简称CDC),根据 消费者驱动契约 ,我们可以将服务分为消费者端和生产者端,而消费者驱动的契约测试的核心思想在于是从消费者业务实现的角度出发,由消费者自己会定义需要的数据格式以及交互细节,并驱动生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑,并在持续集成环境中持续验证。

后文中消费者驱动的契约测试统一用cdc来代替。

cdc核心原则:

  • cdc是以消费者提出接口契约,交由服务提供方实现,并以测试用例对契约进行产生约束,所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。

  • cdc是一种针对外部服务的接口进行的测试,它能够验证服务是否满足消费方期待的契约。 它的本质是从利益相关者的目标和动机出发,最大限度地满足需求方的业务价值实现。




6、契约测试、单元测试、接口测试区别




  • API测试和单元测试,更强调的是覆盖API内部逻辑。
  • 契约测试,更强调是组件之间连接的正确性,除了保证组件内部,还要保证组件间的调用是正确的,也就是服务API之间的调用。

单元测试 单元测试针对代码单元(通常是类)的测试,单元测试的价值在于能提供最快的反馈。另外好的单元测试还可以帮助你改善设计,在你的团队掌握TDD的前提下,单元测试能辅助重构,帮助改善代码整洁度。
API测试 API测试是针对业务接口进行的测试,主要测内部接口功能实现是否完整,比如说内部逻辑是不是正常,异常处理是不是正确。
契约测试 契约测试其实是为了测试服务之间连接或者说接口调用的正确性,为了验证服务提供者的功能是不是真正能够满足消费者的需求。它其实体现了测试前移的思想,把本来要通过集成测试才能验证的工作化作单元测试和接口测试,用更轻量的方式快速进行验证。
集成测试 它从用户的角度验证整个功能的正确性,测的是端到端的流程,并且加入用户场景和数据,验证整个过程是不是OK,它的价值业务价值最高,是验证一个完整的流程。



7、契约测试能解决什么问题




  • 联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行,要同时把握双方的进度,造成资源和时间上的浪费。

  • 对于接口的变动把控相当困难。由于接口变动是普遍存在的,尤其对于调用关系复杂的接口,一旦发生变动,如果没有一套机制进行控制,验证的成本巨大。

  • 接口不匹配”是指服务依赖于彼此间的接口进行通信,如何保证改变一个服务的接口会对其他所有依赖服务是否造成造成影响。

  • 在发生契约变化时,提供一种可立即被服务端和消费端发现的方式。



8、契约测试能给我们带来



  • 降低服务集成的难度,把服务集成这个过程分解成了单元测试和接口测试来做,它从消费者的需求为出发点,把消费者的需求作为你的测试用例驱动出一份契约,然后验证提供者端的功能。


  • 通过使用契约测试,接口调用双方协商接口后就可以并行开发,并且在开发过程中就利用契约进行预集成测试,不用等到联调再来集成调通接口,一旦成熟,在保证质量的前提下,联调的成本可以减低到几乎为0。

  • 因为契约的存在,让接口的变动有迹可循,即使变动也可以确保变动的安全性和准确性。

  • 通过契约测试,团队能以一种离线的方式(不需要消费者、提供者同时在线),通过契约作为中间的标准,验证提供者提供的内容是否满足消费者的期望。



9、契约测试之Pact工具



9.1 Pact 术语介绍

9.1 Pact 术语介绍


  • Consumer: 微服务接口的调用者
  • Provider: 微服务接口的提供者
  • 契约文件: 是由consumer端和provider端共同定义的接口规范,包括接口访问的路径,输入和输出数据。在具体的实施中,是由consumer端生成的一个json文件,并存放在pact broker上
  • Pact Broker: 保存契约文件的服务器
    注:通常在工程实践上,当消费者根据需要生成了契约之后,我们会将契约上传至一个公共可访问的地址,然后生产者在执行时会访问这个地址,并获得最新版本的契约,然后对着这些契约来执行相应的验证过程。

9.2 Pact 基本流程


简要流程:


  • 第一步在消费者端Consumer端写一个对接口发送请求的单元测试,在运行这个单元测试的时候,Pact会将服务提供者自动用一个MockService代替,并自动生成契约文件,这个契约文件是Json形式的。

  • 第二步在Provider端做契约验证测试,将Provider服务启动起来以后,通过pact插件可以运行一个命令,比如你是用maven,就是mvn pact:verify,它会自动按照契约生成接口请求并验证接口响应是否满足契约中的预期,所以可以看到这个过程中,在消费者端不用启动Provider,在服务提供端不用启动Consumer,却完成了与集成测试类似的验证。


详细流程:

基于消费者的业务逻辑,驱动出契约

  其实现步骤如下所示:

  1、使用Pact的DSL,定义Mock提供者,如localhost:8080

  2、将Mock地址传给消费者并对Mock的提供者发送请求。

  3、使用Pact的DSL,定义响应内容(包括Headers、Status以及Body等)。

  4、在消费者端 使用@PactVerification运行单元测试(Pact集成了JUnit、RSpec等框架),生成契约文件。

  5、当运行测试后,Pact框架记录消费者的名称、发送的请求、期望的响应以及元数据,将其保存为当前场景下的契约文件,通常命名为[Consumer]-[Provider].json,例如 orderConsumer-orderProvider.json

  6、契约文件生成后,我们可以将其保存在文件系统或者Pact-Broker(Pact提供的中间件,用来管理契约文件)中,以便后续提供者使用。

基于消费者驱动出的契约,对提供者进行验证

  在提供者端,我们不需要写任何验证的相关代码,Pact已经提供了验证的接口,我们只需要做好如下配置:

1、为提供者指定契约文件的存储源(如文件系统或者Pact-Broker)。

2、启动提供者,运行PactVerify(Pact有Maven、Gradle或者Rake插件,提供pactVerify命令)。

3、当执行pactVerify时,Pact将按照如下步骤,自动完成对提供者的验证:

构建Mock的消费者。

4、根据契约文件记录的请求内容,向提供者发送请求。

5、从提供者获取响应结果。

6、验证提供者的响应结果与Pact契约文件定义的契约中是否一致。


9.3 Pact 特性

传统情况下做集成测试需要把服务消费者和服务提供者两个服务都启动起来再进行测试,而Pact做契约测试时将它分成两步来做,每一步里面都不需要同时启动两个服务。

1、测试解耦,就是服务消费与提供者解耦,甚至可以在没有提供者实现的情况下开始消费者的测试。

2、一致性,通过测试保证契约与现实是一致性的。

3、测试前移,可以在开发阶段运行,并作为CI的一部分,甚至在开发本地就可以去做,而且可以看到一条命令就可以完成,便于尽早发现问题,降低解决问题的成本。

4、Pact提供的Pact Broker 可以自动生成一个服务调用关系图,为团队提供了全局的服务依赖关系图。

5、Pact提供Pact Broker这个工具来完成契约文件管理,使用Pact Broker后,契约上传与验证都可以通过命令完成,且契约文件可以制定版本。

6、使用Pact这类框架,能有效帮助团队降低服务间的集成测试成本,尽早验证当提供者接口被修改时,是否破坏了消费者的期望。

7、Pact目前仅支持REST HTTP 通信,但对于RPC的通信机制,暂不支持。


目录
相关文章
|
6月前
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用合集之idea本地测试代码,要增大 Flink CDC 在本地 IDEA 测试环境中的内存大小如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
2月前
|
JavaScript 前端开发 Java
一文让你了解微服务契约测试
谈到微服务,大家都想到契约测试,到底什么是契约测试呢,为什么要使用契约测试呢,关于这样的文章很多,本文将结合Spring Boot让你了解微服务契约测试。
28 0
一文让你了解微服务契约测试
|
2月前
|
JavaScript 前端开发 Java
Spring Boot+cucumber+契约测试
Spring Boot+cucumber+契约测试
18 0
Spring Boot+cucumber+契约测试
|
3月前
|
安全 测试技术 持续交付
微服务的测试策略
【8月更文第29天】随着微服务架构的普及,测试变得尤为重要,因为它有助于确保各个独立的服务都能正确运行并且能够协同工作。本文将介绍一种全面的测试策略,包括单元测试、集成测试和端到端测试,以及如何为微服务应用编写这些测试。
108 0
|
4月前
|
测试技术 调度 微服务
微服务架构下的两类测试
【7月更文挑战第16天】微服务架构下的两类测试:流量录制回放测试和仿真环境测试
|
5月前
|
Java 测试技术 持续交付
Java一分钟之-Spring Cloud Contract:契约测试
【6月更文挑战第16天】Spring Cloud Contract是微服务契约测试框架,通过DSL定义接口行为,使用WireMock生成存根进行独立开发验证。常见问题包括契约编写不清晰、未集成到CI/CD和契约版本控制混乱。例如,定义一个`GET /greeting`返回JSON响应的契约,Spring Cloud Contract会自动生成测试代码,帮助确保服务间接口一致性,提升开发效率和系统稳定性。
118 7
|
6月前
|
人工智能 算法 测试技术
探索软件自动化测试的未来:AI驱动的测试策略构建高效可靠的微服务架构:后端开发的新范式
【5月更文挑战第28天】 在软件开发的世界中,测试是确保产品质量的关键步骤。随着技术的进步和项目复杂性的增加,传统的手动测试方法逐渐显得力不从心。本文旨在探讨自动化测试的最新趋势——人工智能(AI)驱动的测试策略。我们将分析AI如何通过智能化的测试用例生成、测试执行优化以及结果分析来提高测试效率和精确性。文章还将讨论实施AI测试策略的挑战与机遇,为软件测试工程师提供未来技术转型的视角。 【5月更文挑战第28天】 在当今软件开发的快速迭代和复杂多变的环境中,传统的单体应用架构已经难以满足业务敏捷性和可扩展性的需求。微服务架构作为一种新的解决方案,以其服务的细粒度、独立部署和弹性伸缩等特性,正逐
|
6月前
|
Java 测试技术 持续交付
Java中的异常处理机制探索自动化测试在微服务架构中的实践与挑战
【5月更文挑战第27天】本文将深入探讨Java中的异常处理机制,包括异常的概念、分类以及如何使用try-catch-finally语句进行异常处理。文章还将介绍自定义异常的方法以及在实际开发中如何选择合适的异常处理策略。 【5月更文挑战第27天】 随着软件开发领域向微服务架构的转型,传统的软件测试方法面临诸多挑战。本文旨在探讨自动化测试在微服务环境下的应用实践及所面临的问题。我们将从微服务的特性出发,分析自动化测试的必要性,并深入讨论如何构建一个高效、鲁棒的自动化测试框架。文章还将介绍一系列创新的测试策略和工具选择,以及如何克服微服务带来的分布式复杂性。最后,通过案例研究,展示自动化测试在实
|
6月前
|
SQL Apache 流计算
Apache Flink官方网站提供了关于如何使用Docker进行Flink CDC测试的文档
【2月更文挑战第25天】Apache Flink官方网站提供了关于如何使用Docker进行Flink CDC测试的文档
710 3
|
6月前
|
监控 关系型数据库 MySQL
Flink CDC产品常见问题之使用3.0测试mysql到starrocks启动报错如何解决
Flink CDC(Change Data Capture)是一个基于Apache Flink的实时数据变更捕获库,用于实现数据库的实时同步和变更流的处理;在本汇总中,我们组织了关于Flink CDC产品在实践中用户经常提出的问题及其解答,目的是辅助用户更好地理解和应用这一技术,优化实时数据处理流程。