蓝牙BLE自动化深入：从GATT Profile到数字钥匙

车联APP的自动化测试，最硬的一块骨头不在UI，在BLE。

---

引子

去年我们做蓝牙钥匙的自动化回归时，遇到一个诡异的 bug：iOS 端偶发连接超时，Android 端完全正常。手工复现了整整两天才发现——iOS 的 BLE 扫描策略在后台状态下会降频，导致 Service Discovery 超时。而我们的自动化脚本根本没有覆盖"APP 在后台被拉起"这个场景。

这件事让我意识到：车联 APP 的 BLE 自动化，不是"把 Appium 加个蓝牙权限"就能解决的。它要求你理解协议栈、理解操作系统差异、理解车端 BLE 外设的行为模型。

这篇把我们从零搭建 BLE 自动化的完整思路讲清楚。

---

BLE 测试为什么不能照搬 HTTP 接口测试那套

先对齐一个认知：BLE 通信和 HTTP 接口是两种完全不同的测试对象。

维度	HTTP 接口测试	BLE 自动化测试
通信模型	请求-响应，同步	异步事件驱动，有状态
被测对象	服务端接口	车端 BLE 外设 + APP 蓝牙栈
依赖环境	Mock Server	虚拟 BLE 外设（需操作系统级支持）
典型异常	超时、4xx/5xx	信号衰减、连接中断、MTU协商失败、配对超时
工具链成熟度	极其成熟	还在拼积木阶段

核心矛盾在于：传统接口测试 Mock 的是"数据"，BLE 测试 Mock 的是"一个物理设备"。这不是一个 requests.post() 能解决的事。

---

四层测试模型：从设备发现到数字钥匙

我们把 BLE 自动化拆成四个测试层，每层有独立的 Mock 策略和验证点。

Layer 1：设备发现与广播扫描

这是最基础但最容易出问题的一层。车端 BLE 外设的广播包包含：设备名称、Service UUID、Manufacturer Specific Data、TX Power Level。

自动化要做的是：

• 模拟车端发送指定格式的广播包
• 验证 APP 能在预期时间内发现设备（冷启动首次扫描 vs 后台重扫，时限不同）
• 覆盖各类异常广播（不完整包、Service UUID 缺失、RSSI 波动剧烈）

我们用 Python bleak 在 Linux 主机上构建虚拟外设，通过 bleak.BleakScanner 注册一个可被发现的 GATT Server：

from bleak import BleakScanner, BleakServer

# 注册虚拟车端外设，广播 CCC Digital Key Service UUID
advertisement_data = {
    "name": "MyCar_BLE",
    "service_uuids": ["0000fde9-0000-1000-8000-00805f9b34fb"],  # CCC Service
    "manufacturer_data": {0x004C: b"\x02\x15... \x00\x00"}  # iBeacon 格式
}

这里有一个反直觉的点：广播包不是"配好就行"，它受操作系统蓝牙栈调度策略影响。同一段代码在树莓派、Ubuntu、macOS 上的广播间隔差异可以到 200ms，这会直接影响 APP 端的扫描发现延迟。我们最终的方案是在执行机上用 hcitool 直接控制广播参数，绕过 BlueZ 的默认调度。

Layer 2：GATT Service/Characteristic 读写

设备连上之后，APP 会遍历 GATT 表，按 Service UUID → Characteristic UUID 读写车端数据。

这一层的自动化验证点：

• Service Discovery 完整性：车端暴露的 Service/Characteristic 列表是否符合协议规范
• 读写权限矩阵：Read/Write/Notify/Indicate 属性是否正确，非法写入是否被拒绝
• 特征值边界：VIN 码长度、固件版本号格式、自定义特征值的取值范围

用 bleak 搭建虚拟 GATT Server 的核心代码：

from bleak import BleakServer, BleakGATTService, BleakGATTCharacteristic

# 定义车控 Service
service = BleakGATTService(
    uuid="0000fff0-0000-1000-8000-00805f9b34fb",
    characteristics=[
        BleakGATTCharacteristic(
            uuid="0000fff1-...",  # 车门状态 Read/Notify
            properties=["read", "notify"],
            value=b"\x00",  # 初始值：全锁
        ),
        BleakGATTCharacteristic(
            uuid="0000fff2-...",  # 控车指令 Write
            properties=["write"],
        ),
    ]
)

实际踩坑：bleak 的 GATT Server 在某些 Linux 内核版本上，Notify 推送延迟会随订阅特征值数量线性增长——5 个特征值时延迟 50ms，15 个特征值时飙到 400ms。原因是 BlueZ 的 gatt-server 在一个事件循环里串行处理所有通知。解决方案是限制单连接活跃 Notify 特征值数量 ≤ 8，超出部分轮询替代。

Layer 3：Notify 订阅与事件驱动验证

很多车控场景是事件驱动的——车门状态变化时车端主动推送 Notify，APP 被动接收并更新 UI。

这层的自动化难点不是"发一条 Notify"而是时序验证：

• 指令下发→车端处理→Notify 返回的端到端延迟是否在 SLA 内（我们设的标准是 300ms P99）
• Notify 丢失后的恢复机制（连接中断重连后补推）
• 高频事件下的通知合并策略

测试脚本的结构从"请求-断言"变成"订阅-等待-超时"模式：

import asyncio

async def test_door_status_notify():
    event = asyncio.Event()
    received_values = []

    def notify_handler(sender, data):
        received_values.append(data)
        event.set()

    await client.start_notify(DOOR_STATUS_CHAR_UUID, notify_handler)
    await send_lock_command()  # 下发锁车指令
    await asyncio.wait_for(event.wait(), timeout=5.0)

    assert received_values[-1] == b"\x01"  # 确认收到锁车状态

Layer 4：CCC 数字钥匙交互协议

到了数字钥匙这一层，BLE 自动化才真正打到最硬的地方。

CCC（Car Connectivity Consortium）数字钥匙协议定义了一整套 BLE 交互流程：设备发现 → 安全通道建立（SPAKE2+ 密钥协商）→ 车辆凭证交换 → 车主配对确认 → 钥匙激活。每一步都有严格的状态机和超时约束。

自动化这一层，我们不能只在 GATT 层做 Read/Write——必须模拟完整的 CCC 状态机。我们的做法：

1. 在 bleak 的 GATT Server 之上再封装一层 CCC 协议栈——实现 SPAKE2+ 握手、证书交换、车辆信息通告
2. 按 CCC spec 的状态转移图写自动化用例，覆盖每一条转移路径和超时分支
3. 引入"故障注入"能力：在交换流程的任意节点注入错误码/延迟/超时，验证 APP 的容错行为

说一个实际踩坑：SPAKE2+ 密钥协商对时钟偏差极其敏感。车端和手机端的时钟如果偏差超过 60 秒，协商直接失败。我们在自动化环境中用 NTP 同步了执行机和虚拟外设，但忘了手机端的时间——最后通过 Mock 时间戳字段绕过去。如果你们的数字钥匙测试遇到偶发配对失败，先查时钟，大概率是这个。

---

落地优先级建议

整套方案不建议一上来就全量铺开。我们的实际推进顺序是：

1. 先跑通 Layer 1-2（设备发现 + GATT 读写），搞定 BLE 连接通道——这部分两周可以落地
2. 再加 Layer 3（Notify 事件验证），覆盖控车场景——这是 ROI 最高的一层，因为手工测 Notify 时序几乎不可能
3. 最后啃 Layer 4（CCC 协议），需要读懂 CCC spec 且有密码学基础——建议安排一个对安全协议有兴趣的人专项负责

---

标签：#车联APP #BLE自动化 #数字钥匙 #GATT #自动化测试

下一篇预告：APP 18「远程控车指令链路的端到端自动化」——不是发个 HTTP 请求那么简单。