前言
一大早测试部的老大就召集我们开了个会——原因是我们组负责的业务除了个线上漏测，用户的投诉跟雪花似的纷至杳来。
公司门口那个巨大的显示屏就在那轮播着用户反馈，好几屏都是用户在吐槽这个bug。
没啥可说的，该背的锅还是要背的，那个漏测也不算冤，测试同事造不出那个异常场景，心中侥幸，觉得不至于异常会导致客户端出现啥问题。偏偏它就出了问题！
后来组里开会复盘了下，决定以后在测试环节里引入mock测试工具协助测试。
主要为了解决我们测试过程中遇到的以下问题：
mock测试是个啥
mock这个英文单词的意思是模拟，在测试流程中指的是对不容易构造或不容易获取的对象，用一个虚拟的对象来创建以便测试。大致可分为两类：
客户端 Mock：在被测服务内部工作，直接拦截被测服务的 API 请求方法，直接从方法内部返回预定义的 Mock 响应。
服务端 Mock：在被测服务外部工作，作为 HTTP 服务器接收被测服务发送的 API 请求，并返回预定义的 Mock 响应。
到底要怎么搞
1.直接写代码
python中有个mock模块，支持用mock对象替换掉指定的python对象，达到模拟返回值的效果；
Java中也有jar包——mock server moco，它支持指定配置文件就可开启一个http服务器，支持动态加载。
写代码的优点在于可以完全服务于你所在项目的需求，缺点也很明显，一个迭代版本的需求往往给到的测试时间只有几天，没有时间给测试童鞋写代码来mock。 何况代码也不能保证一次性跑得通，往往调试也要花去很多的时间。
我的想法是——“不要重复造轮子”。市面上其实不乏好些免费的mock工具可以用，只要能够满足我们的目的——可模拟多种异常测试场景，mock配置快速简单。
2.使用mock工具
（1）mock工具的选用原则
接口管理方面： 接口测试一般会涉及数十个甚至上百个接口，这个接口后面还涉及到重构或者版本迭代的问题，因此mock工具需要具备接口管理的功能，能够管理多个版本的接口数据，不要一堆文件胡乱堆着无法处理。
数据构造方面： 接口返回的数据类型和测试数据需要能够做到尽可能少的配置工具和高度仿真，以达到在真实业务场景中测试的效果
场景模拟方面： 能模拟各种异常返回，以及由于接口依赖和资源隔离，业务隔离等原因在测试环境内无法构造出来的场景。
（2）场景Mock工具推荐
a.Fiddler
工具简介：Web调试工具， 它能记录所有客户端和服务器的http和https请求。允许你监视、设置断点、甚至修改输入输出数据。
Fiddler在测试中主要用于拦截接口，篡改接口返回值，来对前端进行调试。
但拦截接口需要设置正则表达式，一个个接口捕捉并修改返回值，对于接口数量少，只需要用到少量接口的测试需求，这个工具还是蛮好用的。
但如果是频繁迭代的需求，一个需求里有上百个接口，那么用Fiddler的效率则不高。
另一个问题是接口返回的数据需要自己手工填入，简单数据还行，复杂数据如base64编码，哈希值等等，那么构造起来非常费时费力。
b.Apifox
工具简介：Apifox提供了接口设计，调试，测试，管理等功能。我们这里只需要用到它的mock功能。
零配置mock
Apifox里面预先设置了常见数据类型的mock规则，不需要用户自己配置，直接选择就可以用，目前已经支持非常多常用的数据类型，包括头像，手机号，邮箱，url，地址等，下图是目前无须配置可直接使用的数据类型：
如何构造数据：
在接口设计tab，直接在返回参数的mock选项框里选择与参数匹配的数据类型
自定义mock规则
如果你的项目里需要用到不怎么常见的数据类型，可以自定义mock规则。
定义完成之后可以在接口设计>response 参数里直接调用改mock规则。
构造异常测试场景
为了提高测试覆盖率，测试童鞋需要验证当接口返回 异常时客户端是否有容错机制，会不会出现崩溃。
这可以利用mock功能来协助测试。
接口管理
一个测试需求/项目常常包含多个测试接口，在Apifox里面可以以项目的形式，通过不同层级的文件夹来对接口进行管理。
总结
造测试数据是每个测试童鞋无法避免的一项事务，如果能借助工具，快速地构造测试场景进行用例测试，就能够极大地提高我们的测试效率。
下载地址：
软件SAAS版免费，私有化部署才收费，放心用。