背景
在美团服务端测试中,被测服务通常依赖于一系列的外部模块,被测服务与外部模块间通过REST API或是Thrift调用来进行通信。要对被测服务进行系统测试,一般做法是,部署好所有外部依赖模块,由被测服务直接调用。然而有时被调用模块尚未开发完成,或者调用返回不好构造,这将影响被测系统的测试进度。为此我们需要开发桩模块,用来模拟被调用模块的行为。最简单的方式是,对于每个外部模块依赖,都创建一套桩模块。然而这样的话,桩模块服务将非常零散,不便于管理。Mock Server为解决这些问题而生,其提供配置request及相应response方式来实现通用桩服务。本文将专门针对REST API来进行介绍Mock Server的整体结构及应用案例。
名词解释
- Mock规则:定义REST API请求及相应模拟响应的一份描述。
- Mock环境:根据请求来源IP来区分的Mock规则分组。Mock Server可以定义多套Mock环境,各套环境间相互隔离。同一个IP只能对应一个Mock环境,不同的IP可以对应同一个Mock环境。
整体结构
Mock Server由web配置页面Mock Admin及通用Mock Stub组成:Mock Admin提供了web UI配置页面,可以增加/删除请求来源IP到Mock环境的映射,可以对各套环境中的Mock规则进行CRUD操作;Mock Stub提供通用桩服务,对被测系统的各类REST API请求调用,返回预先定义好的模拟响应。为了提高桩服务的通吐,使得桩服务能在被测系统压力测试中得到好的表现,我们开启了5个桩服务,通过Nginx做负载均衡。Mock Server的整体结构如下图所示。
数据存储
- 将请求来源IP到Mock环境名的映射存储到mock-env.conf中,mock-env.conf的每一行定义了一条映射,如: 192.168.3.68 闫帅的测试机环境 这条映射表明来源是
192.168.3.68
的请求,使用Mock环境名为闫帅的测试机环境
的Mock规则。 - 将配置的Mock规则存放到<对应Mock环境名>.xml中,下面部分展示了Mock规则的存储格式。
<configuration>
...
<mock id="716add4f-33f7-49ac-abf3-fc617712ffea" name="test001" author="yanshuai">
<request>
<uri>/api/test/.*</uri>
<method>GET|POST|PUT|DELETE</method>
<parameters>
<parameter name="name" value="test.*"/>
...
</parameters>
<headers>
<header name="nb_deviceid" value="1E[0-9a-zA-Z]+"/>
...
</headers>
</request>
<response delay="1000" real="false">
<statusCode>200</statusCode>
<format>application/json;charset=UTF-8</format>
<customHeaders>
...
</customHeaders>
<body>{"name":"闫帅"}</body>
</response>
</mock>
...
</configuration>
Mock Stub
当请求发送到Mock Stub时,Mock Stub会根据请求的来源IP找到对应的独立环境名,然后根据独立环境名获取所有预定义的Mock规则,遍历这些Mock规则,如果找到一条规则与接受到的请求匹配,那么返回预定义的模拟响应。如果找不到规则匹配,那么返回404错误。其中,规则匹配是根据请求中的uri/method/headers/parameters/body是否与Mock规则中定义的对应字段正则匹配来定的。
Mock Admin
- 打开Mock Admin配置页面,如果尚未映射来源IP地址到环境,则点击环境列表导航链接,进入环境列表页面,点击添加,输入源IP及环境名,点击确定按钮,实现源IP到所设环境的映射。