learn
可复现报告：让别人能重新相信你的结论
学习一份 TSN 验证报告应该如何组织拓扑、配置、流量、脚本、原始数据、统计和结论边界。
第九章：验证与进阶阅读工程闭环TSN Validation20 分钟
本节学习目标
- 知道 TSN 报告需要保留可复现材料，而不是只有结论页。
- 能把原始证据、统计结果和结论边界组织成报告结构。
- 理解可复现性如何帮助后续读论文和排查问题。
建议先读
核心概念
reproducibilityraw evidenceconfiguration snapshotconclusion boundary
本章目录
- 01可观测性计划：TSN 测试要留下哪些证据把拓扑、配置、抓包、硬件时间戳、端口计数器、背景压力和故障注入组织成能证明边界的测试计划。
- 02最坏情况指标：平均延迟为什么不够学习 TSN 验证中应该关注最大值、分位数、deadline miss、抖动范围和测量误差，而不是只报告平均延迟。
- 03时间同步证据：没有共同时间，延迟数字也会失真学习 TSN 验证中如何记录 gPTP 状态、时间戳来源、offset、grandmaster 和测量时钟，避免把不同时间基准下的数字硬比较。
- 04故障注入设计：测试要覆盖你声称覆盖的故障学习如何把 FRER、Qbv、Qcc 的故障模型转成断链、端口 down、设备重启、配置失败和恢复阶段的验证场景。
- 05调试手册：TSN 失败时按证据链收敛把 TSN 失败拆成需求、时间、队列、调度、配置、冗余和测量几类证据，形成可复盘的排查顺序。
- 06可复现报告：让别人能重新相信你的结论学习一份 TSN 验证报告应该如何组织拓扑、配置、流量、脚本、原始数据、统计和结论边界。
- 07从验证报告到论文阅读：指标、假设与结论边界把工程测试里的证据意识迁移到论文阅读，判断 TSN 论文的模型、实验、baseline 和结论是否扎实。
解决什么问题
测试做完以后，如果只留一页 PPT，后面很难复盘。设备版本升级后结果变了，没人知道原来配置是什么；论文读到类似指标，也无法对照自己的测试；现场出问题时，报告无法帮助定位。
可复现报告解决的是信任和复盘。别人不必相信你的口头判断，可以沿着材料重新理解测试条件、执行过程和结论边界。
背景与直觉
科学实验要保留方法和数据，工程验证也一样。TSN 的结论依赖很多条件：拓扑、配置、时间同步、背景流量、测量精度、故障动作。缺任何一项，结论都会变成不可复现的经验。
怎么解决
一份可复现报告可以按这个目录组织。
| 目录 | 内容 |
|---|---|
| 01_topology | 拓扑图、端口表、链路速率、故障域 |
| 02_devices | 型号、固件、TSN 能力、时间源 |
| 03_config | gPTP、GCL、CBS、抢占、FRER、Qcc 输出 |
| 04_traffic | 关键流和背景流脚本、参数、持续时间 |
| 05_raw | 抓包、计数器、日志、时间戳原始数据 |
| 06_stats | 统计脚本、最大值、分位数、miss count |
| 07_faults | 故障注入步骤和恢复结果 |
| 08_conclusion | 结论、适用范围、未覆盖风险 |
最好把统计脚本也保存下来。这样别人能确认图表如何从原始数据生成，而不是只看到最终图。
带来了什么新问题
可复现报告会增加工作量和数据管理成本。抓包可能很大，设备配置可能包含敏感信息，报告需要脱敏和归档策略。
但如果目标是证明确定性，这些成本是必要的。没有原始证据的报告，很难支撑长期维护和跨团队协作。
检查点
- 如果一年后设备固件升级导致延迟变差，你希望旧报告里保留哪些材料？
- 为什么统计图不能替代原始抓包和配置快照？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出一份可复现 TSN 报告的目录结构。
- 2能说明为什么原始抓包和配置快照要和统计图一起保存。