内测期间最常收到的反馈，往往不是「功能没做」，而是「打开就白屏」「转圈转半天」「点一下就卡住」。这类问题在办公室稳定的 Wi-Fi 下反复测都复现不了，测试用户一进电梯、一上地铁就出现了。
原因很直接：室内网络环境太好。网络异常不是偶发故障，而是一种需要主动构造的测试场景。本文给出可落地的检查清单。
为什么内测阶段必须补上网络异常测试
- 白屏与转圈大多发生在请求超时或失败之后，而代码里没有对应的提示与兜底。
- 开发与测试常在同一间办公室、同一条网络下工作，弱网问题天然被掩盖。
- 用户遇到卡住多半直接卸载应用，你连一条崩溃日志都收不到。
- 网络相关缺陷在内测阶段发现，要修的是提示与兜底；拖到正式发布，要修的就是口碑。
三种网络场景怎么模拟
- 限速与高延迟。用手机自带的网络限速开关或第三方工具压住带宽，观察首屏加载、图片列表与登录请求的表现。
- 弱信号反复抖动。走到信号只剩一两格的房间，或让手机在 Wi-Fi 与移动数据之间来回切换，重点看重复请求会不会造成重复提交。
- 完全断网与恢复。先断网打开应用，确认有没有离线提示；再恢复网络，观察应用能否自行重连，还是必须杀掉重来。
这三种场景各跑一遍，基本能覆盖大多数用户的真实处境。限速工具不必追求精确数值，关键是让开发者先在自己手机上体验一次卡顿，才知道用户抱怨的到底是什么。
每个场景要重点观察什么
- 加载状态：有没有明确的「加载中」提示，而不是一片空白。
- 失败反馈：请求超时后是否给出看得懂的文案，而不是原样抛出错误码。
- 超时配置：检查请求是否设置了
timeout，以及超时后是直接失败还是进入重试。 - 重试行为：手动重试是否可用，自动重试会不会带来重复下单、重复打卡这类副作用。
- 数据一致性：网络恢复后，本地缓存会不会盖掉服务端的新数据。
- 日志记录：请求失败的记录是否带上网络类型与耗时，方便事后定位。
- 加载时长：记录从点击到首屏可交互的耗时，作为后续优化的基线。
建议：把「有没有提示」和「有没有兜底」拆成两条独立用例来写。前者验证用户看得懂，后者验证数据不出错，两者都通过才算这条用例通过。
常见问题
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| 打开就是白屏 | 首屏请求失败后没有兜底界面 | 补加载失败态与重试入口 |
| 一直转圈不停 | 请求未设置超时时间 | 设置合理超时与取消机制 |
| 断网重连后数据错乱 | 本地缓存盖住了服务端数据 | 明确缓存优先级与失效策略 |
| 弱网下重复提交 | 自动重试未做幂等处理 | 增加请求去重或幂等键 |
| 测试用户说复现不了 | 双方网络环境差异大 | 统一用限速工具构造同一场景 |
网络异常测试不需要额外设备和预算，一条限速规则、一次断网就能开始。补完这一轮，再把安装包通过虾分发（https://xiafenfa.com）发给测试用户时，收回来的反馈就会从「打不开」变成真正有价值的细节描述。