解决什么问题
FRER 的目标是故障连续性，所以不能只在正常情况下测试。你必须真的制造故障，观察副本路径是否接管，deadline 是否仍满足，重复消除是否正确，恢复后是否出现乱序或重复交付。
本节解决验证方法问题：图上可靠不等于故障下可靠。
背景与直觉
备用电源不拉闸测试，就不知道它能不能接管。FRER 也是一样。配置看起来正确，只说明系统处于预期结构，不说明故障行为已经被证明。
怎么解决
基础测试可以覆盖这些场景。
| 场景 | 观察项 |
|---|---|
| 正常双路径 | 两条副本是否都存在，消除是否计数 |
| 主路径断链 | 应用层是否连续，deadline 是否满足 |
| 备用路径断链 | 主路径是否正常，重复状态是否稳定 |
| 主路径恢复 | 是否出现重复交付或乱序 |
| 背景压力下断链 | 备用路径是否仍有时间边界 |
测试材料要包含拓扑、故障动作时间、抓包点、设备计数器、应用层序列、延迟统计和恢复日志。
带来了什么新问题
故障注入可能影响生产环境，因此需要测试窗口或实验网络。某些设备的断链动作也可能触发其他协议收敛，影响结果解释。
此外，故障注入要和故障模型一致。你声称覆盖单桥故障，就不能只拔一根非关键链路；你声称覆盖共因故障，就要说明物理故障域如何验证。
检查点
- FRER 断链测试中，除了应用层是否收到数据，还要观察哪些设备侧证据？
- 为什么主路径恢复阶段也可能暴露重复消除问题？