做轻应用的弱网专项测试我遇到最多的问题不是“弱网怎么模拟”而是“到底要测哪些场景”。团队第一次立项时大家一起照着原生App的弱网用例抄了一份结果到了真实弱现场景里漏掉的全是轻应用特有的问题小程序首屏分包加载卡死、H5页面在弱网下的重复上报、轻量应用重试机制引发的请求风暴……这些才是弱网专项真正要盯的事情。这篇文章把我自己在实际项目中沉淀下来的轻应用弱网场景清单拆开讲清楚适合刚接手弱网测试的测试工程师也适合想补充专项用例的产品和研发同学。先给个大概框架我先讲轻应用弱网测试和原生App有什么本质差异再给一张完整的弱网参数和场景矩阵接着拆解轻应用业务场景里优先级最高的几个测试点然后说环境怎么搭、弱网参数怎么设最后聊聊我在现场弱网和实验室弱网都踩过的坑。1. 轻应用的弱网血统为什么不能直接照搬原生App用例1.1 轻应用依赖宿主环境一条请求的链路比你想的长轻应用不是独立跑在系统上的。无论是小程序、快应用还是H5页面它都寄生在某个宿主容器里。你要清楚一条网络请求从发起到最终成功中间经过了轻应用自身的业务代码、宿主容器的框架逻辑、系统网络协议栈、代理或Wi-Fi链路最后才到服务端。链路每多一层弱网下出问题的概率就多一分。举个例子用户在电梯里打开一个H5页面UI已经渲染出来但某个接口一直转圈。我们在实验室用同样的弱网参数复现发现接口迟迟不返回的原因不在服务端而是容器框架在弱网下对DNS解析有额外的超时逻辑请求在底层库就被挂住了。这个现象在原生App里基本碰不到但在轻应用里却是常态。所以做专项测试前第一件事是搞清楚轻应用代码跑在什么容器里、容器本身对网络请求做了什么拦截或者封装。否则后面测出来的弱网问题很可能一半是业务代码的锅一半是宿主容器的锅分不清就白测了。1.2 原生App那套用例为什么对不上原生App的弱网用例侧重什么呢最常见的是“网络断开后重新连上数据能不能恢复”“弱网下登录和支付事务是否一致”“后台推送是否准时”。这些当然也适用于轻应用但轻应用还有一个特殊性它往往是“用完即走”的形态用户不会长期留在页面上。这意味着弱网专项真正要关注的是“第一次打开能不能打开”“页面加载到一半网络变了会怎样”“用户等得不耐烦关掉页面后再进来是什么状态”。这些场景在原生App时代也有但轻应用因为包体小、启动频次高、生命周期短问题暴露得更频繁。我见过一个团队照搬原生App弱网用例花了大半天测登录、转账、消息同步结果上线后用户反馈最多的是首屏经常白屏、图片加载不出来。不是他们测错了而是优先级排错了。轻应用弱网测试的第一优先级永远是启动和首屏而不是那些深层次的业务事务。2. 弱网场景矩阵不止“没网”和“网慢”这两档2.1 四大网络劣化指标怎么理解很多刚入行的同学对弱网的理解就是“断网”和“网慢”然后模拟器里把网速调低跑一轮就算专项了。实际上弱网专项至少要覆盖四个独立指标它们组合起来就是很多种场景。我习惯把这四个指标单独列成一张表先看清各自影响什么再去谈组合。指标模拟方式轻应用主要影响带宽限制设置上下行速率如300kbps、1Mbps静态资源加载慢、图片分块到达、样式错乱首屏长时间不完整延迟增加固定增加往返时间如600ms、1500ms用户感知“点了没反应”、接口一直转圈、超时误判丢包设置丢包率如1%、3%、5%请求重传、耗时成倍增长、成功与失败结果不确定抖动延迟在高低区间波动如300ms到2000ms实时交互卡顿、长连接断开、消息延迟到达带宽限制场景里重点看低带宽比如300kbps到1Mbps模拟2G/3G网络导致的慢速加载。带宽低的时候页面如果不等资源加载完就渲染就会出现图片破碎、样式错乱。延迟只增加不丢包时请求最终能成功但用户感知是“点了没反应”“一直转圈”这里要关注交互反馈和超时时间的合理性。丢包对轻应用的伤害最大因为TCP遇到丢包会触发重传请求耗时可能成倍增长。强交互业务里丢包带来的后果是请求发出去了但响应超时用户再点触发重复提交。抖动主要影响实时性要求高的功能比如直播弹幕、在线客服、协同编辑。轻应用里如果用了WebSocket或者长轮询做实时通知抖动场景一定会暴露出消息延迟或连接被断开的问题。我会建议团队把四个指标在模拟工具里都预置一份然后分别为每条业务线选择组合。不需要把所有组合都跑一遍而是根据业务特点挑选表单提交多的看丢包首屏资源重的看低带宽实时交互多的看抖动。2.2 信号切换与网络降级轻应用最容易被忽略的场景除了参数劣化网络状态的变化过程也要测。用户在电梯里信号从满格变成一格、从4G切到3G、从Wi-Fi掉到蜂窝网络这些都是典型的“网络切换”场景。切换瞬间轻应用正在进行的请求可能被中断如果代码没有做重连或恢复处理页面就会卡死。实验室里可以用“飞行模式开关”模拟强断网但真实的切换往往是“软断网”网络看起来还有信号但请求发不出去或者超时特别久。这种场景下轻应用如果只监听“网络完全断开”这一个事件就会误判当前网络正常继续发请求白白消耗用户流量。另一个典型场景是Wi-Fi信号弱但没断开页面部分请求成功、部分失败资源加载一半。这个我在第5章还会单独讲。建议在用例设计时至少把以下四种切换场景覆盖掉Wi-Fi切蜂窝、4G切3G/2G、跨基站切换可以理解为地铁沿线那种信号漂移、网络在好与差之间反复横跳。2.3 组合场景真实弱网往往是“多个指标一起摔”单独模拟一个指标比较容易但真实环境从来不会这么客气。地铁里是低带宽高延迟丢包一起出现地下停车场是带宽低、延迟高、偶尔断连商场里的人流密集区则是高延迟高抖动。组合场景才能真正暴露代码里的防御逻辑是否完备。我一般的做法是先定义几个“标准恶劣场景”。用于回归的场景比如300kbps带宽800ms延迟2%丢包用于极限验证的场景比如100kbps带宽2000ms延迟5%丢包用于偶发问题的场景比如带宽正常但延迟抖动大1%丢包。然后把每个场景套到核心业务用例上跑基本一个应用的弱网水平就能摸出来了。这里有个容易犯的错组合参数设得太狠导致所有用例都失败反而看不出问题出在哪。建议第一轮先用“标准恶劣场景”把失败用例捞出来再逐步调整参数缩小到最小复现集合。这个过程也叫降参定位是弱网问题排查里比较实用的一招。3. 轻应用业务场景拆解这六个场景优先级最高3.1 冷启动与首屏资源加载弱网下的“第一道门”轻应用的使用习惯决定了用户不会给它太多耐心。冷启动到首屏可交互的时间在弱网下会明显拉长如果超过用户的容忍度用户直接划走后面功能再好也白搭。专项测试要具体测这些点首屏依赖的HTML/JS/CSS资源能不能在超时时间内加载完成资源是串行加载还是并行加载关键资源有没有做冗余和降级加载失败后有没有重试还是直接白屏页面在加载过程中有没有给出进度反馈或骨架屏。另外还要注意分包与懒加载小程序常见的分包机制在弱网下加载子包如果失败降级页面是否正常。这些用例要重点覆盖“弱网首次打开”和“正常网络已有缓存后进入弱网”两种状态结果可能完全不同。3.2 接口请求超时、重试与并发控制轻应用页面通常十几个接口并发发出弱网下最容易出现的问题是个别接口超时后页面逻辑卡死或者全部接口排着队等待最慢的那个首屏迟迟不完整。专项测试里我会重点验证三条。第一每个关键接口的超时时间是否合理是否与用户体验预期匹配。比如一个登录接口设了30秒超时在弱网下用户可能等不到30秒就走了不如快速失败并提示重试。第二重试机制是不是“傻瓜式重试”。弱网下接口失败率高如果代码在循环里立即重试就会在短时间内发起大量重复请求。正确的做法是限制重试次数加大重试间隔比如指数退避。这块抓包看请求时间线一眼就能看出有没有问题。第三并发数和优先级。页面同时发起20个请求弱网下会把本就紧张的带宽打满。要确认框架有没有做请求合并或优先级调度比如首屏必需接口优先图片请求让路。3.3 缓存与离线能力弱网下的“保命”方案轻应用相较原生App有一个优势部分依赖本地缓存即可完成首屏展示。但如果缓存策略写得不好弱网下反而会退化比如HTTP缓存被禁掉、本地存储读取失败、缓存过期时间设得太短导致每次打开都重新拉取全部资源。专项测试需要验证的缓存场景有弱网下是否走缓存而不是发请求缓存过期后恰好断网用户看到的是“空数据”还是“旧数据提示”离线包或预加载是否生效弱网下前端本地存储写入失败时是否有降级逻辑。这里我最想强调的是“失败后的恢复”缓存能解决弱网启动的问题但恢复网络之后页面能不能自动同步最新数据而不是一直用缓存里的旧数据。3.4 登录态与会话管理弱网下最容易埋雷登录态是轻应用里很不起眼但特别容易出问题的环节。弱网下token验证接口延迟可能导致页面已经渲染成“未登录”状态用户操作又被弹回登录页token过期后刷新接口失败用户被无限踢出登录接口超时后重复提交创建出重复会话。测试的时候我习惯把登录态相关场景单列一档弱网下冷启动检查登录态、登录接口超时、token刷新接口失败、弱网下登出再登录、弱网下切换账号。这些用例用不太复杂的参数比如500ms延迟加2%丢包就能跑出来却往往能提前发现最崩溃的用户体验。3.5 上传下载与多媒体弱网下的“重灾区”轻应用经常有图片上传、音视频上传、文件下载这类功能。弱网下这类功能的用户体验最差进度条卡住、上传到一半断掉、文件下载损坏。专项测试必须覆盖断点续传断网重连后进度是否保留是否有时间超时限制导致大文件永远传不完失败后重试是重新开始还是从断点继续。多媒体加载也要单列图片懒加载在低带宽下是否正常大图在弱网下是否给了缩略图降级视频是边下边播还是必须全量缓存。这里我经常用的用例是把带宽调到200kbps以下然后把一个2MB的图片拖进页面看用户要等多久以及等待过程中页面能不能正常操作。3.6 交互反馈与体验降级弱网下的“体面”最后一个高优先级场景是用户弱网下的操作反馈。弱网不代表用户什么都不做恰恰相反用户会反复点击、下拉刷新、滑动。如果按钮没有防重复提交弱网下用户点两次就会产生两条订单如果加载失败只给一个无限转圈用户会以为卡死了直接杀掉重开体验非常差。这里的测试点是按钮点击后应立即置灰或显示loading并限制重复触发请求失败后应给出明确的错误提示并引导用户重试或返回下拉刷新在弱网下应支持取消和超时结束页面断网时是否有全局弱网提示而不是让用户在某些毫无反应的界面里干等。4. 搭建轻应用弱网专项环境代理、系统工具与真实网络4.1 几种弱网模拟方案的取舍做专项测试环境搭建是绕不开的一步。我按常见度排个序方便团队按资源选型。系统自带工具比如移动系统开发者选项里的网络调节功能。上手最快但仅支持系统全局限制不容易同时模拟“某个域名慢、其他域名快”的精细化策略而且对真机依赖比较强。抓包代理工具最常用的一类是PC端代理加手机走代理。可以在代理里给特定域名设置带宽、延迟、丢包同时还能抓包看请求明细是做场景细化观察的最佳选择。缺点是需要配置证书部分轻应用容器对代理的信任策略不同可能会直接不走代理这时要检查容器是否允许代理。网络损伤仪或硬件设备能模拟比较真实的物理链路延迟和丢包控制精确但成本高、配置麻烦一般用在专项大版本或线上问题复现。云真机平台的弱网环境很多真机平台已经支持一键选择弱网档位。胜在省事弱网参数覆盖广适合快速跑回归缺点是自定义参数不够精细抓包和日志获取链路比较长。真机场地实测去地下车库、电梯、地铁沿线拿着真机实测。这是所有方案里最能发现问题的一个我在第5章会讲为什么它不可替代。4.2 代理工具弱网配置的三个关键细节如果你选择了抓包代理工具我提几个配置时容易踩坑的细节。第一务必只对目标业务域名启用弱网不要全局限制。轻应用容器本身可能会访问一些静态资源域名全局限速会把宿主框架的请求也拖慢让你分不清是业务问题还是环境问题。第二代理模式下务必设置好过滤规则把CDN域名、图片域名、接口域名分开看。弱网专项最需要看的是请求时序分不清域名就很难判断是资源加载慢还是接口超时。第三注意代理对WebSocket的影响。部分代理工具对WebSocket的延迟和丢包模拟并不准确如果你的轻应用用了长连接建议在系统工具或真机场地里额外补测WebSocket场景避免被代理工具的模拟误差误导。4.3 数据采集哪些指标才值得记录弱网专项测试如果没有量化数据最后就变成“我觉得挺卡”。所以执行用例时要固定采集这些指标。首屏时间从用户操作到首屏基础设施可交互的时间弱网下记录多次取中位数。接口耗时分位值同一个接口在弱网下请求耗时的P50、P90、P95对比服务端的处理时间分清是网络耗时还是服务端慢。请求成功率与错误码分布具体到拿到哪些错误码是超时、连接被拒、还是DNS解析失败。沿着错误码分布去翻日志定位会快很多。客户端异常日志页面脚本报错、崩溃、原生宿主侧的加载失败日志都要一并收集。资源加载耗时明细按域名、按资源类型拆分低带宽下哪类资源最耗时一目了然。采集方式上前端性能监控、服务端访问日志、客户端日志三端联动是最好的。如果暂时没有这类平台退而求其次可以用抓包工具的导出列表加客户端日志手动对齐虽然费时间但也能把问题定位到具体请求。5. 现场弱网与实验室弱网的差异几种最容易翻车的异常5.1 弱网下的重复提交与请求风暴先说我翻过最狠的一次车。某个轻应用在弱网下用轮询方式获取任务状态轮询间隔2秒。实测发现每次轮询超时后代码不是跳过继续等下一轮而是立即再发一个请求。于是弱网下一分钟里客户端发出了一两百个请求服务端被打到报警。实验室里不容易复现是因为实验室的弱网参数比较恒定超时的请求数量有限但在真实弱网环境里延迟和丢包忽高忽低触发重试的概率大大增加。解决思路是重试要有上限轮询频率要固定请求要加并发锁。作为测试你要做的就是专门设计“连续超时加快速重试”的场景来逼出这类代码。5.2 半加载状态与页面错乱真实弱网里请求失败并不是“所有请求一起失败”而是部分请求成功、部分失败、部分一直在等。比如一个页面需要图片、列表、弹窗三个资源同时齐了才完整结果图片成功了、列表超时了页面就卡在一个半吊子状态用户只能杀掉应用重进。这种问题在实验室里用“全量断网”模拟不出来因为全量断网时所有请求都失败反而容易触发统一的错误处理。但在弱网切换或部分域名故障时就会出现这种“半好半坏”状态。测试需要做的是专门构造部分请求成功的场景比如给不同域名设置不同的延迟和丢包来验证页面有没有“部分加载失败”的兜底逻辑。5.3 状态不同步与脏数据最后一个高发异常是弱网下的数据不同步。用户在弱网里操作了某个状态变更页面显示成功但实际请求超时了切回正常网络后刷新数据又变了回去。如果这个操作涉及金额、库存、订单状态用户端的认知混乱会非常严重。专项测试需要覆盖“弱网操作、网络恢复、重新拉取数据”的全链路重点验证操作失败后客户端有没有回滚网络恢复后有没有主动同步本地与服务端的数据冲突时以哪边为准。这类问题往往不是客户端单侧能修的需要服务端配合做幂等和状态机约束。测的时候最好前后端一起联调别只盯着客户端看。5.4 为什么真实场地实测不可替代实验室能复现大部分弱网问题但有些坑只有真实场地才踩得到。真实弱网环境有信号漂移、基站切换、地下空间里网络频繁重建这些变化是“不可预测的、动态的”用固定参数很难精确模拟。我的建议是每个版本做完实验室弱网专项之后挑几个核心业务场景去地下车库、电梯、地铁沿线做一轮冒烟式真机抽检单程时间控制在半小时以内记录现场网络信号强度与页面表现。这部分用例不求全只求覆盖“首屏打开、登录、列表加载、提交操作”这几条最高频路径。真机场地实测虽然组织麻烦但经常能撞见实验室永远模拟不出来的偶发问题。这也是弱网专项测试闭环里我认为最值得坚持的一步。最后我把所有场景整理成一份用例清单包含参数、场景、业务点、预期结果和风险点作为后续每次发版的回归基线。我就是拿着这份清单反复迭代才把轻应用弱网专项从“凭感觉”进化到“有章法”。