4. 机载网络系统级验证需求捕获与追踪

机载确定性网络系统级验证的起点不是测试台架，而是需求。若验证需求来源不清、追踪关系断裂，后续无论仿真模型多精细、测试脚本多完整，都无法证明“飞机级功能—系统级安全—网络配置”这条链条真正被覆盖。本节聚焦三件事：从哪里捕获验证需求、如何把需求转成可执行的测试用例与覆盖项、以及如何建立双向追踪矩阵并在变更中维持其有效性。

一、三类需求源与捕获要点

机载网络验证需求通常来自三个层次，它们的抽象程度和语言风格差异很大，捕获时必须做“翻译”。

• 飞机级功能需求：描述飞机完成某项任务的能力，例如“飞行控制律在正常模式下以固定周期交换舵面指令”。它给出的是功能意图、周期量级、端到端时限和失效影响等级，但不指定具体交换机端口或 VLAN。
• 系统级安全需求：来自安全性评估（如 FHA/PSSA），例如“某航电分区与客舱娱乐分区之间不得存在任何数据通路”，或“关键控制消息在链路故障后 50 ms 内完成重构”。它给出的是隔离、冗余、时限和故障响应约束。
• 网络配置规范：来自网络设计与配置文件，例如 VLAN 划分表、静态调度表、TSN 门控列表、带宽预留参数。它给出的是可验证的具体参数，是测试用例最直接的输入。

捕获时建议采用“需求条目化”方式：每条验证需求分配唯一 ID，记录来源文档与条款号、需求类型（功能/安全/配置）、验证方法（测试/分析/检查）、以及可测量的判据。判据必须可观测，例如“端到端时延 ≤ 2 ms”而不是“时延满足要求”。

二、从需求到测试用例与覆盖项

一条验证需求往往需要多个测试用例，一个测试用例也可能覆盖多条需求，因此不能简单一对一映射。以“关键控制消息端到端时延 ≤ 2 ms”为例，可拆解为：正常负载下的时延测试、背景流量冲击下的时延测试、单链路故障重构后的时延测试。每个用例再定义覆盖项，例如“覆盖正常调度路径”“覆盖冗余路径切换”“覆盖门控窗口边界”。

覆盖项是追踪矩阵中承上启下的关键：向上关联需求，向下关联测试用例与执行结果。建议覆盖项按“需求维度 + 场景维度”命名，避免出现“测试通过”这类无法定位的笼统描述。

三、双向追踪矩阵的建立与维护

双向追踪矩阵至少包含四类对象：需求、覆盖项、测试用例、执行结果。正向追踪回答“每条需求是否被覆盖”，反向追踪回答“每个用例是否服务于某条需求”。矩阵可用表格或需求管理工具实现，核心字段包括：需求 ID、来源、覆盖项 ID、用例 ID、验证方法、判据、执行状态、证据链接。

建立顺序建议为：先冻结需求基线，再生成覆盖项，再编写用例，最后回填执行结果。变更时从需求 ID 出发，沿正向和反向两条路径检查受影响对象，确保没有“孤儿用例”和“未覆盖需求”。

四、一个可执行的追踪矩阵示例

下表给出一个简化但结构完整的追踪矩阵片段，字段可直接用于需求管理工具或电子表格。示例中的 ID、参数和状态均为教学假设，不代表真实型号数据。

当 TC-120 失败时，反向追踪可快速定位到 VR-018 与 CFG-03，进而检查门控列表配置与交换机时钟同步状态，而不是盲目扩大测试范围。这正是双向追踪矩阵在排障中的直接价值。

五、常见问题与处理建议

• 需求不可测：如“网络应具有高可靠性”。处理方式是补充可量化判据，例如“单链路故障后 50 ms 内完成重构，丢包率 ≤ 10⁻⁶”。
• 覆盖项过粗：如“覆盖时延”。应拆分为正常、边界、故障三类场景，分别对应不同用例。
• 矩阵长期不更新：建议将矩阵更新纳入变更流程，需求、配置、用例任一变更都触发影响分析。
• 证据缺失：执行结果必须关联可复查的证据，如抓包文件、时延统计脚本输出、交换机日志片段，避免只记录“通过”。

综上，机载网络系统级验证需求捕获与追踪的核心在于：从飞机级功能、系统级安全需求和网络配置规范中提取可测判据，将其转化为覆盖项与测试用例，并通过双向追踪矩阵保持需求、用例、结果三者一致。矩阵的价值不仅在于证明覆盖，更在于变更和排障时能够快速定位影响范围，使验证活动始终围绕真实需求展开。