这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 单页 mock 无法覆盖权限、生命周期和真实 WebRTC 时序。测试架应把 A、B 作为独立身份与存储，统一关联一个 scenarioId 并同时保存状态轨迹。
测试要把状态机、故障注入和真实浏览器组合起来。确定性用例守住已知契约，随机时序寻找竞态，失败 seed 和两端轨迹必须保存成永久回归。
先把实现决策说清楚
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 每个场景声明前置身份、动作、双方断言、资源清理与超时；浏览器上下文隔离 IndexedDB 和权限，必要时使用真实两进程。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“双浏览器 E2E 测试架：真正验证 A 与 B 的完整闭环”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 只断言 A 显示“已发送”会漏掉 B 收到两次通知；复用同一 context 又会共享存储并掩盖身份和刷新问题。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
上线前怎样验证
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 对每项功能跑建立、正常完成、一方刷新、双方刷新、一方取消、断网恢复和关闭页面，双方状态与资源都必须收敛。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。