两年前我在负责一个工具类App的版本测试上线第三天陆续收到用户反馈地铁里打开App转圈转了快二十秒最后弹了个网络错误再点还是错。开发在自己百兆光纤上怎么都复现不了后来查日志才发现是用户走的运营商网络丢包率高首页配置接口带重试机制一共发了七次请求全部失败。这类问题不是个例而是移动App脱离稳定办公网络后的常态。弱网络测试Weak Network Testing要做的就是把这种不完美网络提前搬进测试环境在版本上线前验证应用在低带宽、高延迟、高丢包、网络抖动甚至断网切换场景下的表现。它和性能测试、稳定性测试一样是App专项测试里绕不开的板块。这篇内容适合刚接触移动端质量的测试同学也适合正在搭建专项测试体系的团队参考全文按指标拆解、工具搭建、用例设计、问题复盘、落地执行五个方面展开相关参数和做法都可以直接拿去用。1. 想清楚弱网络测试在测什么——先拆解网络指标很多人一上来就打开工具限个速测完发现页面加载慢了然后就没有然后了。这样测不出价值因为你不清楚到底在模拟什么、业务对哪个指标最敏感。要设计有效的弱网用例第一步是把弱网络这三个字拆开看。1.1 网络为什么弱从延迟、带宽、丢包、抖动四件事说起真实世界里的网络质量主要由四个基础指标决定延迟Latency、带宽Bandwidth、丢包Packet Loss、抖动Jitter。延迟指数据包从一端到另一端需要的时间单位是毫秒。日常办公网延迟一般在10-30ms人几乎没有感知到了4G网络正常环境下延迟大概30-80ms但走进地铁、商场、高铁站延迟翻到200-500ms是非常正常的。延迟高直接影响首屏加载速度用户点一下按钮半天没反应最先怀疑的就是延迟。带宽是单位时间内能传输的数据量单位是bit/s。注意带宽和下载速度的区别我们常说的每秒下载1MB是字节Byte而带宽单位是比特bit1Byte等于8bit所以100Mbps的带宽理论下载上限约为12.5MB/s。弱网测试里常见的256kbps带宽换算下来每秒只能传约32KB一张图片几十KB到几百KB加载起来自然很吃力。丢包指数据包在传输过程中丢失的比例。这是一个非常容易被忽略但又极其致命的指标TCP协议遇到丢包会触发重传丢包率一上来你表面上看到的已经不是慢而是卡死和超时。实测中丢包率超过5%视频通话和直播就开始明显花屏卡顿超过15%普通接口请求基本很难一次成功。抖动是延迟的变化幅度。比如平均延迟200ms但一会跳到100ms一会跳到500ms这种不稳定对音视频、实时消息这类连续传输的业务伤害极大它会导致音频突然断断续续、视频画面忽快忽慢。1.2 常被漏掉的第五类场景断网与网络切换除了上面四个持续存在的弱指标弱网测试还得覆盖两类瞬态场景完全断网和网络切换。完全断网看起来最简单但很多App恰恰在这里翻车断网状态下打开App直接白屏没有任何提示断网后点击操作按钮没有loading反馈用户以为没点到重复点击多次恢复网络后之前失败的操作不会自动重试需要重启App才能恢复。网络切换更隐蔽从Wi-Fi切到4G从4G进电梯变无信号这时TCP连接全部断了但App可能完全没有感知。常见表现是长连接断了不自动重建页面一直转圈等十几秒才超时。我一直认为弱网测试应该把网络变化事件作为独立测试维度它和持续的弱网同样重要。1.3 真实世界是多个指标叠加不看单一值做弱网模拟时不能只调一个参数。真实用户在地铁里遇到的网络往往是中等延迟中等丢包带宽受限抖动明显同时出现。你只把丢包调到20%但延迟和带宽正常可能测不出真实体验问题反之只把带宽调到极低但无丢包接口反而能靠TCP慢慢传完不会触发超时重试逻辑。另外不同业务对指标的敏感度差异很大这一点在用例设计中非常关键视频直播最怕丢包和抖动IM消息最怕延迟和高丢包导致消息收发延迟交易和支付类最怕丢包引起请求超时但服务端已处理从而产生重复提交或状态不一致。后面设计用例时需要根据业务类型确定重点指标。2. 逼真造网从客户端到服务端的弱网络模拟工具路书选工具之前先想清楚一个问题你需要在哪一层模拟弱网在App所在设备上模拟在网关热点上模拟还是在服务端网卡入口模拟三个层面的效果和成本差别非常大需要根据测试目的来选择。2.1 客户端模拟iOS和Android各自的实用方案iOS端最方便的是Network Link Conditioner这是苹果官方提供的网络调节工具通过Xcode连接设备后在设置-开发者里可以找到。它内置了3G、Edge、DSL等预设档位也支持自定义下行/上行带宽、延迟和丢包。优点是无需额外硬件缺点是只适用于iOS真机且只能模拟当前设备多人合作时每个人的参数不一定一致。使用Network Link Conditioner时我个人的习惯是把下行带宽设为300kbps、延迟设为300ms、丢包设为10%这个组合比较接近地铁环境下普通4G网络的体验。如果只测断网重连也可以直接开启100% Loss档位那是最接近完全断网的模拟方式。Android端没有官方自带的全能弱网模拟器常用的方案有三类一是使用基于本地网络虚拟接口原理实现的限速类App这类工具在Play商店或各厂商应用市场里都能搜到通过创建本地网络通道来接管流量并按规则限速二是通过开发者选项里的网络相关开关配合代理工具如Charles、Fiddler限速三是把Android设备连到热点型模拟工具上比如下面要讲的ATC方案。2.2 HTTP代理工具Charles和Fiddler的快速限速Charles和Fiddler本质是HTTP调试代理工具但内置了限速能力适合做应用层弱网模拟。Charles里打开Proxy-Throttle Settings勾选Enable Throttling后就能设置参数Bandwidth是带宽kbpsRound-trip Latency是往返延迟msReliability是可靠性百分比100%表示完全不丢包比如调到90%就模拟10%丢包Stability是稳定性百分比调低会降低稳定性即增加抖动。这里有两个实操细节一是Charles的Throttle默认只作用于经过代理的HTTP请求对原生Socket长连接不一定生效二是如果只想对特定域名限速可以在Throttle Settings里勾选Only for selected hosts添加目标域名这样其他流量不受影响测试定位问题会更清晰。Fiddler对应的是Rules-Performance-Simulate Modem Speeds勾选后快速模拟一个56kbps调制解调器的速度。这个功能比较粗糙适合快速验证慢不适合精细控制。想更精细的话可以在FiddlerScript的OnBeforeRequest里写代码按URL匹配设置延迟但可读性差维护成本较高我一般只在没有Charles授权时用它应急。2.3 网关级模拟ATC与Linux tc/netem代理工具只覆盖HTTP层且对iOS和部分Android App的某些底层网络请求不生效。如果你要测长连接、Socket通信、视频流这些场景最好的方案是把弱网模拟提到网络链路层--也就是在手机连接的真实链路上做手脚。Facebook开源的Augmented Traffic ControlATC是这类的代表把一台Linux设备树莓派或普通电脑配置成Wi-Fi热点手机连上这个热点通过Web页面就能实时调整每个连接的带宽、丢包、延迟、抖动。ATC把所有参数通过Web API暴露出来这意味着可以脚本化让自动化测试在每跑一个用例前切换网络档位实现弱网回归的自动化。实测下来ATC对iOS和Android表现一致因为手机根本感知不到测试工具的存在它只在网关位置处理流量这种方式最接近真实用户网络链路。Linux上更底层的是netem内核模块配合tc命令它可以直接在网卡出口注入延迟和丢包。团队里如果有Linux环境可以在一台充当网关的Linux机器上执行# 注入延迟300ms抖动50ms丢包10% tc qdisc add dev eth0 root netem delay 300ms 50ms loss 10% # 配合带宽限制限制下行约为100kbps tc qdisc add dev eth0 root tbf rate 100kbit burst 32kbit latency 400ms # 还原全部配置 tc qdisc del dev eth0 root需要注意tc命令在服务端网卡上加规则模拟的是客户端到服务端的这一段链路变弱用于服务端联调环境时很好用你可以把开发环境的入口网卡加上丢包延迟然后App端不用做任何配置直接真机连到该环境测试。这份能力对于排查到底是客户端问题还是服务端问题也很有帮助——在服务端入口统一注入弱网时如果问题稳定复现说明服务端对弱网的适配也存在隐患。2.4 云真机平台覆盖真实地域网络的兜底方案自建ATC和netem能满足大部分场景但有一个短板覆盖不了真实的运营商地域网络。比如用户A在广深地铁用户B在西二环写字楼他们遇到的网络调度策略和基站负载完全不一样。市面上主流的云真机平台如wetest、Testin、阿里云移动测试平台等都提供弱网测试能力。它们的做法大致两种一种是在机房里给真机接可编程的弱网网关提供弱网、极弱网、高丢包、无网络等预设档位另一种是直接接入各地IDC机房的真实运营商网络线路测试时可以选北京联通、上海电信这样的节点模拟真实用户在地理位置的网络表现。我的观点是云真机平台适合做发布前的多地区抽检和大批量兼容性验证但不太适合日常迭代的反复调试——原因是环境在远端发现问题后的日志、抓包、录屏获取链路较长定位效率低于本地自建环境。一个可落地的组合是日常开发验证用客户端模拟专项弱网回归用ATC或Linux网关发布前用云真机平台做跨地域随机抽检。下面这张表格汇总了几类方案的差异方便团队按自己的条件选型方案实现层级可模拟参数适用场景成本iOS Network Link Conditioner客户端带宽、延迟、丢包iOS真机日常验证免费Charles/Fiddler限速HTTP代理层带宽、延迟、丢包Fiddler较弱HTTP接口弱网验证需授权ATC热点网关/链路层带宽、丢包、延迟、抖动逐连接控制真实设备专项弱网回归免费需Linux设备Linux tc/netem网卡出口延迟、抖动、丢包、带宽服务端联调、环境模拟免费云真机平台云端网关/真实线路预设部分自定义发布前跨地域抽检按量付费3. 弱网络用例设计不能只把网速调慢点就开测环境搭好后真正的难点来了测什么、怎么测、预期是什么。这一节讲的都是我在项目中沉淀下来的用例设计方法可以直接抄。3.1 先定义网络档位而不是随机调参数测试团队内部如果没有统一的弱网档位定义那大家各测各的今天限100kbps明天限300kbps出问题后谁也说不清是在什么网络条件下发现的。我建议团队内部维护一张网络档位表作为弱网测试的公共基准档位下行带宽上行带宽延迟丢包抖动模拟场景无网络00-100%-断网、飞行模式极弱网50kbps30kbps800ms20%200ms电梯、偏远地区弱信号弱网300kbps100kbps300ms10%50ms地铁中、通勤高峰不稳定网500kbps200kbps200ms5%300ms移动中频繁切换基站高延迟1Mbps500kbps800ms0%10ms跨地域远距离访问网络切换Wi-Fi切4G、4G切无网络----进出电梯、进出隧道档位表的意义有两个一是让测试过程可复现问题回归时有统一的网络条件二是推动产品和开发用同一套语言讨论弱网下到底要支持到什么程度。上面这些参数都是基于真实网络环境采集后粗略归一化的不同业务可以调整但一旦定了建议一个迭代周期内不要随意改动。3.2 核心业务场景清单与关注点弱网用例设计不是把所有功能都过一遍而是要挑出网络状态敏感的业务场景重点验证。根据我的经验下面这些场景基本覆盖了90%的弱网测试价值启动与初始化App冷启动时拉取配置、广告、版本更新检查。弱网下最容易出现启动白屏和启动耗时过长。登录与注册登录请求超时、验证码获取失败、登录态在弱网切换时失效。这是用户卡在第一步的典型场景。列表与详情下拉刷新、分页加载、图片懒加载。重点看列表是否卡在加载态、图文混排是否错位、图片是否长时间占位。上传与下载上传图片/视频失败的提示、断点续传是否生效、下载完成的文件能否正常打开。交易与支付下单、支付回调、订单状态。核心关注数据一致性——用户付了钱是否可能被多扣、少扣或状态迟迟不更新。音视频与IM直播首帧时间、播放是否卡顿、音频是否断续、消息收发延迟、离线消息重拉。地图与定位定位超时、地图瓦片加载失败、离线地图是否可用。这些场景有一个共同点它们都需要实时性和准确性。只对用户展示静态内容的页面比如纯文本协议页在弱网下不会出大问题但涉及网络通信和状态变更的功能几乎都要在弱网下重点验证。3.3 三种执行方式人工探索、脚本回放、接口级验证弱网用例执行不能只靠一种方式。我常用的组合是人工探索式、脚本回放式、接口级验证三者交替使用。人工探索式最适合发现体验类问题在开启弱网的设备上自由操作重点观察加载提示、错位、卡顿、白屏、按钮可点击性。这类问题自动化很难捕捉但正是用户骂声最大的来源。执行时可以配合录屏方便后续给开发看现场。脚本回放式适合做回归用Monkey或UI自动化脚本在弱网环境下跑核心链路自动收集崩溃、ANR、关键页面停留时间等指标。注意脚本本身要处理弱网下的等待慢不能把网络慢导致的加载超时误判为用例失败。接口级验证关注网络通信层本身用Charles或netem对特定接口注入延迟和丢包验证超时时间、重试次数、失败后的降级逻辑是否符合预期。这一层不需要真实界面执行快适合集成到CI里做每天的健康检查。3.4 一个可以直接套用的用例模板这是我个人用了很久的弱网用例模板核心是前置网络条件必须写清楚项目内容用例编号WC-P0-001网络档位弱网下行300kbps延迟300ms丢包10%抖动50ms前置条件已登录账号首页有缓存数据测试步骤1. 断网 2. 打开App 3. 观察首页表现 4. 等待3秒 5. 恢复网络 6. 下拉刷新预期结果断网打开时展示缓存数据并提示当前网络不可用恢复网络后下拉刷新成功且数据更新全程无白屏、无闪退实际结果填写辅助材料录屏文件、系统日志、网络参数截图模板的重点在于预期结果必须覆盖三个方面功能是否正确、数据是否一致、提示是否友好。缺了任何一项用例都不算完整。4. 弱网下踩过的坑典型问题与排查链路复盘这部分是干货中的干货我把这些年真实遇到过的弱网问题整理成五个典型类型按现象-排查链路-根因-建议的结构复盘希望能帮你在测试中少走弯路。4.1 超时时间拍脑袋用户盯着白屏等十五秒现象某个页面接口平均耗时2秒但弱网下用户反馈等了十几秒才提示失败。排查链路抓包后看到接口实际在3秒左右就返回了错误但页面一直转圈到10秒后才显示失败。怀疑是HTTP客户端超时配置问题翻代码发现项目里的超时时间统一设置成了30秒而且没有区分接口类型和网络状态。根因超时时间过于宽松看似稳妥实则让用户在弱网下白等很久体验极差。建议对超时做分级管理。核心接口短超时比如3-5秒快速失败并给予提示数据初始化类接口稍长10秒最理想的情况是超时时间支持服务端动态下发弱网时客户端可以主动缩短等待快速给用户一个可操作的反馈而不是让用户面对一个还在转的页面不知所措。4.2 重试机制引发的重复下单与服务器压力现象弱网环境下用户提交订单界面提示网络异常请重试用户点了两次结果产生了三笔订单。排查链路先看客户端日志发现第一次下单请求实际已成功到达服务端但服务端响应在小带宽下超时了客户端判定失败后触发自动重试再看用户操作日志超时提示出现后用户手动又提交了一次最后查服务端订单日志三笔订单的业务订单号各不相同说明幂等键没有生效。根因客户端重试没有退避策略服务端幂等键没有约束同一个请求的重放双重因素叠加导致重复下单。建议第一请求应携带全局唯一幂等键服务端对同一幂等键的重复请求直接返回已有结果第二客户端自动重试必须做退避不能瞬间连续发多次第三界面响应提交中时禁止用户再次点击弱网下尤其要防重复提交。另外补充一个更深层次的教训多个城市的弱网用户如果同时触发自动重试会造成所谓的重试风暴摇一摇就能把网关打挂。建议在客户端做指数退避例如第1次1秒、第2次2秒、第4次4秒最多5次并在服务端做基于来源IP和账号的限流这道防线必须有。4.3 断网后白屏无提示把网络错误当产品bug现象用户断网时打开App首页白屏下拉刷新也没有任何反馈很多用户第一反应是App崩了直接卸载。排查链路在赋值弱网环境下打开App确实白屏用抓包工具看网络请求已经失败但界面没有捕获到错误状态网络库的错误回调被上层吞掉了没有触发任何UI提示。根因项目缺少统一的网络状态监听和全局错误态处理。页面只处理了成功分支失败分支是空的自然白屏。建议客户端网络层应该统一封装所有请求必经同一个成功/失败回调入口失败回调里统一处理错误提示重试按钮。至少要保证页面加载失败时有明确的文案告诉用户发生了什么并且给一个能点的重试入口。建议在页面骨架加载阶段就预留错误态和空态视图而不是等代码里每处单独写。这个改造做完后类似白屏问题能一次性减少80%以上。4.4 缓存策略与数据一致性弱网下看到昨天的价格现象弱网下用户打开商品详情页价格显示的是昨天的价格但下单后却是按新价格扣款用户投诉价格欺诈。排查链路抓包发现商品详情接口在弱网下没有发起网络请求而是直接走了本地缓存再看缓存策略价格字段和商品名称、图片放在同一个缓存文件里缓存有效期长达24小时。弱网时请求失败客户端走缓存兜底但兜底数据没有标识非实时。根因缓存策略没有区分动态数据和静态数据。价格、库存这类强一致性数据不应该被长时间缓存即便在弱网下走了缓存也必须告知用户当前数据可能不是最新的。建议测试人员在做弱网用例设计时要把数据一致性作为独立断言来写。具体做法弱网下走缓存必须有提示标识服务端在响应头里带版本号缓存数据和最新版本号的差异超过阈值时必须请求新数据对价格、库存、余额这类数据建议禁止客户端缓存或控制在极短时间内如30秒。4.5 网络切换时连接断了不重连长连接全部失效现象用户在地铁里从Wi-Fi切到4GApp里的消息列表停在原地新消息收不到但也没有任何异常提示。排查链路模拟Wi-Fi切4G抓包发现TCP连接在切换时全部断掉客户端未触发重连再翻消息SDK日志发现重连逻辑只在App冷启动时执行网络切换后没有监听回调导致长连接不再进行任何重建。根因客户端没有监听网络状态变化事件或者监听了但没有执行重连动作。这是移动端非常普遍的长连接通病。建议网络库必须监听系统网络变化广播/回调检测到网络变化后延迟一段时间比如1-2秒等待网络稳定自动重建长连接重连要做退避不能用固定频率不断尝试测试时把Wi-Fi切4G、4G切无信号、无信号恢复4G作为固定用例纳入弱网专项中自动化执行而不是每次都靠手工验证。5. 把弱网测试落进迭代优先级、标准和CI实践前面讲的是怎么测、测什么最后这块讲讲怎么让弱网测试真正在迭代中持续产生价值。很多团队做过一次弱网测试出了报告就完事了下次发版之前基本忘干净。问题就出在没有把弱网测试的优先级、通过标准和触发机制固化下来。5.1 弱网测试优先级排序不是所有功能都值得测弱网用例也需要分优先级不能一锅端。我习惯用风险矩阵来排功能对网络实时性的依赖程度越高、产生资损或数据错乱的风险越大优先级就越高。具体来说P0登录、支付、下单、音视频直播首帧、IM消息收发。这些功能出了问题就是资损或核心体验受损必须每个迭代在弱网下执行一遍。P1列表刷新、分页加载、上传下载、地图定位。属于日常高频功能弱网下体验影响明显建议每个迭代执行一次关键路径。P2活动页、分享、个人资料编辑等低频或非核心功能可以放慢节奏每两到三个迭代抽检一次。P0用例要求全量人工加自动化覆盖P1靠自动化覆盖加抽测P2做定向抽查。这个排序不是固定的产品侧某个功能做重点推广时该功能的弱网优先级至少要提到P1。5.2 弱网标准制定从拍脑袋到可量化的验收门槛弱网测试最怕发现一堆问题但说不清到底哪些必须修才能发布。我建议提前和产品、开发一起定一份可量化的弱网验收标准白纸黑字写进需求验收清单里。下面是一份参考门槛指标弱网档位下的要求核心链路接口成功率不低于99.5%允许重试后成功用户可感知卡顿无ANR、无崩溃、无白屏/黑屏超过3秒操作响应反馈点击后1.5秒内必须出现loading或进度反馈资金与订单不允许出现重复扣款、重复下单、状态永久不一致断网恢复恢复网络后30秒内核心功能可恢复使用数据最终一致这些标准看起来严格但都是可以做到的。关键是标准要让开发和产品认可而不是测试单方面拍脑袋。我当时的做法是拿三个月的线上真实弱网数据做参考再结合竞品体验把标准初稿抛给团队讨论最终达成一致的版本才生效。5.3 把弱网回归塞进CI怎么跑稳不吵架做自动化弱网回归时最大痛点是本地能过CI里天天误报。踩过很多坑后我总结出几条让弱网自动化稳定的原则环境要隔离。弱网测试建议用独立的环境和设备池不要和非弱网用例混着跑。因为弱网用例本身对环境网络状态要求苛刻一旦有别的任务抢带宽或干扰网关配置结果必然抖动。独立跑数据才有可信度。网络档位切换要脚本化。先用脚本把网络档位固定好再执行用例。以ATC为例可以直接用Web API先切换网络档位再调用自动化测试框架执行用例import requests PROFILES { weak: {down_bandwidth: 300, up_bandwidth: 100, latency: 300, packet_loss: 10}, extreme: {down_bandwidth: 50, up_bandwidth: 30, latency: 800, packet_loss: 20}, } def run_weak_network_smoke(): for name, params in PROFILES.items(): requests.post(ATC_API_URL /api/change_logical_channel, jsonparams) run_core_ui_cases(name) # 执行核心用例集 upload_logs_and_video(name) assert_no_crash_or_anr(name)关键点网络切换后要等待几秒让链路稳定再开始跑用例否则会在网络切换瞬间产生大量误报。触发策略上我建议核心弱网用例每天固定跑一次验证主干链路健康完整弱网回归放到版本提测后的测试周期里跑一次作为发布前的风险检查项。失败用例要自动收集录屏、系统日志、崩溃堆栈跟着报告一起推送不然开发定位要花很久合作体验会很差。5.4 弱网报告怎么写才有说服力弱网测试报告不建议只列一个通过率。一份有说服力的弱网测试报告至少要包含测试范围覆盖了哪些功能、哪些网络档位、关键问题清单问题描述、复现步骤、优先级、影响面、问题截图或录屏、网络参数截图、修复建议。要把弱网问题讲清楚让产品看到的是用户价值让开发看到的是可复现路径这样测试推动问题修复的效率才会高。我自己写报告的习惯是所有P0问题必须附带录屏所有P1问题必须附带抓包文件。有了录屏和抓包开发定位问题的速度会快非常多很多争论也能直接省掉。关于弱网测试如果团队刚起步找不到那么多硬件和平台可以先在平时功能测试时习惯性把手机Wi-Fi关掉用4G跑几个关键页面或者在真机上装个网络限速工具把带宽调到300kbps左右顺手试试核心链路。这个最低成本的随手测就能暴露相当比例的网络问题。等团队和流程都成熟了再把ATC或Linux网关的方案搭起来逐步把弱网用例自动化、纳入CI。从我在实际项目里的感受来说弱网测试不是一次性任务它本质上是产品对用户在真实世界使用体验的态度问题。愿意在实验室里多模拟一点不完美线上就能少一些明明没问题的客诉。