UI 自动化：UI 自动化测试结果如何做可视化展示
UI 自动化结果如果只剩一句 passed / failed，那它的价值通常非常有限。因为 UI 自动化和接口自动化最大的不同，是它的关键信息大量存在于“现场”里：
- 页面当时长什么样
- 卡在第几步
- 当前 URL 是什么
- 异常更像环境问题还是业务问题
如果这些信息没有被组织进结果展示里，维护者最终还是只能回到最原始的方式：本地重跑、边跑边看、猜到底发生了什么。
所以我一直把结果可视化看成 UI 自动化体系的一部分，而不是跑完之后顺手做个报告。
一、我最反对哪种“结果展示”
最没价值的一类结果页通常长这样：
- 只有通过数和失败数
- 点击进去只有控制台日志
- 没有截图
- 没有失败步骤
- 看不到历史趋势
这种报告更像“证明任务确实执行过”，而不是帮助团队理解为什么失败。
二、更关键的是 UI 自动化结果页至少要承载什么
如果要设计，我至少会把结果拆成四层信息。
1. 任务层
例如：
- 环境
- 浏览器类型
- 执行人或触发方式
- 开始时间、结束时间
- 总通过率
这一层用于快速回答：这次任务到底是什么背景下跑出来的。
2. Case 层
例如：
- case 名称
- 执行状态
- 执行时长
- 失败分类
- 失败发生步骤
这一层用于快速筛选问题范围。
3. 现场层
这是 UI 自动化最核心的一层，包括：
- 截图
- video 或 trace
- 当前 URL
- 页面标题
- 最近一步动作
这一层决定维护者能不能在不重跑的情况下先看出大概问题。
4. 历史层
例如：
- 最近 7 次成功率
- 最近失败类型分布
- 是否属于高噪声 case
这一层决定结果页能不能支撑治理，而不只是当次查看。
三、为什么失败分类在 UI 自动化里特别重要
的 UI 报告只会告诉你“失败了”，但不会告诉你失败属于哪一类。真实项目里，这个区别非常关键。
通常会至少区分：
- 定位失败
- 等待失败
- 环境失败
- 数据失败
- 业务断言失败
有了这层分类以后，结果页就能回答：
- 是页面真坏了
- 还是脚本需要治理
- 是环境抖动
- 还是测试数据前置没准备好
如果没有分类，报告越多，越容易把人看麻木。
四、怎么组织产物，而不是只留 HTML
如果是平台或 Jenkins 任务，不适合只产一份 HTML 报告，而更适合统一保留：
- HTML 报告
- 截图目录
- video / trace 文件
- 结构化 JSON 结果
其中 JSON 是最容易被低估的部分。因为后面所有：
- 历史趋势
- 高频失败页面统计
- 高噪声 case 识别
- 平台化展示
都依赖结构化结果，而不是依赖解析控制台日志。
五、一个更接近现场的结果查看链路
假设有一条“新建任务” case 失败了，我希望结果页里第一屏就能看到：
- 失败发生在第几步
- 当时页面截图
- 当前 URL
- 最近一步动作说明
- 失败分类
- 最近 7 次成功率
如果再往下一层，还能看到：
- video 或 trace
- console error
- 同类失败最近是否频繁出现
这样维护者大概率不用先把任务重跑一遍。
六、为什么“历史趋势”不是可有可无
只看单次执行结果，但真正的治理价值往往来自趋势。
比如某条 case 今天失败了，单次看不出太多东西；但如果你看到：
- 最近 10 次里失败了 6 次
- 而且 5 次都是等待失败
那你几乎可以确定：这不是偶发环境问题，而是脚本设计本身需要治理。
所以会把趋势能力看成结果页的“治理入口”，不是附属图表。
七、如果平台化，怎么展示
如果接进平台，通常会在结果页上给三个入口：
1. 快速看现场
给测试、研发最快速判断问题用。
2. 深入看产物
包括：
- 截图
- video
- trace
- 日志
给维护者深挖问题用。
3. 看历史趋势
包括：
- 最近成功率
- 失败分类占比
- 高频失败页面
- 高噪声 case
给团队做治理用。
这三种消费方式缺一不可。
八、怎么判断结果展示是不是做对了
更值得看的结果是：
- 失败后是否能更快判断问题方向
- 维护者是否更少需要本地复现才能开始排查
- 团队是否能直接从结果页识别高噪声 case
- 报告是否真的被用来做治理，而不是只是存档
如果这些结果没有出现，那说明结果页可能只是“更好看了”，还没有真正提升工程价值。
九、结语
UI 自动化测试结果的可视化展示，核心不是图表多漂亮，而是让截图、步骤、分类、trace 和趋势足够快地帮助团队理解失败。只有做到这一点，结果页才不是附件，而是 UI 自动化体系里真正能降低维护成本、提升决策效率的一层基础设施。