真正做过 UI 自动化测试的同学都知道脚本写完只是自动化测试的第一步真正的痛苦往往是从「跑测试」开始。我见过不少团队脚本攒了几百上千条最后倒在执行这一环。要么环境跑不起来要么跑起来收不了场。一、开头说两句这个系列一直在做一件事用 Agent Skill 把 UI 自动化测试的各个环节逐个自动化。前面几篇解决的是「脚本怎么来」。页面元素解析、测试脚本生成、脚本健壮性增强一路走下来脚本能稳定跑通了。接下来就轮到「脚本怎么跑」。按传统做法这一步就是把 pytest 命令敲进终端然后人守在旁边看结果。听着简单实际是整个 UI 自动化里翻车率最高、也最消耗人的环节。所以在这个位置我专门做了一个 Skillui-test-executor一个 WEB UI 测试的智能执行调度引擎。触发执行、浏览器环境管理、用例筛选、并发调度、过程监控、结果收集这些活全部交给它。本篇就聚焦这个 Skill从它面对的问题讲起到它怎么解决再到实战跑一遍。二、传统执行方式存在什么问题把执行环节的账摊开算问题往往集中在几个主要地方。1、环境问题防不胜防。浏览器版本、驱动匹配、Playwright 装没装、无头模式支不支持每一项都可能让任务卡住。一句「我本地明明能跑」成了 CI 环境里最经典的开场白。排查半小时最后发现只是某台机器没装 Edge。2、等待时机不固定过不过全靠运气。页面加载、接口返回、动画收尾每一处都有时间差。很多脚本用写死的 sleep 等 3 秒环境快了白白等 3 秒环境慢了 3 秒后又把还没加载完的页面当成失败。同一个用例今天过、明天挂时好时坏全看缘分。3、用例不独立每次全量跑就出幺蛾子。上一条用例注册了账号没清理下一条用同一个手机号注册就挂了。单独跑能过放进全量跑就挂排查半天发现是别人的脏数据。共享的缓存、文件、数据库都是雷区。4、失败现场是一次性的。用例跑挂了没截图、没录屏、没 Trace明明三分钟前它就发生在眼前你却拿不出任何证据。重跑一遍想复现居然又过了。挂了不知道为什么挂过了不知道为什么过。写失败分析一半时间花在翻文件找线索上。5、跑哪些用例全靠手拼命令。想只跑登录模块的 P0 冒烟得先翻文档查pytest -m表达式怎么写。标签拼错一个字母全量几百条用例跑飞一等等半小时。会写的人觉得没什么不会写的人每次都要重新查一遍。6、并行、跨浏览器、重试样样自己搭。想多浏览器跑一轮兼容矩阵想并行加速想偶发失败自动重试每一样都是一轮配置折腾。搭好了是这个项目的下个项目再来一遍。这几件事有个共同点。它们规则明确、重复劳动、人工极容易遗漏而这些工作恰恰是 AI 最擅长接手的那类活。那能不能让 AI 把「执行调度」这一步彻底接管答案是可以。而且经过我的项目实测效果比预期想象中还要更好。三、ui-test-executor Skill 它是怎么解决的ui-test-executor是一个专门负责测试执行的 Agent Skill。它将已编写好的Playwright PytestUI 测试脚本真正跑起来形成「标签筛选 → 环境检测 → 执行调度 → artifact 采集 → 报告产出」的完整执行闭环。适用场景触发执行 UI 测试、按标签/模块/优先级筛选跨浏览器矩阵执行、并行加速、失败重试自动采集失败截图、录屏、Trace、Console 日志、Page Source生成 JUnit XML / HTML / JSON 多格式报告便于 CI 集成它的整个设计遵循两条原则。只读不写。它只读你的测试目录只在执行层面做调度一个字都不改你的测试脚本。脚本该怎么写还是脚本的事执行归它管。这条边界划清楚才敢放心把它放进 CI。执行前先亮牌执行后留证据。开跑之前先让你看清楚这次用什么跑、跑哪些跑完之后失败用例的现场证据一样不落。中间的过程尽量不需要人盯。落到执行流程上它固化成一套五步流程。标签筛选 → 环境检测 → 执行调度 → 现场采集 → 报告产出对着前面这几个问题一步一步看它是怎么拆的。1. 环境问题先检测后执行正式开跑前它会先打印一份浏览器环境清单。本机装了哪些浏览器Playwright 内置的加系统装的、版本号、支不支持无头模式逐项列出来。没装的也会列出来后面直接附上安装命令。扫一眼这张表环境有没有坑、该选哪个浏览器心里基本就有数了。2. 用例选择说人话就行不需要翻文档拼pytest -m表达式直接说人话。/ui-test-executor 只跑购物车模块的 P0 冒烟用例Chrome 无头模式AI 会把这句话翻译成 marker 表达式。翻译完还不急着跑。它会先打印一份待执行用例清单按「文件名、测试类、用例名」逐条列出本次命中的用例连参数化展开都显示出来。比如同一条搜索用例展开成手机、小米、手表三个参数一眼能看到。配合--dry-run参数只打印构建出的完整 pytest 命令不实际执行。调度逻辑对不对一眼可验「参数拼错全量跑飞」这种事故从根上堵住了。3. 失败现场六类证据自动采集这是这个 Skill 最值钱的能力。用例一旦失败现场自动保住。六类证据一次保全截图 / 录屏 / Trace / 日志 / 源码 / 网络覆盖失败现场全维度追溯零盲区。截图。视口截图加全页截图各来一张。录屏。失败用例的完整操作视频从头看到尾。Trace。Playwright 运行轨迹可以逐步回放每一步操作前后的页面状态。控制台日志。五段合并页面错误、Console 报错、警告、网络请求摘要、性能指标一份文件看全。页面源码。失败时刻的完整 HTML 快照。网络请求摘要。URL、状态码、资源类型九成的接口追溯场景够用了。而且有一条铁律。只在失败时采集并保留完整执行过程证据链通过的用例只保留执行结果信息。以前是失败了什么都没有现在是失败了什么都有。写失败分析从翻文件夹拼线索变成打开一份归档好的证据包。4. 并行、矩阵、重试说话就行这一块最容易让人想到一堆参数但在 ui-test-executor 这里你只需要把要求说出来。「全部用例并行跑开 4 个进程越快越好」 「登录模块用 Chrome、Firefox、WebKit 三个浏览器各跑一遍」 「有偶发失败的用例自动重试一次」三句话对应执行里的三件事快、全、稳。要快。一句「并行跑」几百条用例从串行一小时压到十几分钟。中午吃饭前说一声回来报告已经躺好了。进程怎么开、任务怎么分发AI 在底下自己安排不用你操心。要全。一句「三个浏览器各跑一遍」用例自动展开成矩阵一条用例乘三个引擎就是三条执行记录。有些兼容性问题在 Chromium 上一片祥和到 Firefox 上原形毕露不跑一轮根本看不见。要稳。一句「偶发失败自动重试」网络抖一下、CI 机器资源挤一下导致的失败自动再跑不用人守着重跑。但有一条要说清楚确定性失败定位器失效、DOM 结构变了重试一百次也是挂重试只兜偶发不治本。分发策略这种更深的细节它也按项目情况自己选。POM 项目默认同一类的用例在同一个进程里跑避免 fixture 重复初始化和状态污染顺带压住了前面说的脏数据互相干扰。这些原本要自己踩坑才摸得出来的经验全部做成了默认行为。前面说的偶发失败这里也接住了。时序抖出来的失败重试先兜住这一轮让结果不被偶发因素污染真要排查配合 Trace 回放看每一步操作的时间线到底哪一步等少了一眼定位。至于 CI 环境里不方便对话的场景它底层封装了完整的执行脚本直接传参数调用就行同一套能力的另一个入口。5. 报告五件套一次跑完全产出产出用途report.json结构化数据CI/CD 和看板直接消费report.html可视化报告浏览器直接打开report.xmlJUnit 标准Jenkins 和 GitLab CI 原生支持summary.md人读的 Markdown 摘要summary.txt单行摘要CI 流水线直接抓作 build description只要有一条失败还会自动追加一份failure_analysis.md深度分析报告。每条失败用例还会展开七个小节判定规则、断言原文、预期与实际、页面元素校验、失败截图路径、录屏与 Trace 复现命令、其他诊断材料。跑完之后再补一句「打开最新失败那条的 Trace」它自动定位 trace.zip 并启动 Trace Viewer还支持中文用例名匹配。以前要去目录里一个个翻的事现在一句话。四、Skill 实战演练将技能安装好在技能列表中选择ui-test-executor输入一句指令。跑一下 shop-lab-ui-test 的 P0 冒烟用例。接下来Skill 自动完成四件事。第一用例清单确认。主筛选集命中 8 条用例逐条列出「文件名、测试类、用例名」参数化展开也在内。确认无误开跑。第二环境自检。打印本机浏览器环境清单检测到 4 个可用浏览器Chromium、Chrome、Edge、Safari附版本号和 Headless 支持情况。没装的 Firefox 后面跟了一条安装命令。本次执行选用 Chromium。第三执行与现场采集。实时流式输出执行进度。失败的用例自动完成六类证据采集全部归档到test-results/artifacts/下的标准目录。技能开发调试期间通常建议默认采用有头模式打开浏览器方便观察操作正式投产或者后续接入CICD时可再改为无头模式运行。等待所有P0冒烟用例执行完成。第四报告产出。执行结束报告五件套加失败深度分析一次性生成并给出下一步建议有失败则直接给出 Trace 复现命令。最终拿到的产出长这样。test-results/ ├── report.json# 结构化报告├── report.html# 可视化报告├── report.xml# JUnit XMLCI 标准├── summary.md# Markdown 摘要├── summary.txt# 单行 CI 摘要├── failure_analysis.md# 失败深度分析全过则不生成└── artifacts/ ├── screenshots/# 失败截图视口 全页├── page-source/# 失败时 HTML 快照├── console-logs/# 失败时五段合并日志└── pytest-raw/# 录屏 video.webm trace.zip当用例执行出现失败时会在test-results目录下自动生成一份failure_analysis.md 失败用例故障分析报告在失败用例故障分析报告中会以失败用例为单位详细列出失败的判定规则、失败截图、失败录屏与Trace等信息。进入到test-results-pytest-raw目录查看是否有生成失败截图png格式、录屏webm格式、trace.zip等文件。查看失败录屏文件如果你想查看trace.zip文件详细内容可以直接问AI:查看失败用例的trace整个过程人只需要像日常对话一样自然语言、口语化沟通即可。五、最后再补充说两点有一个问题需要说清楚。AI 把测试跑完测试工作没有结束。ui-test-executor接管的是「执行加采集」这些规则明确的活把环境检测、命令拼装、证据归档从几小时压缩到几分钟。但下面这些事仍然需要人来把关。AI 负责的事人负责的事浏览器环境检测与选择确认浏览器范围是否符合测试策略自然语言翻译成用例筛选确认筛选范围覆盖本次迭代的风险点并行调度与失败重试判断失败是环境抖动还是真实缺陷六类失败证据自动采集看截图、看 Trace判定缺陷归属报告五件套自动产出基于报告做出发布决策特别提醒一句。重试通过不代表没问题。偶发失败的用例往往藏着时序问题或资源竞争值得单独拎出来排查。看到「重试后全绿」就放心发布这个懒偷不得。回顾一下整个过程。痛点。环境翻车靠玄学等待时序靠缘分脏数据靠人肉排查失败现场一次性用例筛选靠翻文档并行重试自己搭。方案。ui-test-executor 把执行固化成「标签筛选、环境检测、执行调度、现场采集、报告产出」的五步流程。执行前先亮牌两份清单让你看清跑什么、用什么跑执行后留证据六类现场材料自动归档报告五件套一次产出。效果。以前跑一轮测试要人盯着失败了满世界找现场写报告靠翻文件夹。现在一句自然语言指令启动环境、范围、证据、报告全部自动到位直接可以对接 CI/CD。边界。AI 负责调度和采集人负责决策和复盘。大家可以自己根据本文提供的思路开发 skill如果需要现成的教程和 skill也可以加入「狂师 . AI 进化社」获取里面有各类 AI 技术落地保姆级图文教程、视频教程包括 AI 测试全流程的实战教程保姆级手把手喂饭教程跟着步骤操作零基础也能快速上手。温馨提醒「AI 测试」只是 AI 进化社八大技能版块之一。执行这个环节理顺之后手里握着的就不再是一堆跑挂了的用例而是一份证据齐全的失败档案。怎么让 AI 顺着这些证据自动分析失败原因、定位根因、给出修复建议我们后面的文章接着聊。