契约测试--pact框架使用 - 简书

标签: | 发表时间:2021-12-05 21:07 | 作者:
出处:https://www.jianshu.com

背景

最近刚换城市,忙于找工作,趁着等待面试结果的间隙给自己充充电。把之前一直很好奇的“微服务测试”学习了一番,了解了一个新的概念----契约测试。

接口的契约

对于一个api接口,一般会有接口文档说明。文档中会规定如何调用该接口、如何传参,以及接口会如何响应。其实这个就可以理解为接口的"契约"。前端按照这个“契约”去调用,服务端按照“契约”返回响应的内容。若服务端擅自修改了返回内容结构,就算作违反"契约",也是造成bug的一个原因。
扩展到微服务当中,每个服务与服务之间的调用,同样需要遵守这种"契约",才能保证接口功能的稳定性。

什么是契约测试?

微服务架构中,一般分为“提供者”(provider,提供接口的服务) 和“消费者”(consumer,调用接口的服务)
接口文档可以称之为对接口契约的具体描述,主要提供给人看。而契约测试,则是将契约具象为代码/工具可识别的形式,比如json、yml、DSL格式。然后借助相关测试工具,根据这份契约,自动测试“消费者/提供者”接口是否正常。
契约测试一般分两种,一种是消费者驱动,一种是提供者驱动。其中最常用的,是消费者驱动的契约测试(简称 CDC)。即由“消费者”定义出接口“契约”,然后测试“提供者”的接口是否符合契约。

契约测试工具使用--PACT

契约测试工具貌似有不少,此处介绍一个常用工具--- PACT。
pact是一个契约测试框架,目前支持java、python、ruby等多种语言。
pact契约测试分为两步:

  1. 编写test用例,生成契约文件(不需要启动服务)。
  2. 利用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的功能、逻辑,而契约测试主要关注接口是否符合“契约”,监控接口的变动。
契约测试相当于将测试工作前移,在开发阶段就能自测。并且契约测试更加轻量级。

参考

微服务下的契约测试 (CDC) 解读
契约测试之核心解惑
Pact中文参考指南

相关 [契约 测试 pact] 推荐:

契约测试--pact框架使用 - 简书

- -
最近刚换城市,忙于找工作,趁着等待面试结果的间隙给自己充充电. 把之前一直很好奇的“微服务测试”学习了一番,了解了一个新的概念----契约测试. 对于一个api接口,一般会有接口文档说明. 文档中会规定如何调用该接口、如何传参,以及接口会如何响应. 其实这个就可以理解为接口的"契约". 前端按照这个“契约”去调用,服务端按照“契约”返回响应的内容.

Spring Cloud Contract 契约测试简介

- -
Spring Cloud Contract是一个项目,简单地说,就是帮助我们编写 消费者驱动的合同(CDC). 这确保了分布式系统中 Producer和 Consumer之间的契约——用于基于 HTTP 和基于消息的交互. 在这篇快速文章中,我们将探索通过 HTTP 交互为 Spring Cloud Contract 编写生产者和消费者端测试用例.

测试

- 香姜 - 韩寒
测试......>>点击查看新浪博客原文.

/人◕‿‿◕人\只要跟Casio定下契约成为魔法少女的话...你的愿望都可以实现呦

- 斌 - Engadget 中国版
Casio近年动漫联名相机真的是狂出阿,继火影忍者、多啦A梦、钢之炼金术士的特别款相机后,这次又把歪脑筋动到风格可爱、内容黑暗到破表的动画"魔法少女小圆",相机上面除了印上不祥物吉祥物Q比以外,也把Q比的名言印上去了,所以各位小圆迷们,打算跟Casio签下去了吗. 这款相机是基于Casio EX-S200,1,410万像素,等效27mm~105mm,背面LCD为2.7寸,内置魔法少女小圆相关合成素材,日本售价2万7,800日币,限定3,000台.

Android单元测试与模拟测试

- - 神刀安全网
考虑可读性,对于方法名使用表达能力强的方法名,对于测试范式可以考虑使用一种规范, 如 RSpec-style. 不要使用逻辑流关键字(If/ese、for、do/while、switch/case),在一个测试方法中,如果需要有这些,拆分到单独的每个测试方法里. 测试真正需要测试的内容,需要覆盖的情况,一般情况只考虑验证输出(如某操作后,显示什么,值是什么).

免费测试VPN

- 勇 - iGFW
lusovps目前提供免费15天的PPTP VPN试用服务,. 申请地址:https://cart.lusovps.com/cart.php?a=add&pid=13. WHMCS注册系统,可以参考 http://igfw.tk/archives/3727. 注册后无需审核,立刻激活,帐号信息会发至邮箱.

HTTP负载测试

- - 博客 - 伯乐在线
英文原文: ON HTTP LOAD TESTING 来源: oschina. 有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择. 这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑. 在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.

mongodb性能测试

- - 数据库 - ITeye博客
1) Mongodb的非安全插入方式,在一开始插入性能是非常高的,但是在达到了两千万条数据之后性能骤减,这个时候恰巧是服务器24G内存基本占满的时候(随着测试的进行mongodb不断占据内存,一直到操作系统的内存全部占满),也就是说Mongodb的内存映射方式,使得数据全部在内存中的时候速度飞快,当部分数据需要换出到磁盘上之后,性能下降很厉害.

Android集成测试

- - 百度质量部 | 软件测试 | 测试技术 | 百度测试
  Android集成测试主要是在单元测试的基础上测试接口访问或者异步任务是否正确,在. 移动凤巢系统中,大概有30+个接口需要测试,他们都遵循一个特定的访问模式:前台的. Activity获取到触发事件后,将它传给这些接口,这些接口都是AsyncTask的实现——即后台. 异步线程执行某个任务(一般是发送http请求到后端服务或者执行存取数据库等耗时操作),.