做埋点测试这件事很多团队都熟悉流程但真正做起来通常还是一套偏手工的路径产品给一份埋点表测试自己翻需求、自己找账号、自己连手机、自己点页面、自己等上报、自己去日志平台查再把结果一条条复制回表格最后给研发提 Bug。这套方式能完成任务但问题也很明显重复动作太多执行成本高同样的需求换一个版本还要重新组织一遍流程证据分散复测时经常要重新拼背景“查到日志”不等于“埋点通过”多报、错报、串报很容易漏掉Bug 虽然提了但从首测失败到修复复测闭环仍然依赖人工记忆所以我把这套流程进一步沉淀成了 3 个 Skill让埋点测试从一次次重复劳动逐步变成一条可以复用的工程链路tracking-workbook-prepare把原始埋点 CSV 整理成可直接执行测试的 XLSXtracking-android-verify执行 Android 埋点真机验证、日志查询、表格回写和缺陷提单tracking-ios-verify执行 iOS 埋点真机验证、日志查询、表格回写和缺陷提单一、为什么要把埋点测试做成 Skill埋点测试看起来只是“点一下页面然后查一下日志”但真正影响效率和质量的不是这一个点击动作而是背后几件事能不能被稳定串起来需求表是否已经整理成可执行形式操作路径是否足够明确真机执行时是否记录了准确时间窗日志查询时是否绑定了设备、版本、事件和时间结果判定是否做到了字段级校验未通过是否可以直接生成结构化 Bug修复后能不能按原上下文自动复测如果这些环节全靠人脑和临时经验测试越做越累复测越做越散。而 Skill 的价值就在于把“每次都要重新组织一次”的流程沉淀成稳定可复用的执行能力。二、这 3 个埋点 Skill 分别解决什么问题1.tracking-workbook-prepare这个 Skill 解决的是埋点测试最前置的问题原始需求表并不适合直接测试。原始 CSV 往往只有埋点基础字段例如页面名称区块名称元素名称事件名重要描述版本开发需求记录相关列但真正执行测试时还缺很多关键信息比如实际操作路径怎么走测试数据要准备什么曝光/点击/浏览的判定口径是什么哪些地方存在不确定项需要提前确认所以这个 Skill 会把原始 CSV 整理成一份测试可直接使用的整理版 Excel并自动补出几类结构化信息操作路径/操作数据补充操作路径补充操作数据定位/验证说明需求/APP依据疑问点/待确认待确认清单对应本地脚本python3 /Users/leiyuxing/.codex/skills/tracking-workbook-prepare/scripts/csv_to_tracking_workbook.py\--input/绝对路径/埋点列表_xxx.csv2.tracking-android-verify这个 Skill 解决的是 Android 真机埋点验证的闭环问题。它的职责不是只帮忙“查一条日志”而是负责把下面这些动作串起来连接 Android 手机按整理版埋点表执行目标场景记录触发动作和时间窗查询埋点日志判定通过/未通过回写安卓测试结果回写完整 JSON未通过按埋点编号拆分提 Bug3.tracking-ios-verify这个 Skill 和 Android 版本的职责类似只是落在 iOS 设备验证上。它保留了同样的核心约束不是只看有无日志必须校验事件数量必须校验关键字段必须回写完整 JSON必须按埋点编号单独提 Bug这样 Android 和 iOS 的测试链路虽然设备不同但方法论和结果口径是一致的。三、Skill 化之前埋点测试最耗时间的地方在哪真正做过版本埋点验收的人通常都知道最耗时间的不只是点页面而是中间的上下文搬运。典型场景是这样的先从埋点需求表里找这一条是测什么再判断它是 Android 还是 iOS还是都要测再找对应账号再进 App 找入口再确定这次操作具体发生在几点几分几秒再去日志里拼查询条件查到了还要继续判断是不是本次操作产生的最后再把结果抄回 Excel复制 JSON提 Bug这里面真正“有效验证”的时间其实不多大量时间都花在理解需求组织步骤切换工具复制证据补全说明Skill 的价值不是神奇地替代测试判断而是把这些高频、重复、容易出错的动作先收拢成稳定流程。四、埋点 Skill 的整体工作流下面这张图更适合用来理解这套 Skill 化方案的全貌。从执行角度看整体工作流可以概括成下面这条链原始埋点 CSVtracking-workbook-prepare整理版 XLSXtracking-android-verify / tracking-ios-verify真机执行日志查询字段判定回写结果与完整 JSON按埋点编号提 Bug修复后自动复测这条链路的关键不是某一环多复杂而是每一环之间的输入输出被固定住了。例如tracking-workbook-prepare的输出不是一张“更好看”的表而是一张后续 Skill 可以稳定消费的执行表tracking-android-verify/tracking-ios-verify的输出不是一句“通过”而是结构化测试结果 完整 JSON 缺陷材料修复后的复测也不需要重新组织背景而是可以回到原埋点编号、原页面路径、原查询规则继续验证五、第一步为什么要先整理 Workbook很多埋点测试失败并不是因为 App 上报错了而是测试前置信息根本不够。这张图可以直接说明整理版工作簿的作用Skill 化之后整理版表不再只是“记录需求”而是同时承担三件事执行入口每一条埋点都能直接看到操作路径、操作数据和验证说明结果载体Android / iOS 结果回写在固定列完整 JSON 回写在固定列问题上下文哪些字段需要重点看哪些地方还存在待确认项哪些行需要补充业务样例这一步做得越扎实后面的真机验证越稳定。因为测试不再是在“解释需求”而是在“执行需求”。六、第二步Android / iOS 真机验证为什么适合做成 Skill埋点测试和普通 UI 测试有一个很大的不同它不是只验证页面行为而是同时验证“页面行为 日志上报 字段口径”。所以一个合格的真机埋点 Skill至少要同时处理 4 层问题设备层手机是否在线版本是否正确登录态是否正确场景层入口路径是否准确测试数据是否存在按钮、卡片、筛选器是否可见日志层事件是否上报是否命中本次时间窗是否是本机、本版本产生的日志判定层是否多报是否少报是否错报是否串报对应的真机执行流可以理解成这样七、Skill 在自动化里的真正应用不是“自动点击”而是“自动组织闭环”很多人一提自动化第一反应是点击、输入、滑动。但埋点场景里自动化最有价值的地方往往不是这几个动作本身而是把它们和日志证据、表格回写、缺陷流转连起来。更准确地说这套 Skill 化方案把自动化应用到了 5 个层面1. 需求整理自动化原始埋点表转整理版不再完全靠手工补充。2. 真机执行标准化不再每条埋点都从头想“这次怎么测”而是优先按整理版给出的路径执行。3. 日志查询自动化用本地查询脚本把EID设备版本时间窗组合成稳定查询条件。4. 字段级判定自动化把“看起来像通过”升级成“字段、数量、时间窗都符合预期才算通过”。5. 缺陷闭环自动化未通过项不只是标红而是继续进入结果回写结构化描述Yunxiao 提单修复后复测这个阶段最能体现 Skill 的工程价值。否是否是否是真机操作完成查询到日志?未上报数量是否正确?重复上报/少报字段是否匹配?字段错误/串报判定通过回写完整 JSON 与问题描述按埋点编号提 Bug回写通过结果与完整 JSON八、为什么“完整 JSON 回写”必须是硬规则这件事在埋点测试里特别重要。如果表里只写一句“通过”或者“未通过”后面会有几个问题研发看不到具体上报内容产品没法复核字段是否和需求一致复测时测试自己也要重新查一次日志需求变更后无法回头核对历史口径而把完整 JSON 固定回写到版本开发需求记录.黏贴json之后价值会非常直接通过项也能复核不是只有失败才留证据失败项更容易归因是没报、错报、多报还是字段错一眼能看出来复测上下文可复用下次不是重新查而是拿历史 JSON 对照这张图能更直观地说明日志查询和字段核对的关系九、为什么 Android / iOS 两个 Skill 要拆开这不是为了“多建一个 Skill”而是为了把平台差异隔离开。虽然两边的业务需求和字段口径是一套但实际执行时差异很明显设备连接方式不同自动化工具链不同页面元素定位策略不同日志触发时机偶尔也会不同如果把 Android 和 iOS 混成一个 Skill最终往往会出现两种问题说明越来越长真正执行时反而不清晰平台差异和公共规则混在一起不利于维护拆成两个 Skill 后公共规则保持一致完整 JSON 必须回写点击一次上报两次算 bugBug 必须按埋点编号拆开查询必须绑定时间窗和设备而平台差异则留在各自 Skill 内部处理。这样更稳。十、埋点 Skill 和 Appium / ADB / 查询脚本是什么关系Skill 不是替代这些工具而是把这些工具组织起来。可以这么理解ADB / 真机操作工具负责设备连接、基础操作、环境确认Appium负责复杂页面流程、元素定位、可见性确认日志查询脚本负责把埋点证据查出来Skill负责决定什么时候调用哪一个能力以及最终如何落成闭环下面这张图很适合理解 Appium 在这条链路里的位置所以从工程上看Skill 更像一个“流程层”把自然语言需求转成执行路径把执行路径转成日志查询条件把日志结果转成表格结论和缺陷材料十一、埋点 Skill 最适合解决哪些问题这套 Skill 特别适合下面这些场景1. 版本新增埋点较多每个版本都要从头整理和执行重复度很高Skill 化收益最大。2. 多平台都要测同一批埋点 Android / iOS 都要验证时统一规则、拆分执行最合适。3. 缺陷复测频繁如果一个版本里埋点问题较多后续反复复测时Skill 能明显减少背景重建成本。4. 字段归因容易争议例如有日志但字段错点击一次上报两次页面名按 tab 动态拼接from_nav / content_type 依赖页面上下文这类问题只靠一句“未通过”很难推动修复结构化 Skill 更适合。十二、做成 Skill 之后最大的变化是什么最大的变化不是“测试更快了”这么简单而是埋点测试终于有了稳定的工程结构。以前更像这样需求在表里操作在脑子里证据在日志里结论在聊天里Bug 在 Yunxiao 里现在更像这样需求先整理进可执行 Workbook真机验证按 Skill 执行日志证据回写回同一张表未通过直接流向缺陷闭环修复后继续按原上下文复测对应闭环过程可以看这张图这意味着测试工作从“人肉搬运信息”逐渐转成“维护一条稳定流程”。当流程一旦稳定下来后续每个版本的边际成本都会继续下降。十三、下一步还可以怎么继续演进如果这套 Skill 继续往下做我认为有几个方向很值得补1. 进一步补强待确认规则让tracking-workbook-prepare不只是生成整理版还能更聪明地区分可直接执行项需要样例数据项需要开发确认字段枚举项2. 把复测触发再自动化例如Yunxiao 状态变成“待复测”自动回到原埋点编号自动复用原时间窗策略和字段规则3. 建立埋点结果看板把通过率未通过分布多报/少报/错报类型待复测积压量做成版本级汇总视图而不只是逐条表格记录。4. 沉淀更多专项 Skill比如再拆分成埋点复测 Skill埋点 Bug 复核 Skill埋点 JSON 差异对比 Skill埋点需求口径校对 Skill这样整条链会更细也更稳定。十四、结语埋点测试本身并不新但把埋点测试做成 Skill会带来一个很实在的变化测试不再是“这次把任务做完”而是“把这类任务沉淀成以后还能反复用的能力”。这 3 个 Skill 的价值不在于名字而在于它们把一条原本零散的链路固定了下来tracking-workbook-prepare解决输入问题tracking-android-verify解决 Android 执行闭环tracking-ios-verify解决 iOS 执行闭环真正有用的自动化从来不是只会自动点页面而是能把需求、执行、查询、判定、回写和缺陷流转真正串起来。埋点 Skill 的意义也正在这里。
埋点skill使用与自动化
做埋点测试这件事很多团队都熟悉流程但真正做起来通常还是一套偏手工的路径产品给一份埋点表测试自己翻需求、自己找账号、自己连手机、自己点页面、自己等上报、自己去日志平台查再把结果一条条复制回表格最后给研发提 Bug。这套方式能完成任务但问题也很明显重复动作太多执行成本高同样的需求换一个版本还要重新组织一遍流程证据分散复测时经常要重新拼背景“查到日志”不等于“埋点通过”多报、错报、串报很容易漏掉Bug 虽然提了但从首测失败到修复复测闭环仍然依赖人工记忆所以我把这套流程进一步沉淀成了 3 个 Skill让埋点测试从一次次重复劳动逐步变成一条可以复用的工程链路tracking-workbook-prepare把原始埋点 CSV 整理成可直接执行测试的 XLSXtracking-android-verify执行 Android 埋点真机验证、日志查询、表格回写和缺陷提单tracking-ios-verify执行 iOS 埋点真机验证、日志查询、表格回写和缺陷提单一、为什么要把埋点测试做成 Skill埋点测试看起来只是“点一下页面然后查一下日志”但真正影响效率和质量的不是这一个点击动作而是背后几件事能不能被稳定串起来需求表是否已经整理成可执行形式操作路径是否足够明确真机执行时是否记录了准确时间窗日志查询时是否绑定了设备、版本、事件和时间结果判定是否做到了字段级校验未通过是否可以直接生成结构化 Bug修复后能不能按原上下文自动复测如果这些环节全靠人脑和临时经验测试越做越累复测越做越散。而 Skill 的价值就在于把“每次都要重新组织一次”的流程沉淀成稳定可复用的执行能力。二、这 3 个埋点 Skill 分别解决什么问题1.tracking-workbook-prepare这个 Skill 解决的是埋点测试最前置的问题原始需求表并不适合直接测试。原始 CSV 往往只有埋点基础字段例如页面名称区块名称元素名称事件名重要描述版本开发需求记录相关列但真正执行测试时还缺很多关键信息比如实际操作路径怎么走测试数据要准备什么曝光/点击/浏览的判定口径是什么哪些地方存在不确定项需要提前确认所以这个 Skill 会把原始 CSV 整理成一份测试可直接使用的整理版 Excel并自动补出几类结构化信息操作路径/操作数据补充操作路径补充操作数据定位/验证说明需求/APP依据疑问点/待确认待确认清单对应本地脚本python3 /Users/leiyuxing/.codex/skills/tracking-workbook-prepare/scripts/csv_to_tracking_workbook.py\--input/绝对路径/埋点列表_xxx.csv2.tracking-android-verify这个 Skill 解决的是 Android 真机埋点验证的闭环问题。它的职责不是只帮忙“查一条日志”而是负责把下面这些动作串起来连接 Android 手机按整理版埋点表执行目标场景记录触发动作和时间窗查询埋点日志判定通过/未通过回写安卓测试结果回写完整 JSON未通过按埋点编号拆分提 Bug3.tracking-ios-verify这个 Skill 和 Android 版本的职责类似只是落在 iOS 设备验证上。它保留了同样的核心约束不是只看有无日志必须校验事件数量必须校验关键字段必须回写完整 JSON必须按埋点编号单独提 Bug这样 Android 和 iOS 的测试链路虽然设备不同但方法论和结果口径是一致的。三、Skill 化之前埋点测试最耗时间的地方在哪真正做过版本埋点验收的人通常都知道最耗时间的不只是点页面而是中间的上下文搬运。典型场景是这样的先从埋点需求表里找这一条是测什么再判断它是 Android 还是 iOS还是都要测再找对应账号再进 App 找入口再确定这次操作具体发生在几点几分几秒再去日志里拼查询条件查到了还要继续判断是不是本次操作产生的最后再把结果抄回 Excel复制 JSON提 Bug这里面真正“有效验证”的时间其实不多大量时间都花在理解需求组织步骤切换工具复制证据补全说明Skill 的价值不是神奇地替代测试判断而是把这些高频、重复、容易出错的动作先收拢成稳定流程。四、埋点 Skill 的整体工作流下面这张图更适合用来理解这套 Skill 化方案的全貌。从执行角度看整体工作流可以概括成下面这条链原始埋点 CSVtracking-workbook-prepare整理版 XLSXtracking-android-verify / tracking-ios-verify真机执行日志查询字段判定回写结果与完整 JSON按埋点编号提 Bug修复后自动复测这条链路的关键不是某一环多复杂而是每一环之间的输入输出被固定住了。例如tracking-workbook-prepare的输出不是一张“更好看”的表而是一张后续 Skill 可以稳定消费的执行表tracking-android-verify/tracking-ios-verify的输出不是一句“通过”而是结构化测试结果 完整 JSON 缺陷材料修复后的复测也不需要重新组织背景而是可以回到原埋点编号、原页面路径、原查询规则继续验证五、第一步为什么要先整理 Workbook很多埋点测试失败并不是因为 App 上报错了而是测试前置信息根本不够。这张图可以直接说明整理版工作簿的作用Skill 化之后整理版表不再只是“记录需求”而是同时承担三件事执行入口每一条埋点都能直接看到操作路径、操作数据和验证说明结果载体Android / iOS 结果回写在固定列完整 JSON 回写在固定列问题上下文哪些字段需要重点看哪些地方还存在待确认项哪些行需要补充业务样例这一步做得越扎实后面的真机验证越稳定。因为测试不再是在“解释需求”而是在“执行需求”。六、第二步Android / iOS 真机验证为什么适合做成 Skill埋点测试和普通 UI 测试有一个很大的不同它不是只验证页面行为而是同时验证“页面行为 日志上报 字段口径”。所以一个合格的真机埋点 Skill至少要同时处理 4 层问题设备层手机是否在线版本是否正确登录态是否正确场景层入口路径是否准确测试数据是否存在按钮、卡片、筛选器是否可见日志层事件是否上报是否命中本次时间窗是否是本机、本版本产生的日志判定层是否多报是否少报是否错报是否串报对应的真机执行流可以理解成这样七、Skill 在自动化里的真正应用不是“自动点击”而是“自动组织闭环”很多人一提自动化第一反应是点击、输入、滑动。但埋点场景里自动化最有价值的地方往往不是这几个动作本身而是把它们和日志证据、表格回写、缺陷流转连起来。更准确地说这套 Skill 化方案把自动化应用到了 5 个层面1. 需求整理自动化原始埋点表转整理版不再完全靠手工补充。2. 真机执行标准化不再每条埋点都从头想“这次怎么测”而是优先按整理版给出的路径执行。3. 日志查询自动化用本地查询脚本把EID设备版本时间窗组合成稳定查询条件。4. 字段级判定自动化把“看起来像通过”升级成“字段、数量、时间窗都符合预期才算通过”。5. 缺陷闭环自动化未通过项不只是标红而是继续进入结果回写结构化描述Yunxiao 提单修复后复测这个阶段最能体现 Skill 的工程价值。否是否是否是真机操作完成查询到日志?未上报数量是否正确?重复上报/少报字段是否匹配?字段错误/串报判定通过回写完整 JSON 与问题描述按埋点编号提 Bug回写通过结果与完整 JSON八、为什么“完整 JSON 回写”必须是硬规则这件事在埋点测试里特别重要。如果表里只写一句“通过”或者“未通过”后面会有几个问题研发看不到具体上报内容产品没法复核字段是否和需求一致复测时测试自己也要重新查一次日志需求变更后无法回头核对历史口径而把完整 JSON 固定回写到版本开发需求记录.黏贴json之后价值会非常直接通过项也能复核不是只有失败才留证据失败项更容易归因是没报、错报、多报还是字段错一眼能看出来复测上下文可复用下次不是重新查而是拿历史 JSON 对照这张图能更直观地说明日志查询和字段核对的关系九、为什么 Android / iOS 两个 Skill 要拆开这不是为了“多建一个 Skill”而是为了把平台差异隔离开。虽然两边的业务需求和字段口径是一套但实际执行时差异很明显设备连接方式不同自动化工具链不同页面元素定位策略不同日志触发时机偶尔也会不同如果把 Android 和 iOS 混成一个 Skill最终往往会出现两种问题说明越来越长真正执行时反而不清晰平台差异和公共规则混在一起不利于维护拆成两个 Skill 后公共规则保持一致完整 JSON 必须回写点击一次上报两次算 bugBug 必须按埋点编号拆开查询必须绑定时间窗和设备而平台差异则留在各自 Skill 内部处理。这样更稳。十、埋点 Skill 和 Appium / ADB / 查询脚本是什么关系Skill 不是替代这些工具而是把这些工具组织起来。可以这么理解ADB / 真机操作工具负责设备连接、基础操作、环境确认Appium负责复杂页面流程、元素定位、可见性确认日志查询脚本负责把埋点证据查出来Skill负责决定什么时候调用哪一个能力以及最终如何落成闭环下面这张图很适合理解 Appium 在这条链路里的位置所以从工程上看Skill 更像一个“流程层”把自然语言需求转成执行路径把执行路径转成日志查询条件把日志结果转成表格结论和缺陷材料十一、埋点 Skill 最适合解决哪些问题这套 Skill 特别适合下面这些场景1. 版本新增埋点较多每个版本都要从头整理和执行重复度很高Skill 化收益最大。2. 多平台都要测同一批埋点 Android / iOS 都要验证时统一规则、拆分执行最合适。3. 缺陷复测频繁如果一个版本里埋点问题较多后续反复复测时Skill 能明显减少背景重建成本。4. 字段归因容易争议例如有日志但字段错点击一次上报两次页面名按 tab 动态拼接from_nav / content_type 依赖页面上下文这类问题只靠一句“未通过”很难推动修复结构化 Skill 更适合。十二、做成 Skill 之后最大的变化是什么最大的变化不是“测试更快了”这么简单而是埋点测试终于有了稳定的工程结构。以前更像这样需求在表里操作在脑子里证据在日志里结论在聊天里Bug 在 Yunxiao 里现在更像这样需求先整理进可执行 Workbook真机验证按 Skill 执行日志证据回写回同一张表未通过直接流向缺陷闭环修复后继续按原上下文复测对应闭环过程可以看这张图这意味着测试工作从“人肉搬运信息”逐渐转成“维护一条稳定流程”。当流程一旦稳定下来后续每个版本的边际成本都会继续下降。十三、下一步还可以怎么继续演进如果这套 Skill 继续往下做我认为有几个方向很值得补1. 进一步补强待确认规则让tracking-workbook-prepare不只是生成整理版还能更聪明地区分可直接执行项需要样例数据项需要开发确认字段枚举项2. 把复测触发再自动化例如Yunxiao 状态变成“待复测”自动回到原埋点编号自动复用原时间窗策略和字段规则3. 建立埋点结果看板把通过率未通过分布多报/少报/错报类型待复测积压量做成版本级汇总视图而不只是逐条表格记录。4. 沉淀更多专项 Skill比如再拆分成埋点复测 Skill埋点 Bug 复核 Skill埋点 JSON 差异对比 Skill埋点需求口径校对 Skill这样整条链会更细也更稳定。十四、结语埋点测试本身并不新但把埋点测试做成 Skill会带来一个很实在的变化测试不再是“这次把任务做完”而是“把这类任务沉淀成以后还能反复用的能力”。这 3 个 Skill 的价值不在于名字而在于它们把一条原本零散的链路固定了下来tracking-workbook-prepare解决输入问题tracking-android-verify解决 Android 执行闭环tracking-ios-verify解决 iOS 执行闭环真正有用的自动化从来不是只会自动点页面而是能把需求、执行、查询、判定、回写和缺陷流转真正串起来。埋点 Skill 的意义也正在这里。
