第1章:理解快照回归——定义、目标与适用场景
1.1 定义与目标
快照回归是对 Mock BLE 设备在特定时间点的完整数据状态(含特征值、句柄、描述符、MTU 配置、连接参数等)进行序列化存档,并与后续版本的数据快照执行逐字节/逐字段精确比对的过程。其核心目标包括:
- 消除波动干扰:屏蔽 UI 渲染、系统时钟、日志输出等非数据因素对回归结果的污染。
- 提升回归效率:将分钟级的全链路回归压缩至秒级,仅聚焦数据层一致性。
- 建立基线契约:为 Mock BLE 设备的版本发布提供可追溯、可复现的数据基准。
要点速记: 快照回归面向的是“数据状态”而非“功能流程”。它回答的是“数据变没变”,而不是“功能通不通”。
1.2 与传统回归测试的区别
| 对比维度 | 传统回归 | 快照回归 |
|---|---|---|
| 验证对象 | 用户操作流程、UI 元素、端到端链路 | 数据报文、特征值快照、属性协议栈 |
| 执行时长 | 通常依赖设备交互,10~30 分钟/轮 | 秒级完成,适合 CI 流水线频繁触发 |
| 结果判定 | 断言通过/失败,依赖环境稳定性 | 差异清单对比,明确标注变更字段 |
| 环境耦合 | 高(受系统调度、外设干扰大) | 低(仅需模拟器运行时数据) |
| 维护成本 | 高(频繁更新定位器、截图基线) | 中(需管理快照版本与基线仓库) |
1.3 适用场景
- BLE 固件 OTA 升级验证:确认升级前后设备数据特征值集合未发生非预期偏移。
- Mock 模拟器版本兼容性矩阵:快速覆盖旧版 App 对新版模拟器的数据交互是否正常。
- 自动化测试数据基线确立:在复杂测试套件执行前,预先校验 Mock 数据源是否处于已知健康状态。
- 协议栈回归比:对 GATT 层属性、MTU 协商结果、连接间隔等底层参数进行快照监控。
注意: 快照回归无法覆盖功能逻辑和 UI 交互正确性,必须与传统功能回归互补使用。
1.4 前置条件
- 工具链就绪:安装
ble-mock-snapshotCLI(版本 ≥ 2.1.0)。 - 存储仓库:已通过 Git LFS 初始化的基线仓库,用于存放 .bls 快照文件。
- 模拟器可达:Mock BLE 设备模拟器处于运行状态且暴露管理接口(默认端口 19021)。
- 历史快照:目标基线版本的历史快照已打标签并存档。
# 检查工具版本
ble-mock-snapshot version
# 初始化基线仓库
git lfs track "*.bls"
git add .gitattributes
git commit -m "chore: track BLE snapshot files with LFS"
1.5 操作步骤
| 步骤 | 操作描述 | 命令示例 |
|---|---|---|
| 1 | 标记当前版本为基线 | ble-mock-snapshot tag --name baseline_v2.1 --device hrm |
| 2 | 捕获新版 Mock 设备快照 | ble-mock-snapshot capture --device hrm --output snapshots/hrm_v2.2.bls |
| 3 | 执行基线比对 | ble-mock-snapshot compare --baseline tag:baseline_v2.1 --target snapshots/hrm_v2.2.bls --report report.json |
| 4 | 审核差异报告 | 打开 report.json 或 Allure 仪表盘 |
1.6 输入输出物
- 输入:Mock BLE 设备 IP:Port、认证 、基线标签(如
baseline_v2.1)。 - 输出:.bls 二进制快照文件、
report.json结构化报告、delta.log详细变更日志。
{
"status": "PASS",
"delta_count": 0,
"execution_time_ms": 12450,
"checkpoint": "v2.2.0",
"baseline": "baseline_v2.1"
}
1.7 责任边界
- QA 工程师:定义快照采集粒度,维护测试用例→基线标签映射关系。
- 开发工程师:审查快照 Delta,确认差异是否为预期协议变更。
- 基础设施团队:保障 Git LFS 仓库的可用性、存储容量和访问权限。
1.8 记录材料与异常处理
| 异常场景 | 错误码 | 处理措施 |
|---|---|---|
| 快照文件哈希校验失败 | SNAPSHOT_CORRUPTION |
从 Git LFS 重新拉取完整文件并校验 |
| Mock 模拟器连接拒绝 | CONNECTION_REFUSED |
检查模拟器运行状态和管理端口 |
| 基线标签不存在 | TAG_NOT_FOUND |
执行 snapshot tag --list 确认正确标签名 |
| 差异超阈值(P0 漂移) | CRITICAL_MISMATCH |
自动阻断流水线,提 JIRA 缺陷到开发组 |
记录材料:Jenkins 构建日志、Allure 报告链接、Git 提交 SHA、快照比对原始 JSON。
1.9 验收标准
- 快照捕获成功率 ≥ 99.5%(允许网络抖动重试 1 次)。
- 从触发回归到输出报告时间 ≤ 30 秒。
- 报告中清晰区分“无差异通过”、“预期变更”、“非预期缺陷”三类状态。
- 所有非预期差异均已在缺陷管理系统中创建对应任务。
SOP 检查点: 第 1 章完成后,团队应能从零搭建一次快照回归流程并理解其与传统回归的定位差异。
快照回归核心概念结构图