上一篇介绍了设计思想，并已实现报文篡改，点击传送门，本篇主要介绍 Mock Better 的接口测试
1.传统的接口测试都是基于模拟前端发起请求，验证后端返回报文的正确性，测试对象是后端；Mock Better 的接口测试是基于真实的前端程序发起请求，既可以关注前端传参的正确性，也可以验证后端返回的正确性，这就是我所说的打通前后端测试的任督二脉；
关于什么是打通前后端测试，举个真实的典型案例：前天用 Mock Better 做接口测试发现某些报文该加密的接口没有加密，我把问题和持久化的证据链提交给前端开发和后端，在铁证面前，前端承认少传一个和加密相关的参数，后端也承认即便这个参数传过去，也不一定会加密，一个问题，前后端都测试到了，不巧的是前后端都发现各自存在问题。
2.传统的接口测试做场景化，需要解决登陆态、token、盐值、敏感加密、动态参数截取和绑定、特殊请求参数动态生成等一系列复杂问题；Mock Better 的接口场景化是基于用户操作真实的程序，接口串联完全由前后端程序自主实现的。
关于这一点，可能很多人无法理解，举个例子：手机连上 Mock Better 的代理，然后在 App 上购买一个商品，整个购买场景调用的接口和返回的报文，都在 Mock Better 的监视之下，通过代理配置的规则，可以过滤出哪些是需要测试的接口，并根据规则配置的断言判断接口是否异常；
前端通过 AutoTraveler 驱动 App 遍历测试，自动定位错误日志，在之前的自动遍历文章已介绍过。
后端通过 Mock Better 执行接口测试，辅助定位问题，是今天要介绍的一个特性，上面的工作图已表达的比较清楚，这里再细说实现方式：
条件一：有一套完整的日志体系；
条件二：提供日志查询接口服务；
条件三：找出接口通用的唯一性标识，可以是请求参数的某个字段，也可以是响应报文的某个字段，例如：时间戳等。
实现原理：假定接口 A 测试未通过，把接口 A 的唯一性标识作为日志查询接口的过滤条件，调用日志查询接口获取到被测接口的上下文日志，存档作为定位问题的重要线索。
1.进行 UI 测试的同时，同步进行接口测试；
2.既可以关注前端传参的正确性，也可以验证后端返回的正确性。
1. 接口测试规则列表
初版支持系统规则，后续会支持用户自定义规则。这里是触发和停止接口测试的入口。
2. 接口测试任务列表
通过任务列表，可以查看测试结果。
3. 测试结果详情
默认显示所有接口的测试情况。
点击 “显示失败”，只显示校验未通过的接口。
点击 “定位问题”，开始异步抓取上下文日志，点击 “刷新”，可查看定位问题进度的状态，如果问题已定位，点击 “查看定位日志”。
