Mock服务使用

路径：接口下面和Header、Query、Body、认证...Mock服务，如下图：

使用前准备

环境选择必须是Mock环境

非mock环境 mock服务是不起作用的。

环境设置如下：

路径：在小眼睛左边

默认情况下是有一个官方自带的环境列表：

1. 默认环境

2. mock环境

新建环境参考:「ApiPost」环境变量（10）

域名地址

笔者使用的是自带的，好像也没必要自定义。

相对地址自定义

固定域名后，进行自定义相对地址。这样在切换环境的时候

例如：定义环境变量{{host}}

当切换环境的时候{{host}}的值随环境变化：

以上是举个例子，实际上固定的域名地址是写入上面的。相对的地址才作为环境变量。比如Mock环境自带一个URl固定地址

如下图：

避免误导使用，这里特此说明一下。

刷新、美化、复制链接按钮、导出响应示例等操作略过。

响应数据编辑

数据编辑框 & 预览数据框

比如数据如下填写：

```javascript{"id": "87ef1Dbb-b4eB-549F-EbdF-C69F6369bADB","name": "李四","phone": "13718425555"}```

预览效果如下图：

看到这里可能觉得奇怪，一样的有些多此一举哈！不用急这里是固定响应数据是一样的。后面还有随机动态响应数据

到这里所有的Mock服务准备工作完成。

举个例子（前后端使用）

然后在接口里输入相对地址：register，然后点击发送即可看到实时响应数据，如下图：

这个例子相对简单一些。但进行模拟api响应很完整。到这里可以体会到在后端还没有准备好服务的情况下，使用这个来提供api服务，前端开发会很开心。后面还有几个小技巧会让前端、后端、测试分离工作各不依赖。有点类似填充式作业方式哈！

固定基本数据使用（前后端使用）

```javascript{code:1000,msg:"sucess",data:{"id": "87ef1Dbb-b4eB-549F-EbdF-C69F6369bADB","name": "李四","phone": "13718425555"}}```

这个例子看上去更符合响应数据结构规范哈！

随机动态数据（前后端使用）

一个简单的title例子如下:

```javascript{title:"@ctitle"}```

实际预览效果是：

```javascript{"title": "真里就共成成"}```

如下图所示：

再来一个复杂一些的：

这里定义一个动态列表数据

```javascript{"code": "0","data": {"list|10": [{"name": "@name","age": "@integer(2)"}],"url": ";},"desc": "成功"}```

实际效果如下:

```javascript{"code": "0","data": {"list": [{"name": "Susan Williams","age": 4202047804417013},{"name": "Cynthia Martinez","age": 7836460292479682},{"name": "Joseph Rodriguez","age": 7904378098119320},{"name": "Susan Perez","age": 2839392309833828},{"name": "Scott White","age": 8529217801206224},{"name": "David Allen","age": 3507736869454853},{"name": "Jennifer Brown","age": 186237858137008},{"name": "Margaret Anderson","age": 7679312547559736},{"name": "Brenda Lee","age": 105486912822656},{"name": "Brian Jackson","age": 1856742232963432}],"url": ";},"desc": "成功"}```

界面效果如下图：

RESTFUL逻辑动态数据响应（前后端使用）

这个需要js编程哈！如果后端会这个就很nice了

```javascript{"code": "0000","data": {"verifySuccess": function() {let body = _req.body;console.log(body);return body.phone === '13718425555' && body.pwd === '123456';},"userInfo": function() {let body = _req.body;if (body.phone === '13718425555' && body.pwd === '123456') {return Mock.mock({"id": "87ef1Dbb-b4eB-549F-EbdF-C69F6369bADB","name": "李四","phone": "13718425555"});} else {return null;}},},"desc": "成功"}```

如下图:

下面的是测试使用的哈！

在使用Mock服务的时候同时使用断言（官网没有这个骚操作，笔者在实际开发过程中体悟的，在开发之前就进行断言测试，后端童鞋想搞错都很困难）

使用获取用户信息这个mock服务接口来举例说明：

在后执行脚本里添加断言定义如下:

```javascriptapt.assert('response.raw.responseTime>=50');apt.assert('response.raw.type=="json"');apt.assert('response.json.hasOwnProperty("code")');apt.assert('response.json.hasOwnProperty("msg")');apt.assert('response.json.hasOwnProperty("data")');```

如图所示：

下面是运行效果图：

看到这里相信前后端童鞋应该品味出笔者为什么这么干了。嘿嘿！文档可以出错，api接口有可能搞错结构。但是只要用断言进行统一。至少返回的数据结构字段名不一样立马就知道了。尤其是团队大，协作人多的时候。没有断言测试来保障，谁敢动谁的api服务代码。因为也许并不知道这个api给了多少个业务组使用。牵一发动全身哈哈！

同时也是能有效重构API的利器！！！！

以上的过程再结合接口流程测试，会有一种快乐加倍

上面的过程再加上自动化接口测试那就有一种起飞的赶脚了。

结语

灵活使用Mock服务，前端不用依赖后端API接口。测试脚本提前锁定字段以及字段值范围。实现API设计、测试、数据模型前置。API服务后置。解耦API服务。这样前端迭代可以加倍加速。

写给前端开发者的一段小话：

在api对接调试过程中，最令前端开发者难受的就是字段是一个状态字段。而这个字段状态值影响了界面很大。几乎是一个状态值一种界面。如果这个状态值有好多个。那就是一个非常难搞的前端业务了。这种情况下使用api模拟服务器是最优的选择。笔者亲身经历了这种api字段每次要创建一个字段状态都是一个很漫长的创建流程，但开发自测要完成能涉及所有前端业务路径。在这样的情况下一定不要走业务路径的开发测试方式。要走api模拟服务器的方式。这样只需要改变这个字段的状态值即可。简单、高效，可测还能回溯。