接口测试过程中，最常见的困难不是接口有问题，而是测试不了：
- 后端接口还没开发完，但前端想先联调
- 特定业务数据难以触发，如用户等级99、状态“冻结”等
- 生产上出现过异常数据，测试环境却复现不了
- 前端 bug 修复后，想验证过去的错误场景是否解决
这些场景，都不适合靠“写代码”解决，最合适的方式其实是：抓包 + 修改 + 重放。
抓包工具在接口测试中的几种典型用法
| 场景 | 工具 | 操作方式 |
|---|---|---|
| 模拟接口还未返回真实数据 | Charles | 拦截并伪造响应内容 |
| 重放用户历史请求 | Charles / mitmproxy | 保存会话，修改参数后再次发送 |
| 测试边界数据 | Fiddler / Charles | 修改请求体中的数值字段，如时间戳、金额、状态码等 |
| 接口性能回归 | mitmproxy | 编写脚本批量请求接口，对比响应时间 |
Charles 实战操作：构造用户冻结场景
我们需要验证一个前端提示“账号被冻结”的功能，但测试账号在后台永远不会被真正冻结。
解决方式是：用 Charles 设置断点，在接口响应返回前，将返回数据修改为：
{
"code": "403",
"msg": "账户被冻结",
"data": null
}
这样就能在测试环境模拟冻结场景，不用依赖后端数据修改。
中文支持教程：charlesproxy.net/
真实测试场景复盘1：订单接口无法重复测试？
我们某个支付接口，在支付成功后接口状态会变为“已处理”，无法再走原路径。
为了回归测试前端展示逻辑，我用 Charles 抓取第一次成功支付时的请求与响应，再次发送相同数据结构，用来验证前端是否正确跳转状态页。
真实测试场景复盘2：高并发测试场景构造
mitmproxy 可编写 Python 脚本实现批量构造用户请求，如：
for i in range(100):
flow = HTTPFlow(...)
flow.request.headers["X-User-ID"] = f"user_{i}"
ctx.master.commands.call("replay.client", [flow])
用于接口压测、并发触发边界值条件（如：秒杀、抢购等）。
抓包在测试流程中的最佳位置
| 流程环节 | 作用 |
|---|---|
| 接口未完成阶段 | 模拟后端响应，帮助前端先行开发 |
| 前后端联调阶段 | 精确查看请求参数、Header、响应字段 |
| 功能测试阶段 | 构造异常数据、验证容错逻辑 |
| 回归测试阶段 | 重放历史 bug 请求，确认修复有效性 |
| 性能测试准备 | 批量生成并发请求脚本，用于限流/超时验证 |
工具组合建议（测试视角）
| 工具 | 用法优势 |
|---|---|
| Charles | UI 易用，断点/修改响应最强 |
| Fiddler | 配合脚本规则，适合 PC 本地接口调试 |
| mitmproxy | 自动重放、数据构造神器 |
| Wireshark | 网络底层抓包，适合复杂网络场景排查 |
测试不是“填表”，是“设局”
抓包工具的存在，让测试不再被动等待后端、受限数据环境，而是可以主动构造、设计场景。
只要你会“抓”、会“改”、会“重放”，就可以覆盖更多边界、模拟更多可能、找到更多 bug。
别把抓包当工具，它其实是测试设计力的一部分。
如果你还没用过 Charles 或不知道如何配置，不妨参考这个网站上手： charlesproxy.net/
