做过 UI 自动化的团队都懂写脚本只是第一步真正的痛苦往往是从「执行测试」开始跑测试手拼pytest -m表达式筛用例标签错一个字母全量几百条跑飞一等半小时。挂了没截图、没录屏、没 Trace失败现场转瞬即逝想复现全靠缘分。排查对着满屏英文堆栈猜原因猜环境、猜数据、猜前端改了东西一下午搭进去。修脚本改定位、调超时、清脏数据定位到了还是一条条人肉动手。出报告从 XML 数数字、去目录翻截图、计算器算通过率手工拼一下午。自动化测试执行阶段是整个测试体系里翻车率最高、最消耗人、也最值得 AI 赋能的一段。今天这篇文章给大家分享5个 Agent Skill串起「标签怎么打、脚本怎么跑、挂了怎么修、结果怎么报」完整链路的。一、UI 测试的痛远不止跑脚本很多团队一提到执行环节的痛点第一反应就是「环境问题」。但实际上环境只是冰山一角。从用例管理到流程编排UI 测试的执行阶段每一个环节都有让人崩溃的地方环节痛点典型表现标签管理用例没分级分类没法按需执行几百条用例一把梭想只跑登录模块的 P0 冒烟得手拼长命令测试执行环境、筛选、证据、并行全是坑「我本地明明能跑」成 CI 经典开场白失败现场一次性失败诊断原因靠猜误判代价大环境问题提单被开发退回真 bug 当偶发失败漏到线上测试报告手工拼表只有数字没结论报告发到群里老板回一句所以能不能发流程编排环节各自为战人当传话筒执行、诊断、重跑、报告一条链要人叫四次 AI这五个环节的痛点单靠一个 Skill 解决不了。很多新手容易踩的坑想做一个「万能执行 Skill」一条命令从跑测试一路干到出报告执行、诊断、修复、报告全塞在一起。结果就是逻辑臃肿、出错难定位、环节没法单独用。正确的做法还是那句话按职责拆分每个 Skill 只做一件事做到极致。二、41 Skill 全流程架构先看全貌。UI 测试执行侧的 AI 赋能链路由4 个核心 Skill 1 个编排 Skill组成形成完整闭环Skill核心职责解决什么痛点ui-test-tagger脚本标签化管理用例没分级分类、没法按需执行、筛选靠手拼命令ui-test-executor智能执行调度环境翻车、失败无现场、并行矩阵重试自己搭ui-failure-diagnoser失败诊断与自动修复失败原因靠人猜、误判代价大、修复靠人肉ui-report-generator可视化测试报告报告手工拼、只有数字没结论、证据翻不着ui-pipeline-scheduler编排全链路统一编排环节靠人串、重试没规矩、接不进 CI️ ui-pipeline-scheduler · 一条指令编排全链路零侵入标签底座有失败才触发修复后只重跑失败用例执行完成️ ui-test-tagger六维标签体系 ui-test-executor智能执行调度 ui-failure-diagnoser六类分类 · 自动修复 ui-report-generator三源融合报告 测试脚本tests/ pages.yaml✅ 单文件 HTML 可视化报告证据内嵌 · 风险分级这几个 Skill 形成完整闭环标签 → 执行 → 诊断 → 报告由scheduler统一编排既能串联使用也能独立调用。测试脚本 (tests/ pages.yaml) │ ▼ ui-test-tagger ──→ 六维标签体系 标签统计报告 │ ▼ ui-test-executor ──→ 执行结果 六类失败证据截图/录屏/Trace/日志 │ ├──→ ui-failure-diagnoser ──→ 六类分类 自动修复 验证回滚 │ │ │ ▼ │ ui-test-executor定向重试只跑失败用例 │ ▼ ui-report-generator ──→ 单文件 HTML 可视化报告证据内嵌、风险分级 │ ▴ └── ui-pipeline-scheduler 把以上全部串成一条指令零侵入编排为什么这么拆还是那三个原则单一职责每个 Skill 只做一类核心动作打标、执行、诊断、报告编排层只编排不干活。闭环衔接tagger 的标签是 executor 的筛选依据executor 的证据是 diagnoser 的诊断依据全部产物汇入 report-generator。灵活复用每个 Skill 都能独立调用。只想跑测试单独用 executor已有失败要排查单独用 diagnoser拿到结果要出报告单独用 report-generator。接下来逐个拆清楚每个 Skill 的定位和作用。三、逐个拆解每个 Skill 的定位与作用Skill 1ui-test-tagger — 脚本标签化管理定位用例管理地基 Skill为 Playwright POM Pytest 的 UI 测试脚本自动打上标准化标签建立可筛选、可过滤、可统计的标签体系为按标签执行、按模块生成报告、按优先级调度、按浏览器分发提供基础。它解决什么问题脚本生成技能一跑就是几百条用例没有标签体系后面按需执行、按模块统计、按优先级调度全都无从谈起。适用场景为 UI 测试脚本批量打标签、检测冲突、补全缺失标签按模块/场景/页面/优先级分类管理 Playwright 用例生成标签分布统计报告结合 pytest-m实现冒烟、回归、模块化执行核心能力六维标签体系优先级P0-P3、模块module:xxx、场景scene:xxx、页面类型page:xxx、执行策略run:smoke/regression/full、浏览器平台browser:xxx**智能推荐解析方法名、docstring、page.goto()路径、Playwright 操作步骤、断言内容参照 pages.yaml 推断模块和优先级冲突检测自动检测优先级、场景、策略、页面类型冲突装饰器映射module:login→pytest.mark.module_login含冒号标签自动转下划线三种模式analyze仅分析/ apply写入/ report仅统计默认 analyze 安全优先输入测试脚本目录tests/pages.yaml可选用于辅助模块和优先级推断输出自动打好六维标签的测试脚本标签统计报告ui_tag_statistics.md核心价值把「一堆平铺的脚本文件」变成「一套可管理的用例资产」。它是执行调度的前提一句「只跑购物车 P0 冒烟」能被准确翻译靠的就是这套标签底座。Skill 2ui-test-executor — 智能执行调度定位测试执行的核心引擎把「跑测试」从手拼命令变成一句自然语言。1️⃣ 标签筛选自然语言 → marker 表达式2️⃣ 环境检测浏览器清单 · 版本 · 无头支持3️⃣ 执行调度并行 · 浏览器矩阵 · 失败重试4️⃣ 现场采集六类证据 · 仅失败时保留5️⃣ 报告产出五件套 失败深度分析它解决什么问题传统执行方式下环境靠玄学「我本地明明能跑」、筛选靠翻文档手拼 marker 表达式、失败现场一次性没截图没 Trace、并行跨浏览器重试样样自己搭。执行环节规则明确、重复劳动、容易遗漏是 AI 接管收益最高的一环。适用场景触发执行 UI 测试、按标签/模块/优先级筛选跨浏览器矩阵执行、并行加速、失败重试自动采集失败截图、录屏、Trace、Console 日志、Page Source生成 JUnit XML / HTML / JSON 多格式报告便于 CI 集成核心能力执行前先亮牌自动浏览器检测Playwright 内置 系统浏览器无可用浏览器时引导安装开跑前打印浏览器环境清单版本、无头支持 待执行用例清单含参数化展开配合 dry-run 先验证调度逻辑自然语言筛选用例依托 tagger 的标签体系「只跑购物车 P0 冒烟」直接翻译成 marker 表达式优先级累积、多标签交集、多模块并集贴合测试直觉六类失败证据自动采集截图视口全页、录屏、Trace、控制台五段日志、页面源码、网络请求摘要只在失败时采集通过的不占一块磁盘并行、矩阵、重试一句「并行跑」「三个浏览器各跑一遍」「偶发失败自动重试」全部支持报告五件套JSON / HTML / JUnit XML / Markdown 摘要 / 单行 CI 摘要有失败自动追加深度分析报告输入测试脚本目录已打标签执行意图自然语言或参数范围、优先级、浏览器、并行数输出标准化执行结果JUnit XML / JSON 六类失败证据artifacts/核心价值把执行环节固化成「标签筛选、环境检测、执行调度、现场采集、报告产出」五步流程。跑得明白跑得有据可查。Skill 3ui-failure-diagnoser — 失败诊断与自动修复定位失败分析的智能大脑不只给建议直接把修复做掉。⚠️ 失败用例执行结果 六类证据️ 环境错误浏览器/包未装 · 端口占用→ 自动 install 真实缺陷Page Error · 网络 5xx→ xfail 标记 · 建议提单 定位错误元素不在 DOM 快照→ AST 修复 pages.yaml 对比⏱️ 超时错误元素在但渲染慢→ 调 timeout / 补 wait️ 数据错误脏数据 · 唯一约束冲突→ 调数据清理 脚本错误方法 typo · 废弃 API→ AST 改写它解决什么问题executor 留下了证据但判断还是要人做。对着堆栈猜原因、误判方向白干半天、真 bug 当偶发漏到线上、修一条改一行——诊断环节最吃经验也最重复。而它有一条硬约束兜底永远不修改测试用例的断言和业务语义修的有边界才敢放心让它修。核心能力六类失败自动分类环境 / 定位 / 超时 / 数据 / 脚本 / 真实缺陷每类有明确判定信号按优先级判定环境挂了一切无意义十四种根因定位判定信号 失败证据交叉验证。最典型的一招同样是 Timeout 报错打开失败瞬间的 DOM 快照看元素在不在在就是渲染慢调等待不在就是定位漂移修定位四类修复直接落地AST 改写定位器和超时pages 层、自动装环境playwright install、调数据清理技能处理脏数据、真实缺陷打 xfail 标记不掩盖修完自动验证每处修复重跑单用例修不好自动回滚备份全程留痕审计日志 修复报告分类统计、根因统计、每条明细输入executor 输出的执行结果JUnit XML 失败证据artifacts/项目目录与pages.yaml定位修复的金标准输出修复后的代码 数据 ui_repair_report.md诊断报告核心价值以前失败是负担现在失败是数据。每条失败都有分类、有根因、有处理结果跑上几轮哪个模块最脆弱、哪类问题最频繁报告直接告诉你。Skill 4ui-report-generator — 可视化测试报告定位把执行结果、诊断结论、历史数据融合成能支撑发布决策的单文件报告。它解决什么问题活干完了汇报掉链子。数据散在 XML、截图、诊断报告、历史邮件里四处躺着人工拼表一下午算错一个数被打回重算。报告里写着「通过率 85%」然后呢能不能发风险在哪老板要的是判断拿到手的是一堆表格。核心能力三源数据融合执行结果 诊断结论 历史趋势一处合并口径统一总览大盘六张 KPI 卡总数/通过/失败/跳过/通过率/耗时 状态饼图 模块柱图 历史趋势折线浏览器矩阵Chromium / Firefox / WebKit 通过率并排对比跨浏览器不一致一眼现形UI 测试特有失败详情证据直达截图内联、录屏外链、「打开 Trace」按钮一键复制回放命令风险分级 优化建议通过率低于 70% 标高风险失败按根因聚类直接给出「先修什么」输入执行结果JUnit XML / JSON 诊断报告 artifacts 历史数据输出单文件 HTML 可视化报告所有样式、图表、截图全内联双击就能打开核心价值测试做了一百分汇报也能讲出一百分。报告是给决策看的不是给存档看的三分钟回答那个终极问题能不能发风险在哪。Skill 5编排ui-pipeline-scheduler — 全链路统一编排定位不当球员只当指挥。把四个 Skill 串成一条指令跑完的流水线。全过 · 直通车有失败全过 / 达上限 / 修复无效本轮有修复且未达上限 首轮执行有失败 诊断修复六类分类 · 自动修复 定向重试只跑失败用例熔断判断 多轮合并首轮为基底逐条覆盖 终版报告它解决什么问题四个 Skill 各自能打但串链子的活还是人干执行完看一眼、诊断完叫重跑、跑完再叫报告一条链人要叫四次 AI中间衔接全靠人盯。而且这种多环节流程CI 里根本没法落地。核心能力五阶段闭环执行 → 诊断 → 重试 → 合并 → 报告一条指令按序自动走完零侵入编排不改任何子 Skill 的代码、入参、出参只传参、读产物、控顺序。子技能单独调用完全不受影响全绿直通车首轮全过直接跳到报告不为「流程完整」空跑环节熔断兜底重试到上限、修复无效、全部通过三种条件立即停机仍有失败会明确标出「这几条机器修不好」附用例清单多轮结果合并重试只跑失败用例会覆盖结果文件首轮 8 条变 3 条合并步骤以首轮为基底逐条覆盖报告数字不失真输入测试项目目录 执行参数 重试上限默认 2 轮输出融合全部轮次信息的终版 HTML 报告 各轮留档核心价值单个 Skill 是能力编排才是生产力。测试同学从「盯着每个环节的操盘手」变成「定好参数看报告的决策者」。四、除了 41 核心架构还可以按需集成上面的 41 Skill 覆盖了 UI 测试执行侧的核心闭环。Skill 体系的价值发挥还取决于与现有研发工具链的集成深度常见方向集成方向做法适用场景CI/CD 集成pipeline 单入口接 Jenkins / GitLab CI / GitHub Actions代码提交即测试报告自动归档代码仓库集成Git 感知前端代码变更自动触发对应测试集前端改版后的自动回归消息通知集成报告生成后自动推送钉钉 / 企微 / 邮件失败预警、报告触达定时调度集成夜间定时全量回归早上看报告版本发布前的完整验证核心原则先把 41 Skill 的闭环落地再做集成扩展避免过度设计。五、全流程串联回顾把整条链路用命令行风格串起来就是这样的# 0. 前提一套现成的测试脚本 tests/ pages/ pages.yaml ← 已编写好的 UI 自动化项目 # 1. 第一站标签管理 /ui-test-tagger 给 tests/ 下的脚本建立六维标签体系 ├─ 语义推断方法名/docstring/goto/断言 pages.yaml ├─ 冲突检测 缺失补全 └─ 输出打标脚本 标签统计报告 # 2. 第二站执行调度 /ui-test-executor 只跑购物车 P0 冒烟Chrome 无头失败要截图和 Trace ├─ 环境清单 用例清单执行前亮牌 ├─ 自然语言 → marker 表达式 ├─ 执行 失败时六类证据自动采集 └─ 输出 JUnit XML artifacts/ 报告五件套 # 3. 第三站诊断修复有失败才触发 /ui-failure-diagnoser 刚才挂的用例能修的自动修修完验证 ├─ 六类分类 十四种根因看证据判方向 ├─ 自动修复定位/超时/环境/数据/缺陷标记 ├─ 修完重跑单用例验证不行自动回滚 └─ 输出修复代码 ui_repair_report.md # 4. 第四站报告生成 /ui-report-generator 把这轮结果和诊断结论生成报告 ├─ 执行 诊断 历史三源融合 ├─ KPI 大盘 浏览器矩阵 风险分级 └─ 输出单文件 HTML证据内嵌直达 # 5. 终点站一键编排把 1-4 串成一句话 /ui-pipeline-scheduler 一键全跑 P0失败自动诊断修复重试最后出报告 ├─ 执行 → 诊断 → 重试 → 合并 → 报告 自动接力 ├─ 全绿直通 / 熔断兜底 / 多轮合并不失真 └─ 人只说一句话回来直接看报告六、AI 负责干活人负责把关这里有一个关键问题必须说清楚AI 把测试跑完、修完、报告出完测试工作没有结束。这套 41 Skill 能帮你完成的是「打标、执行、诊断、报告」这些动作把数小时甚至数天的体力劳动压缩到几分钟。但以下这些事情AI 做不了仍然需要人来把关AI 负责的事人负责的事六维标签自动推断抽查模块归属、优先级是否符合业务实际自然语言翻译成用例筛选确认筛选范围覆盖本次迭代的风险点六类失败证据自动采集看截图、看 Trace判定缺陷归属自动修复 验证回滚Review 修复的定位器是否符合业务语义风险分级 优化建议基于报告做出发布决策说白了AI 负责把「从 0 到 80」的体力活干完人负责「从 80 到 100」的质量把关。这样既高效又不会失去对质量的控制。特别提醒有两个地方最容易松懈。一是「重试后全绿」不代表没问题偶发失败里往往藏着时序问题和资源竞争值得单独拎出来排查二是「预期失败」标记不能代替确认把所有失败都标成 xfail 让报告变绿是用另一种方式掩盖问题。七、Skill 如何获取大家可以自己根据本文提供的思路和架构进行开发 Skill如果需要学习更系统化的AI落地技术也可以加入「狂师 . AI 进化社」里面有各类 AI 技术落地保姆级图文教程、视频教程包括 AI 赋能测试全流程的实战教程。目前所有的AI Skill已全部上传发布到AI测试开发导航网站https://www.testfather.cn/,访问https://www.testfather.cn/后菜单栏路径「AI工具」- 「Skill技能商店」中。在Skill技能商店中在非常多实用的免费、付费的Skill 技能大家可按需获取、下载。前两天新开了一个「AI测开进化圈」知识星球聚焦 AI 测试方向年订阅交付的是能直接用的工具包、https://github.com/zhoujinjian/ai-testing-guide路线带学和全年答疑目标是利用AI把手里的活干快不同于AI进化社星球侧重的是「会用」拿来就能跑的 Skill 技能包、工具包、实测避坑教程、AI 面试刷题与测评、AI测试路线带学打卡等。想踏实学 AI 测试、不靠东拼西凑浪费时间的话相信我直接冲。目前星球处于初建期可享受早鸟价随精华内容、答疑服务、AI提效工具包持续扩容会逐步上调早加入早锁价。写在最后回顾一下整套架构痛点从用例管理到流程编排UI 测试执行侧每个环节都耗时费力且高度依赖人工临场判断。方案不要搞万能 Skill按职责拆成 41 个专业 Skill形成标签 → 执行 → 诊断 → 报告的完整闭环由编排层统一串联。效果传统模式Agent Skill 模式手拼 pytest -m 表达式全量跑飞一句自然语言标签自动翻译失败没截图没 Trace现场一次性六类证据自动保全只在失败时采集失败原因靠猜修复靠人肉改代码六类分类十四种根因自动修复自动验证报告手工拼一下午只有数字没结论一句指令几分钟出报告风险分级直接给判断执行诊断报告各自为战人当传话筒一条指令全链路自动跑完可直接接 CI边界AI 负责执行、诊断、修复和报告人负责校验和决策。如果你想深入某个具体 Skill 的实操细节可以看这个系列之前单独的拆解。这 5 个 Skill串起来是一条从执行到报告的完整流水线拆开来是 5 件各自趁手的独立工具。UI 自动化最难啃的那段路现在可以交给 AI 了。