软件测试之契约测试

2021-12-21 22:33 作者:十指环 0人读过 | 我要投稿

1. 为什么需要契约测试？

1.1 微服务

微服务本质上是一种架构模式，是面向服务架构SOA的一种变种。与SOA的区别在于：SOA,要求绑定具体的技术，微服务鼓励用恰当的技术来实现。

https://martinfowler.com/articles/microservices.html

微服务提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

微服务架构案例：

https://mp.processon.com/view/5c77d08ae4b0628e8208c507

https://www.bilibili.com/video/BV147411w7su?p=2

微服务不一定提供界面；微服务还可以划分为更小的模块

微服务三要素：

契约是一种定义在服务提供者和调用者之间的交付方式，对于基于restful API的微服务，它的契约指API的请求和响应的规则。

1）请求，包括请求URL及参数，请求头，请求内容等；

2）响应，包括状态码，响应头，响应内容等；

3）元数据，指消费者与提供者间一次交互过程的描述。例如消费者/提供者的名称、上下文及场景描述等。

案例：

1.2 微服务带来的问题

问题案例1：

问题案例2：

问题案例3：

参见上述3个问题案例，当一个服务被多个使用者同时使用时，如何保证服务的修改不会对其他所有使用者造成影响？多个服务场景，各个服务由独立的团队开发，团队之间业务交流困难。微服务的提供方很可能会被多个服务调用，调用链路复杂，造成责任链混乱。服务等到API集成测试时才开始验证，问题反馈周期太长。

1.3 微服务测试

微服务测试的挑战

1、微服务测试原则

自动化层次化可视化

2、微服务测试方法

1.4 契约测试

如1.1 &1.2所述，微服务架构模式下，接口通常由服务提供方约定和提供，接口被多个消费者调用更是常态，提供方接口的变更如何快速、高效、无遗漏的通知给消费者？当服务同时被多个消费者调用时，如何保证对服务的修改的信息可以同步给他们消费者？等等问题，契约测试可以解决。

契约测试是验证服务的提供方是否按照期望的方式与服务的消费者进行交互（服务与服务间的API测试），通过解耦服务依赖关系和单元测试来加快测试的运行效率，是随着微服务架构的兴起而发展起来的测试活动。

1.5 契约测试的目的

为了测试服务之间连接或者说接口调用的正确性，为了验证服务提供者的功能是不是真正能够满足消费者的需求。（发现契约破坏而进行的测试）它其实体现了测试前移的思想，把本来要通过集成测试才能验证的工作用更轻量的方式提前快速进行验证。

1.6 契约测试的价值

2. 契约测试测什么？

https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html

3. 如何进行契约测试？

3.1 测试流程

3.2 测试场景

3.3 测试方法

1）从Provider出发：记录Provider的行为，然后验证Consumer是否按照Provider期望的方式工作。该方法用的比较少。

2）从Consumer出发：记录Consumer的行为，然后验证Provider是否按照Consumer期望的方式工作。该方法用的比较的多，也是大家常提到的CDCT（Consumer-Driven Contract Test）测试。其核心思想是：从消费者业务实现的角度出发，由消费者端定义需要的数据格式以及交互细节，生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证该实现结果是否正确。