网络已经恢复了，App 为什么还停在转圈？

打开列表，页面开始加载。网络短暂卡住，转圈持续了一会儿。等网络恢复，其他页面已经可以访问，眼前这一页却还在原地等。

退出再进，内容又出来了。

面对这种现象，只记录“弱网时加载失败”会漏掉后半段：条件恢复以后，原来的任务和页面有没有继续往下走？

下面围绕这个示例，整理一组恢复测试的方法。它关注的是请求和页面状态，不把软件模拟直接当成真实电梯或蜂窝切换的复刻。

网络可用了，旧任务也可能已经结束了

一次加载至少涉及三件事：网络能不能通信、请求处于什么状态、页面正在展示什么。

网络恢复时，旧请求可能还在等待，也可能已经超时失败。页面可能准备重试，也可能早已停止调度，只剩一个没有被清理的加载动画。

这些状态不会因为网络变好就自动变得一致。

图 1｜三层状态示意。恢复测试需要继续追踪请求和页面，不能只看网络条件是否恢复。

排查时，可以先沿着几个具体问题往下问：旧请求还在运行吗？有没有收到失败回调？谁负责下一次尝试？页面的加载状态由哪个任务结束？

Android 的网络回调提供的是网络及其能力变化。官方文档也提醒，不要在 onAvailable 中同步查询能力并假定结果可靠，应等待相应能力回调。

即使网络具有系统验证的互联网访问能力，也不能替某个业务接口确认成功。

因此，监听到网络变化以后，还需要回到当前业务状态决定下一步。页面已经离开、用户已经取消的任务，不应该只因网络恢复就再次启动。

中断发生的位置，要写进用例

同样是一小段网络不可达，发生在不同位置，问出来的问题也不同。

中断位置	恢复以后重点检查什么
刚进入页面	首次加载能否完成，失败时是否有可用入口
内容加载过程中	已有内容是否保留，后续结果是否正确合并
错误提示出现以后	自动或手动重试能否重新开始
用户离开页面以后	旧任务是否还会更新已经失效的页面

每次先选一个位置，不必把所有变化塞进同一轮。尤其是“请求已经超时”与“请求仍在等待”，应该分别覆盖，它们可能走完全不同的恢复路径。

操作时也要留一条正常对照。如果没有弱网时页面就会卡住，先把基础流程查清楚，否则网络参数会把原本的问题遮得更复杂。

用连续丢包观察反复中断

为了让短暂不可达的情况反复出现，可以设置一段连续丢包，再设置一段放行时间。

这里用我自己开发的「弱网管家」展示配置入口。上下行能够分别设置连续丢包时长和放行时长；同一方向的两项需要一起填写。

图 2｜Pixel 6 配置演示：上下行均填写丢包 3000 ms、放行 10000 ms。截图展示参数入口，并非一次恢复测试的结果。

例如先采用“丢包 3 秒、放行 10 秒”的探索性配置，观察列表在多次受阻之后能否继续加载。其他损伤项先关闭，协议范围与被测流量对应。

这里的“放行”只是结束这项连续丢包限制。原始网络的延迟、其他启用的限制以及服务端处理仍然存在，不能理解为整个网络突然变成理想状态。

也别把周期配置当成业务计时器。点击按钮后恰好过 3 秒开始丢包，并不是这张设置图能保证的事。测试记录应写实际操作和条件变化的位置；需要严格对齐业务节点时，应另用受控测试手段。

想观察一次恢复，可以在页面里切换条件

连续丢包适合观察反复受阻。如果只想看一次“受阻后恢复”，可以准备两个模板：一个施加目标损伤，另一个关闭这些损伤项，然后在操作过程中切换。

弱网管家的悬浮窗能够显示模板列表和参数面板，便于在被测页面上查看、切换条件。使用前需要开启相关选项，并授予系统悬浮窗权限。

图 3｜Pixel 6 的设置页。悬浮窗适合在业务操作过程中切换条件；图中同时可见抓包和报告开关。

为了让恢复前后的对照更清楚，可以继续保持工具运行，只切换网络参数。直接结束 VPN 测试可能同时改变连接环境，带来另一类需要解释的影响。

录屏时，把业务操作和模板切换一起留下。手动操作难以保证每轮精确到同一毫秒，但至少能回看中断落在哪个阶段，而不是只剩一句“我刚才好像断过网”。

如果自动恢复一直没有发生，再尝试手动重试，并分别记录这两种结果。用户主动刷新成功，不能直接记成“应用自动恢复成功”。

恢复成功，要落到页面行为上

只看内容最终出现，仍然可能漏掉问题。内容出现之前，用户也许已经点了几次重试；内容出现之后，列表可能重复追加了几份。

可以把通过条件拆得更具体。

加载会结束。 成功、失败或取消之后，页面进入一个明确状态。自动重试有等待预算，不能让一轮轮重试把转圈无限续下去。

已有内容不被无谓清空。 刷新失败时，能保留的旧内容可以继续展示，同时说明它的状态。涉及实时价格或权限的数据，需要按业务规则确认有效性。

重试不会叠出多个任务。 自动重试与用户点击重试同时发生时，是否重复请求、重复追加结果，要单独观察。

离开的页面能够结束工作。 用户已经返回上一级，旧页面恢复后不应突然弹出提示，也不应把迟到结果塞进新页面。

恢复时间可以记录，但通过阈值应来自产品要求和实际任务特点。大文件下载、普通列表和实时通话，不适合共用一个随手规定的秒数。

软件丢包与真实断网，仍然要分开测

数据包暂时不通时，系统网络可能始终处于连接状态。此时应用依靠超时、重试或连接检测处理问题，不一定收到与关闭 Wi-Fi 相同的回调。

这正是两类测试都值得保留的原因：一类检查“网络看似还连着，但请求走不动”；另一类检查真实的网络断开、切换和重新连接。

工具里的连续丢包可以帮助缩小问题范围，但无法替代真实设备在蜂窝网络切换、认证门户或弱信号环境中的观察。

完成一轮后，把条件、业务时机、恢复方式和页面最终状态放在同一条记录里。这样别人接手时，才知道该检查请求没有重试，还是重试完成后页面没有更新。

错误提示出现以后，再多看一段

弱网用例常常在错误提示出现时结束。对用户来说，麻烦可能才刚开始：网络已经能用了，他还得猜是继续等、点重试，还是退出重进。

下次测试加载失败时，先别马上结束。恢复条件，再做一次用户真正会做的操作，看看这页能不能自己走到一个说得清楚的结果。