AI 测试丨一句指令生成测试报告，带失败截图、操作录屏、Trace、日志，这套 Skill 思路可以直接抄...

大家好，我是狂师。

前两篇，我们把「跑测试」和「修脚本」都交给了 AI。执行有证据，失败有结论，修复有验证，测试这条链算是跑顺了。

但每到版本发布前，还是有一件事让人头疼，写测试报告。

明明活都干完了，最后还要从 XML 里找数字、往 Word 里贴截图、在 Excel 里算通过率。折腾一下午，发到群里，老板回一句，所以能不能发？

测试做了一百分，汇报只讲出六十分。 这种哑巴亏，很多测试团队都吃过。

一、写在前面

这个系列一直在做一件事，用 Agent Skill 把 UI 自动化测试的各个环节逐个自动化。 如果觉得有用，欢迎点赞、收藏、转发哦。

第一篇的 ui-test-executor 解决了「跑」，留下了执行结果和六类失败证据。

第二篇的 ui-failure-diagnoser 解决了「修」，留下了诊断结论和修复报告。

到这里，原料其实全齐了。执行结果、失败证据、诊断结论、历史数据，分散在四个地方各自躺着。

缺的是最后一步，把这些原料变成一份能看的、能懂的、能支撑决策的报告。

测试报告的价值从来不是存档，是让看报告的人（组长、开发、老板）在三分钟内回答一个问题，这个版本，能不能发，风险在哪。

所以这一环，我做了 ui-report-generator，一个把执行结果、诊断结论、历史数据融合成单文件 HTML 可视化报告的 Skill。

本篇就聚焦这个 Skill，从它面对的问题讲起，到它怎么解决，再到实战跑一遍。

二、传统测试报告方式存在什么问题

把「出报告」这件事拆开来看，问题往往集中在几个主要地方。

1、报告是手工拼出来的。

跑完测试，从 XML 里数通过数失败数，去 artifacts 目录翻截图，打开计算器算通过率，再复制进 Word 排版。一份报告一小时起步，数据多的时候一下午就交代进去了。

2、数据散落四处，口径对不上。

执行结果在 JUnit XML，失败截图在 artifacts，诊断结论在修复报告 md，历史数据在上个月的邮件附件里。人工汇总，算错一个数被打回重算，是每个测试都经历过的尴尬。

3、只有数字，没有结论。

报告里写着「用例 120 条，通过 102 条，通过率 85%」。然后呢？能发不能发？风险集中在哪？先修什么？看报告的人要的是判断，拿到手的却是一堆表格，还得自己再分析一遍。

4、失败详情，翻不着。

报告里一句「AssertionError 断言失败」，想看当时的页面截图？去目录里翻。想看 Trace 回放？先找到 trace.zip 路径，再拼一条命令。报告和证据之间，隔着好几次文件夹跳转。

5、没有历史，看不出趋势。

这轮通过率 90%，上一轮 85%，是变好了还是测试范围变了？没有历史累积，每次报告都是一张孤立快照，质量是在变好还是变差，谁也说不清。

6、报告格式，因人而异。

每个测试一个模板，十份报告十种花样。组长合并汇总要重新对格式，老板看十份报告得适应十种排法。

这几件事有个共同点。数据是现成的，规则是明确的，格式是固定的。全是 AI 擅长的活。

那能不能让 AI 把「出报告」这一步也接管了？

答案是，可以。而且它出的报告，比你手工拼的好看，还更能说服人。

三、ui-report-generator Skill 技能介绍

简单来说，ui-report-generator 是一个把 UI 测试执行结果、诊断结论、历史数据融合成可视化、可决策单文件 HTML 报告的 Agent Skill。

它的输入正好是前两篇 Skill 的全部产出。

输入：

• ui-test-executor 输出的执行结果（JUnit XML / report.json）
• 失败证据（截图、录屏、Trace、日志，artifacts 目录）
• ui-failure-diagnoser 输出的诊断报告（分类、根因、修复状态）
• 历史执行数据（多次通过率序列，可选）

处理逻辑：

1. 多源数据解析：读取执行结果，提取每条用例的状态、耗时、浏览器；把截图、录屏、Trace 逐条关联到对应用例；解析诊断报告，取出每条失败的分类与根因；
2. 多维聚合分析：按业务模块、按优先级、按浏览器三个维度分组统计，失败按根因聚类，找出高频问题；
3. 风险分级：模块通过率低于 70% 标为高风险，70% 到 90% 中风险，90% 以上低风险；
4. 优化建议生成：基于失败模式自动产出建议（哪个模块优先修、环境问题集中处理、跨浏览器差异排查）；
5. 单文件渲染：全部 CSS、图表、截图内联进一个 HTML，发给谁、在哪台机器都能直接打开。

输出：

• 一份单文件 HTML 可视化测试报告（ui_test_report.html）

适用场景：

• 执行/诊断完成后一键生成测试报告
• 版本发布前出质量评估报告，支撑发布决策
• 多浏览器矩阵执行结果对比分析
• 历史趋势追踪，看质量是在变好还是变差
• 失败用例证据（截图/录屏/Trace）随报告一键直达

它的整个设计遵循两条原则。

只读，只写一份报告。 这个 Skill 有一条硬约束，不改测试脚本、不改页面对象、不改任何配置文件。它读入所有结果，唯一写出的东西就是那一份 HTML 报告。测试工程干干净净，报告爱怎么生成就怎么生成。

报告是给决策看的，不是给存档看的。 每个区块都必须回答一个具体问题，整体能不能发、风险在哪、先修什么、证据在哪。回答不了的区块，一律不放进报告里。

落到流程上，它固化成一套报告生成五步流程。

数据接入 → 解析关联 → 聚合分析 → 渲染成页 → 决策建议

对着前面这几个问题，一步一步看它是怎么拆的。

1. 一个文件，装下所有证据

ui-report-generator Skill 执行完成后，最终产出是一个单文件 HTML。所有样式、图表数据、失败截图全部内联，不用带附件包、不用搭环境，双击就能打开。发给组长、转给开发、甩到群里，谁拿到都是完整的一份。

以前「报告和证据隔着好几次文件夹跳转」，现在证据就嵌在报告里。

2. 总览大盘，三分钟看完

打开报告，头部就是六张 KPI 卡，总用例数、通过、失败、跳过、通过率、总耗时。往下是状态分布饼图、模块通过率柱状图、历史趋势折线图。

「这轮跑得怎么样」，不用翻表格，扫一眼大盘就有答案。

3. 浏览器矩阵，UI 测试特有

这是 UI 报告区别于接口报告的地方。同一批用例在 Chromium、Firefox、WebKit 上的通过率并排对比，哪个功能只在某个浏览器上挂，一眼现形。跨浏览器不一致这类隐蔽问题，以前要人工对三份结果，现在一张矩阵图说清。

4. 失败详情，证据就在手边

每条失败用例展开，分类、根因、错误信息、Traceback，加上内联的失败截图。旁边还有「打开 Trace」按钮，点一下，回放命令自动复制到剪贴板，粘到终端就能逐步回放当时的操作。

看报告的人不用再问「截图在哪、Trace 怎么开」，所有证据跟着用例走。

5. 风险分级 + 优化建议，直接给判断

报告最后不是一堆数字了事。高风险模块标红列出来，失败按根因聚类，高频问题排在最前面，配着具体的建议动作，优先修哪个模块、环境问题集中处理、跨浏览器差异单独排查。

「先修什么」这个原来要人再分析一遍的问题，报告直接给了答案。

四、Skill 实战演练

接着前两篇的现场。测试跑完了，失败也诊断修复完了，test-results/ 目录里躺着执行结果、诊断报告和全部失败证据。

在技能列表中选择 ui-report-generator，输入一句指令。

/ui-report-generator 把刚才那轮的执行结果和诊断结论，
生成一份测试报告，带上失败截图和趋势

接下来，Skill 自动会完成四件事。

第一，多源数据接入。 读入 JUnit 执行结果、上一轮的诊断报告、artifacts 里的截图录屏 Trace、浏览器环境清单，还有最近几次的历史通过率。

第二，聚合分析。 按模块、优先级、浏览器三个维度分组统计，失败按根因聚类，模块按通过率标出高中低三档风险。

第三，渲染成页。 九大区块依次生成，报告头部、总览大盘、数据图表、浏览器矩阵、模块统计、根因聚合、风险建议、失败详情、用例明细，全部内联进一个 HTML 文件。

第四，给出决策建议。 高风险模块排在最前，高频根因标亮，配着「先修什么」的具体建议。

值得注意的是，测试报告还增加了失败截图、操作录屏、查看DOM快照、Console日志、打开Trace等功能。

最终拿到的报告，结构长这样。

ui_test_report.html
├── 报告头部        标题 · 环境 · 时间 · 浏览器清单
├── 总览大盘        6 张 KPI 卡（总数/通过/失败/跳过/通过率/耗时）
├── 数据图表        状态饼图 · 模块柱图 · 历史趋势折线
├── 浏览器矩阵      Chromium / Firefox / WebKit 通过率对比
├── 模块统计        模块 × 通过率 × 风险等级（高/中/低）
├── 根因聚合        失败分类分布 · 高频根因排名
├── 风险与建议      高风险模块清单 · 优先修复顺序
├── 失败详情        分类 + 根因 + 内联截图 + Trace 一键打开
└── 用例明细        全量用例列表 · 按浏览器筛选

UI 自动化测试完整测试报告效果如下：

如果你之前习惯了Allure格式报告，你还可以直接在点击打开Allure报告。

整个过程，人只做一件事。调用ui-report-generator持能，然后把报告链接发进群里，等大家来看就完活了。

五、最后再啰嗦两句

先说说我的真实感受。

测试这个岗位，一直有个隐形的吃亏点。活干得不错，但呈现不出来。自动化跑了几百条用例，最后汇报的时候只剩一句「都跑过了」。前两篇把执行和诊断做扎实，如果最后一步汇报还是手工拼表，整套投入的价值就打了折扣。

ui-report-generator 补上的是最后一环，让测试的产出被看见。

一份好报告还会反过来改变协作。开发拿到报告，失败详情里截图和 Trace 直接点开，不再来回问「复现步骤发我一下」；老板拿到报告，三分钟看完大盘和风险分级，发布决策有据可依。测试的价值，就是在这种时刻被记住的。

当然，边界必须讲清楚。报告是决策的输入，不能代替决策本身。

AI 负责的事	人负责的事
多源数据融合、口径统一	确认报告口径符合团队质量标准
三维统计、风险自动分级	拍板风险是否可接受、能否发布
高频根因聚类、建议排序	结合业务判断修复优先级
失败证据内联、一键直达	拿着证据和开发对齐缺陷归属
历史趋势追踪	从趋势里发现系统性问题

特别提醒一句。通过率是输入，不是结论。90% 的通过率，剩下 10% 如果全砸在支付链路上，照样不能发；70% 的通过率，失败全集中在边缘浏览器，核心链路全绿，也许可以带条件发布。报告把数据摆齐了，判断仍然是人的事。 别让「报告好看」变成新的表演。

回顾一下整个过程。

痛点。 报告手工拼、数据口径乱、只有数字没结论、失败证据翻不着、没有历史趋势、格式因人而异。

方案。 ui-report-generator 把报告固化成「数据接入、解析关联、聚合分析、渲染成页、决策建议」的五步流程。多源数据一处融合，九大区块单文件输出，证据内联直达，风险分级直接给判断。

效果。 以前一份像样的测试报告要手工折腾一下午，还常被打回重算。现在执行诊断一完成，一句指令几分钟出报告，数据零误差，证据随手点，发布决策有了统一依据。

边界。 AI 负责融合和呈现，人负责判断和决策。报告摆齐数据，发布权在人。

大家可以自己根据本文提供的思路开发 skill，如果需要现成的教程和 skill，也可以加入「狂师 . AI 进化社」获取，里面有各类 AI 技术落地保姆级图文教程、视频教程，包括 AI 测试全流程的实战教程（保姆级手把手喂饭教程，跟着步骤操作，零基础也能快速上手，目前含有 30 多个 AI 测试全场景的 Agent Skill）。

温馨提醒，「AI 测试」只是 AI 进化社八大技能版块之一。

到这里，执行、诊断、报告，三个 Skill 各自都能独当一面了。但每次要人工依次调用三个技能，还是麻烦。下一篇，ui-pipeline-scheduler，把整条链路串成一条指令一键跑完的流水线。我们下篇见。