“支持弱网”不是完整的采购条件。机器人可能在 Wi-Fi 覆盖边缘移动，可能连接拥挤的公共网络，也可能在不同网络之间切换。每种情况都需要明确测试输入、用户可见结果和恢复过程，才能比较不同 RTC 方案。
把弱网拆成独立变量
先建立正常网络下的基线，再分别改变可用上行带宽、下行带宽、丢包、时延和抖动。一次改变一个变量，有助于找出触发声音中断或画面停顿的原因。之后再组合接近真实现场的条件，避免只拿极端实验结果推断所有场景。
上下行需要分别测试。机器人上传视频受限，与操作者接收受限，可能表现相近，但排查位置不同。每轮记录测试工具、配置、持续时间、设备版本和网络方向，让另一位工程师能够重做。
同时观察通话与任务完成
数据层记录呼叫成功、首个声音或画面出现时间、卡顿和重连过程；体验层记录指令是否听清、现场画面是否足够新、双方是否需要重复沟通。浏览器端的 getStats 可提供连接统计，设备端则需确认 SDK 提供哪些指标。
不要把网络往返时间当成完整音视频时延。需要测端到端体验时，应设计同步可观察的音画测试，并注明测量方法与误差来源。比较方案时保持同样的设备、任务和参数。
恢复是否可理解，同样重要
模拟短时断网、网络地址变化和重新联网，检查用户看到的提示、恢复后是否仍在原会话、是否出现重复播放或单向无声。恢复策略还应避免无限重试持续消耗电量。
对远程查看类场景，可以与产品团队讨论音频优先或降低视频质量。涉及机器人运动时，控制系统需要自行定义断连后的行为；音视频连接正常不能单独证明控制链路满足要求。
将结果写成可比较的结论
报告应区分“已通过的条件”“仍存在的问题”和“未测试的组合”，同时保留异常样本。不要将某次通过写成所有网络下的保证。
以上是通用测试框架，具体阈值与降级策略应依据项目任务确定，并通过真实网络复测。咨询机器人 RTC 方案时，提供目标市场、网络类型和最影响业务的故障现象，有助于确定验证范围。
参考：MDN getStats 文档，说明连接统计接口；本文弱网矩阵和任务标准是项目评估建议。