1. 别只盯着功能测试：弱网场景为什么必须单独设计
做过几年客户端测试的人都清楚，功能测试只能保证"网络通畅时功能可用"，但用户真实场景里，永远有地铁、电梯、停车场、郊外这种信号飘忽不定的环境。App在弱网下的表现——超时是直接报错还是优雅降级、数据是否会重复提交、页面是否白屏或一直转圈、断网重连后状态是否一致——恰恰是用户最容易感知到"这App卡死了"的环节。
我在一个测试项目里遇到的情况很典型：某App的登录模块在正常网络下毫秒级响应，但把带宽压到几十KB/s时，点击登录没有任何提示，按钮也不置灰，用户反复点击，结果同一个请求被发出七八次，服务端生成了多个会话。这种问题只靠真机踩点或主观"感觉网络不好"根本无从排查，必须用工具把网络状态量化、可控、可复现地模拟出来，这就是弱网测试的核心价值：把模糊的"信号差"变成确定的"延迟X毫秒、带宽Y KB/s"，让问题可以被稳定复现和验证修复效果。
而在所有弱网模拟工具里，Fiddler是入门门槛最低、调试信息最透明、和抓包被测请求强绑定的一类。它不需要额外硬件，只要把手机代理指向PC上的Fiddler端口，就能在会话层面自由注入延迟、限制下载带宽、构造超时响应，而且能看到修改后每个请求的真实耗时和状态码分布。这套方案适合所有H5、Android、iOS、小程序前端团队，是移动端测试人员必须具备的基本功。
2. 弱网测试的完整思路与Fiddler的定位
2.1 弱网测试到底要控什么、怎么量化
在配置工具之前，先要把弱网测试的抽象目标转成可操作参数。一套完整的弱网模拟至少需要覆盖四个维度：
- 延迟（Latency）：请求发出去到服务端收到的时间，以及响应返回的时间。用户感知最明显，表现为页面一直"加载中"。
- 带宽（Bandwidth）：单位时间内能传输的数据量，决定了大图、视频、首包资源的加载耗时。
- 丢包（Packet Loss）：数据包在网络传输中丢失，表现为偶发超时、请求立即失败、页面加载不完整。丢包一般伴随TCP重传，对业务的影响比延迟更严重。
- 抖动（Jitter）：延迟的波动幅度，比如某个请求延迟稳定在200ms，另一个请求延迟在30ms到1200ms之间乱跳，后者更接近真实弱网体验。
手动测试阶段，我们最常用的组合是"固定延迟 + 带宽限制 + 部分丢包"。其中延迟和带宽，Fiddler自带的脚本机制就能精确控制；丢包模拟Fiddler本身支持较弱，通常配合代理转发到Linux机器上用TC规则实现，或者用专门的弱网模拟App（比如某实验室的网络损伤仪、Android端的Network Emulator工具），这部分放在后面单独说。
2.2 为什么选Fiddler而不是其他方案
市面上做弱网模拟的方案不算少，各有适用边界：
| 方案 | 优点 | 局限 |
|---|---|---|
| Fiddler脚本 | 免费、跨平台、能精确关联单个请求、直接看到耗时 | 丢包支持弱、无法模拟链路拥塞、只影响HTTP/HTTPS |
| Chrome DevTools网络面板 | 零配置、适合前端快速调试 | 只能浏览器内生效，无法覆盖App请求 |
| Charles | 界面友好、弱网配置简单 | 收费，数据对比功能弱于Fiddler |
| 真机路测 | 最真实 | 不可控、不可复现、问题定位效率低 |
| 专用硬件（网络损伤仪） | 高端、精确到链路层 | 贵，适合专项测试，不适合日常迭代 |
对于绝大多数日常迭代和回归验证，Fiddler是性价比最高的选择。它有一个其他调试代理工具没有的天然优势：弱网模拟和请求/响应拦截是强耦合的。同一个会话列表里，你能看到"[Slow] 请求A → 200 (2.3s)"、"请求B → 504"，延迟是被Fiddler注入的还是服务端本身的处理时间，一目了然，不需要额外打日志。
3. Fiddler弱网配置的核心参数详解
3.1 内置弱网模式：一键开启但不建议直接用
Fiddler菜单栏依次点开Rules → Performance → Simulate Modems Speed，实测一下就会发现：所有请求的响应时间都被拖得很慢，尤其是静态资源，延迟特别明显，但具体慢到什么程度，页面完全没有任何显示。全看内部默认参数被动生效，这才是这个功能被很多人误会的原因——它其实只改了脚本里的两个全局变量。
打开FiddlerScript编辑器（快捷键 Ctrl+R），找到OnBeforeRequest处理器里的这段：
var m_SimulateModem: boolean = true; if (m_SimulateModem) { // Delay sends by 300ms per KB uploaded oSession["request-trickle-delay"] = "300"; // Delay receives by 150ms per KB downloaded oSession["response-trickle-delay"] = "150"; }所以内置模式的实际效果是：每下载1KB数据，人为加150毫秒延迟；每上传1KB，加300毫秒延迟。这不是全局固定延迟，而是"按传输字节数比例延迟"，下载一个500KB的首页，光人为注入的等待时间就有 500×150 = 75秒，明显过重。而且它没有区分2G/3G/4G，也没有首个请求的固定延迟模拟。
3.2 真正可控的参数：trickle-delay 与延迟注入
Fiddler通过两个会话属性来控制弱网行为：
request-trickle-delay：每上传1KB数据的额外延迟（毫秒）。控制上行带宽。response-trickle-delay：每下载1KB数据的额外延迟（毫秒）。控制下行带宽。
这两个参数的计算逻辑是：
换算成带宽就是带宽(KB/s) = 1024 / delay。比如设置response-trickle-delay = 100，意味着下行速度大约为10KB/s，也就是80Kbps，接近2G网络的下限。
此外要模拟网络往返延迟，需要在OnBeforeRequest和OnBeforeResponse里加固定等待：
Thread.Sleep(200); // 单位是毫秒，模拟往返链路延迟但固定延迟只改一处不够，真实网络的延迟同时体现在请求上行和响应下行两个方向。规范的做法是在请求处理器里做上行延迟，在响应处理器里做下行延迟，两个方向叠加才是用户感受到的完整RTT。
3.3 脚本里定位修改位置：OnBeforeRequest 与 OnBeforeResponse
脚本编辑器中，弱网控制逻辑分布在两个关键处理器中：
- OnBeforeRequest：请求尚未离开Fiddler，是模拟上行方向的最佳位置，处理上传延迟、请求超时。
- OnBeforeResponse：响应已经到达Fiddler、还没转发给客户端，是模拟下行方向的最佳位置，处理下载延迟、响应超时。
第二步用到的核心代码模板如下：
// 在 OnBeforeRequest 中： static function OnBeforeRequest(oSession: Session) { if (oSession.HostnameIs("api.example.com") || oSession.HostnameIs("img.example.com")) { // 上行带宽：每KB加X毫秒 oSession["request-trickle-delay"] = "200"; // 模拟请求往返链路延迟 Thread.Sleep(150); } } // 在 OnBeforeResponse 中： static function OnBeforeResponse(oSession: Session) { if (oSession.HostnameIs("api.example.com") || oSession.HostnameIs("img.example.com")) { // 下行带宽：每KB加Y毫秒 oSession["response-trickle-delay"] = "200"; // 模拟响应链路延迟 Thread.Sleep(150); } }两个处理器中都加入延迟，是因为一次完整的HTTP请求要经历：客户端上行请求 → 服务端处理 → 服务端下行响应。上行链路和下行链路都有各自的物理延迟，只在一端睡会导致时间分布失真。
3.4 一键切换不同网络制式的脚本设计
实际工程中，手动打开脚本编辑器改数字再保存本身就很低效，更可靠的做法是在脚本里预设好2G/3G/4G配置，用一个公共函数集中管理。我常用的方式如下：
// 在 Handlers 区域定义函数 public static function SetWeakNetworkMode(mode: String) { var uploadDelay: int = 0; var downloadDelay: int = 0; var latDelay: int = 0; if (mode == "2G") { uploadDelay = 500; // 上行约2KB/s downloadDelay = 400; // 下行约2.5KB/s latDelay = 400; // 额外固定延迟 400ms } else if (mode == "3G") { uploadDelay = 80; downloadDelay = 90; latDelay = 150; } else if (mode == "4G") { uploadDelay = 50; downloadDelay = 50; latDelay = 30; } else { uploadDelay = 0; downloadDelay = 0; latDelay = 0; } // 存放在全局变量中，供两个处理器读取 g_uploadDelay = uploadDelay; g_downloadDelay = downloadDelay; g_latDelay = latDelay; } // 在两个处理器里读取变量 if (g_uploadDelay > 0) { oSession["request-trickle-delay"] = g_uploadDelay.ToString(); }但脚本里定义的变量在Fiddler重新加载脚本后会重新初始化，所以更推荐把"模式切换"绑定到Fiddler的自定义菜单项上：
// 在 OnCreateTab 或菜单扩展中动态添加菜单 public static var g_weakMode: String = "off"; // 菜单项点击后调用 public static function OnWeak2G() { g_weakMode = "2G"; SetWeakNetworkMode("2G"); }实际操作中，每次修改脚本后需要点击Rules → Reload Script（或按 Ctrl+Shift+R）让脚本重新编译生效，确保下发的判断逻辑是最新的。提醒一下，Fiddler的脚本基于JScript.NET，修改语法错误会直接导致代理无法正常工作，保存前建议先仔细检查配对。
4. 2G/3G/4G不同网络制式的参数配置方案
4.1 不同网络制式的基准参数表
弱网测试的参数不是拍脑袋定的，不同网络制式有相对公认的性能下限和典型值。下面是我实际测试中常驻的一组基准配置，兼顾"能够暴露问题"和"接近真实下限"：
| 网络制式 | 下行带宽参考值 (Kbps) | 上行带宽参考值 (Kbps) | RTT参考值 (ms) | Fiddler配置参考（上行/下行 delay） |
|---|---|---|---|---|
| 2G (GPRS) | 20~40 | 10~20 | 500~800 | 上行/下行 delay = 300~500 |
| 2G (EDGE) | 80~160 | 40~80 | 300~500 | 上行/下行 delay = 150~250 |
| 3G (UMTS/HSPA) | 300~2000 | 100~1000 | 100~200 | 上行/下行 delay = 50~100 |
| 4G (LTE常用场景) | 3000~20000 | 1000~5000 | 20~50 | 上行/下行 delay = 30~50 |
| 4G (弱信号/多用户场景) | 300~1000 | 200~500 | 50~150 | 上行/下行 delay = 100~200 |
提示：这里不是让你严格照搬数字。2G/3G/4G在每个运营商、每个基站、每个地铁隧道的表现都不同，基准表的意义是提供一个"能复现问题"的起点。先按基准表测试，如果问题未复现，再逐档收紧带宽和延迟，找到暴露问题的最小参数组合。
比如在某个消息推送模块的弱网测试中，用上表4G弱信号参数测试，图片消息发送完全正常；但当我把下行delay从150调到250，并且在上行链路上额外加200ms固定延迟时，出现了发送超时后本地显示"已发送"、服务端实际未收到的问题。这说明基准参数需要结合实际场景动态调整，不是一套参数包打天下。
4.2 参数配置的取舍逻辑
不同网络制式的配置不能只看带宽数字，还要考虑传输模式和拥塞控制的影响。GPRS/EDGE属于2G技术，带宽极窄，TCP连接的初始拥塞窗口很小，第一次请求尤其容易超时；而4G带宽充裕，但弱信号场景下主要的瓶颈是无线链路的RTT抖动和重传。
所以配置上有两条取舍经验：
- 模拟2G时，重点是加大固定延迟而不是只靠带宽。因为2G实际表现是"极窄带宽 + 高RTT"，如果只设置带宽限制而不加延迟，请求并不会出现明显超时，只会感觉到下载慢。只有把固定延迟加到800ms以上，各种超时重试逻辑才会被真正触发。
- 模拟4G弱信号时，重点是模拟"间歇性丢包"而非单纯限速。4G正常时带宽很大，但信号弱时表现的是突发延迟和瞬间丢包，这会让请求在某个节点卡住几秒，然后瞬间恢复。Fiddler对突发延迟的支持弱一点，我通常通过在
OnBeforeRequest里"每三次请求中随机一次设置更高延迟"来模拟：
if (Math.random() < 0.3) { Thread.Sleep(1500); // 30%的概率出现1.5秒卡顿 }这种概率化延迟比固定延迟更接近真实弱信号场景。
4.3 HTTPS流量的证书配置
弱网测试必须覆盖HTTPS流量，Fiddler抓HTTPS需要安装根证书并开启解密，方法如下：
- 菜单Tools → Options → HTTPS，勾选Decrypt HTTPS traffic，按提示安装Fiddler根证书。
- 手机访问
http://fiddler:8888，下载并安装Fiddler证书到系统信任列表。 - Android 7.0以上，应用默认不信任用户证书，需要把证书安装至系统证书目录，或者应用开启
<network-security-config>允许用户证书。 - iOS高版本同样需要"设置 → 通用 → 关于本机 → 证书信任设置"里信任Fiddler根证书。
不要贪图方便跳过证书配置。很多弱网问题恰恰是HTTPS握手超时导致的，不解密的话，你只能看到HTTP CONNECT，根本看不到握手在哪一步卡住。初始化连接慢、证书校验超时、Session复用失效，这些都需要在解密后的会话里才能定位。
4.4 不同网络制式的测试场景选择
参数设置在逻辑上要贴合具体测试场景，这里有一个实操经验：公开测试用例通常分为"首次启动弱网场景""页面资源加载弱网场景""接口交互弱网场景""弱网恢复场景"四类，每类场景适合的制式不同。
| 测试场景 | 推荐制式 | 关注重点 |
|---|---|---|
| 冷启动/首屏加载 | 2G、3G | 首包时间、超时策略、页面白屏 |
| 图片列表/长列表滚动 | 3G、4G低带宽 | 图片懒加载、占位图、滚动卡顿 |
| 表单提交/支付 | 2G、3G、4G随机 | 重复提交、超时重试、幂等性 |
| 长连接/消息推送 | 4G低带宽+抖动 | 断线重连、协议心跳、消息乱序 |
| 弱网恢复 | 各制式之间切换 | 加载失败重试、缓存策略、数据一致性 |
测试时把每类场景的2G/3G/4G参数分别跑一遍，用弱网参数矩阵表记录每个用例的结果，是保证覆盖度的最有效方式，避免"只测了两三个网络档位就说弱网测试通过"的问题。
5. 弱网测试中的常见问题与排查技巧实录
5.1 延迟和限速参数完全没生效
这是最常遇到的问题，设置了trickle-delay但请求耗时没有任何变化。排查步骤按这个顺序来：
- 检查脚本是否重新加载了。修改FiddlerScript后如果没执行Rules → Reload Script，新参数不会生效。
- 检查匹配域名是否准确。用通配符
HostnameIs("*.example.com")这种写法在Fiddler里经常踩坑，它不会子集匹配，需要分别列举，或改用oSession.HostnameIs("example.com") || oSession.HostnameIs("img.example.com")。 - 检查是不是命中缓存了。如果页面请求返回304 Not Modified，或者命中了App本地缓存，Fiddler根本不会转发请求，自然也没有弱网注入机会。这种情况下需要用Ctrl+F5强制刷新，或者清掉App的缓存再测。
- 确认代理生效。手机流量是否真的走了Fiddler，看会话列表里有这个请求，说明走了，没有则说明代理没配对。
5.2 所有请求都被拖慢，但只想限速某个域名
弱网模拟的常见误区是"对全部流量统一限速"，这会干扰对比测试。正确做法是先精确筛选需求：
private static function IsWeakHost(oSession: Session): boolean { var hosts: String[] = ["api.example.com", "img.example.com"]; for (var i = 0; i < hosts.Length; i++) { if (oSession.HostnameIs(hosts[i])) { return true; } } return false; }在OnBeforeRequest开头判断if (!IsWeakHost(oSession)) { return; }，把弱网影响范围控制在目标域名。注意除了业务域名，还需要把日志上报、监控统计这类流量排除在限速之外，否则整个测试会被埋点上报请求拖到接近不可用，干扰判断服务端真实响应时间。
5.3 模拟出的弱网效果与真实弱网相差很大
Fiddler模拟的是应用层HTTP传输过程的延迟和限速，和真实物理网络丢包导致的链路层重传、DNS解析超时、TCP握手失败造成的异常还是有差别的。尤其是服务端处理正常但Fiddler人为等待很久，可能表现为"首字节时间过长"，和真实网络中"请求发出后服务器迟迟不响应"的现象能混在一起，分析是注入产生的还是服务端本身问题需要注意区分。
针对这个问题，我的做法是"混合模拟"：
- 在测试环境用Fiddler注入延迟和带宽来暴露业务问题。
- 对疑似网络链路问题的复现，使用TC/NETEM工具模拟真实的丢包和抖动（需要一台Linux作为网关代理）。
- 关键功能上线前，最后再做一轮真机路测（地铁、地下车库）作为最终验证。
没有一种工具能完美覆盖真实弱网，要做的是利用Fiddler的高可控性把业务逻辑问题提前暴露，把剩下的偶发性链路问题留给更接近物理层的工具去验证。
5.4 请求超时后页面表现与线上不一致
这是一个经常让人困惑的现象。Fiddler模拟的延迟是"数据在Fiddler里被睡过去了"，而对客户端来说，连接始终是通的，TCP层没有断开、没有RST、没有TIME_WAIT堆积，所以客户端看到的往往是"一直等待"而不是"立即失败"。而在真实弱网中，TCP连接可能半开、对端拒绝、重传超时，这时候客户端短时间内就会报"网络错误"或者抛出504。
处理方式是在测试用例设计上额外加入"连接失败""无响应直接断开"场景。在Fiddler中可以主动让请求卡死，或者通过oSession["x-replywithfile"]返回自定义响应，甚至直接oSession.ForceResetConnection()强制断开连接，模拟"连接被重置"的体验。这是很多测试新手忽略的一环。
5.5 测试报告如何呈现：参数记录和可复现性
负责地讲，弱网测试的项目交付物不只是一份"测过通过"的结论。如果参数没有固化、问题没有可复现参数集，后续开发没法定位，回归没法验证。实际工作中我会在测试报告里附上以下内容：
- 弱网模拟工具及版本：Fiddler版本、操作系统的网络配置
- 参数矩阵：每种网络制式的上行、下行delay、固定延迟、丢包比例
- 导出的Fiddler会话存档（.saz文件），便于开发本地加载复现
- 每个问题用例对应的弱网参数档位和真实耗时数据
这样做的好处是，开发拿到报告后直接用同一套参数就能复现问题，不需要再和我反复对"当时网络有多差"。这也是弱网测试区别于普通功能测试的专业体现。
5.6 弱网测试的自动化整合方案
如果项目迭代频率高，每次发版都手工配置Fiddler再操作手机，效率太低。实际中可以结合Fiddler的脚本和持续集成做部分自动化：
- 使用Fiddler的命令行模式（
Fiddler.exe -Script）加载预设脚本。 - 在自动化测试框架里动态切换Fiddler的代理规则，比如通过修改注册表或直接操作Fiddler的RemoteCommand。
- 在Robot Framework或自研框架中封装"切换2G/3G/4G"的关键字，内部实现是通过HTTP访问Fiddler的控制端口来修改脚本变量的值。
自动化整合的收益不只是省时间，更重要的是让弱网测试覆盖每次提交的冒烟用例。它让"弱网才是常态"这个理念真正落到日常流水线中，而不是只在版本发布前突击一次。
6. 最后再分享几个实战中的小技巧
测试过程中有几个顺手的小技巧，能省下不少时间：
技巧一：使用QuickExec命令快速开关弱网。Fiddler左下角的QuickExec命令行（黑色小框）可以直接输入命令，通过在脚本中自定义命令，输入weak2g就能切到2G参数，weakoff关闭，不用每次都打开脚本编辑器。命令绑定方式是在脚本的OnRegisterCommand里注册：
FiddlerObject.UI.RegisterCustomCommand("weak2g", function() { SetWeakNetworkMode("2G"); }); FiddlerObject.UI.RegisterCustomCommand("weako3g", function() { SetWeakNetworkMode("3G"); }); FiddlerObject.UI.RegisterCustomCommand("weak4g", function() { SetWeakNetworkMode("4G"); }); FiddlerObject.UI.RegisterCustomCommand("weakooff", function() { SetWeakNetworkMode("off"); });技巧二：百试不爽的"慢网截图法"。做弱网测试时，开启Fiddler的计时信息（菜单QuickExec输入!timers，或查看会话栏目的ClientDNS / ClientConnected / ClientBeginRequest / ClientDoneRequest / ServerConnected / ServerBeginResponse / ServerDoneResponse / ClientDoneResponse列），可以在截图里直观展示每个阶段耗时。我曾靠这组时间戳快速定位到一个图片加载慢的问题，发现瓶颈根本不在图片传输，而是DNS解析占了整整1.9秒。
技巧三：弱网参数不是越小越好。很多人以为参数拉得越低，测出来的问题越多。但实际上，过低的带宽会让绝大多数请求全部超时，页面完全无法使用，反而掩盖了业务逻辑层面的差异。比如2G带宽下，列表页加载完成要180秒，那么"图片懒加载是否延迟"这个交互细节根本没机会被观察。真正有效的是"能加载出来但明显变慢"的边界值，只在需要验证极限情况时才用极致恶劣参数。
技巧四：不要只在测试环境测弱网。很多时候弱网问题在测试环境（内网服务端、本地接口）根本暴露不了，因为服务端响应本身只要几毫秒，Fiddler的延迟全被吞掉了。要尽可能连到接近生产的环境，或者用线上域名解析到测试IP，这样Fiddler注入的延迟才能叠加在真实的端到端链路上，结果更有说服力。
我个人在这条路上踩过最多的坑，永远是"以为弱网测试就是打开Simulate Modems Speed然后点点页面"。等到真正把参数矩阵做细、把域名筛选做对、把环境连到生产链路，才意识到弱网测试的本质不是模拟慢，而是模拟"用户在最糟糕的环境下依然能完成核心任务"。Fiddler只是一个入口，背后考验的是对整个网络链路、客户端超时策略和异常处理机制的理解深度。希望这篇分享能让你少走几步弯路，先从参数配置做起，一步一步把弱网场景真正管起来。
