背景
最近刚换城市，忙于找工作，趁着等待面试结果的间隙给自己充充电。把之前一直很好奇的“微服务测试”学习了一番，了解了一个新的概念----契约测试。
接口的契约
对于一个api接口，一般会有接口文档说明。文档中会规定如何调用该接口、如何传参，以及接口会如何响应。其实这个就可以理解为接口的"契约"。前端按照这个“契约”去调用，服务端按照“契约”返回响应的内容。若服务端擅自修改了返回内容结构，就算作违反"契约"，也是造成bug的一个原因。
扩展到微服务当中，每个服务与服务之间的调用，同样需要遵守这种"契约"，才能保证接口功能的稳定性。
什么是契约测试？
微服务架构中，一般分为“提供者”(provider，提供接口的服务) 和“消费者”(consumer，调用接口的服务)
接口文档可以称之为对接口契约的具体描述，主要提供给人看。而契约测试，则是将契约具象为代码/工具可识别的形式，比如json、yml、DSL格式。然后借助相关测试工具，根据这份契约，自动测试“消费者/提供者”接口是否正常。
契约测试一般分两种，一种是消费者驱动，一种是提供者驱动。其中最常用的，是消费者驱动的契约测试（简称 CDC）。即由“消费者”定义出接口“契约”，然后测试“提供者”的接口是否符合契约。
契约测试工具使用--PACT
契约测试工具貌似有不少，此处介绍一个常用工具--- PACT。
pact是一个契约测试框架，目前支持java、python、ruby等多种语言。
pact契约测试分为两步:
- 编写test用例，生成契约文件（不需要启动服务）。
- 利用pact-verifier命令和契约文件，验证接口提供者是否正确 (需要启动提供者服务)
以下为demo示例：
1、服务A，提供者
import json
from flask import Flask
app = Flask(__name__)
@app.route('/')
def get_info():
info = {
"name": "zhangsan",
"age": 20
}
return json.dumps(info)
if __name__ == '__main__':
app.run(port=8080)
2、服务B，消费者。(调用服务A的接口)
import json
import requests
from flask import Flask
app = Flask(__name__)
@app.route('/')
def show_info():
res = requests.get("http://localhost:8080/").json()
result = {
"code":0,
"msg":"ok",
"data": res
}
return json.dumps(result)
if __name__ == '__main__':
app.run(port=8081)
3、测试用例，用于生成契约文件
import atexit
import requests
import unittest
from pact.consumer import Consumer
from pact.provider import Provider
# 定义一个pact，消费者是ModuleB，生产者是ModuleA，契约文件存放在pacts文件夹下
pact = Consumer('ModuleB').has_pact_with(Provider('ModuleA'), pact_dir='./pacts')
# 启动服务
pact.start_service()
atexit.register(pact.stop_service)
# 测试用例
class UserTesting(unittest.TestCase):
def test_service(self):
# 消费者定义的期望结果
expected = {"name": "zhangsan", "age": 20}
# 消费者定义的契约的实际内容。包括请求参数、请求方法、请求头、响应值等
(pact
.given('test service.')
.upon_receiving('a request for serviceB')
.with_request('get', '/')
.will_respond_with(200, body=expected))
# pact自带一个mock服务，端口 1234
# 用requests向mock接口发送请求，验证mock的结果是否正确
with pact:
res = requests.get("http://localhost:1234").json()
self.assertEqual(res, expected)
if __name__ == "__main__":
ut = UserTesting()
ut.test_service()
4、实际生成的契约文件 moduleb-modulea.json
{
"consumer": {
"name": "ModuleB"
},
"provider": {
"name": "ModuleA"
},
"interactions": [
{
"description": "a request for serviceB",
"providerState": "test service.",
"request": {
"method": "get",
"path": "/"
},
"response": {
"status": 200,
"headers": {
},
"body": {
"name": "zhangsan",
"age": 20
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}
}
5、根据契约文件，验证服务A是否正确
a. 启动服务A(提供者)
b. 执行pact-verifier --provider-base-url=http://127.0.0.1:8080 --pact-url=./pacts/moduleb-modulea.json，即可验证接口是否符合契约
契约测试的优点
- 在开发接口前定义好契约，消费者和提供者可以并行开发。根据契约可以很容易自测，不必等到联调时才暴露问题
- 确保变动的安全性和准确性。只要有变化，契约测试即可第一时间发现
- 契约文件可以直观追踪接口的变化
- 可以将契约测试集成到CI中
- 每次只测试单个服务，更容易定位问题
- 来自于模拟服务的可靠响应能够降低测试的不稳定性
契约测试与接口测试的区别
契约测试与接口测试的原理都是一样的，都是发送请求、验证响应结果。但是接口测试更多的关注业务api的功能、逻辑，而契约测试主要关注接口是否符合“契约”，监控接口的变动。
契约测试相当于将测试工作前移，在开发阶段就能自测。并且契约测试更加轻量级。
网友评论