埋点验收中途换手机，怎样保证证据链不断？

埋点验收做到一半，测试手机突然需要更换，这时最危险的做法不是暂停测试，而是把新手机的日志继续追加到原来的日志文件里，然后假装什么都没有发生。

因为设备一换，至少有四件事可能同时变化：

日志来源变了；
Firebase DebugView 中选择的调试设备变了；
App 构建、环境或登录账号可能不一致；
原来建立的时间边界已经失效。

如果这些变化没有被记录，最后即使报告写着“全部通过”，也很难回答一个基本问题：这条事件究竟在哪台设备、哪个构建、哪段操作中被验证？

我在一次移动端埋点验收中遇到了中途换机。最终没有把两台手机的输出强行拼成一段“连续日志”，而是保留同一个验收任务，在新设备上重新建立正式采集窗口，并让最终结论只引用能够确认来源的新证据。

这篇文章就从这个场景出发，讲清换机后哪些东西可以继续使用，哪些必须重新开始。

换机后保持埋点证据链的核心结构

一、先纠正一个误区：证据链连续，不等于日志文件连续

埋点验收中的“连续”，指的是下面几项关系没有断：

同一份验收规格
    ↓
同一个运行编号
    ↓
明确记录的设备切换
    ↓
相互隔离的采集窗口
    ↓
逐条事件引用对应证据
    ↓
结论修改有历史记录

它不要求两台设备共用一个日志文件，更不要求旧设备采集到一半的输出必须继续参与最终判定。

恰恰相反，跨设备日志混在一起会破坏可追溯性。更稳妥的方式是把每台设备上的采集看成一个独立的“证据段”。运行任务可以继续，但每个证据段必须有自己的设备身份、时间范围、文件和哈希。

二、哪些信息应该保持不变

如果只是测试硬件发生变化，下面这些内容通常仍属于同一个验收运行：

信息	为什么保持不变
`run_id`	表示这是同一项验收任务，而不是重新创建了一份结果
原始规格及其哈希	证明换机前后验证的是同一版需求
验收矩阵	保留相同的用例编号、事件名和预期参数
已登记的原始证据	旧证据不能被覆盖或静默删除
结论历史	能看出某条用例何时、依据什么证据发生变化
最终汇总规则	仍然从同一份权威矩阵计算 Pass、Fail、Blocked 等数量

本次实践里，验收任务覆盖某个编辑模块的 15 条埋点。换机后，原来的规格、矩阵和运行编号都没有改变；最终报告仍然从同一份验收矩阵生成。

但设备、正式采集时间窗和权威日志重新登记了。早期没有满足证据门槛的探索性输出，没有被拿来支撑最终的 Pass。

三、哪些内容必须重新建立

1. 设备身份

至少重新确认：

平台与系统版本；
设备型号或脱敏设备标识；
App 包名或 Bundle ID；
App 版本和构建号；
当前测试环境；
当前登录账号是否仍属于同一测试身份。

这里不能只写“换成另一台 Android 手机”。如果新设备装的是另一个构建，后续证据实际上已经不再属于原来的运行条件。

2. 调试配置

Firebase Analytics 的调试模式是针对开发设备启用的。Android 换机后，需要在新设备上重新启用调试模式，并在 DebugView 中选择正确的设备：

adb shell setprop debug.firebase.analytics.app PACKAGE_NAME

结束后可以关闭：

adb shell setprop debug.firebase.analytics.app .none.

Firebase 官方文档也说明，DebugView 提供设备选择器，用于在多个已启用调试模式的开发设备之间切换。因此，换机后只盯着原来选中的设备，很容易把“看错设备”误判成“事件没有上报”。

3. 日志时间边界

旧设备上的开始时间，不能继续充当新设备的采集起点。

在新设备上应该：

确认设备、构建与环境；
清理日志，或者记录一个新的明确起始时间；
启动新的持续采集文件；
再通知操作者执行目标场景；
操作结束后停止采集，并记录结束时间。

Android 官方的 logcat 工具可以从设备读取系统和应用日志，但日志本身不会替你证明“这段输出属于哪次验收”。设备信息、起止时间和场景编号仍然需要由验收流程补充。

4. DebugView 观察窗口

DebugView 会展示开发设备上记录的原始事件，并按设备区分。换机后要重新确认：

当前选择的是新设备；
事件时间与新一轮操作一致；
目标事件名和必要参数匹配；
不是旧设备留下的历史事件；
同一动作是否发生了重复上报。

换机后的埋点验收流程

四、一个可落地的换机处理流程

第一步：冻结旧设备现场

不要急着清理旧文件。先完成三件事：

停止旧设备的日志监听；
保存已经产生的原始日志和截图；
记录停止原因、停止时间和当时进行到的用例。

旧证据可以保留，但不代表它已经足以支撑结论。尚未达到 SDK、DebugView 或网络接收层门槛的用例，应该继续保持 Not Run、In Progress 或 Blocked，不能因为“好像看到过日志”就先判 Pass。

第二步：判断是否还能使用同一个运行编号

可以继续使用同一个 run_id 的典型条件是：

验收规格没有变化；
平台没有变化；
App 包和构建一致；
测试环境一致；
分析平台项目一致；
更换设备不会改变待验收的产品逻辑。

如果构建、环境、平台或埋点规格已经变化，更稳妥的做法是新建运行，而不是在旧运行里增加一句备注。

变化	建议
只更换同平台真机，构建和环境相同	保留运行，创建新设备证据段
Android 换成 iOS	新建运行
测试环境换成预发布环境	新建运行
App 构建发生变化	新建运行，或按团队规则创建明确的新 revision
埋点规格更新	新建运行并保存新规格哈希
仅更换测试账号	可保留运行，但必须登记新的账号角色和切换时间

第三步：登记设备切换事件

建议至少记录下面这些字段：

{
  "segment_id": "SEG-02",
  "reason": "device_switched",
  "platform": "android",
  "device_label": "Android 真机 B",
  "app_build": "<BUILD>",
  "environment": "test",
  "capture_started_at": "2026-08-19T21:21:08+08:00",
  "capture_ended_at": "2026-08-19T21:43:24+08:00",
  "raw_log": "raw/segment-02.log",
  "raw_log_sha256": "<SHA256>"
}

segment_id 是本文根据实践归纳出的通用建模方式，不代表所有工具都必须使用这个字段。关键是让设备、时间窗和证据文件形成明确的一对一关系。

第四步：在新设备上做一个最小冒烟

正式重跑剩余用例前，先选择一个低成本事件验证整条链路：

页面操作成功
  → App 尝试记录事件
  → Analytics SDK 接收
  → DebugView 选择了正确设备并出现事件

如果冒烟失败，优先排查调试模式、设备选择、包名、网络、构建和分析项目，而不是立即怀疑所有业务埋点都失效。

第五步：重跑所有受影响用例

换机前已经获得完整权威证据的用例，可以保留原结论；只有模糊日志、未保存截图或未确认 SDK 接收的用例，应在新设备上重跑。

在本次实践中，最终采用了更保守的方式：在新设备上重新建立正式窗口，并用一份完整的 SDK 日志覆盖全部 15 条验收项。最终每条 Pass 都指向同一份已登记、带 SHA-256 的权威日志，部分场景再补充截图和网络证据。

第六步：通过证据索引，而不是文件名，关联结论

一份最小证据索引可以长这样：

evidence_id	case_id	segment	layer	captured_at	source	sha256
EV-001	GLOBAL	SEG-02	sdk	21:43:37	`raw/segment-02.log`	`<SHA256>`
EV-002	TC-003	SEG-02	product	21:43:50	`evidence/editor.png`	`<SHA256>`
EV-003	TC-007	SEG-02	network	21:44:04	`evidence/save-api.log`	`<SHA256>`

这样做有三个好处：

同一份全局 SDK 日志可以被多条用例引用；
截图、SDK 日志和网络证据可以分层组合；
文件被替换后，哈希变化会暴露证据不一致。

第七步：保留结论变化历史

不要直接把 Not Run 覆盖成 Pass，然后只留下最终表格。至少保留：

修改时间 | 用例编号 | 原结果 | 新结果 | 原因 | 证据引用 | 操作者

如果换机前曾经给出临时结论，换机后被新证据推翻，也应该在历史里说明撤回原因，而不是让旧结论悄悄消失。

五、最终 Pass 应该由什么证据支撑

换机不会降低埋点验收门槛。

一条用例判 Pass，仍然要确认：

执行了正确的产品动作；
业务结果符合场景前提；
精确匹配目标事件名；
必填参数、类型和必要顺序正确；
至少获得 SDK、DebugView 或网络接收层证据；
证据能够定位到明确设备段和采集时间窗。

App 页面打开成功、自动页面事件出现，或者业务层打印了一句 track，都不能代替目标事件的接收证据。

六、换机后最容易出现的五种误判

1. 还在看旧设备的 DebugView

新设备已经操作完成，DebugView 却没有目标事件。真正原因可能只是设备选择器仍停留在旧设备。

2. 新设备安装了不同构建

事件名相同不代表证据可以混用。构建不同，就可能对应不同代码和埋点实现。

3. 两台设备日志写入同一个文件

后续无法证明某行日志来自哪台设备，也无法给出可靠的采集起止时间。

4. 把换机前的“看到过”写成 Pass

没有保留原始文件、时间戳和接收层证据，就只能算观察线索，不能成为最终验收证据。

5. 只更新报告，不更新权威矩阵

Excel 写着 15 条通过，CSV 或系统矩阵仍有 2 条 Not Run，说明验收产物已经互相矛盾。最终汇总必须从同一份权威矩阵生成。

七、AI 和测试人员怎样分工

AI 适合负责	测试人员必须确认
比较换机前后的构建、环境和包身份	是否允许继续使用同一个验收运行
创建新的日志时间边界和证据索引	新设备上的账号、权限和业务状态是否正确
按时间戳关联事件、参数和截图	哪些旧用例必须重跑
检查报告总数与矩阵是否一致	产品预期、缺陷等级和最终放行判断
发现证据冲突并生成待确认项	处理验证码、授权和敏感账号操作