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

1.微服务特点

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

 

 

 

 

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

 

2. 微服务下的测试现状

例如， 我们想测试某微服务架构中的某一个服务时，比如下图第一排中间的服务，如：

 

 

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

• 部署所有的服务来实现端到端测试。

• 在集成测试中Mock其他服务。

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

第一种方式：部署所有服务

优点：

1、可以真实地测试服务交互，真实地模拟生成的环境

缺点：

1、测试其中一个服务，不得不布署全部服务，包括各基础设施

2、要运行很长时间
3、不能及时给予测试反馈
4、测试环境被一个测试服务锁定，别人无法同时使用。 

第二种方式：Mock其它服务 

优点:

1、测试反馈快
2、没有基础服务依赖要求 

缺点：

1、服务的实现方创建的Stubs，可能实现与这个无关
2、无法模拟真实数据交互环境 

3、微服务下的开发现状

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

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

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

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

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

契约测试是验证服务的Provider是否按照期望的方式与服务的Consumer进行交互，简单的说是Consumer与Provider两者之间的集成。而Contract即合同、契约，就是Provider与Consumer的交互方式。

基于消费者驱动的契约测试分两个阶段：

（1）Consumer生成契约，开发者在Consumer端写测试时Mock掉Provider，运行测试生成契约文件；

（2）Provider验证契约，开发者拿契约文件直接在Provider端运行测试进行验证。

      

 

 

 

 

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

 

集成测试是指系统集成后的自动化测试。（也可以说是系统端对端的集成测试）

是的，最初QA都是手动执行测试用例，开发人员每修改一个版本，测试人员就要手动测试一遍，随着功能的不断增加，重复工作量越来越大。为了解脱QA重复性劳动，提高工作效率，重复执行的测试用例被自动化了。

上述的自动化测试都是系统集成后的自动化测试，它的出现让QA的工作前进了一大步。然而，集成测试是系统或模块真实组装后的测试，反馈与修复的周期比较长、运行速度慢，测试运行不稳定，有时随机失败，维护成本也很高。它不像单元测试，单元测试测具体一个方法或API，定位准确，采用Mock机制，运行速度非常快（毫秒级），又是开发本地执行，反馈修复及时，成本较低。所以，测试分层后，把绝大部分能在单元测试里覆盖的用例都在单元测试覆盖，只有单元测试测不了的（比如模块或API之间连通性），会通过集成测试来覆盖，见下面测试分层图（有时上层UI和集成会一起测）。

 

5、契约测试对比系统集成测试

集成测试的特点：

(1)真实安装后测试，测试更接近真实使用情况；

(2)可见性强，容易理解。（比如：看一遍跑关键业务的集成测试，业务人员或客户会觉得很放心。也可以作为验收测试）

(3)模块或系统真实调用，测试运行慢，秒级别或分钟级别，反馈与修复的周期慢，成本高；

(4)问题定位难，由于多个子模块或子系统真实安装后，很难定位是哪个模块出的问题；

(5)真实的安装或环境搭建，不稳定，容易导致测试随机失败；

(6)沟通成本高，需要不同模块团队间的协调工作；

(7)与底层测试或集成测试会有重复，集成测试中有的路径单元测试已经覆盖。

契约测试的特点：

(1)开发人编写，采用Mock机制，开发本地就可以运行，没有真实调用，运行快，毫秒级修复反馈周期短；

(2)Provider与Consumer两两之间的验证，容易定位问题，而且与底层测试或其它契约之间没有重复；

(3)不需要部署真实的集成环境，稳定成功率高；

(4)沟通成本低；(比如一个消费端的加入导致服务端API修改，服务端开发人员不必跑去找所有其它消费端开发人员沟通确认是否会被影响，直接运行契约测试就能知道结果）

由此可见，开篇谈到的系统集成测试运行慢、不稳定、修复反馈周期长等等问题，换成契约测试都能得以解决或改进。

 

cdc核心原则:

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

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

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

• API测试和单元测试，更强调的是覆盖API内部逻辑。

• 契约测试，更强调是组件之间连接的正确性，除了保证组件内部，还要保证组件间的调用是正确的，也就是服务API之间的调用。

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

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

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

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

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

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

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

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

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

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

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

 

 

 

9、契约测试之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的通信机制，暂不支持。