有次版本上线前功能用例全部跑通结果真实用户一连串反馈“开屏要等好几秒”“图片加载不出来”。排查下来发现问题不在业务逻辑而是我们没有在弱网环境下把关键流程完整跑过。后来我养成了一个习惯每次版本测试都把 Fiddler 切到 2G、3G、4G 场景模拟真实用户在不同网络下的表现。这篇就把这套 Fiddler 弱网测试方法从原理到实操完整拆开讲Fiddler 怎么做代理接管、FiddlerScript 怎么限制延迟和带宽、2G/3G/4G 参数怎么设置、测试时重点看什么、常见坑有哪些。客户端开发、测试工程师和前端性能优化的同学都可以直接参考。1. 弱网测试到底在测什么带宽、延迟与丢包1.1 弱网场景的三个关键维度很多人第一次做弱网测试想的很简单把带宽调小。但实际上一旦调起来就会发现弱网环境里最折磨人的不只有带宽还有延迟和丢包。拿一个典型场景举例。你在正常 4G 网络下打开某个 App请求发出去之后 200 毫秒内就能收到响应页面唰一下出来了。但换到 2G 或者信号很差的场景请求可能几秒都得不到响应连接一直挂着。如果代码里没有合理的超时机制用户看到的就是图标一直转圈等很久才跳出一个失败提示。这种情况主要就是延迟在起作用。延迟Latency可以简单理解成从发出请求到收到数据的时间间隔。延迟高的时候即使带宽不小体验也会很卡顿。带宽Bandwidth则决定了单位时间内能传多少数据带宽小的时候一个几百 KB 的接口响应都要传半天。丢包Packet Loss就更直观了数据包在半路丢失TCP 协议会自动重传但重传会进一步加剧延迟和卡顿。所以一个合格的弱网测试方案至少要能同时控制带宽和延迟这两个维度有条件的话还要模拟丢包。如果只是把带宽调低而不关注延迟很多问题其实是测不出来的。反过来如果只加延迟不限制带宽那大图片和大接口的加载速度又体现不了真实弱网的“传输缓慢”感。这两者必须配合着来。1.2 为什么选 Fiddler 而不是其他限速方式选择 Fiddler 做弱网模拟最核心的原因是它足够可控、足够易用而且跨平台支持不错。Fiddler 本质上是一个 HTTP/HTTPS 调试代理。所有走代理的请求会先经过 Fiddler由 Fiddler 代为转发给目标服务器。因为流量都要经过它Fiddler 就能在转发前后做各种处理弱网模拟就是在这一步里注入延迟和带宽控制逻辑。对比其他方案用真实网络卡做弱网测试可以做到完全真实但成本高、复现差2G 卡现在都不好找用路由器限速也能做但配置复杂而且只能针对整网生效没法区分不同的 2G/3G/4G 场景身边有同行用 Charles 做弱网功能上类似但如果你是 Windows 开发环境Fiddler 的普及度和资料丰富度都更高。Fiddler 自带一个“Simulate Modem Speeds”菜单项点一下就能把所有请求变慢。但它模拟的是非常慢的拨号网络只有单一档位显然不够用。真正能用的是 FiddlerScript——通过脚本自定义延迟、带宽、甚至跳过低版本网络下不必要的请求这套灵活度是其他菜单式操作没法比的。这也是这篇文章选择 Fiddler 作为核心工具的根本原因。2. Fiddler 弱网控制机制从代理到 FiddlerScript2.1 OnBeforeRequest 与 OnBeforeResponse 的分工FiddlerScript 是基于 JScript.NET 的扩展脚本。Fiddler 在启动时会加载这个脚本并在每个 HTTP 请求的生命周期节点调用对应函数。对弱网测试来说只需要关注最核心的两个函数OnBeforeRequest和OnBeforeResponse。OnBeforeRequest在客户端请求刚到达 Fiddler、还没发往服务器的时候执行。你在这里做的操作会直接影响请求的“上行”过程也就是上传数据、发送请求头、等待服务器开始响应之前的整个阶段。OnBeforeResponse在服务器响应已经到达 Fiddler、还没转发给客户端的时候执行。这是做“下行”控制的位置模拟下载数据的耗时和响应延迟都放在这里。理解这两个函数的分工非常重要。很多弱网测试做出来效果不对问题就出在把延迟全加在了一个函数里没分清上行和下行的差异。比如要模拟上传一张图片上传动作发生在请求阶段如果只在响应阶段加延迟图片上传速度根本没有被限制住自然测不出上传超时这类问题。反过来要模拟列表页数据加载慢如果只在请求阶段加延迟接口返回后的大 JSON 包下载耗时依然没有被模拟到。2.2 延迟和带宽的脚本模拟思路FiddlerScript 本身没有提供一个叫“设置带宽”的 API但它给了我们一个万能的工具System.Threading.Thread.Sleep()。Thread.Sleep的作用是让当前线程暂停执行指定毫秒数。放在OnBeforeRequest里就是让请求在发出去之前先等待一段时间等效于高延迟。放在OnBeforeResponse里就是让响应在到达客户端之前先等待等效于模拟下行延迟。延迟值可以直接根据场景设置比如 2G 场景 300~500ms3G 场景 100~200ms4G 弱信号场景 40~80ms。但只有延迟不够。如果只加延迟一个 1KB 的接口和一个 1MB 的图片加载时间会是一样的这显然不符合真实情况。要模拟带宽限制业界常用的做法是根据请求/响应体的字节数算出“按目标带宽传输需要多久”然后把这个耗时通过Thread.Sleep补进去。举个例子目标下载带宽是 40kbps一个响应体是 100KB理论传输时间就是 (100 × 1024 × 8) / (40 × 1024) 20 秒那么就让这个响应在发给客户端之前先 Sleep 20 秒。客户端感知到的下载速度就非常接近真实 2G 网络了。这个方案不是底层字节级的精确限速但做弱网场景模拟已经足够。客户端感受到的是“请求发得慢”“响应下得慢”和真实弱网的体验一致这就达到了测试目的。3. 环境准备让手机流量先走 Fiddler 代理3.1 电脑端 Fiddler 代理开关与端口在做弱网模拟之前先把基础环境搭好。安装 Fiddler 后第一件事是确认代理功能处于开启状态。打开 Fiddler点击菜单栏 Tools - Options - Connections确认勾选 “Allow remote computers to connect”。这是手机、模拟器、远端设备能连上 Fiddler 代理的关键开关。默认代理端口是 8888没有特殊需求就保持默认。这里有个小提醒Fiddler 默认只监听本机回环地址如果不勾选允许远程连接手机怎么连都连不上这是新手最容易卡住的地方。另外Windows 防火墙可能会拦截来自局域网其他设备的连接如果端口通行但一直连不上优先检查防火墙入站规则把 8888 端口的 TCP 入站放行或者直接允许 Fiddler 应用通过防火墙。3.2 手机和模拟器连上代理的步骤手机要和 Fiddler 建立连接前提是手机和电脑在同一个局域网上。然后打开手机的 Wi-Fi 设置找到当前连接的网络进入代理设置选“手动”填入电脑的局域网 IP端口填 8888。电脑的局域网 IP 可以在命令行里输入ipconfig查看取 IPv4 地址那个。不要在手机上填127.0.0.1那是手机自己不是电脑。填完之后手机上的流量就会全部经过 FiddlerFiddler 主界面的会话列表里会实时出现手机发起的请求。如果是 Android 模拟器情况类似只是入口不同。Android 模拟器里可以直接设置代理为本机局域网 IP也可以用模拟器网关地址访问电脑。不同模拟器产品的差异比较大最简单通用的办法是在模拟器的设置里打开无线网络长按当前 Wi-Fi 修改代理和真机的操作基本一致。如果用的是 iOS 真机代理设置入口在 Wi-Fi 网络名的右侧感叹号里选“配置代理”为手动同样填入 IP 和端口。设置完成后用 Safari 随便访问一个 HTTP 页面Fiddler 会话列表里能看到新会话说明连通成功。3.3 HTTPS 解密与证书信任弱网测试如果只测 HTTP 流量现在基本没戏了正规 App 全是 HTTPS。Fiddler 默认能看到 HTTPS 请求的域名但看不到明文内容拿不到请求体和响应体自然没法模拟带宽。所以需要先把 HTTPS 解密打开。在 Fiddler 的 Tools - Options - HTTPS 页面勾选 “Capture HTTPS CONNECTs” 和 “Decrypt HTTPS traffic”。Fiddler 会生成一个根证书手机需要信任这个证书才能完成解密否则请求会直接失败。iOS 设备需要下载证书后到“设置 - 通用 - 关于本机 - 证书信任设置”里手动开启完全信任。Android 7.0 及以上系统默认不信任用户安装的 CA 证书如果发现装了证书还是无法解密可以走 debug 包的方式在应用里开启允许用户证书或者用系统证书安装方案。这一步是实操里最典型的坑我遇到的不下十次。切记证书问题不解决FiddlerScript 里就算写了带宽限制HTTPS 流量拿不到响应体脚本效果也发挥不出来。4. 核心实操用 FiddlerScript 模拟 2G/3G/4G4.1 脚本模板参数集中管理 场景切换入口打开 Fiddler 后按 CtrlR 打开 FiddlerScript 编辑器。脚本里默认有一个class Handlers类要做的就是在类里添加自己的变量和函数然后在OnBeforeRequest、OnBeforeResponse两个函数中插入调用代码。我建议把网络场景配置写成独立函数方便后续切换。下面这份脚本是我在实际项目里用的模板直接复制到 FiddlerScript 里保存后即可生效// FiddlerScript 弱网模拟参数配置 public static var weakScenario: String none; // 各场景参数 public static var weakDelayMs: int 0; // 网络延迟毫秒 public static var weakUploadKbps: double 0; // 上行带宽kbps public static var weakDownloadKbps: double 0; // 下行带宽kbps public static function SetWeakProfile(scenario: String): void { weakScenario scenario; switch (scenario) { case 2G: weakDelayMs 300; weakUploadKbps 20; weakDownloadKbps 40; break; case 3G: weakDelayMs 120; weakUploadKbps 100; weakDownloadKbps 600; break; case 4G: weakDelayMs 40; weakUploadKbps 2000; weakDownloadKbps 10000; break; case none: weakDelayMs 0; weakUploadKbps 0; weakDownloadKbps 0; break; default: break; } } function OnBeforeRequest(oSession: Session) { if (weakScenario none) return; // 1. 模拟上行带宽限制按请求体大小计算传输耗时 if (weakUploadKbps 0 oSession.requestBodyBytes.Length 0) { var upTimeMs: int Math.round(oSession.requestBodyBytes.Length * 8 / (weakUploadKbps * 1024) * 1000); System.Threading.Thread.Sleep(upTimeMs); } // 2. 模拟基础网络延迟 if (weakDelayMs 0) { System.Threading.Thread.Sleep(weakDelayMs); } } function OnBeforeResponse(oSession: Session) { if (weakScenario none) return; // 3. 模拟下行带宽限制按响应体大小计算传输耗时 if (weakDownloadKbps 0 oSession.responseBodyBytes.Length 0) { var downTimeMs: int Math.round(oSession.responseBodyBytes.Length * 8 / (weakDownloadKbps * 1024) * 1000); System.Threading.Thread.Sleep(downTimeMs); } }脚本默认状态是none也就是不限速。用的时候在 Fiddler 左下角 QuickExec 里输入命令切换场景。模拟 2G输入SetWeakProfile(2G)执行后当前 Fiddler 会话里的所有流量都会按 2G 参数模拟。要恢复不限速输入SetWeakProfile(none)如果你的 FiddlerScript 编辑器对中文注释显示乱码直接把注释删掉就行不影响执行。脚本保存后 Fiddler 会重新编译不需要重启。4.2 2G/3G/4G 参数对照与调整原则上面脚本里的参数是我结合行业通用标准和实际测试场景调过的但不同团队、不同业务对弱网的定义不完全一样。下面把常见参考值单独列出来方便按项目调整网络类型延迟ms下行带宽kbps上行带宽kbps适用场景2GGPRS400~50020~4010~20极弱网、海外市场、偏远地区2GEDGE250~300100~15040~60弱网但略优于 GPRS3GUMTS150~200384~600100~200常规弱网测试标准3GHSPA80~1201000~2000300~500中等弱网4GLTE 弱信号40~802000~50001000~2000信号差但勉强有网4G正常20~50100005000基准对比表格里的“4G 正常”不是用来模拟弱网的是做对照实验的。弱网测试不是说把所有场景都调到最低而是根据业务实际覆盖的地区和信号状况来定。如果 App 主要面向一二线城市重点测 3G 和 4G 弱信号就够了如果面向发展中国家和偏远地区2G 就是必测的底线。参数设置还有一个容易忽略的点真实网络环境的延迟和带宽是持续波动的一会儿 3G 一会儿 4G 才是常态。我自己的做法是一组场景先测固定值保证可复现真正回归的时候用不同场景之间的手动快速切换来模拟网络断续的感受。要是你不想在脚本里写随机数逻辑手动在不同场景间来回切也是可行的低成本方案。4.3 场景切换、白名单与断点配合在项目里我不建议直接改脚本里的数字而是把所有场景都放在SetWeakProfile函数里用 QuickExec 切换。这样有个额外好处其他同事接手测试时不用去翻脚本输入一个函数名就能完成调度。还有一个很实用的组合用法配合 Fiddler 的断点功能做特殊弱网场景。比如想模拟“请求发到一半卡住”可以先切到某个弱网场景然后在 QuickExec 里输入断点命令来命中某类 URL把它挂住几秒钟不执行人为制造卡顿。断点不是严格意义上的丢包但在模拟“请求一直转圈”这个 UI 状态时非常直观。另外提醒一点FiddlerScript 里的变量是全局的QuickExec 调用函数后所有请求都会受影响。如果你不想让测试工具内置的请求比如统计 SDK 上报、崩溃日志上报也被限速可以通过在OnBeforeRequest里判断请求域名来跳过。方法是在函数开头加一个判断if (oSession.HostnameIs(example.com) || oSession.uriContains(/telemetry)) { return; }开发自带的统计请求如果也被限速你会误以为业务接口变慢了后期分析数据时非常痛苦。这个白名单思路我强烈建议加上。5. 弱网测试执行要点与数据采集5.1 测试前的用例与标准弱网测试不是拿到脚本就能直接开测需要提前设计好用例和参数。我的习惯是先列出核心流程再针对每个流程设置弱网验证点。核心流程一般选这些App 启动、首屏加载、登录、列表页滑动加载、图片加载、上传下载、支付、消息推送。每个流程至少要覆盖三个状态成功态、超时态、失败态。比如首屏接口在 2G 下请求超时客户端有没有合理的超时时间有没有重试机制失败后用户能不能手动重试有没有错误提示这些在真实弱网下才是用户真正感知到的东西。用例设计的时候还要明确可接受的标准。比如启动时间在 2G 下不能超过 10 秒首屏接口超时时间不能超过 30 秒。没有标准就测弱网最后只能得到一堆“感觉有点卡”的主观结论回归和复盘时没有参照。标准不一定要非常严格但一定要有。5.2 执行节奏基准、弱网、恢复执行的时候我建议按照“基准 - 弱网 - 恢复”的节奏操作。先正常网络跑一遍核心流程记录各项指标作为基准线。然后通过 QuickExec 切到 2G 场景重跑同一套流程。再分别测 3G、4G 弱信号场景。最后切回正常网络再跑一遍确认客户端能恢复。每个场景跑完之后除了记录功能表现还要从 Fiddler 会话列表里导出关键请求的耗时数据。选中一个请求在右侧的 Statistics 面板里能看到请求发送时间、接收时间、吞吐量等数据。把这些数据整理进表格就能形成一份很有说服力的弱网测试报告。我常用的记录字段包括接口名称、网络场景、接口耗时、首包时间、失败次数、页面呈现状态正常/白屏/转圈/报错、是否触发重试。有了这些字段复盘时才能快速定位是前端问题、接口问题还是网络策略问题。只看截图说明不了太多但一张带耗时数据和失败次数的表格开发拿到手基本就能定位方向。5.3 功能层面的三个重点验证项除了性能数据功能层面有几个弱网下特别容易出问题的点我单独列一下。第一请求超时和重试。很多开发在正常网络下从没见过超时代码里压根没写超时控制或者写了一个超长的时间。弱网一开请求挂十几秒都没有任何反馈用户早就不耐烦了。测的时候重点看超时时间是否合理、超时后有没有重试、重试会不会造成重复提交。第二并发限制。列表页同时请求多个接口、图片懒加载触发一堆小请求的时候弱网下这些请求会排队如果客户端没有限制并发数可能出现大量请求堆积导致内存暴涨、页面卡死。我遇到过一次比较极端的情况某个 App 在 2G 场景下一次发出几十个图片请求结果直接把页面拖挂。第三缓存策略。正常网络下缓存快速更新看起来没什么问题但弱网下如果缓存策略不合理每次启动都强制刷新用户会发现连打开一个已经访问过的页面都慢到怀疑人生。弱网测试时重点观察静态资源、列表缓存是否发挥了应有的作用而不是每次弱网都从服务器拉一次全量数据。6. 弱网测试常见问题与排查实录6.1 手机连不上 Fiddler 代理手机能连上 Wi-Fi但打开页面直接报网络异常这种问题十有八九出在三个地方。第一个是电脑端没勾选 Allow remote computers to connect。打开 Fiddler 的 Connections 页面如果这里没勾手机根本走不进来。第二个是防火墙拦截Windows 防火墙默认策略对入站连接非常严格需要在防火墙里放行 Fiddler或者添加 8888 端口的入站规则。第三个是 IP 填错手机上填的必须是电脑在同一个局域网里的 IPv4 地址很多人都填成 127.0.0.1那当然连不上。排查时先确认电脑ipconfig的地址再确认 Fiddler 左下角是否出现手机的 Session 记录。如果 Session 记录都没有说明代理还没进来重点查前两个原因。如果 Session 有了但请求全是 CONNECT 类型且没有内容那就是 HTTPS 解密部分的问题了。6.2 HTTPS 解密不生效勾选了 Decrypt HTTPS traffic也装了证书但 Fiddler 里看到的请求体仍然是乱码或者请求直接失败。这个问题的核心在证书信任链路。iOS 上最容易遗漏的是“证书完全信任”这一步。下载证书后系统会默认安装但不信任必须进入设置里的证书信任设置打开开关。Android 上则是版本问题Android 7.0 以上用户证书默认不生效要么用 debug 包开启允许用户证书要么走系统证书安装路线。不同测试设备的差异比较大我建议在项目一开始就把弱网测试的设备基线定下来统一用固定的几台设备做测试减少证书问题带来的反复。每换一台新设备就要重新走一遍证书信任流程这事虽然不复杂但很消耗时间也容易漏。6.3 限速脚本不生效或速度波动大保存脚本后在 QuickExec 里输入SetWeakProfile(2G)没有任何反应抓包看请求耗时和之前一样。这种情况最常见的原因是 FiddlerScript 没有重新编译。在编辑器里改了代码之后必须 CtrlS 保存Fiddler 才会重新编译脚本。如果保存后仍不生效重点检查函数名拼写和变量定义有没有报错。FiddlerScript 的报错不会直接弹窗而是显示在 QuickExec 输出区域开着抓包软件跑一个请求然后看输出区有没有红色错误信息基本就能定位。还有一种情况是限速生效了但速度表现不稳定。这通常和电脑本身的网络状况、Fiddler 处理线程阻塞有关。毕竟Thread.Sleep会阻塞线程大量请求并发时Fiddler 来不及处理所有请求实际表现就会和设定值有偏差。这种偏差在测试中一般可以接受但如果需要更精确的带宽模拟建议把大响应体场景单独调参不要和真实弱网进行一比一的数值计较。6.4 丢包模拟的补充方案Fiddler 本身不直接提供丢包开关。弱网场景里要模拟 2%~5% 的丢包率通常需要借助额外的轻量级网络模拟工具在同一台机器上对指定端口生效设置丢包率、乱序、延迟等参数。组合的效果是Fiddler 负责协议层的延迟和带宽模拟网络工具负责传输层的丢包和乱序模拟叠加起来更接近真实弱网。如果不引入额外工具也可以用 Fiddler 的断点加手动丢弃方式做人工丢包验证。方法就是命中一个 URL 后把请求挂住断掉连接看看客户端在连接中断时怎么表现。这种方式适合小规模、单接口的异常测试但效率不高没法自动化批量执行。我在实际项目中更推荐组合方案。丢包对 TCP 重传、弱网下的连接稳定性影响非常大完全忽略丢包会让弱网测试少覆盖很多真实场景。Fiddler 能把延迟和带宽做得足够好再补一个丢包模块基本就是一个完整的弱网测试工具箱了。做弱网测试这几年我自己最大的一个教训是千万不要只测“固定的慢”。真实用户手里的网络是波动的上一秒还是 3G 信号下一秒可能直接掉到 2G甚至完全没网。你费尽心思把 2G、3G、4G 的固定参数都测一遍其实只能覆盖一部分情况。现在我更习惯在固定场景测完之后主动在 2G、3G、4G 之间来回切换配合断点挂起和恢复操作去模拟网络断续和信号漂移的体验。另外有一个很实用的小习惯每次弱网测试前先在脚本里把当前场景名打印到 Fiddler 日志区测试过程中每切换一次场景就打一个标记。事后整理测试报告时对着日志标记就能知道哪一段数据是哪个网络场景下的不用靠回忆猜。工具用熟之后多花点心思在场景设计上会比到处找更高级的网络模拟工具更有用。
有次版本上线前功能用例全部跑通结果真实用户一连串反馈“开屏要等好几秒”“图片加载不出来”。排查下来发现问题不在业务逻辑而是我们没有在弱网环境下把关键流程完整跑过。后来我养成了一个习惯每次版本测试都把 Fiddler 切到 2G、3G、4G 场景模拟真实用户在不同网络下的表现。这篇就把这套 Fiddler 弱网测试方法从原理到实操完整拆开讲Fiddler 怎么做代理接管、FiddlerScript 怎么限制延迟和带宽、2G/3G/4G 参数怎么设置、测试时重点看什么、常见坑有哪些。客户端开发、测试工程师和前端性能优化的同学都可以直接参考。1. 弱网测试到底在测什么带宽、延迟与丢包1.1 弱网场景的三个关键维度很多人第一次做弱网测试想的很简单把带宽调小。但实际上一旦调起来就会发现弱网环境里最折磨人的不只有带宽还有延迟和丢包。拿一个典型场景举例。你在正常 4G 网络下打开某个 App请求发出去之后 200 毫秒内就能收到响应页面唰一下出来了。但换到 2G 或者信号很差的场景请求可能几秒都得不到响应连接一直挂着。如果代码里没有合理的超时机制用户看到的就是图标一直转圈等很久才跳出一个失败提示。这种情况主要就是延迟在起作用。延迟Latency可以简单理解成从发出请求到收到数据的时间间隔。延迟高的时候即使带宽不小体验也会很卡顿。带宽Bandwidth则决定了单位时间内能传多少数据带宽小的时候一个几百 KB 的接口响应都要传半天。丢包Packet Loss就更直观了数据包在半路丢失TCP 协议会自动重传但重传会进一步加剧延迟和卡顿。所以一个合格的弱网测试方案至少要能同时控制带宽和延迟这两个维度有条件的话还要模拟丢包。如果只是把带宽调低而不关注延迟很多问题其实是测不出来的。反过来如果只加延迟不限制带宽那大图片和大接口的加载速度又体现不了真实弱网的“传输缓慢”感。这两者必须配合着来。1.2 为什么选 Fiddler 而不是其他限速方式选择 Fiddler 做弱网模拟最核心的原因是它足够可控、足够易用而且跨平台支持不错。Fiddler 本质上是一个 HTTP/HTTPS 调试代理。所有走代理的请求会先经过 Fiddler由 Fiddler 代为转发给目标服务器。因为流量都要经过它Fiddler 就能在转发前后做各种处理弱网模拟就是在这一步里注入延迟和带宽控制逻辑。对比其他方案用真实网络卡做弱网测试可以做到完全真实但成本高、复现差2G 卡现在都不好找用路由器限速也能做但配置复杂而且只能针对整网生效没法区分不同的 2G/3G/4G 场景身边有同行用 Charles 做弱网功能上类似但如果你是 Windows 开发环境Fiddler 的普及度和资料丰富度都更高。Fiddler 自带一个“Simulate Modem Speeds”菜单项点一下就能把所有请求变慢。但它模拟的是非常慢的拨号网络只有单一档位显然不够用。真正能用的是 FiddlerScript——通过脚本自定义延迟、带宽、甚至跳过低版本网络下不必要的请求这套灵活度是其他菜单式操作没法比的。这也是这篇文章选择 Fiddler 作为核心工具的根本原因。2. Fiddler 弱网控制机制从代理到 FiddlerScript2.1 OnBeforeRequest 与 OnBeforeResponse 的分工FiddlerScript 是基于 JScript.NET 的扩展脚本。Fiddler 在启动时会加载这个脚本并在每个 HTTP 请求的生命周期节点调用对应函数。对弱网测试来说只需要关注最核心的两个函数OnBeforeRequest和OnBeforeResponse。OnBeforeRequest在客户端请求刚到达 Fiddler、还没发往服务器的时候执行。你在这里做的操作会直接影响请求的“上行”过程也就是上传数据、发送请求头、等待服务器开始响应之前的整个阶段。OnBeforeResponse在服务器响应已经到达 Fiddler、还没转发给客户端的时候执行。这是做“下行”控制的位置模拟下载数据的耗时和响应延迟都放在这里。理解这两个函数的分工非常重要。很多弱网测试做出来效果不对问题就出在把延迟全加在了一个函数里没分清上行和下行的差异。比如要模拟上传一张图片上传动作发生在请求阶段如果只在响应阶段加延迟图片上传速度根本没有被限制住自然测不出上传超时这类问题。反过来要模拟列表页数据加载慢如果只在请求阶段加延迟接口返回后的大 JSON 包下载耗时依然没有被模拟到。2.2 延迟和带宽的脚本模拟思路FiddlerScript 本身没有提供一个叫“设置带宽”的 API但它给了我们一个万能的工具System.Threading.Thread.Sleep()。Thread.Sleep的作用是让当前线程暂停执行指定毫秒数。放在OnBeforeRequest里就是让请求在发出去之前先等待一段时间等效于高延迟。放在OnBeforeResponse里就是让响应在到达客户端之前先等待等效于模拟下行延迟。延迟值可以直接根据场景设置比如 2G 场景 300~500ms3G 场景 100~200ms4G 弱信号场景 40~80ms。但只有延迟不够。如果只加延迟一个 1KB 的接口和一个 1MB 的图片加载时间会是一样的这显然不符合真实情况。要模拟带宽限制业界常用的做法是根据请求/响应体的字节数算出“按目标带宽传输需要多久”然后把这个耗时通过Thread.Sleep补进去。举个例子目标下载带宽是 40kbps一个响应体是 100KB理论传输时间就是 (100 × 1024 × 8) / (40 × 1024) 20 秒那么就让这个响应在发给客户端之前先 Sleep 20 秒。客户端感知到的下载速度就非常接近真实 2G 网络了。这个方案不是底层字节级的精确限速但做弱网场景模拟已经足够。客户端感受到的是“请求发得慢”“响应下得慢”和真实弱网的体验一致这就达到了测试目的。3. 环境准备让手机流量先走 Fiddler 代理3.1 电脑端 Fiddler 代理开关与端口在做弱网模拟之前先把基础环境搭好。安装 Fiddler 后第一件事是确认代理功能处于开启状态。打开 Fiddler点击菜单栏 Tools - Options - Connections确认勾选 “Allow remote computers to connect”。这是手机、模拟器、远端设备能连上 Fiddler 代理的关键开关。默认代理端口是 8888没有特殊需求就保持默认。这里有个小提醒Fiddler 默认只监听本机回环地址如果不勾选允许远程连接手机怎么连都连不上这是新手最容易卡住的地方。另外Windows 防火墙可能会拦截来自局域网其他设备的连接如果端口通行但一直连不上优先检查防火墙入站规则把 8888 端口的 TCP 入站放行或者直接允许 Fiddler 应用通过防火墙。3.2 手机和模拟器连上代理的步骤手机要和 Fiddler 建立连接前提是手机和电脑在同一个局域网上。然后打开手机的 Wi-Fi 设置找到当前连接的网络进入代理设置选“手动”填入电脑的局域网 IP端口填 8888。电脑的局域网 IP 可以在命令行里输入ipconfig查看取 IPv4 地址那个。不要在手机上填127.0.0.1那是手机自己不是电脑。填完之后手机上的流量就会全部经过 FiddlerFiddler 主界面的会话列表里会实时出现手机发起的请求。如果是 Android 模拟器情况类似只是入口不同。Android 模拟器里可以直接设置代理为本机局域网 IP也可以用模拟器网关地址访问电脑。不同模拟器产品的差异比较大最简单通用的办法是在模拟器的设置里打开无线网络长按当前 Wi-Fi 修改代理和真机的操作基本一致。如果用的是 iOS 真机代理设置入口在 Wi-Fi 网络名的右侧感叹号里选“配置代理”为手动同样填入 IP 和端口。设置完成后用 Safari 随便访问一个 HTTP 页面Fiddler 会话列表里能看到新会话说明连通成功。3.3 HTTPS 解密与证书信任弱网测试如果只测 HTTP 流量现在基本没戏了正规 App 全是 HTTPS。Fiddler 默认能看到 HTTPS 请求的域名但看不到明文内容拿不到请求体和响应体自然没法模拟带宽。所以需要先把 HTTPS 解密打开。在 Fiddler 的 Tools - Options - HTTPS 页面勾选 “Capture HTTPS CONNECTs” 和 “Decrypt HTTPS traffic”。Fiddler 会生成一个根证书手机需要信任这个证书才能完成解密否则请求会直接失败。iOS 设备需要下载证书后到“设置 - 通用 - 关于本机 - 证书信任设置”里手动开启完全信任。Android 7.0 及以上系统默认不信任用户安装的 CA 证书如果发现装了证书还是无法解密可以走 debug 包的方式在应用里开启允许用户证书或者用系统证书安装方案。这一步是实操里最典型的坑我遇到的不下十次。切记证书问题不解决FiddlerScript 里就算写了带宽限制HTTPS 流量拿不到响应体脚本效果也发挥不出来。4. 核心实操用 FiddlerScript 模拟 2G/3G/4G4.1 脚本模板参数集中管理 场景切换入口打开 Fiddler 后按 CtrlR 打开 FiddlerScript 编辑器。脚本里默认有一个class Handlers类要做的就是在类里添加自己的变量和函数然后在OnBeforeRequest、OnBeforeResponse两个函数中插入调用代码。我建议把网络场景配置写成独立函数方便后续切换。下面这份脚本是我在实际项目里用的模板直接复制到 FiddlerScript 里保存后即可生效// FiddlerScript 弱网模拟参数配置 public static var weakScenario: String none; // 各场景参数 public static var weakDelayMs: int 0; // 网络延迟毫秒 public static var weakUploadKbps: double 0; // 上行带宽kbps public static var weakDownloadKbps: double 0; // 下行带宽kbps public static function SetWeakProfile(scenario: String): void { weakScenario scenario; switch (scenario) { case 2G: weakDelayMs 300; weakUploadKbps 20; weakDownloadKbps 40; break; case 3G: weakDelayMs 120; weakUploadKbps 100; weakDownloadKbps 600; break; case 4G: weakDelayMs 40; weakUploadKbps 2000; weakDownloadKbps 10000; break; case none: weakDelayMs 0; weakUploadKbps 0; weakDownloadKbps 0; break; default: break; } } function OnBeforeRequest(oSession: Session) { if (weakScenario none) return; // 1. 模拟上行带宽限制按请求体大小计算传输耗时 if (weakUploadKbps 0 oSession.requestBodyBytes.Length 0) { var upTimeMs: int Math.round(oSession.requestBodyBytes.Length * 8 / (weakUploadKbps * 1024) * 1000); System.Threading.Thread.Sleep(upTimeMs); } // 2. 模拟基础网络延迟 if (weakDelayMs 0) { System.Threading.Thread.Sleep(weakDelayMs); } } function OnBeforeResponse(oSession: Session) { if (weakScenario none) return; // 3. 模拟下行带宽限制按响应体大小计算传输耗时 if (weakDownloadKbps 0 oSession.responseBodyBytes.Length 0) { var downTimeMs: int Math.round(oSession.responseBodyBytes.Length * 8 / (weakDownloadKbps * 1024) * 1000); System.Threading.Thread.Sleep(downTimeMs); } }脚本默认状态是none也就是不限速。用的时候在 Fiddler 左下角 QuickExec 里输入命令切换场景。模拟 2G输入SetWeakProfile(2G)执行后当前 Fiddler 会话里的所有流量都会按 2G 参数模拟。要恢复不限速输入SetWeakProfile(none)如果你的 FiddlerScript 编辑器对中文注释显示乱码直接把注释删掉就行不影响执行。脚本保存后 Fiddler 会重新编译不需要重启。4.2 2G/3G/4G 参数对照与调整原则上面脚本里的参数是我结合行业通用标准和实际测试场景调过的但不同团队、不同业务对弱网的定义不完全一样。下面把常见参考值单独列出来方便按项目调整网络类型延迟ms下行带宽kbps上行带宽kbps适用场景2GGPRS400~50020~4010~20极弱网、海外市场、偏远地区2GEDGE250~300100~15040~60弱网但略优于 GPRS3GUMTS150~200384~600100~200常规弱网测试标准3GHSPA80~1201000~2000300~500中等弱网4GLTE 弱信号40~802000~50001000~2000信号差但勉强有网4G正常20~50100005000基准对比表格里的“4G 正常”不是用来模拟弱网的是做对照实验的。弱网测试不是说把所有场景都调到最低而是根据业务实际覆盖的地区和信号状况来定。如果 App 主要面向一二线城市重点测 3G 和 4G 弱信号就够了如果面向发展中国家和偏远地区2G 就是必测的底线。参数设置还有一个容易忽略的点真实网络环境的延迟和带宽是持续波动的一会儿 3G 一会儿 4G 才是常态。我自己的做法是一组场景先测固定值保证可复现真正回归的时候用不同场景之间的手动快速切换来模拟网络断续的感受。要是你不想在脚本里写随机数逻辑手动在不同场景间来回切也是可行的低成本方案。4.3 场景切换、白名单与断点配合在项目里我不建议直接改脚本里的数字而是把所有场景都放在SetWeakProfile函数里用 QuickExec 切换。这样有个额外好处其他同事接手测试时不用去翻脚本输入一个函数名就能完成调度。还有一个很实用的组合用法配合 Fiddler 的断点功能做特殊弱网场景。比如想模拟“请求发到一半卡住”可以先切到某个弱网场景然后在 QuickExec 里输入断点命令来命中某类 URL把它挂住几秒钟不执行人为制造卡顿。断点不是严格意义上的丢包但在模拟“请求一直转圈”这个 UI 状态时非常直观。另外提醒一点FiddlerScript 里的变量是全局的QuickExec 调用函数后所有请求都会受影响。如果你不想让测试工具内置的请求比如统计 SDK 上报、崩溃日志上报也被限速可以通过在OnBeforeRequest里判断请求域名来跳过。方法是在函数开头加一个判断if (oSession.HostnameIs(example.com) || oSession.uriContains(/telemetry)) { return; }开发自带的统计请求如果也被限速你会误以为业务接口变慢了后期分析数据时非常痛苦。这个白名单思路我强烈建议加上。5. 弱网测试执行要点与数据采集5.1 测试前的用例与标准弱网测试不是拿到脚本就能直接开测需要提前设计好用例和参数。我的习惯是先列出核心流程再针对每个流程设置弱网验证点。核心流程一般选这些App 启动、首屏加载、登录、列表页滑动加载、图片加载、上传下载、支付、消息推送。每个流程至少要覆盖三个状态成功态、超时态、失败态。比如首屏接口在 2G 下请求超时客户端有没有合理的超时时间有没有重试机制失败后用户能不能手动重试有没有错误提示这些在真实弱网下才是用户真正感知到的东西。用例设计的时候还要明确可接受的标准。比如启动时间在 2G 下不能超过 10 秒首屏接口超时时间不能超过 30 秒。没有标准就测弱网最后只能得到一堆“感觉有点卡”的主观结论回归和复盘时没有参照。标准不一定要非常严格但一定要有。5.2 执行节奏基准、弱网、恢复执行的时候我建议按照“基准 - 弱网 - 恢复”的节奏操作。先正常网络跑一遍核心流程记录各项指标作为基准线。然后通过 QuickExec 切到 2G 场景重跑同一套流程。再分别测 3G、4G 弱信号场景。最后切回正常网络再跑一遍确认客户端能恢复。每个场景跑完之后除了记录功能表现还要从 Fiddler 会话列表里导出关键请求的耗时数据。选中一个请求在右侧的 Statistics 面板里能看到请求发送时间、接收时间、吞吐量等数据。把这些数据整理进表格就能形成一份很有说服力的弱网测试报告。我常用的记录字段包括接口名称、网络场景、接口耗时、首包时间、失败次数、页面呈现状态正常/白屏/转圈/报错、是否触发重试。有了这些字段复盘时才能快速定位是前端问题、接口问题还是网络策略问题。只看截图说明不了太多但一张带耗时数据和失败次数的表格开发拿到手基本就能定位方向。5.3 功能层面的三个重点验证项除了性能数据功能层面有几个弱网下特别容易出问题的点我单独列一下。第一请求超时和重试。很多开发在正常网络下从没见过超时代码里压根没写超时控制或者写了一个超长的时间。弱网一开请求挂十几秒都没有任何反馈用户早就不耐烦了。测的时候重点看超时时间是否合理、超时后有没有重试、重试会不会造成重复提交。第二并发限制。列表页同时请求多个接口、图片懒加载触发一堆小请求的时候弱网下这些请求会排队如果客户端没有限制并发数可能出现大量请求堆积导致内存暴涨、页面卡死。我遇到过一次比较极端的情况某个 App 在 2G 场景下一次发出几十个图片请求结果直接把页面拖挂。第三缓存策略。正常网络下缓存快速更新看起来没什么问题但弱网下如果缓存策略不合理每次启动都强制刷新用户会发现连打开一个已经访问过的页面都慢到怀疑人生。弱网测试时重点观察静态资源、列表缓存是否发挥了应有的作用而不是每次弱网都从服务器拉一次全量数据。6. 弱网测试常见问题与排查实录6.1 手机连不上 Fiddler 代理手机能连上 Wi-Fi但打开页面直接报网络异常这种问题十有八九出在三个地方。第一个是电脑端没勾选 Allow remote computers to connect。打开 Fiddler 的 Connections 页面如果这里没勾手机根本走不进来。第二个是防火墙拦截Windows 防火墙默认策略对入站连接非常严格需要在防火墙里放行 Fiddler或者添加 8888 端口的入站规则。第三个是 IP 填错手机上填的必须是电脑在同一个局域网里的 IPv4 地址很多人都填成 127.0.0.1那当然连不上。排查时先确认电脑ipconfig的地址再确认 Fiddler 左下角是否出现手机的 Session 记录。如果 Session 记录都没有说明代理还没进来重点查前两个原因。如果 Session 有了但请求全是 CONNECT 类型且没有内容那就是 HTTPS 解密部分的问题了。6.2 HTTPS 解密不生效勾选了 Decrypt HTTPS traffic也装了证书但 Fiddler 里看到的请求体仍然是乱码或者请求直接失败。这个问题的核心在证书信任链路。iOS 上最容易遗漏的是“证书完全信任”这一步。下载证书后系统会默认安装但不信任必须进入设置里的证书信任设置打开开关。Android 上则是版本问题Android 7.0 以上用户证书默认不生效要么用 debug 包开启允许用户证书要么走系统证书安装路线。不同测试设备的差异比较大我建议在项目一开始就把弱网测试的设备基线定下来统一用固定的几台设备做测试减少证书问题带来的反复。每换一台新设备就要重新走一遍证书信任流程这事虽然不复杂但很消耗时间也容易漏。6.3 限速脚本不生效或速度波动大保存脚本后在 QuickExec 里输入SetWeakProfile(2G)没有任何反应抓包看请求耗时和之前一样。这种情况最常见的原因是 FiddlerScript 没有重新编译。在编辑器里改了代码之后必须 CtrlS 保存Fiddler 才会重新编译脚本。如果保存后仍不生效重点检查函数名拼写和变量定义有没有报错。FiddlerScript 的报错不会直接弹窗而是显示在 QuickExec 输出区域开着抓包软件跑一个请求然后看输出区有没有红色错误信息基本就能定位。还有一种情况是限速生效了但速度表现不稳定。这通常和电脑本身的网络状况、Fiddler 处理线程阻塞有关。毕竟Thread.Sleep会阻塞线程大量请求并发时Fiddler 来不及处理所有请求实际表现就会和设定值有偏差。这种偏差在测试中一般可以接受但如果需要更精确的带宽模拟建议把大响应体场景单独调参不要和真实弱网进行一比一的数值计较。6.4 丢包模拟的补充方案Fiddler 本身不直接提供丢包开关。弱网场景里要模拟 2%~5% 的丢包率通常需要借助额外的轻量级网络模拟工具在同一台机器上对指定端口生效设置丢包率、乱序、延迟等参数。组合的效果是Fiddler 负责协议层的延迟和带宽模拟网络工具负责传输层的丢包和乱序模拟叠加起来更接近真实弱网。如果不引入额外工具也可以用 Fiddler 的断点加手动丢弃方式做人工丢包验证。方法就是命中一个 URL 后把请求挂住断掉连接看看客户端在连接中断时怎么表现。这种方式适合小规模、单接口的异常测试但效率不高没法自动化批量执行。我在实际项目中更推荐组合方案。丢包对 TCP 重传、弱网下的连接稳定性影响非常大完全忽略丢包会让弱网测试少覆盖很多真实场景。Fiddler 能把延迟和带宽做得足够好再补一个丢包模块基本就是一个完整的弱网测试工具箱了。做弱网测试这几年我自己最大的一个教训是千万不要只测“固定的慢”。真实用户手里的网络是波动的上一秒还是 3G 信号下一秒可能直接掉到 2G甚至完全没网。你费尽心思把 2G、3G、4G 的固定参数都测一遍其实只能覆盖一部分情况。现在我更习惯在固定场景测完之后主动在 2G、3G、4G 之间来回切换配合断点挂起和恢复操作去模拟网络断续和信号漂移的体验。另外有一个很实用的小习惯每次弱网测试前先在脚本里把当前场景名打印到 Fiddler 日志区测试过程中每切换一次场景就打一个标记。事后整理测试报告时对着日志标记就能知道哪一段数据是哪个网络场景下的不用靠回忆猜。工具用熟之后多花点心思在场景设计上会比到处找更高级的网络模拟工具更有用。
