打开列表页面开始加载。网络短暂卡住转圈持续了一会儿。等网络恢复其他页面已经可以访问眼前这一页却还在原地等。退出再进内容又出来了。面对这种现象只记录“弱网时加载失败”会漏掉后半段条件恢复以后原来的任务和页面有没有继续往下走下面围绕这个示例整理一组恢复测试的方法。它关注的是请求和页面状态不把软件模拟直接当成真实电梯或蜂窝切换的复刻。网络可用了旧任务也可能已经结束了一次加载至少涉及三件事网络能不能通信、请求处于什么状态、页面正在展示什么。网络恢复时旧请求可能还在等待也可能已经超时失败。页面可能准备重试也可能早已停止调度只剩一个没有被清理的加载动画。这些状态不会因为网络变好就自动变得一致。图 1三层状态示意。恢复测试需要继续追踪请求和页面不能只看网络条件是否恢复。排查时可以先沿着几个具体问题往下问旧请求还在运行吗有没有收到失败回调谁负责下一次尝试页面的加载状态由哪个任务结束Android 的网络回调提供的是网络及其能力变化。官方文档也提醒不要在 onAvailable 中同步查询能力并假定结果可靠应等待相应能力回调。即使网络具有系统验证的互联网访问能力也不能替某个业务接口确认成功。因此监听到网络变化以后还需要回到当前业务状态决定下一步。页面已经离开、用户已经取消的任务不应该只因网络恢复就再次启动。中断发生的位置要写进用例同样是一小段网络不可达发生在不同位置问出来的问题也不同。中断位置恢复以后重点检查什么刚进入页面首次加载能否完成失败时是否有可用入口内容加载过程中已有内容是否保留后续结果是否正确合并错误提示出现以后自动或手动重试能否重新开始用户离开页面以后旧任务是否还会更新已经失效的页面每次先选一个位置不必把所有变化塞进同一轮。尤其是“请求已经超时”与“请求仍在等待”应该分别覆盖它们可能走完全不同的恢复路径。操作时也要留一条正常对照。如果没有弱网时页面就会卡住先把基础流程查清楚否则网络参数会把原本的问题遮得更复杂。用连续丢包观察反复中断为了让短暂不可达的情况反复出现可以设置一段连续丢包再设置一段放行时间。这里用我自己开发的「弱网管家」展示配置入口。上下行能够分别设置连续丢包时长和放行时长同一方向的两项需要一起填写。图 2Pixel 6 配置演示上下行均填写丢包 3000 ms、放行 10000 ms。截图展示参数入口并非一次恢复测试的结果。例如先采用“丢包 3 秒、放行 10 秒”的探索性配置观察列表在多次受阻之后能否继续加载。其他损伤项先关闭协议范围与被测流量对应。这里的“放行”只是结束这项连续丢包限制。原始网络的延迟、其他启用的限制以及服务端处理仍然存在不能理解为整个网络突然变成理想状态。也别把周期配置当成业务计时器。点击按钮后恰好过 3 秒开始丢包并不是这张设置图能保证的事。测试记录应写实际操作和条件变化的位置需要严格对齐业务节点时应另用受控测试手段。想观察一次恢复可以在页面里切换条件连续丢包适合观察反复受阻。如果只想看一次“受阻后恢复”可以准备两个模板一个施加目标损伤另一个关闭这些损伤项然后在操作过程中切换。弱网管家的悬浮窗能够显示模板列表和参数面板便于在被测页面上查看、切换条件。使用前需要开启相关选项并授予系统悬浮窗权限。图 3Pixel 6 的设置页。悬浮窗适合在业务操作过程中切换条件图中同时可见抓包和报告开关。为了让恢复前后的对照更清楚可以继续保持工具运行只切换网络参数。直接结束 VPN 测试可能同时改变连接环境带来另一类需要解释的影响。录屏时把业务操作和模板切换一起留下。手动操作难以保证每轮精确到同一毫秒但至少能回看中断落在哪个阶段而不是只剩一句“我刚才好像断过网”。如果自动恢复一直没有发生再尝试手动重试并分别记录这两种结果。用户主动刷新成功不能直接记成“应用自动恢复成功”。恢复成功要落到页面行为上只看内容最终出现仍然可能漏掉问题。内容出现之前用户也许已经点了几次重试内容出现之后列表可能重复追加了几份。可以把通过条件拆得更具体。加载会结束。成功、失败或取消之后页面进入一个明确状态。自动重试有等待预算不能让一轮轮重试把转圈无限续下去。已有内容不被无谓清空。刷新失败时能保留的旧内容可以继续展示同时说明它的状态。涉及实时价格或权限的数据需要按业务规则确认有效性。重试不会叠出多个任务。自动重试与用户点击重试同时发生时是否重复请求、重复追加结果要单独观察。离开的页面能够结束工作。用户已经返回上一级旧页面恢复后不应突然弹出提示也不应把迟到结果塞进新页面。恢复时间可以记录但通过阈值应来自产品要求和实际任务特点。大文件下载、普通列表和实时通话不适合共用一个随手规定的秒数。软件丢包与真实断网仍然要分开测数据包暂时不通时系统网络可能始终处于连接状态。此时应用依靠超时、重试或连接检测处理问题不一定收到与关闭 Wi-Fi 相同的回调。这正是两类测试都值得保留的原因一类检查“网络看似还连着但请求走不动”另一类检查真实的网络断开、切换和重新连接。工具里的连续丢包可以帮助缩小问题范围但无法替代真实设备在蜂窝网络切换、认证门户或弱信号环境中的观察。完成一轮后把条件、业务时机、恢复方式和页面最终状态放在同一条记录里。这样别人接手时才知道该检查请求没有重试还是重试完成后页面没有更新。错误提示出现以后再多看一段弱网用例常常在错误提示出现时结束。对用户来说麻烦可能才刚开始网络已经能用了他还得猜是继续等、点重试还是退出重进。下次测试加载失败时先别马上结束。恢复条件再做一次用户真正会做的操作看看这页能不能自己走到一个说得清楚的结果。
打开列表页面开始加载。网络短暂卡住转圈持续了一会儿。等网络恢复其他页面已经可以访问眼前这一页却还在原地等。退出再进内容又出来了。面对这种现象只记录“弱网时加载失败”会漏掉后半段条件恢复以后原来的任务和页面有没有继续往下走下面围绕这个示例整理一组恢复测试的方法。它关注的是请求和页面状态不把软件模拟直接当成真实电梯或蜂窝切换的复刻。网络可用了旧任务也可能已经结束了一次加载至少涉及三件事网络能不能通信、请求处于什么状态、页面正在展示什么。网络恢复时旧请求可能还在等待也可能已经超时失败。页面可能准备重试也可能早已停止调度只剩一个没有被清理的加载动画。这些状态不会因为网络变好就自动变得一致。图 1三层状态示意。恢复测试需要继续追踪请求和页面不能只看网络条件是否恢复。排查时可以先沿着几个具体问题往下问旧请求还在运行吗有没有收到失败回调谁负责下一次尝试页面的加载状态由哪个任务结束Android 的网络回调提供的是网络及其能力变化。官方文档也提醒不要在 onAvailable 中同步查询能力并假定结果可靠应等待相应能力回调。即使网络具有系统验证的互联网访问能力也不能替某个业务接口确认成功。因此监听到网络变化以后还需要回到当前业务状态决定下一步。页面已经离开、用户已经取消的任务不应该只因网络恢复就再次启动。中断发生的位置要写进用例同样是一小段网络不可达发生在不同位置问出来的问题也不同。中断位置恢复以后重点检查什么刚进入页面首次加载能否完成失败时是否有可用入口内容加载过程中已有内容是否保留后续结果是否正确合并错误提示出现以后自动或手动重试能否重新开始用户离开页面以后旧任务是否还会更新已经失效的页面每次先选一个位置不必把所有变化塞进同一轮。尤其是“请求已经超时”与“请求仍在等待”应该分别覆盖它们可能走完全不同的恢复路径。操作时也要留一条正常对照。如果没有弱网时页面就会卡住先把基础流程查清楚否则网络参数会把原本的问题遮得更复杂。用连续丢包观察反复中断为了让短暂不可达的情况反复出现可以设置一段连续丢包再设置一段放行时间。这里用我自己开发的「弱网管家」展示配置入口。上下行能够分别设置连续丢包时长和放行时长同一方向的两项需要一起填写。图 2Pixel 6 配置演示上下行均填写丢包 3000 ms、放行 10000 ms。截图展示参数入口并非一次恢复测试的结果。例如先采用“丢包 3 秒、放行 10 秒”的探索性配置观察列表在多次受阻之后能否继续加载。其他损伤项先关闭协议范围与被测流量对应。这里的“放行”只是结束这项连续丢包限制。原始网络的延迟、其他启用的限制以及服务端处理仍然存在不能理解为整个网络突然变成理想状态。也别把周期配置当成业务计时器。点击按钮后恰好过 3 秒开始丢包并不是这张设置图能保证的事。测试记录应写实际操作和条件变化的位置需要严格对齐业务节点时应另用受控测试手段。想观察一次恢复可以在页面里切换条件连续丢包适合观察反复受阻。如果只想看一次“受阻后恢复”可以准备两个模板一个施加目标损伤另一个关闭这些损伤项然后在操作过程中切换。弱网管家的悬浮窗能够显示模板列表和参数面板便于在被测页面上查看、切换条件。使用前需要开启相关选项并授予系统悬浮窗权限。图 3Pixel 6 的设置页。悬浮窗适合在业务操作过程中切换条件图中同时可见抓包和报告开关。为了让恢复前后的对照更清楚可以继续保持工具运行只切换网络参数。直接结束 VPN 测试可能同时改变连接环境带来另一类需要解释的影响。录屏时把业务操作和模板切换一起留下。手动操作难以保证每轮精确到同一毫秒但至少能回看中断落在哪个阶段而不是只剩一句“我刚才好像断过网”。如果自动恢复一直没有发生再尝试手动重试并分别记录这两种结果。用户主动刷新成功不能直接记成“应用自动恢复成功”。恢复成功要落到页面行为上只看内容最终出现仍然可能漏掉问题。内容出现之前用户也许已经点了几次重试内容出现之后列表可能重复追加了几份。可以把通过条件拆得更具体。加载会结束。成功、失败或取消之后页面进入一个明确状态。自动重试有等待预算不能让一轮轮重试把转圈无限续下去。已有内容不被无谓清空。刷新失败时能保留的旧内容可以继续展示同时说明它的状态。涉及实时价格或权限的数据需要按业务规则确认有效性。重试不会叠出多个任务。自动重试与用户点击重试同时发生时是否重复请求、重复追加结果要单独观察。离开的页面能够结束工作。用户已经返回上一级旧页面恢复后不应突然弹出提示也不应把迟到结果塞进新页面。恢复时间可以记录但通过阈值应来自产品要求和实际任务特点。大文件下载、普通列表和实时通话不适合共用一个随手规定的秒数。软件丢包与真实断网仍然要分开测数据包暂时不通时系统网络可能始终处于连接状态。此时应用依靠超时、重试或连接检测处理问题不一定收到与关闭 Wi-Fi 相同的回调。这正是两类测试都值得保留的原因一类检查“网络看似还连着但请求走不动”另一类检查真实的网络断开、切换和重新连接。工具里的连续丢包可以帮助缩小问题范围但无法替代真实设备在蜂窝网络切换、认证门户或弱信号环境中的观察。完成一轮后把条件、业务时机、恢复方式和页面最终状态放在同一条记录里。这样别人接手时才知道该检查请求没有重试还是重试完成后页面没有更新。错误提示出现以后再多看一段弱网用例常常在错误提示出现时结束。对用户来说麻烦可能才刚开始网络已经能用了他还得猜是继续等、点重试还是退出重进。下次测试加载失败时先别马上结束。恢复条件再做一次用户真正会做的操作看看这页能不能自己走到一个说得清楚的结果。
