3. 一致性测试与互操作测试的边界与关系

在机载网络测试中,一致性测试与互操作测试经常被并列提及,但它们回答的是两个不同层面的问题。一致性测试回答的是“这台设备的协议实现,是否严格符合标准或接口控制文件所规定的行为”;互操作测试回答的是“多台来自不同供应商、可能实现细节各异的设备,能否在同一网络中正确交换数据并完成协同功能”。前者以规范为唯一裁判,后者以真实系统之间的协同结果为裁判。理解这条边界,是设计测试方案、分配测试资源、定位现场故障的前提。

一、测试目的与判定基准的差异

一致性测试的判定基准是规范文本,包括 ARINC 664 Part 7、ARINC 653、IEEE 802.3、ARINC 429 等标准,以及项目专用的 ICD(接口控制文件)。测试时通常采用“被测实现 IUT + 上层测试器 UT + 下层测试器 LT”的结构,通过抽象测试套件 ATS 生成可执行测试例,观察 IUT 在受控激励下的输出是否与规范预期一致。判定结果是二值的:通过或不通过,并附带“无结论”状态,用于表示测试环境或测试例本身不足以给出确定判断。

互操作测试的判定基准不是某一份规范,而是系统级功能是否达成。例如两台航电设备通过 AFDX 交换机通信,即使双方都通过了一致性测试,仍可能因为虚拟链路 VL 的带宽分配策略、BAG 抖动容忍度、冗余管理算法差异而出现丢包或时延超限。互操作测试关注的是端到端时延、丢包率、冗余切换时间、功能正确性等系统指标,判定往往是“满足/不满足任务要求”,而非简单的协议合规。

二、测试层次与覆盖范围

一致性测试通常聚焦于协议栈的某一层或某一接口。以 AFDX 为例,可细分为物理层一致性(眼图、抖动、幅度)、链路层一致性(MAC 帧格式、VL 标识、冗余序列号)、网络层一致性(IP 分片、组播地址)、传输层一致性(UDP 校验和、端口号)以及应用层一致性(采样端口、队列端口服务)。测试覆盖强调“规范条款覆盖率”,要求每条 MUST 语句至少有一个测试例对应。

互操作测试则跨越多个层次和多个设备,覆盖的是“场景”。典型场景包括:正常通信场景、冗余链路切换场景、网络拥塞场景、设备上下电场景、时间同步场景。覆盖范围由系统功能需求决定,而不是由协议条款决定。因此,互操作测试的用例数量往往少于一致性测试,但每个用例的集成度和执行复杂度更高。

一致性测试与互操作测试的层次与关系 一致性测试(Conformance) 判定基准:标准 / ICD 规范条款 测试对象:单台设备(IUT) 结果形式:通过 / 不通过 / 无结论 应用层:采样/队列端口服务、ARINC 653 分区 传输层:UDP 校验和、端口号、长度 网络层:IP 分片、组播地址、TTL 链路层:MAC 帧、VL 标识、冗余序列号 物理层:眼图、抖动、幅度、阻抗 覆盖目标:规范 MUST 条款覆盖率 ≥ 95% 测试方式:受控激励 + 预期响应比对 互操作测试(Interoperability) 判定基准:系统功能需求 / 任务指标 测试对象:多设备 + 网络(≥2 台) 结果形式:满足 / 不满足任务要求 正常通信:端到端时延、丢包率 冗余切换:A/B 网切换时间、序列连续性 网络拥塞:VL 带宽隔离、优先级调度 上下电:启动同步、链路重建 时间同步:gPTP 偏差、同步收敛 覆盖目标:系统功能场景覆盖率 100% 测试方式:真实组网 + 端到端观测 基础 反馈 典型冲突:双方均通过一致性测试,但 VL 带宽分配策略不同导致互操作失败

三、典型冲突场景分析

一致性测试与互操作测试之间最值得警惕的,是“双方都合规,但合在一起不通”的情况。以下三类冲突在机载网络中尤为常见。

第一类:规范留白导致的实现分歧。标准中常存在“可选”或“建议”条款。例如 AFDX 冗余管理中,序列号在 0 到 255 之间循环,规范允许接收端在检测到序列号不连续时采用不同的处理策略:有的实现直接丢弃,有的实现等待一个 BAG 周期后再判断。两台设备各自通过一致性测试,但组合后可能出现冗余切换时延超标。此类冲突的排查方法是:在互操作测试中构造序列号跳变场景,记录接收端行为,再对照双方 ICD 中的冗余管理描述。

第二类:参数配置边界不一致。以 VL 带宽分配为例,发送端按 BAG=2ms、Lmax=500 字节配置,接收端按 BAG=4ms 配置。双方单独测试均通过,但实际通信时接收端因缓冲区溢出而丢包。排查时需要在交换机端口镜像处抓包,统计实际到达速率与接收端配置的令牌桶参数,确认哪一侧的配置与系统 ICD 不符。

第三类:时间同步与调度耦合。ARINC 653 分区调度与网络时间同步存在耦合。若 gPTP 同步偏差超过分区窗口保护带,分区切换可能丢失网络数据。一致性测试只验证 gPTP 协议报文格式和同步算法,不验证分区调度与网络收发的时序配合。互操作测试则需要在同步收敛后,持续观测分区窗口内的数据到达情况。

四、测试策略上的协同关系

一致性测试是互操作测试的基础,但不是充分条件。工程实践中通常采用“先一致性、后互操作”的顺序:设备级一致性测试通过后,再进入系统集成阶段的互操作测试。这样做的原因是,一致性测试可以在受控环境下快速定位协议实现缺陷,避免将底层问题带入复杂的系统联试。

反过来,互操作测试的结果会反馈给一致性测试。当互操作测试发现某类冲突反复出现时,应检查一致性测试套件是否遗漏了相关规范条款,或测试例的激励是否过于理想化。例如,若多台设备在冗余切换场景下均出现丢包,则说明一致性测试中关于冗余序列号处理的测试例需要增加边界条件。

在实际项目中,建议为每台设备建立“一致性测试通过项清单”和“互操作测试场景清单”两张表。前者记录协议条款覆盖情况,后者记录系统功能场景执行结果。当互操作测试出现失败时,先查一致性清单确认相关条款是否已覆盖,再查场景清单确认是否为多设备交互引入的新问题。两张表交叉比对,可以显著缩短故障定位时间。

五、边界判定示例

以下用一个具体判断过程说明边界如何划分。假设某型 AFDX 交换机在测试中出现“组播帧转发正确,但单播帧在特定 VL 下丢失”。

  • 若检查发现该 VL 的 MAC 地址过滤表配置与 ICD 不符,属于交换机实现未按规范配置过滤规则,归入一致性测试范畴,判定为一致性缺陷。
  • 若检查发现交换机过滤规则正确,但发送端在单播帧中填写的目的 MAC 地址与接收端期望的 VL 映射不一致,且双方 ICD 对“单播 VL 是否使用组播 MAC 映射”描述存在歧义,则归入互操作测试范畴,判定为接口约定冲突。
  • 若检查发现双方配置均正确,但交换机在同时处理 128 个 VL 时因内部队列调度导致单播帧被组播帧阻塞,则属于系统级性能问题,归入互操作测试中的拥塞场景,需结合交换机队列深度和调度算法分析。

通过上述划分可以看出,一致性测试关注“实现是否偏离规范”,互操作测试关注“协同是否达成功能”。两者在测试层次上互补,在测试目的上递进,在覆盖范围上交叉。只有把两者放在同一测试体系中统筹设计,才能既保证单设备合规,又保证整网可用。