Fiddler实践心得

2017-08-11   出处:搜狗测试  作/译者:张文芳  


一、打断点和AutoResponder返回404/502等状态码的不同

之前一直以为这两种方式没有区别,都是阻断了请求,改变了返回结果。但是今天在测一个问题时,恍然间明白了两者的不同。 
1、打断点,是阻塞了请求,一直没有结果返回,请求将在线程中一直存在,直到超时被踢出来。 
2、AutoResponder返回404/502,这种情况是有结果返回的,代表请求也结束了,不会在线程中一直存在。 
线程,细心的朋友可能发现了,线程,是的,在遇到线程相关的问题时,两者就明显的不同了。 
其实在发现两者在线程上的不同之后,再仔细思考这个问题,两者本质上是服务器是否响应的问题,是否有状态码的问题。打断点阻塞,没有状态码,服务器是没有响应。404/502是服务器有响应的。体现中线程中的不同,只是一个症状体现而已。

二、修改Response数据时要注意超时的问题

通过设置Rules -> Automatic Breakpoints ->After Response,之后再修改响应回来的数据,来实现修改response的内容。但是这样修改数据很容易造成另外一个问题,那就是请求超时导致客户端不对请求做处理。 
怎么理解呢? 就是客户端发送一个请求出去,如果在指定的时间内请求没有返回,则认为该请求超时了,就算以后这个请求返回数据,则客户端也不再对请求做出响应。 
如果,修改内容的操作能够很快的进行,放行断点,在超时时间之内完成,那么修改之后的内容将会被客户端处理。 
如果,修改内容的操作大于超时时间,就算之后将断点放行,请求返回200,这个时候客户端是不做任何处理的,也可以理解为修改的内容没有产生效果。 
综合上述,一定要注意修改内容的操作时间和超时时间的关系。 
其实在修改数据的时候,不太容易去把控时间的长短,也很容易造成修改数据失误,那么怎么样才能很好的解决这个问题呢? 
可以用AutoResponder自动响应数据,用本地文件替换服务器的返回数据。这样就不用在打断点之后急忙的修改数据,也不怕一不小心把数据修改错了。AutoResponder功能替换是一瞬间的事儿,也不用担心超时的问题,真的是一举两得啊。

三、重新认识Decode

在之前的认识中,知道有这样的Decode在工具栏中,也知道是解密的,但是在实践中并没有涉及到这块,今天就被我碰到了,而且自己也跳到坑里了,还好还好最后终于明白了。 
Decode在平时默认是被选中的,我不知道什么时候就给取消了。


今天的情况是这个样子的: 
客户端请求一个接口的数据是加密的,通过save -> response -> response body ,将返回结果保存下来,之后用这个本地文件替换服务器返回的数据。结果客户端接到数据之后,在后台报了一个错误,提示数据格式不对。 
正常的业务流程是客户端在接到数据之后,需要对数据进行解密。现在是在对数据解密的时候发现数据格式不对。 
保存下来的response body,如下所示:

服务端一阵排查问题,客户端一阵排查问题,没毛病啊!!!最后问我,你的本地文件内容是什么?我把内容贴出去之后,大家都是很疑问 6 、0 是怎么回事? 
服务端说不是我们返回的,客户端说不是我们添加的。 
OH MY GOD ! 我也急了,怎么可能是我这里的问题,平时都是这样用本地文件替换服务器文件的,没毛病啊! 
后来仔细瞅了瞅,发现了 Response body is encoded ,Click to decode . 点了一下,哦~~~顿时豁然开朗。 
第一行和最后一行是数字,其实是对数据failed加的密,虽然看起来是明文,6是数据failed的长度。 
应该也看到Response body is encoded. Click to decode. understand ? 点击一下就可以解密了。 
解密之后的数据,如下所示:


这个时候再save -> response -> response body ,将返回结果保存下来,AutoResponder替换服务器文件,客户端就可以正常的解密运行了。 
问题虽然是解决了,但是得找到真正的原因啊? 
提到解密,当然是第一时间想到了Decode,一看,居然没有被选中,突然间就明白了Decode的作用,如果返回的数据时加密的,就自动解密。 
为了验证,选中Decode,又重新请求了一次,结果你猜怎么着,还真的是这个道理。 
细节决定成败啊,任何一个小功能都不能被忽视啊!盆友们啊,都要慎重啊,慎重!

四、bpu 阻塞多个请求

背景: 
今天同事问我,bpu怎么同时阻塞多个请求呢? 
同事 : 
我是这样写的 bpu a b ,我这样写怎么实现不了同时阻塞a 和 b 请求呢? 
我: 
我没有这样阻塞过,但是在我的理解里应该这样写,bpu a enter执行,bpu b enter执行,分开执行(因为我之前没有这样阻塞过,只是按照自己的理解这样认为的,接下来就打脸了,不都是你以为的就是你以为的啊,泪奔啊)。 
同事: 
我按照你说的方式做了,但是还是不可以啊。 
额~,好尴尬啊 
我只有默默的打开Fiddler,ctr+R打开脚本,ctr+F 输入关键字 bpu,找到bpu命令所在的核心代码 
case "bpu": 
var len = sParams.Length ; 
if(sParams.Length<2){ 
bpRequestURI=null; FiddlerObject.StatusText="bpRequestURI breakpoint cleared"; 
return false; 

var len = sParams.Length ; 
bpRequestURI= sParams[1]; 
FiddlerObject.StatusText="RequestURI breakpoint for "+sParams[1]; 
return true; 
核心: bpRequestURI= sParams[1]; 只取了一个参数值。 
场景1解析(也就是同事的执行方法): bpu /sdk /zwf , 
使用空格隔开的,那么 
sParams[0] = “bpu” 
sParams[1] = “/sdk” 
sParams[2] = “/zwf” 
只取了sParams[1] = “/sdk”,所以只会阻塞包含/sdk的请求

场景2解析(也就是我认为的方法,允许我哭一会): 
bpu /sdk 
bpu /zwf 
每次执行bpRequestURI,都会被赋新值,所以我阻塞包含/zwf 的请求 
我们怎么样才可以实现,阻塞多个请求呢? 
让我沿着核心代码,顺藤抹瓜,ctr+F 输入关键字 bpRequestURI 查询,找到参数定义的地方

这个是定义变量的地方,是全局变量

//在main()方法中 // These static variables are used for simple breakpointing & other QuickExec rules     BindPref("fiddlerscript.ephemeral.bpRequestURI")
    public static var bpRequestURI:String = null;
找到使用此参数,bpRequestURI 不为null ,并且 请求的uri 包含bpRequestURI ,则阻断该请求 if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) {
    oSession["x-breakrequest"]="uri";
}

这样捋下来,就搞明白了,阻塞请求是怎么个原理了,是不是也很简单呢?! 
接下来就是改造它来实现bpu 阻塞多个请求了。 
第一步: 
//在main()添加如下代码 
BindPref(“fiddlerscript.ephemeral.bpRequestURI”) 
//数组的长度10,10个阻塞的命令,内容为空格,和bpu命令用空格分割保持一致 
public static var bpRequestURIs:String[] = [” “,” “,” “,” “,” “,” “,” “,” “,” “,” “] ;

第二步:

   case "bpu":
                var len1 = sParams.Length ;
                var len2 = bpRequestURIs.Length;
                //每次赋值之前先恢复原始值                for(var i = 0; i< len2; i++){
                    bpRequestURIs[i]=" ";
                }
                if (len1 < 2) {bpRequestURI=null; FiddlerObject.StatusText="RequestURI breakpoint cleared"; return false;}


                var text = "";
                for(var i = 1; i < len1; i++){
                    bpRequestURIs[i-1] = sParams[i];
                    text += sParams[i] +" ";
                }
                FiddlerObject.StatusText="RequestURI breakpoint for " + text;
                return true;

第三步:

// 在OnBeforeRequest() 方法中 // 注释掉之前的方法 //  if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) { //      oSession["x-breakrequest"]="uri"; //  }        var len = bpRequestURIs.Length;
        for(var i = 0; i< len; i++){
            if(bpRequestURIs[i]!=null && bpRequestURIs[i]!= " "&& oSession.uriContains(bpRequestURIs[i]) ){
                    oSession["x-breakrequest"]="uri";
            }
        }

完成,这样就完成了bpu同时阻塞多个请求了!



欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
149°|1499 人阅读|0 条评论

登录 后发表评论