fiddler修改接口响应的几种方式

引子：

在做业务功能测试的时候，时常需要模拟某种特殊的业务场景，而这种业务场景在常规业务流程下难以复现，此时需要将这个业务流程按照对应的技术框架做结构拆分，从验证各个拆分部分+关联接口从而验证整个业务是否满足预期。

其中一种是验证某个数据流到客户端的后的响应，这里主要是讲到验证app在获取后端一些特定数据后做出响应的业务过程。

思路：利用fiddler抓包并修改接口响应结果，以模拟出app端业务响应所需条件，然后验证客户端的功能反馈即可。

三种实现方式：

1.通过设置Rules-Automatic Breakpoint-After Responses选中，为接口打断点的方式设置响应结果。

图中标红1为比如修改34℃为38℃，2修改完毕点击运行完成

优点：方便对一个接口单步调试

缺点：断点规则同样会阻塞其他接口的执行，目标接口可能需要等待前置接口执行完毕，需要和app端同步进行；修改响应结果的操作时间较长有时会导致在app端的响应失效。

2.通过设置AutoResponder可以批量使接口按照预期的结果执行。

图中标红部分：

1--增加目标接口匹配规则（正则表达式）

2--编辑和保存匹配字符串

3--设置响应结果

3.通过设置FiddlerScript脚本直接设置接口响应过程

static function OnBeforeResponse(oSession: Session) {

//其他默认代码......

if (oSession.fullUrl.Contains("www.sojson.com/open/api/weather/json.shtml?city")){

//对响应结果解码

oSession.utilDecodeResponse();

//设置替换响应结果内容

oSession.utilReplaceInResponse('"date":"17日星期一","high":"高温 34℃"','"date":"17日星期一","high":"高温 38℃"');

}

优点：接口执行效率基本没有损耗，更接近真实情况下接口响应过程；只需修改脚本保存就可，适合复杂情况下模拟接口执行过程

缺点：需要对脚本语法和api有一定了解，文档资料较少

补充：上面第三种修改脚本的方式，比较熟悉fiddler script语法后可以做到更灵活使用。比如可以在手工测试的时候抓取目标接口数据，并以某种格式保存写文件中，然后清洗接口数据再拼装，可作为自动化接口测试的数据来源之一。