引子：
在做业务功能测试的时候，时常需要模拟某种特殊的业务场景，而这种业务场景在常规业务流程下难以复现，此时需要将这个业务流程按照对应的技术框架做结构拆分，从验证各个拆分部分+关联接口从而验证整个业务是否满足预期。
其中一种是验证某个数据流到客户端的后的响应，这里主要是讲到验证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有一定了解，文档资料较少
script用法参考：http://www.fiddlerbook.com/Fiddler/dev/ScriptSamples.asp
补充：上面第三种修改脚本的方式，比较熟悉fiddler script语法后可以做到更灵活使用。比如可以在手工测试的时候抓取目标接口数据，并以某种格式保存写文件中，然后清洗接口数据再拼装，可作为自动化接口测试的数据来源之一。
