6. Fiddler 抓包怎么辅助定位 Bug？
Fiddler 是测试工程师常用的 HTTP 抓包和调试工具，尤其在 Windows 环境中非常普遍。它可以帮助测试人员查看浏览器或客户端发出的请求、分析响应内容、定位前后端问题、模拟异常返回、修改请求参数、复现接口问题。和 Charles 类似，Fiddler 的核心价值不是“能抓包”，而是用抓包证据把 Bug 定位清楚。
很多测试同学提 Bug 时只写“页面显示不对”“接口报错”“按钮没反应”。开发拿到后还要自己猜是前端问题、接口问题、数据问题还是环境问题。如果你能通过 Fiddler 把请求 URL、请求参数、响应状态码、响应体、耗时和错误信息贴出来，Bug 的定位效率会高很多。
一、Fiddler 在测试中的常见用途
1. 查看接口请求
页面点击一个按钮后，到底发了哪个接口？请求方式是什么？参数是什么？Fiddler 可以直接看到。
2. 查看接口响应
接口返回了什么数据？业务 code 是多少？message 是什么？页面展示是否和响应一致？这些都可以通过响应体判断。
3. 判断前后端问题
如果响应正确但页面错，多半是前端；如果响应就错，多半是后端或数据；如果请求参数错，可能是前端传参问题。
4. 模拟异常场景
通过 AutoResponder 或断点，可以模拟接口返回 500、超时、空数据、异常字段，测试前端容错。
5. 分析接口耗时
Fiddler 可以查看请求耗时，帮助判断页面慢是否由某个接口慢导致。
二、Fiddler 抓包基本流程
- 打开 Fiddler；
- 确认浏览器或客户端流量经过 Fiddler 代理；
- 如果抓 HTTPS，安装并信任证书；
- 执行业务操作；
- 在会话列表中找到目标请求；
- 查看 Inspectors 中的 Request 和 Response；
- 分析参数、Header、状态码、响应体和耗时。
抓包时建议先清空历史请求，再执行操作，这样更容易定位目标接口。
三、Fiddler 重点看哪些信息
1. Host 和 URL
确认请求发到了哪个服务、哪个接口路径。有时问题是前端调用了错误域名或旧接口。
2. HTTP Method
GET、POST、PUT、DELETE 是否符合接口设计。比如删除接口错误地用了 GET，可能有安全和缓存问题。
3. Request Headers
重点看 Token、Cookie、Content-Type、Referer、User-Agent。有些 401 或 403 问题就是鉴权信息没带。
4. Request Body
确认参数是否完整、字段名是否正确、类型是否正确。例如金额传字符串还是数字，订单号是否为空。
5. Response Status
HTTP 状态码能初步判断请求结果。500 说明服务端异常，401 说明未认证，403 说明无权限，404 说明接口路径可能不对。
6. Response Body
业务系统通常还有业务 code 和 message。HTTP 200 但业务 code 失败，也要算接口业务失败。
7. Time / Duration
接口耗时过长可能导致页面加载慢、超时或用户重复点击。
四、用 Fiddler 定位 Bug 的经典思路
场景：页面点击保存提示失败
定位步骤：
- 清空 Fiddler 会话；
- 点击页面保存；
- 找到保存接口；
- 查看请求参数是否符合页面输入；
- 查看响应状态码和业务 code；
- 如果请求参数错，前端问题；
- 如果参数正确但响应失败，看 message 和日志，后端问题；
- 如果响应成功但页面提示失败，看前端处理逻辑。
这就是抓包工具辅助定位的价值。
五、Fiddler AutoResponder 怎么用
AutoResponder 可以把某个请求的响应替换成本地文件或自定义响应。常用于模拟服务端异常。
比如你想测试前端在订单列表接口返回空数组时的展示，可以准备一个本地 JSON：
{
"code": 0,
"data": []
}
然后用 AutoResponder 映射订单列表接口，刷新页面看是否展示“暂无数据”。
也可以模拟 500 错误、字段缺失、超长文本、异常状态等。
六、Fiddler 断点修改请求
Fiddler 支持在请求发送前或响应返回前打断点。测试可以修改参数来验证后端校验。
例如前端限制商品数量最多 99，但你可以用断点把数量改成 9999，观察后端是否拦截。如果后端没校验，说明存在安全或业务风险。
常见可测试场景：
- 修改金额；
- 修改用户 ID；
- 修改角色权限；
- 删除必填字段；
- 修改订单状态；
- 构造超长字符串。
注意：这类测试要在测试环境进行，不能影响生产数据。
七、Fiddler 和 Charles 的区别
两者都能抓包。简单说：
- Fiddler 在 Windows 上使用广泛，HTTP 调试能力强；
- Charles 跨平台体验好，移动端和弱网测试使用较多；
- 两者都可以抓 HTTPS、改请求、看响应；
- 面试中不用争哪个更好，重点讲你如何用它定位问题。
八、完整案例：订单金额显示错误
现象：订单详情页显示金额 99 元，但用户实际支付 89 元。
定位：
- 用 Fiddler 抓订单详情接口；
- 查看响应体中订单金额字段；
- 如果接口返回 89，但页面显示 99，前端展示或字段取值问题；
- 如果接口返回 99，再查数据库订单表和支付流水；
- 如果数据库订单金额 99、支付流水 89，后端金额计算或优惠券逻辑问题；
- 如果数据库也是 89，但接口返回 99，后端查询或缓存问题。
抓包只是第一步，结合数据库才能定位更准。
九、Bug 报告里怎么写抓包证据
建议包含：
- 请求 URL；
- 请求方式；
- 请求参数；
- 响应状态码；
- 响应业务 code；
- 响应体关键字段；
- 实际页面结果；
- 期望结果；
- 初步判断。
示例：
点击保存后，接口 /api/address/update 返回 HTTP 200，但业务 code=4001，message=手机号格式错误。Fiddler 抓包显示前端传参 mobile 为空，页面输入框实际已填写手机号。初步判断前端提交参数绑定异常。
这种 Bug 描述比“保存失败”高质量很多。
十、面试回答模板
如果面试官问“Fiddler 怎么辅助定位 Bug”，可以这样回答：
我主要用 Fiddler 查看页面或客户端发出的接口请求和响应。比如页面展示异常时，我会抓包看请求 URL、参数、Header、状态码、业务 code 和响应体。如果请求参数就错，通常定位到前端传参；如果参数正确但响应错误，再结合日志和数据库定位后端；如果响应正确但页面展示错误，通常是前端渲染问题。另外我也会用 AutoResponder 或断点模拟异常响应、修改请求参数，验证前端容错和后端参数校验。
十一、常见追问
追问：Fiddler 如何抓 HTTPS？
需要安装并信任 Fiddler 证书，开启 HTTPS 解密，然后重新访问目标页面。
追问：如何用 Fiddler 判断是前端还是后端问题？
看请求参数和响应结果。参数错偏前端，响应错偏后端，响应正确但页面错偏前端展示。
追问：怎么模拟服务端返回异常？
可以用 AutoResponder 映射本地响应，或者用断点修改响应内容，模拟 500、空数据、字段缺失等场景。
十二、练习清单
- 用 Fiddler 抓登录接口；
- 查看请求 Header 和 Body；
- 查看响应状态码和业务 code；
- 分析一个页面展示异常；
- 用 AutoResponder 模拟空列表；
- 用断点修改请求参数；
- 测试后端是否校验金额；
- 抓 HTTPS 请求；
- 写一份带 Fiddler 证据的 Bug；
- 准备 Fiddler 面试回答。
Fiddler 的核心价值是让问题有证据。能把抓包结果转化为定位结论，才是测试工程师真正应该掌握的能力。
配套刷题：
