看本质：微服务为什么需要契约测试？

梦里梦外; 2023-10-08 13:51 36阅读 0赞

![在这里插入图片描述][5fb87c883155482198a70b4dca710d26.gif_pic01_E3_80_81_center]

### 01.微服务为什么需要契约测试 ###

首先我介绍一下公司的情况。我们使用的是微服务架构，每个部分会负责其中的几个微服务的研发和维护。我所在的部门维护公司的支付服务（billing），这个服务需要依赖其他部门的几个服务。

当用户需要支付一笔订单时，会调用 billing 服务，同时携带很多参数，为了方便，我们先只考虑核心的两个参数：用户 id 和支付金额。

当 billing 接收到用户请求时，会调用其他的依赖服务，用户服务（user）是其中的一个。我们需要查询该用户是否有足够多的余额可以支付订单。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16]

def pay(uid, amount):  
        """付款"""  
        user_host = app.config.get("user_server_host")  
        user_server = f'{user_host}/user/{uid}/pay'  
        resp = httpx.get(user_server)  
        user = resp.json()  
        if user.get('balance') < amount:      
          return {"msg": "not enough money"}  
        return {"msg": "success", "amount": amount, "uid": uid}

user 被很多服务调用，而 billing 主要想消费它的 balance 字段校验余额是否足够。user 判断如果是 billing 请求的 /user/ 接口，则把余额给它。其他的消费者请求时返回的数据不太一样。

def user_info(uid, src):  
        """用户信息"""  
    if src == 'pay':      
        return {"id": uid,"balance": 8000}  
    elif src == 'manage':      
        return { "id": uid, "age": 19}  
    ...

某一天用户直接反馈支付出错，但是我们最近都没有对 billing 服务进行任何的修改，显然，这个突发情况可能不是由我们部门引起的。

我们只能紧急的去线上排查问题，通过一系列分析，终于发现是 user 服务返回的余额字段由 balance 改成了 user\_balance，其他没有发生任何变化。user 服务修改了代码，却没有通知我们。

数据结构的轻微变化导致我们根本拿不到 balance 字段，所以我们的支付服务无法继续。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
于是我只能立马给 user 部门发邮件。在微服务的维护过程中，最简单有效的测试工具是邮件。因为一个服务往往依赖于其他多个服务，又被另外的服务依赖，导致最后的数据流向变得跟蜘蛛网一样。可是当涉及到跨部门协作的时候，沟通起来也并不那么容易。

我们来看一下这么简单的一处改动会涉及到的流程。首先，user 服务收到需求更改，修改代码之后，user 的测试人员会对自己服务进行组件测试，但是 billing 调用 user 的集成测试他们没有办法测，因为他们根本不知道 billing 是怎么消费它提供的数据的。

user 决定通知所有的下游服务，凡是使用了我这个服务，这个接口的，通通发一遍邮件，麻烦你们各自部门测试一下你们的业务，我的 /user/ 接口进行了修改，可能会引发你们的服务异常。其他部门收到通知以后，再针对性的测试这个接口。

这些下游部门会因为一处小改动，浪费非常多的时间和资源。为什么呢？billing 服务是受到修改影响的，所以对我们来说是必要的。但是其他的服务虽然调用了 /user/ 这个接口，却并没有消费 balance 这个字段，balance 字段的改动对他们不会产生任何影响。但是他们在测试之前是不知道会不会有影响的，是不是浪费时间呢？

还有一个问题，billing 部门难道不可以建立对 user 服务的集成测试吗？当然可以，实际上我们有专门 mock user 服务的测试，也有对 user 的集成测试，偶尔也会进行手工测试。

但是 mock 测试、集成测试和手工测试这些测试手段都不能及时发现问题。

首先我们看看 mock 测试。mock 服务器是由我们自己掌控的，他的结果是不可信赖的，并不能完全代替真实服务，我们之所以用 mock，是因为快、可控、稳定性高，而且能做到环境隔离。

当真实的 user 服务发生变动时，mock 的数据格式并不能及时更新，所以这些测试用例并不会爆红，而是继续通过。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
而集成测试和手工测试都有相同的缺陷，他们太慢了。billing 部门的整套集成测试从构建到结束需要 5 个小时，手工测试一轮就更久了。也就是说，我们至少需要 5 个小时才能发现我们依赖的服务发生了变化，而这个问题早就引发了我们的系统瘫痪长达 5 个小时之久。

契约测试是融合了 mock 测试和集成测试的综合性测试手段，他把消费者 billing 编写的测试用例形成契约文件（contract file），放到提供者 user 端去构建。

当代码修改以后，提供者 user 先针对所有的契约文件构建一次测试，如果所有的契约文件都满足，没有造成毁约现象，就可以上线了。如果有毁约，则需要和被毁约方协商解决，再上线。

附消费者和提供者示例代码，以及 mock 测试和集成测试示例代码：

billing server:

import httpx
    from flask import (Flask,request)
    app = Flask(__name__)
    app.config.update(user_server_host='<http://localhost:5001>')
    
    @app.route('/pay/<uid>/<int:amount>')
    def pay(uid, amount):  
        """付款"""  
        user_host = app.config.get("user_server_host")  
        user_server = f'{user_host}/user/{uid}/pay'  
        resp = httpx.get(user_server)  
        user = resp.json()  
        if user.get('balance') < amount:      
            return {"msg": "not enough money"}  
        return {"msg": "success","amount": amount, "uid": uid    }
    if __name__ == '__main__':  
        app.run(port=5000, debug=True)

user\_server：

from flask import (Flask, request)
    app = Flask(__name__)
    @app.route('/user/<uid>/<src>')
    def user_info(uid, src):  
    """付款"""  
    if src == 'pay':      
        return {"id": uid, "balance": 8000}  
    elif src == 'manage': 
        return {"id": uid, "age": 19}  
    ...
    if __name__ == '__main__':  
        app.run(port=5001)

测试代码：

import unittest
    from billing_server import app
    
    class TestBilling(unittest.TestCase):  
        def test_mock_user_server(self):      
            app.config.update(user_server_host='<http://localhost:5002>')      
            with app.test_client() as client:          
            resp = client.get('/pay/1/100')          
            assert b"amount" in resp.data  
        def test_real_user_server(self):      
            app.config.update(user_server_host='<http://localhost:5001>')      
            with app.test_client() as client:         
            resp = client.get('/pay/1/100')          
            assert b"amount" in resp.data
    if __name__ == '__main__':  
        unittest.main()

真实的 user 服务更新后，bill 服务端的测试用例如果 mock 了依赖的 user 服务，测试用例会继续通过，因为 mock 服务是不可信赖的。

如果使用集成测试方法，直接调用远端的服务，不可避免的会造成测试运行很慢，如果整套测试运行需要 2 个小时，则会造成用户无法使用 2 个小时后，才能发现问题。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

**最后：** 可以关注公众号：伤心的辣条 ！ 进去有许多资料共享！资料都是面试时面试官必问的知识点，也包括了很多测试行业常见知识，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

**如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！推荐软件测试交流学习群：914172719 里面会分享一些资深架构师录制的视频录像**

--------------------

### 好文推荐 ###

[转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！][Link 1]

[面试经：一线城市搬砖！又面软件测试岗，5000就知足了…][5000]

[面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…][Link 2]

[什么样的人适合从事软件测试工作？][Link 3]

[那个准点下班的人，比我先升职了…][Link 4]

[测试岗反复跳槽，跳着跳着就跳没了…][Link 5]

[5fb87c883155482198a70b4dca710d26.gif_pic01_E3_80_81_center]: https://img-blog.csdnimg.cn/5fb87c883155482198a70b4dca710d26.gif#pic01%E3%80%81_center
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/b173a766d524474f9184221213b02449.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/69c3f95c85c143c09ae8fbdc57594dc9.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/992b1bb387b14961a528d1437c54b0e1.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: https://img-blog.csdnimg.cn/ddf4282d4b9d4dc8ba703bc646a4f72d.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6L2v5Lu25rWL6K-V5ZCb,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[Link 1]: https://blog.csdn.net/m0_56736369/article/details/117909132
[5000]: https://blog.csdn.net/m0_56736369/article/details/117915399
[Link 2]: https://blog.csdn.net/weixin_50829653/article/details/117422433
[Link 3]: https://blog.csdn.net/weixin_50271247/article/details/108421434
[Link 4]: https://blog.csdn.net/weixin_50829653/article/details/117856900
[Link 5]: https://blog.csdn.net/m0_56736369/article/details/117923266