哈喽，艾瑞巴蒂，现在搜狗商城产品需求已经趋于稳定，为了提高上线的效率前端开始梳理UI自动化，但是商城存在订单状态不同的问题，这就引出了今天我们要了解的Mock。
为什么要用Mock？
下图这样的情况大家是否遇到过呢？
Mock的优点
1. 团队可以并行工作
前后端人员只需要定义好接口文档就可以开始并行工作，互不影响。后端与后端之间如果有接口耦合，也同样能被Mock解决；测试过程中如果遇到依赖接口没有准备好，同样可以借助Mock；不会出现一个团队等待另一个团队的情况。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品质量以及进度的保证。
2. 测试驱动开发
单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。
3. 可以模拟那些无法访问的资源
比如说，你需要调用一个“墙”外的资源来方便自己调试，就可以自己Mock一个。
4. 隔离系统
假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的“响应”，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。
5. 减轻测试执行难度
假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，难道你要千方百计地给系统做各种手脚让他返回以便测试吗？比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，需要服务端代码返回500 。。。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回，妈妈再也不用担心我的测试覆盖度了！
Mock风险
无法体现真实的测试环境 1.性能测试，对于接口的依赖，把代码需要运行的时间忽略而过，资源创建和销毁没有被体现。 2.多重假设导致功能出现故障的概率大大增加，测试和回归都如此。 3.执行用例时候，因为使用的都是mock，无法发现真实的问题，使测试失真。 4.代码往往牵一发而动全身，有时候mock，不如不mock，如退款，需要先在数据库中插入支付信息等，构造繁琐。
说了这么多那我们看下市面上的Mock服务器
我们现在已经在使用的工具名为Moco，可以参考《一款好用的测试工具之MOCO》《学习Moco接口框架》我们今天讨论的是Mitmproxy工具，对比Moco工具的优势 1.Moco为服务器部署，需要单独占用服务器资源，而Mitmproxy 工具为本地部署，直接本地mock无需单独占用服务器 2.Moco需要在服务端编辑Json文件进行，你们来感受下
这个文件配置过程中只要有一个符号或者标点出错，Moco服务是启动不了的。 Moco需要服务端请求，请求返回的快慢完全取决为服务器的响应速度，但是Mitmproxy却不需要，因为是本地Mock数据，响应速度就是快
Mitmproxy是什么？
代码语言：javascript复制相信大家对Fiddler这个款工具都很了解了，这个Mitmproxy代理非常类似Fiddler在本地初始化一个代理，所有请求都会过，所以就实现了定制返回请求。
def response(self, flow:mitmproxy.http.HTTPFlow):
# 读取url及替换的json文件路径
d = yaml.load(open(DATA_PATH, 'r', encoding='utf-8').read(), Loader=yaml.FullLoader)
yaml.warnings({'YAMLLoadWarning': False})
count = d['keyCount']
#读取替换json内容
for count in range(count, 0, -1):
print(count)
url = d['request' str(count)]['url']
response_path = JSON_PATH '\' d['request' str(count)]['response']
# 读取替换json内容
f = open(response_path, encoding='utf-8')
replaced_data = f.read()
if url in flow.request.url:
flow.response = flow.response.make(200)
flow.response.set_text(replaced_data)
count = 1
else:
count = 1
return
以上为部分功能代码，大家可以试着自己搭建下自己的mock环境，如果有问题欢迎留言讨论
