大家好，我是狂师。
前两篇，我们把「跑测试 」和「修脚本」都交给了 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输出的诊断报告（分类、根因、修复状态）- 历史执行数据（多次通过率序列，可选）
处理逻辑：
- 多源数据解析：读取执行结果，提取每条用例的状态、耗时、浏览器；把截图、录屏、Trace 逐条关联到对应用例；解析诊断报告，取出每条失败的分类与根因；
- 多维聚合分析：按业务模块、按优先级、按浏览器三个维度分组统计，失败按根因聚类，找出高频问题；
- 风险分级：模块通过率低于 70% 标为高风险，70% 到 90% 中风险，90% 以上低风险；
- 优化建议生成：基于失败模式自动产出建议（哪个模块优先修、环境问题集中处理、跨浏览器差异排查）；
- 单文件渲染：全部 CSS、图表、截图内联进一个 HTML，发给谁、在哪台机器都能直接打开。
输出：
- 一份单文件 HTML 可视化测试报告（
ui_test_report.html）
适用场景：
- 执行/诊断完成后一键生成测试报告
- 版本发布前出质量评估报告，支撑发布决策
- 多浏览器矩阵执行结果对比分析
- 历史趋势追踪，看质量是在变好还是变差
- 失败用例证据（截图/录屏/Trace）随报告一键直达
它的整个设计遵循两条原则。
只读，只写一份报告。 这个 Skill 有一条硬约束，不改测试脚本、不改页面对象、不改任何配置文件。它读入所有结果，唯一写出的东西就是那一份 HTML 报告。测试工程干干净净，报告爱怎么生成就怎么生成。
报告是给决策看的，不是给存档看的。 每个区块都必须回答一个具体问题，整体能不能发、风险在哪、先修什么、证据在哪。回答不了的区块，一律不放进报告里。
落到流程上，它固化成一套报告生成五步流程。
bash
数据接入 → 解析关联 → 聚合分析 → 渲染成页 → 决策建议
对着前面这几个问题，一步一步看它是怎么拆的。
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，输入一句指令。
bash
/ui-report-generator 把刚才那轮的执行结果和诊断结论，
生成一份测试报告，带上失败截图和趋势
接下来，Skill 自动会完成四件事。
第一，多源数据接入。 读入 JUnit 执行结果、上一轮的诊断报告、artifacts 里的截图录屏 Trace、浏览器环境清单，还有最近几次的历史通过率。
第二，聚合分析。 按模块、优先级、浏览器三个维度分组统计，失败按根因聚类，模块按通过率标出高中低三档风险。
第三，渲染成页。 九大区块依次生成，报告头部、总览大盘、数据图表、浏览器矩阵、模块统计、根因聚合、风险建议、失败详情、用例明细，全部内联进一个 HTML 文件。
第四，给出决策建议。 高风险模块排在最前，高频根因标亮，配着「先修什么」的具体建议。
值得注意的是，测试报告还增加了失败截图、操作录屏、查看DOM快照、Console日志、打开Trace 等功能。 
最终拿到的报告，结构长这样。
text
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，把整条链路串成一条指令一键跑完的流水线。我们下篇见。