📚 课程目录第4章互操作性测试基础

4. 互操作性测试基础

互操作性测试（Interoperability Test，IOT）要回答的核心问题不是“这块板子能不能跑起来”，而是“它和另一台真实设备放在一起，能不能按蓝牙规范完成既定交互”。在 Nordic nRF54 系列开发中，这句话意味着：你的 DUT（被测设备）要能与手机、耳机、门锁、心率带等对端设备完成发现、连接、配对、加密、服务发现、数据读写、断连重连等动作，并且行为可复现、可判定。要讲清这件事，先要分清四个角色：IUT、测试仪、参考设备、测试用例。

四个角色：谁被测、谁施压、谁对照、谁判定

IUT（Implementation Under Test，被测实现）是测试的靶子。它可以是 nRF54 上运行的完整产品固件，也可以是被裁剪到只保留 GAP/GATT 某几个角色的最小工程。IUT 的关键属性是“可观测、可控制”：你能通过日志、UART、RTT 或调试器看到它的状态机迁移，也能通过配置让它进入指定状态。若 IUT 行为不可观测，测试就退化成“猜”。

测试仪（Tester）是主动施压的一方。它可以是蓝牙协议测试仪（如基于 Ellisys、Frontline 的商用分析/测试系统），也可以是运行在 PC 或第二块 Nordic 板上的自动化测试程序。测试仪负责按测试用例发送激励、控制时序、采集响应，并给出通过/失败判定。测试仪与 IUT 之间是“激励—响应”关系，而不是对等通信关系。

参考设备（Reference Device）是已知行为正确的对照物。它通常来自芯片原厂、认证实验室或成熟量产产品，其协议栈版本、配置、角色能力都已确认。参考设备的作用是提供“基准行为”：当 IUT 与参考设备互通失败时，可以先用参考设备替换 IUT 或替换对端，快速定位问题出在哪一侧。参考设备不是测试仪，它不主动判定，只提供可信的交互对象。

测试用例（Test Case）是把规范条款翻译成可执行步骤的最小单元。一个合格的测试用例至少包含：前置条件（IUT 状态、对端状态、绑定信息）、激励序列、预期响应、判定准则、清理步骤。测试用例不是“操作手册”，它必须能独立复现并给出二值结论。

测试用例分类：不同类别解决不同问题

蓝牙测试用例通常分为五类，每类的目的、工具和判定依据都不同。把它们混在一起，就会出现“用一致性测试的结论去回答互操作问题”的错位。

协议一致性测试（Protocol Conformance）：验证 IUT 的协议行为是否符合 Core Spec。例如 GAP 广播间隔是否在规定范围内、ATT 错误码是否使用正确。测试仪通常直接控制 IUT 的底层，绕过真实空口。
互操作性测试（Interoperability）：验证 IUT 与真实对端能否完成端到端交互。它不追求覆盖所有协议分支，而是覆盖真实产品组合。例如 nRF54 作为 Peripheral 与某品牌手机作为 Central 的配对与重连。
射频测试（RF / PHY）：验证发射功率、频偏、灵敏度、调制特性等物理层指标。通常用综测仪（如 CMW270）完成，与协议栈行为无关。
配置文件测试（Profile）：验证 IUT 是否满足某个 Profile 的强制要求，如 HID、HFP、A2DP。它介于一致性与互操作之间，关注角色、服务、特征和流程。
安全测试（Security）：验证配对、加密、密钥分发、隐私（RPA）等行为。nRF54 支持 LE Secure Connections、Privacy 1.2，安全测试会重点检查这些路径。

蓝牙资格认证流程：从测试到 QDID

蓝牙资格认证（Qualification）是产品使用蓝牙商标、进入市场的前置条件。它的流程可以概括为：先确定产品要声明哪些功能（Declaration），再选择对应的测试用例，执行测试并收集证据，最后提交到 Bluetooth SIG 获得 QDID（Qualified Design ID）。

具体来说，流程包含以下关键节点：

确定声明范围：明确产品是 End Product 还是 Component，支持哪些 Core Spec 版本、哪些 Profile、哪些角色。nRF54 作为 Component 时，通常引用 Nordic 已有的 Component QDID，再叠加自己的 Profile 声明。
选择测试用例：根据声明范围，从 Test Case Reference List（TCRL）中筛选必须执行的用例。TCRL 会标注每个用例的适用条件、依赖关系和测试类型。
执行测试：一致性测试在认可测试设施（BQTF）或使用认可测试系统完成；互操作性测试可用参考设备组合完成。测试结果需保留日志、抓包和配置记录。
提交声明与证据：通过 Bluetooth SIG 的 Qualification 工具提交 Declaration、测试报告和产品信息。
获得 QDID 与列名：审核通过后获得 QDID，产品可列入 SIG 的 Product Listing，合法使用蓝牙商标。

对于 nRF54 项目，常见做法是：先引用 Nordic 的 Component QDID 覆盖协议栈部分，再针对自研 Profile 或自定义 GATT 服务补充测试。这样能显著减少重复测试量，但前提是固件没有修改协议栈核心行为。

实操示例：一次最小互操作性测试的配置与判定

下面给出一个可复现的示例，用于验证 nRF54 作为 Peripheral 与手机作为 Central 的“配对后重连并恢复加密”行为。示例参数属于教学假设，不是实测结果。

IUT: nRF54L15 DK, Peripheral, 自定义 GATT 服务
对端: 参考手机（已知支持 LE Secure Connections）
测试用例: IOT-SM-002 重连加密恢复
前置条件:
  - IUT 已与手机完成首次配对并绑定
  - 手机蓝牙已开启，IUT 处于可连接广播
激励序列:
  1. 手机发起连接
  2. 手机发起加密流程（不重新配对）
  3. 手机读取自定义特征 0x2A00
预期响应:
  - 连接建立后 500 ms 内进入加密状态
  - 读请求返回 0x00 且无 ATT 错误
判定准则:
  - 加密状态在 1 s 内达成
  - 读响应与写入值一致
  - 无意外断连
清理:
  - 断开连接，IUT 回到广播态

执行时，测试仪或抓包工具应记录空口交互。判定时重点看三件事：连接事件是否稳定、加密流程是否在预期时间内完成、GATT 操作是否返回正确值。若失败，先用参考设备替换手机，若仍失败则问题在 IUT；若替换后通过，则问题在对端兼容性，需要进一步分析对端的配对参数或 GATT 缓存行为。

互操作性测试的结论只对“测试过的组合”有效。手机型号、系统版本、协议栈实现都会影响结果。因此测试报告必须记录对端设备的型号、固件/系统版本和关键配置，否则结论不可复现。

常见误区与排查方向

初学者最容易犯的错误是把“能连上”当成“互操作通过”。实际上，连接成功只是第一步，后续的配对、加密、服务发现、特征读写、通知订阅、断连重连都可能失败。另一个误区是忽略绑定信息（bonding）的清理：如果 IUT 和手机都保留了旧密钥，重连测试可能因为密钥不匹配而失败，但现象看起来像“连接不稳定”。

排查时建议按层推进：先看广播与扫描是否正常，再看连接参数是否被接受，然后看配对与加密是否完成，最后看 GATT 操作是否返回预期值。每一层都用抓包或日志确认，而不是靠现象猜测。对于 nRF54，可以打开 RTT 日志输出协议栈事件，配合 Nordic 的 Bluetooth Low Energy 抓包工具，能较快定位问题发生在哪一层。

最后要强调：互操作性测试不是一次性动作，而是随固件迭代持续进行的回归活动。每次修改 GAP 参数、GATT 表、安全配置或连接参数，都应重新跑一遍关键互操作用例，确保没有引入新的兼容性问题。