今天我尝试把 AI 真正接入一次移动端埋点验收：给它埋点文档、测试设备和 Firebase DebugView，让它协助触发场景、读取日志、核对参数，并最终整理验收表。

这次实践最重要的收获不是“AI 可以帮我点手机”，而是我建立了一条更可靠的埋点证据链：

埋点文档
  ↓
用户操作与业务结果
  ↓
App 业务层是否调用埋点
  ↓
Analytics SDK 是否接收或拒绝
  ↓
DebugView 是否出现事件与参数
  ↓
验收表与缺陷证据

其中最容易误判的一点是：App 日志打印了事件，不等于 Firebase 已经接收。

一、为什么埋点测试适合 AI 协助

埋点验收包含大量重复但需要保持一致的工作：

  • 从文档中提取事件名、触发时机和预期参数；
  • 把埋点映射到 App 的具体操作路径；
  • 在 Android、iOS 不同端重复执行；
  • 从连续日志中筛选目标事件；
  • 对比事件名、参数、顺序和出现次数；
  • 把结果回填到 Excel，并整理成开发可复现的问题。

这些任务同时具备“结构化”和“高上下文切换”两个特点。AI 很适合处理前者，也能减少后者带来的人工遗漏。

但埋点测试不是把文档扔给 AI 后等待一句“全部通过”。AI 必须接触真实环境和原始证据，否则它只能生成测试思路，不能给出验收结论。

二、开始前要准备什么

1. 埋点文档

最少需要包含：

字段 作用
业务模块 确定所在流程
事件名 与日志、DebugView 精确匹配
事件类型 区分曝光、点击、结果等
触发时机 决定什么时候采集证据
预期参数 校验名称、值、类型和必填性
平台或页面形态 区分 Android/iOS、半屏/全屏等变体

2. 可操作的测试环境

  • 已安装目标构建的 Android 或 iOS 真机；
  • 可进入 Firebase 对应测试项目的账号；
  • 测试账号及必要的验证码协助；
  • 已确认可以创建测试数据、授予哪些权限、哪些第三方授权必须由人完成。

3. Firebase 调试模式

Android 可以通过 ADB 为指定包开启 Analytics 调试模式：

adb shell setprop debug.firebase.analytics.app PACKAGE_NAME

结束后关闭：

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

iOS 开发构建可使用 -FIRDebugEnabled 启用调试，使用 -FIRDebugDisabled 关闭。具体配置和最新说明以 Firebase DebugView 官方文档 为准。

三、先让 AI 做静态预检

真机操作前，先检查文档本身，可以提前发现一批“无需点击就能确定”的风险：

  • 事件名是否合法；
  • 事件名是否过长；
  • 是否使用保留前缀或保留名称；
  • 参数是否缺少定义；
  • 同一动作在不同端的前缀是否矛盾；
  • 文档中是否存在重复事件或不可达路径。

以 Firebase Analytics 为例，官方 Android SDK 参考说明自定义事件名最长为 40 个字符，只能使用字母、数字和下划线，必须以字母开头，并且不能使用 firebase_、google_、ga_ 等保留前缀。超出采集限制的事件不会被正常处理，详见 Firebase Android Event 参考 和 Google Analytics 事件采集限制。

今天的实践里，静态长度检查非常有价值：部分事件名在业务层能够打印，但 SDK 随后明确提示名称过长并拒绝记录。如果只看 App 自己的 track 日志，就会错误地把它判为通过。

四、用五层证据链执行验证

第 1 层：产品操作

先确认实际执行的动作与文档一致，例如：

  • 从哪个入口进入；
  • 当前是登录、注册还是游客状态；
  • 是弹窗、半屏还是全屏页面；
  • 点击、曝光、返回、授权成功或取消分别是什么动作；
  • 操作后业务是否真的成功。

业务结果很重要。假如登录本身失败，首页曝光事件没出现不能直接判为埋点漏报。

第 2 层：App 业务日志

业务日志可以证明 App 的埋点封装层是否尝试调用事件。为了降低噪声，可以在每个短场景前清理或记录日志时间点，然后只执行一个动作链。

AI 在这里适合做：

  • 实时筛选目标事件；
  • 按时间戳关联用户动作；
  • 提取事件名和参数；
  • 对比相似前缀；
  • 发现“预期是 page，实际却是 sheet”一类实现偏差。

第 3 层：Analytics SDK 诊断日志

这一层解释“为什么 App 看起来调用了，DebugView 却没有”。

常见原因包括：

  • 事件名为空、超长或字符非法；
  • 使用保留事件名或前缀；
  • 参数名或参数值非法；
  • 参数数量超限；
  • 调试设备、应用包、Firebase 项目或构建不匹配。

Firebase 官方错误码文档明确说明，事件名非法时事件会被忽略，并生成带错误信息的诊断事件；SDK 控制台日志通常能给出更直接的拒绝原因，详见 Firebase Analytics 错误码。

第 4 层：DebugView

DebugView 用来确认 Firebase 在调试设备上实际收到了什么：

  • 事件是否出现；
  • 时间是否与操作一致；
  • 参数名、参数值和用户属性是否正确；
  • 同一事件是否重复；
  • 一组事件的先后顺序是否合理；
  • 当前选择的是否是正确调试设备。

我的实践体会是：设备日志适合快速定位，DebugView 适合最终抽查与可视化确认。 如果每个动作都只等待网页刷新，速度慢且容易受到页面状态影响；如果完全不看 DebugView，又可能只验证到 App 自己的封装层。

第 5 层：验收表

最终结果不应只有 Pass/Fail。建议至少区分：

状态 定义
Pass 触发、事件、必填参数和必要顺序均已确认
Fail 已到达预期场景，证据证明事件漏报、拒收、重复或参数错误
Not Run 本轮明确没有执行
Blocked 被设备、环境、权限、账号或工具阻塞
N/A 已确认当前平台或产品设计不适用
待确认 产品预期或埋点文档是否过期还未确认

这几个状态不能混用。页面上找不到某个入口时，可能是实现缺失，也可能是埋点文档没有同步更新。在产品确认前，直接判 Bug 或直接判 N/A 都不严谨。

五、一个典型误判：App 已触发，Firebase 没收到

可以把今天遇到的问题抽象成下面这组证据：

[App] track: signup_profile_referral_code_autofill_click
[Firebase SDK] Name is too long, maximum supported length: 40
[Firebase SDK] Invalid public event name. Event will not be logged

正确结论是：

  • 用户操作已完成；
  • App 业务层已尝试触发；
  • Firebase SDK 拒绝了事件；
  • DebugView 不会出现目标事件；
  • 验收结果应为 Fail，而不是 Pass，也不是“DebugView 延迟”。

这里暴露了一个很重要的分层思维：

调用成功 ≠ SDK 接收成功 ≠ 服务端可见 ≠ 分析口径正确

六、AI 还需要学会撤回错误结论

今天的验证中，也出现过一次旧结论缺少原始日志、开发反馈与之矛盾的情况。正确做法不是继续坚持，而是：

  1. 回到原始日志，检查结论是否真的有证据；
  2. 暂时从已确认缺陷中撤回证据不足的描述；
  3. 清理日志并重新执行一条干净的对照链路；
  4. 用同一次操作中的关联参数确认事件属于同一流程；
  5. 更新验收表，保留更正后的结论。

这也是 AI 测试很关键的一条原则：AI 的价值不在于永远第一遍就判断正确，而在于它能否在新证据出现后可追溯地修正结论。

七、AI 与测试人员如何分工

AI 适合负责 测试人员必须把关
解析埋点文档、生成验收矩阵 确认业务预期和文档是否仍有效
控制已授权设备执行重复路径 输入验证码、确认敏感权限和第三方授权
实时筛选日志、对齐时间戳 判断某个缺失入口是否真的属于缺陷
检查事件名、参数、顺序和重复 决定缺陷优先级与上线风险
生成 Excel 结果和缺陷摘要 审核最终结论是否可对外发送
在争议后重放场景、修正记录 对账号、数据和环境安全负责

八、可直接复用的提示词

你是我的埋点验收助手。请基于我提供的埋点文档和已授权测试环境完成验证。

要求：
1. 先把文档整理成“模块、场景、事件名、触发时机、预期参数、平台”的验收矩阵。
2. 真机操作前先静态检查事件名、参数名、重复项和不同端命名一致性。
3. 每个场景分别记录：用户动作、业务结果、App 埋点日志、Analytics SDK 日志、DebugView 结果。
4. 不要把 App 业务层打印事件当作 Firebase 已接收的证明。
5. 结果严格区分 Pass、Fail、Not Run、Blocked、N/A、待确认。
6. 如果页面入口不存在，先判断是实现缺失、平台不适用还是文档过期，不要直接报 Bug。
7. 遇到账号创建、验证码、位置权限、Apple/Google 授权等操作时先让我确认。
8. 每个 Fail 输出复现步骤、实际结果、预期结果、原始证据、时间戳和测试环境。
9. 如果新证据推翻旧结论，明确撤回并更新验收表。
10. 最终生成一份验收明细和一份开发可直接阅读的失败问题汇总。

九、我把这次方法沉淀成了什么

这次工作最终沉淀成两类资产：

  1. 一套 AI 协助埋点验收的方法：静态预检、五层证据链、状态分类、争议复测和验收报告。
  2. 一个可复用 Skill：以后再给 AI 埋点文档时，它会按同一套证据标准执行，而不是从零开始临时判断。

我也把“从真实工作生成脱敏技术博文”的流程单独做成了写作 Skill。这样，工作不只产出一次验收结果，还能继续沉淀为复盘、教程和长期可复用的个人方法库。

十、最后的检查清单

  • 埋点文档已转为逐行验收矩阵
  • 已记录平台、设备、系统、App 构建和环境
  • Firebase 调试模式已启用，DebugView 设备选择正确
  • 事件名和参数已做静态规则检查
  • 每个场景都有明确操作和业务结果
  • 已同时检查 App 日志和 SDK 诊断日志
  • DebugView 中已核对事件、参数、顺序和重复
  • Fail 都有原始证据与时间戳
  • N/A、Blocked、Not Run、待确认没有混用
  • 有争议的结论已重新查看证据或干净复测
  • 报告中没有真实账号、Token、内部地址和项目标识

总结

AI 可以把埋点测试从“人工点页面、肉眼找事件”升级成一套更连续的证据处理流程，但它不能代替真实环境，也不能代替产品判断。

真正可靠的协作方式是：让 AI 负责结构化、重复执行、日志关联和报告整理，让测试人员掌握权限、业务预期、风险判断和最终结论。只要坚持“没有证据就不判定，证据变化就修正”，AI 就不只是写用例的助手，也可以成为移动端数据质量验证的一部分。

参考资料