抓包工具Fiddler

Fiddler的工作原理

所谓抓包其实是网络数据分析的一种通俗且简单的说法。主要是将你的PC、APP客户端发送与接收的数据包进行截获,截获后就可以进行编辑、转存、重发等操作。因为我们日常测试的对象,访问的服务多以http/https为主,截获的也都是http(s)的数据包。
抓包工具原理图:
在这里插入图片描述
本质是在客户端与服务器之间安插一个中间人,所有来往的消息都经过它,它会通过监听固定的端口获取请求和相应的内容。这个中间人就是我们常说的http代理。
为什么要抓包呢?
1、分析定位问题
比如线上金额显示null,到底是前端没有从接口获取到数据,还是获取到数据没有正确显示呢?这就需要截获一下接口的响应报文信息,看这个字段是否存在。如果存在,是否字段名称不符合接口协议规范导致无法获取,还是精度、格式问题不符合约定。如接口没有返回该字段,也不能确定是后端服务的问题,此时还需截获请求信息,看前端的请求信息中,参数是否正确传递。总之,在定位问题时,必须要看到完整的前后端请求和响应内容,才能做出问题归属的判断。
2、对后端服务进行异常测试
如果单纯通过页面,我们无法模拟所有的测试场景。比如用户名只能输入10位,页面上很多隐藏域无法输入内容,数据不完整无法点击提交按钮。但通过直接修改请求数据的内容,我们就可以绕过前端页面的限制,对服务端的异常场景做测试。这种手段在安全测试领域是很常见的,比如直接给服务端传递不符合规范的数据;修改用户的cookie信息达到仿造登录、越权的效果。
3、模拟接口的异常返回
除了对服务端进行测试外,有时客户端的健壮性也是很重要的。比如客户端请求支付接口,正常情况下第三方支付接口会成功返回结果。如果我想要测试支付接口超时返回时,我们的系统是否可以正常处理给出用户提示,我就要让第三方接口给我一个错误的返回,这个通常是比较困难的,尤其是线上环境。那我就可以利用抓包工具,截获原本正确的响应,在发送给客户端之前,修改成错误的信息再返回。再比如,我们有时候需要测试接口返回数据超长、某字段值为空,客户端是否会发生崩溃。比起让开发人员修改接口,最快捷的方式就是截获响应,自行修改。
4、在无接口文档的情况下,获取接口调用信息
在没有完善的接口文档的情况下,如果发生代码变更,需要对服务端接口进行测试,或需要对旧接口进行自动化测试监控,要花大量时间收集整理接口信息,最头疼的是不知道每个数据字段是如何传递的,正确的数据示例是什么。有了抓包工具,我们就可以借助页面正常做业务路程操作,期间调用的接口都会被抓包工具记录下来,方便后期筛选和整理,工作量就小很多,也能看到数据的正确示例。

Fiddler的基本使用

1、Fiddler配置证书
Tools->Options->HTTPS
在这里插入图片描述
2、移动端配置代理
移动端自身无法充当代理服务器,只能设置PC为远程代理服务
在这里插入图片描述
IOS端:点击wifi蓝色感叹号->点击底部配置代理->点击手动->输入PC端IP和端口号(8888);浏览器地址栏输入网址,提示是否允许显示描述文件,允许并安装描述文件;打开设置->通用->关于本机->证书信任设置
Android端:修改wifi网络->配置手动代理->输入PC端IP和端口号(8888)
在这里插入图片描述
3、基本功能区域
fiddler的主界面分为两个部分:会话列表区域、会话详情展示区域。
左侧会话列表区域主要展示所有截取到的请求,选择某个请求可以进行回放、断点调试,工具栏还提供搜索、保存等功能。
右侧会话详情展示区域,主要查看该会话的详细信息,主要页签:statistics、inspectors
在这里插入图片描述
statistics分页,显示的数据全部和本次会话的时间相关:
Request Count:请求数,表示该session总共发起多少个请求
Bytes Sent:发送请求的字节数(包括请求头和请求体)
Bytes Received:接收到的字节数(包括响应头和响应体)
ClientConnected:客户端连接的时间
ClientBeginRequest:客户端开始发送请求的时间
GotRequestHeaders:获得请求头文件的时间
ClientDoneRequest:客户端完成请求的时间
Determine Gateway:确定网关使用的时间
DNS Lookup:查看DNS使用的时间
TCP/IP Connect:tcp/ip连接使用时间
HTTPS Handshake:https握手使用的时间
ServerConnected:服务连接发生的时间
FiddlerBeginRequest:fiddler开始请求的时间
ServerGotRequest:服务器得到请求的时间
ServerBeginResponse:服务器开始响应的时间
GotResponseHeaders:得到响应头文件的时间
ServerDoneResponse:服务器完成响应的时间
ClientBeginResponse:客户端开始响应的时间
ClientDoneResponse:客户端开始响应的时间
Overall Elapsed:全部花掉的时间(使用客户端完成响应的时间-客户端开始请求的时间)
RESPONSE BYTES (by Content-Type):响应的字节(内容格式)
inspectors分页,上半部分对请求进行解包,下半部分对响应进行解包:
Header:请求头信息,UA,cookie发送请求来源
textView:返回的数据
Imageview:返回的图片
Webforms:请求传递的信息
Auth:请求的认证信息
Json:请求正文如果是json格式,则在此查看
Xml:请求正文如果是xml格式,则在此查看
Cookies:请求携带的cookie
Response header:响应报文的头文件
Content-type:请求或响应的正文体格式
User-agent:告诉服务器客户端的操作系统版本、浏览器版本等信息
Referer:告诉服务器,用户是从哪个地址跳转过来的
Cache-control:缓存存储策略
Cookie:请求时携带的客户端缓存信息,又很多字段与身份认证相关
Authorization:很多场景下我们不会使用cookie,比如桌面应用c/s、移动APP应用,此时我们就需要换一种携带用户身份信息的方式。authorization也是头信息中的一部分。
URL参数:当用户参数需要发给服务器时,我们可以选择把他放在URL地址栏后面,也可以选择放在请求正文体中,也可同时存在。
请求正文:传统的form表单提交数据;raw格式。

传统form表单提交的数据:当数据中没有二进制文件时,数据以字符串形式在正文中存在。格式:k1=v1&k2=v2…也就是我们常说的url-encode方式。当数据中存在二进制文件时,数据依然以k1=v2&k2=v2…的格式存放在请求正文中,只不过value的值有可能时文件的二进制流格式,这就是mult-part form-data表单。
raw格式:请求正文是一段纯文本内容。主要格式有:json、xml、html、javascript、txt,一般测试的接口请求正文以标准form表单、json最为常见。

响应头:set-cookie用于在客户端创建一个cookie,服务器把需要保存的cookie信息放在set-cookie返回,通知浏览器进一步保存。
Expires:缓存终止的日期
Cache-control:缓存有效时间,单位为秒
响应正文:响应正文和请求正文一样,也是有格式区别的,一般有html、json、xml、二进制
在这里插入图片描述
在这里插入图片描述

filters过滤器的使用

域名过滤:
在这里插入图片描述
进程过滤:
(1)在客户端进程区域,勾选或添加所需要的过滤条件即可,常用”只展示来自[下拉框]的进程流”,选择好后,启用即可;若勾选”只展示包括[输入内容]的URL”,一般针对远程(手机端)进程进行筛选。
(2)浏览器和非浏览器进程过滤,在fiddler左侧底部区域,可选择”全部进程”、”全部隐藏”、”浏览器进程”、”非浏览器进程”。
在这里插入图片描述

应用场景:

1、无文档的接口测试
在这里插入图片描述
用fiddler抓取BA登录接口,File->Export Sessions->Selected Sessions将其导出成har文件,然后使用har2case命令将har文件转换为自动化测试用例json文件,直接运行httprunner,对刚才抓包转存的接口进行测试。
在这里插入图片描述
在这里插入图片描述
HttpRunner使用见https://blog.csdn.net/xiaocai5731/article/details/108147003
2、模拟弱网测试
在移动网络应用的测试过程中,网络不稳定是一个经常会遇到的场景,但接口返回超时,页面样式无法被正常加载时,客户端是否有合理的重试机制,多次失败后是否能给出合理的提示,会不会引发app的崩溃?
fiddler主要通过Rules->Performance->Simulate Modem Speeds功能进行网络延迟的模拟,勾选该项后访问网站,会发现网络慢了很多。
通过Rules->Customize Rules打开CustomRules.js文档,在文档中搜索关键字m_SimulateModem
在这里插入图片描述
// Delay sends by 300ms per KB uploaded.
上传1KB需要300ms,转化一下上传速度:1KB/0.3s=3.33(KB/s)
如果你想设置上传的速度为50KB/s,你需要设置Delay时间为20ms
同样的方法,限制下行速度,调整oSession[“response-trickle-delay”]即可
常见的网络类型上、下行平均传入速率:

网络上行下载
2G2.7K9.6K
3G1.8M7.2K
4G50M100M

假如模拟3G网络:
上行=1843KB 延时0.54ms
下行=7373KB 延时0.15ms

if (m_SimulateModem) {
            // Delay sends by 300ms per KB uploaded.
            oSession["request-trickle-delay"] = "0.54"; 
            // Delay receives by 150ms per KB downloaded.
            oSession["response-trickle-delay"] = "0.15"; 
        }

设置完毕后,启动fiddler代理,我们就模拟了3G网络下的真是网速情况。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值