1. 互操作测试工程导入

蓝牙产品能不能“连得上、跑得稳、过得了认证”，往往不取决于某一颗芯片本身，而取决于它和不同品牌手机、不同协议栈版本、不同操作系统之间能否正确协商与协作。Nordic nRF 系列（如 nRF52832、nRF52840、nRF5340）提供了完整的蓝牙低功耗协议栈（SoftDevice 或 S140/S132 等）与开发工具链，但芯片厂商的协议栈一致性测试通过，并不等于产品在真实生态中互操作成功。互操作测试工程，就是把这件“看起来靠运气”的事情，变成可设计、可执行、可复现、可追溯的工程活动。

一、定义：互操作测试到底测什么

互操作测试（Interoperability Testing，IOT）是指：在被测设备（DUT，通常基于 Nordic nRF 的蓝牙产品）与对端设备（手机、平板、网关、另一块开发板等）之间，按照真实使用场景建立连接、交换数据、维持链路，并验证双方在协议行为、时序、参数协商和异常处理上是否一致、稳定、可接受。

它和另外两类测试容易混淆，需要先划清边界：

• 一致性测试（Conformance）：验证协议实现是否符合蓝牙规范，通常在认证实验室用蓝牙 SIG 认可的测试仪完成，回答“合不合规”。
• 射频/性能测试：验证发射功率、灵敏度、频偏、丢包率等物理层指标，回答“信号好不好”。
• 互操作测试：验证真实设备组合下的端到端行为，回答“和它配合能不能用、稳不稳”。

三者互补：一致性是入场券，射频是基础，互操作是产品能否被用户接受的最后一道现实检验。

二、目标：从“能连”到“可交付”

互操作测试工程的目标不是简单跑通一次连接，而是建立可量化的质量证据链，通常包括：

• 连接可靠性：在目标机型上连接成功率、重连成功率、断连恢复能力。
• 数据正确性：GATT 读写、通知/指示（Notify/Indicate）、MTU 协商、分包重组的数据一致性。
• 时序与参数兼容：连接间隔、从机延迟、监督超时、PHY 选择（1M/2M/Coded）在不同主机下的实际表现。
• 异常鲁棒性：配对失败、绑定丢失、信号弱、主机主动断连、并发连接等场景下的行为。
• 可追溯性：每个问题都能定位到具体机型、系统版本、协议栈版本、固件版本与复现步骤。

三、范围：测哪些组合、哪些场景

蓝牙生态组合爆炸是互操作测试最大的挑战。范围界定要基于产品定位，而不是“能测的都测”。一个可落地的范围矩阵通常包含四个维度：

范围之外要明确写出“不测什么”，例如不覆盖经典蓝牙音频、不覆盖未上市系统版本，避免后期争议。

四、在蓝牙产品开发中的位置：完整测试链路

互操作测试不是孤立环节，它嵌在从需求到认证的链路中。下图给出一个典型的 Nordic nRF 蓝牙产品测试链路，说明互操作测试所处的位置及其上下游关系。

从图中可以看到，互操作测试位于固件开发、一致性测试、射频测试之后，认证与上市之前，同时通过反馈回路反向驱动固件与参数修正。它不是一次性关卡，而是贯穿开发后期的持续活动。

五、工程化落地：从“手工试”到“可复现”

要让互操作测试真正成为工程能力，需要建立几个基本要素。第一是设备池：把目标手机、平板按型号和系统版本编号管理，记录系统版本、蓝牙芯片型号、是否开启蓝牙 5 特性等。第二是固件版本管理：每次测试必须记录 nRF 芯片型号、协议栈版本（如 S140 v7.3.0）、应用固件 Git 提交号。第三是用例脚本化：把“打开 App→扫描→连接→订阅通知→发送 20 字节→断开→重连”写成可重复执行的步骤，减少人为差异。

一个典型的测试记录字段可以这样设计：

用例编号: IOT-CONN-001
DUT: nRF52840 DK, FW v1.2.3, S140 v7.3.0
对端: iPhone 14, iOS 17.4
场景: 首次配对 + 订阅通知 + 主动断连重连
预期: 连接成功, 收到 10 次通知, 重连成功
实际: 连接成功, 收到 10 次通知, 重连成功
结论: PASS
备注: 连接间隔协商为 30ms

当出现失败时，判断依据要具体：是扫描不到、连接超时、服务发现失败、通知未到达，还是重连后绑定信息丢失。不同现象指向不同根因，例如绑定丢失通常与配对参数、密钥存储或主机侧缓存有关，而连接超时可能与广播间隔、连接参数或射频环境有关。

六、本节小结