learn
故障注入设计：测试要覆盖你声称覆盖的故障
学习如何把 FRER、Qbv、Qcc 的故障模型转成断链、端口 down、设备重启、配置失败和恢复阶段的验证场景。
第九章：验证与进阶阅读工程闭环TSN Validation22 分钟
本节学习目标
- 能把故障模型转成具体测试动作。
- 知道故障注入要覆盖故障发生、持续和恢复三个阶段。
- 能判断测试是否支撑报告里的可靠性声明。
建议先读
核心概念
fault modelinjection pointrecovery phasecoverage
本章目录
- 01可观测性计划：TSN 测试要留下哪些证据把拓扑、配置、抓包、硬件时间戳、端口计数器、背景压力和故障注入组织成能证明边界的测试计划。
- 02最坏情况指标：平均延迟为什么不够学习 TSN 验证中应该关注最大值、分位数、deadline miss、抖动范围和测量误差，而不是只报告平均延迟。
- 03时间同步证据：没有共同时间，延迟数字也会失真学习 TSN 验证中如何记录 gPTP 状态、时间戳来源、offset、grandmaster 和测量时钟，避免把不同时间基准下的数字硬比较。
- 04故障注入设计：测试要覆盖你声称覆盖的故障学习如何把 FRER、Qbv、Qcc 的故障模型转成断链、端口 down、设备重启、配置失败和恢复阶段的验证场景。
- 05调试手册：TSN 失败时按证据链收敛把 TSN 失败拆成需求、时间、队列、调度、配置、冗余和测量几类证据，形成可复盘的排查顺序。
- 06可复现报告：让别人能重新相信你的结论学习一份 TSN 验证报告应该如何组织拓扑、配置、流量、脚本、原始数据、统计和结论边界。
- 07从验证报告到论文阅读：指标、假设与结论边界把工程测试里的证据意识迁移到论文阅读，判断 TSN 论文的模型、实验、baseline 和结论是否扎实。
解决什么问题
故障测试不能随便拔一根线就结束。你测试的故障必须对应设计里声称覆盖的故障。否则报告写的是单桥故障，测试却只断了非关键链路，结论就不成立。
本节解决故障注入设计问题：测试要覆盖你声称覆盖的故障。
背景与直觉
消防演练如果只测试办公区撤离，却声称覆盖机房火灾，就不匹配。网络故障注入也是一样。故障模型和测试动作要一一对应。
怎么解决
可以按三阶段设计：故障前、故障中、恢复后。
| 阶段 | 要观察什么 |
|---|---|
| 故障前 | baseline 延迟、同步、计数器 |
| 故障发生 | miss、丢包、切换时间、告警 |
| 故障持续 | 备用路径是否满足 deadline |
| 故障恢复 | 重复、乱序、状态回收 |
| 结束后 | 配置和计数器是否回到可解释状态 |
故障类型可以包括断链、端口 down、桥设备重启、grandmaster 切换、配置下发失败、背景流量突发、FRER 主路径恢复等。
带来了什么新问题
故障注入测试可能破坏业务，因此要明确测试环境、时间窗口和回滚方案。某些故障很难在生产中测试，就要在实验环境或仿真环境中补证据，并在报告中写清限制。
故障注入还会产生大量日志和抓包，需要提前规划采集点。故障发生的一瞬间往往最关键，事后再开抓包通常已经晚了。
检查点
- 如果设计声称覆盖单桥故障，你会怎样设计故障注入动作？
- 为什么恢复阶段可能比故障发生瞬间更容易暴露 FRER 重复消除问题？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能为单链路故障和配置下发失败分别设计测试。
- 2能解释为什么恢复阶段也属于故障测试范围。