01-协议一致性与认证测试
8.1 协议一致性与认证测试
本节摘要：协议栈"能用"与"合规"是两回事。本节讲 LoRaWAN 认证体系的测试维度、设备侧一致性测试的关键项，以及量产前的测试金字塔。位置：第 7 章打通了数据链路，本章回答"怎么证明这套实现是对的"。
认证与一致性测试的维度
LoRa Alliance 的认证（LoRaWAN Certification）覆盖三大维度：射频（发射功率、频率、占空比、杂散）、协议（入网流程、帧格式、MIC、命令交互）、互通（与不同厂商 NS/网关的互操作）。设备通过认证测试才能进入官方设备库，是进入运营商网络的前提。
| 测试组 | 覆盖内容 | 常见失败点 |
|---|---|---|
| 入网 | OTAA 全流程、DevNonce 唯一性、JoinAccept 处理 | AppKey 错误、CFList 解析缺失 |
| 帧处理 | 帧格式、MIC、加密、上下行方向 | B0 块拼接错误、字节序 |
| 命令 | 全部 MAC 命令的请求/应答 | 应答缺失、参数校验错误 |
| 射频 | 功率、频率容差、占空比 | 功率超标、频率越界 |
| 互通 | 与参考 NS、参考网关的联调 | 时序、去重、下行调度 |
设备侧自测的关键项
没有认证条件时，设备侧至少自测这几项：回环测试（自收自发验证 MIC 与加解密）、帧计数边界（回绕与重启回退）、命令全表（逐条命令触发与应答）、断电恢复（NVM 持久化与重新入网）、连续压力（数千帧不丢不重）。
测试金字塔
从低到高：单元测试（协议解析、加密算法，开发期跑）→ 集成测试（设备 + 模拟 NS，CI 里跑）→ 一致性测试（官方工具，出货前跑）→ 实网验证（目标区域冒烟）。金字塔的底部越扎实，顶部越少翻车——大多数"认证失败"都能在单元测试阶段暴露（MIC、字节序、命令解析）。
易错点清单
- 只在开发板验证：量产的射频性能（功率、灵敏度、谐波）与开发板差异大，认证与抽测要用量产物料；
- 跳过互通测试：自己 NS 自测全通过，换了运营商 NS 就出问题（时序、参数差异），互通测试不能省；
- 测试用例不回归：协议栈升级后必须全量回归，升级往往引入"修了一个 bug 带出另一个"。
要点回顾：认证覆盖射频、协议、互通三维度；自测从单元到实网分四层；量产物料与互通测试是避免"换环境就坏"的关键。下一节走向现场——覆盖诊断与场测方法。
一致性测试工具的使用
LoRaWAN 的一致性测试常用官方 Certification Test Tool（CTT）或社区脚本：脚本驱动设备发特定报文，参考 NS 侧检查响应，逐项比对协议行为。用 CTT 的注意点：测试脚本版本要与协议版本对应；测试要在可控射频环境跑（屏蔽箱），避免环境干扰误判；测试结果保留报告，作为认证与出货的依据。
一致性测试典型流程： 1. 设备进入测试模式（通过串口或特定按键） 2. CTT 逐项下发测试用例：入网、上行、下行、命令、帧计数 3. 每项用例记录设备响应是否符合预期 4. 汇总报告：全部通过 → 可提交认证；失败项 → 定位修复后重测
量产抽测与批一致性
量产不能只测首件：抽测比例（按批次的 1–5%，批量大取低值）、抽测项聚焦（射频功率/频率、入网成功率、功耗剖面，这些最容易受物料与焊接影响）、数据留档（每批抽测结果归档，追溯问题时按批次排查）。批一致性的关键是产线参数（校准值、密钥、区域标识）在每台的烧录一致，抽测时随机挑几台比对产测记录。
易错点补充
- 测试环境与实网环境混淆：屏蔽箱里的灵敏度与实网差很多，一致性测试在屏蔽箱、覆盖验证在实网，两个口径分开记录；
- 只看结果不看过程：测试通过率之外，还要看失败项的分布（同一用例反复失败 = 稳定 bug，随机失败 = 环境或时序问题）；
- 认证后改代码：认证通过后任何协议相关改动都要重新评估认证范围，小改可以回归测试，大改必须重新认证。
关键实现清单
- 测试金字塔：单元→集成→一致性→实网，逐层通过
- 一致性测试用官方 CTT，版本与协议版本对应
- 量产抽测 1–5%，聚焦射频/入网/功耗，数据留档
- 认证通过后协议改动要重新评估认证范围
典型故障与处置
| 现象 | 原因 | 处置 |
|---|---|---|
| 单测全过实网失败 | 环境差异或时序问题 | 加实网冒烟与互通测试 |
| 同一用例反复失败 | 稳定 bug，非环境 | 定位代码修复后回归 |
| 批间性能差异大 | 产线烧录或物料差异 | 抽测比对产测记录 |
常见认证失败与对策
| 失败项 | 根因 | 对策 |
|---|---|---|
| Join 测试失败 | AppKey 或 DevNonce 问题 | 核对密钥台账与随机源 |
| MIC 校验失败 | B0 块或字节序错误 | 对照规范示例逐字节比对 |
| 命令应答缺失 | 命令引擎未配对 | 补全 Req/Ans 配对逻辑 |
| 射频功率超标 | 法规上限未封顶 | 按区域参数封顶功率 |
把失败项按"协议类/射频类"分类，协议类查代码、射频类查物料与校准。
从测试到认证的完整路径
设备从开发到进入运营商网络，测试路径一般分四步。第一步，开发期单元测试：协议解析、加解密、命令引擎在 CI 里每天跑，问题当天暴露。第二步，模拟 NS 联调：用 ChirpStack 或 TTN 沙箱跑真实入网与收发，验证与参考实现的互通性。第三步，一致性测试：用官方测试工具逐项验证协议行为，形成测试报告。第四步，实网验证：在目标区域用目标运营商或自建 NS 做冒烟测试。
| 阶段 | 工具/环境 | 覆盖范围 | 通过标准 |
|---|---|---|---|
| 单元测试 | 本机/CI | 协议解析、加密 | 全部用例通过 |
| 联调 | 模拟 NS | 入网、收发、命令 | 端到端成功率 > 95% |
| 一致性 | 官方 CTT | 协议行为 | 官方报告全过 |
| 实网 | 目标环境 | 区域参数、信道 | 冒烟全过 |
这条路径的价值在于把问题留在成本最低的阶段暴露：单元测试阶段修一个解析 bug 只要几分钟，实网阶段发现同样问题要涉及换固件、重新验证、甚至现场出差。
测试数据的留痕与追溯
测试不只是"过不过"，还要能追溯：每次测试记录环境（固件版本、区域配置、工具版本、日期）、失败项关联代码（bug 编号与提交号）、量产抽测结果归档（批次号、序列号、结果）。留痕的意义在量产后的质量回溯：某批设备现场故障率高，靠抽测记录能快速定位是物料批次问题还是烧录问题。建议把测试记录接入缺陷管理系统或至少用结构化文件存档，别用"我记得当时测过"来管理。
易错点补充
- 测试环境与量产环境分离：开发测试用假密钥假网络，量产烧录用真实密钥，两套环境要物理隔离防误烧；
- 抽测样本要覆盖批次首尾：批次首件与末件都要抽，产线参数漂移往往是中间件烧录软件更新导致的；
- 测试报告不归档：认证复验或客户审计时要能拿出历史报告，归档是硬要求。