UI 自动化：UI 自动化平台建设复盘

发表于 分类于 本文字数： 2.3k 阅读时长 ≈ 8 分钟

UI 自动化平台这个词很容易被做虚。说要做平台，最后做出来的其实只是一个页面：

  • 选环境
  • 点执行
  • 跳 Jenkins
  • 下载报告

这种东西当然有一点入口价值，但它解决不了 UI 自动化真正痛的地方。真实项目里，UI 自动化难的从来不是“怎么跑一次”，而是下面这些长期问题：

  • 多环境、多角色怎么管
  • 同一套脚本怎么支撑 smoke、回归、巡检
  • 执行器怎么调度
  • 截图、视频、trace 怎么统一沉淀
  • 哪些 case 是高噪声脚本，哪些是真问题
  • 哪些页面长期不稳定，哪些任务最该治理

如果平台不解决这些，它就只是“更贵的入口层”。

一、我为什么会从脚本走到平台

脚本阶段一般会经历三个时期。

1. 小规模脚本期

只有少量脚本，本地执行和 Jenkins 就够了，维护者也基本是测试开发本人。

2. 多任务并发期

开始出现：

  • smoke
  • nightly regression
  • 线上巡检
  • 指定模块专项回归

这时候任务组织、账号管理、结果入口开始复杂。

3. 协作平台期

再往后，使用者不再只有写脚本的人，而是：

  • 测试同学要自助执行
  • 研发希望查看某个 case 历史情况
  • 项目经理关心趋势和稳定性

这一步，平台化才真正变得必要。它承接的不是“按钮点击”，而是协作复杂度。

二、设计平台时，会先设计什么

不适合先画页面，而更适合先把下面四样东西设计清楚：

1. 任务模型

任务怎么表达，决定了平台是不是可扩展。

2. 资源模型

环境、账号、浏览器、数据池怎么表达，决定了平台是不是可持续。

3. 执行器模型

不同框架、不同节点、不同并发策略怎么跑，决定了平台是不是可运维。

4. 结果模型

最终存什么、怎么分类、怎么趋势化，决定了平台是不是有治理价值。

页面只是这四者的管理界面。

三、任务模型怎么拆

真实项目里，不适合让平台里充满一堆复制出来的任务，而更适合用一套统一任务模型承接不同场景。

至少会包含：

  • 环境
  • 浏览器类型
  • 角色集合
  • 执行范围
  • 标签
  • 并发数
  • 是否保存视频
  • 是否保存 trace
  • 是否发送告警
  • 重试策略
  • 产物保留策略

这样：

  • smoke
  • full regression
  • probe

只是参数组合不同，不需要每次复制任务。

四、资源模型为什么比页面更重要

如果平台只是一个人本地玩，资源问题不显眼；但一旦进入团队协作，环境和账号会成为最容易失控的部分。

常见问题包括：

  • 测试、预发、线上地址不同
  • 管理员、审核人、普通用户要分开登录
  • 巡检账号和回归账号不能混用
  • 某些账号有并发限制
  • 某些环境只能在固定节点跑

所以更适合把资源做成一等公民：

  • 环境资源
  • 浏览器资源
  • 账号资源
  • 节点资源
  • 数据池资源

任务执行时只引用资源，不直接写死。

五、执行层怎么设计，才不会推翻现有资产

如果结合你现有技术栈，更倾向于：

  • 平台后端：Go + Gin
  • 前端：React + TypeScript
  • 执行器：复用 Playwright、Selenium、chromedp
  • 调度：平台任务中心或 Jenkins 驱动 worker
  • 存储：MySQL / MongoDB
  • 缓存和状态：Redis

这里最关键的一点是：不要为了做平台，把已经稳定的脚本执行能力推翻重写。平台应该包裹执行层，而不是替代执行层。

六、更像真实系统的分层会长什么样

UI 自动化平台通常会拆成六层：

1
2
3
4
5
6
7
platform/
├── api/                # 任务创建、查询、报告接口
├── scheduler/          # 调度与队列
├── worker/             # 浏览器执行器
├── artifact/           # 截图、视频、trace、日志
├── analysis/           # 失败分类、趋势统计、告警
└── governance/         # 高噪声case治理、规则配置

API 层负责

  • 创建任务
  • 查询任务状态
  • 查看报告和产物
  • 查看历史趋势

Scheduler 层负责

  • 选 worker
  • 控制并发
  • 控制队列
  • 防止同类任务资源冲突

Worker 层负责

  • 拉起 Playwright / Selenium / chromedp
  • 注入环境和账号
  • 执行任务
  • 回传结果和产物

Artifact 层负责

  • 管理截图
  • 管理 video
  • 管理 trace
  • 管理执行日志

Analysis 层负责

  • 失败分类
  • 趋势统计
  • 页面稳定性分析
  • 告警判断

Governance 层负责

  • 标记高噪声 case
  • 配置降级策略
  • 调整重试和告警规则

这最后一层， 都没有，但它恰恰决定平台是不是只会“展示红灯”，还是会“帮助治理红灯”。

七、结果模型不该只存“通过/失败”

这点很重要。平台如果只存：

  • 任务状态
  • case 结果

那它和 Jenkins 的差别非常有限。

通常会至少保留：

  • case 级执行状态
  • 执行时长
  • 当前页面截图
  • trace / video
  • 失败步骤
  • 失败分类
  • 当前角色
  • 环境
  • 执行节点

这样平台后续才能回答：

  • 哪些页面最不稳定
  • 哪类失败最常见
  • 哪些 case 连续三周都在抖
  • 某次发布后是哪一类页面最先出问题
  • 哪些失败更像脚本问题而不是业务问题

八、一个真实任务执行链路会怎么走

例如用户在平台点击“预发环境核心 smoke”：

  1. 前端传入环境、浏览器、任务集、是否录屏、是否告警等参数
  2. API 层创建任务记录和执行上下文
  3. Scheduler 根据标签和节点能力选 worker
  4. Worker 初始化浏览器和账号上下文
  5. 执行 Playwright 套件
  6. 执行中即时上传截图、video、trace
  7. 全量结果回写数据库
  8. Analysis 层做失败分类和告警判断
  9. Governance 层根据历史波动更新噪声状态

这里真正有价值的不是“成功执行了”，而是平台在整个链路里形成了完整上下文和后续治理能力。

九、为什么高噪声治理必须做成平台能力

的平台做到后面，只会展示：

  • 哪些任务红了
  • 哪些 case 失败了

但这还不够。因为 UI 自动化真正长期的问题是：

  • 哪些 case 一直在抖
  • 哪些页面历史上就是高波动
  • 哪些失败其实是定位或等待问题
  • 哪些任务不该继续高优先级告警

如果平台不识别这些，它最后只会成为一个“更花哨的红灯看板”。

所以会把治理能力做进平台：

  • 标记高噪声 case
  • 降级非关键告警
  • 识别长期低价值脚本
  • 提示哪些脚本值得重构

十、平台建设里最容易踩的坑

1. 先做页面，后补执行层

结果页面有了，但底层还是零散脚本，平台最后只是个壳。

2. 没有统一任务模型

平台里充满：

  • pre-smoke-chrome
  • pre-smoke-firefox
  • prod-probe-chrome

这种复制任务，后面会非常难维护。

3. 不把资源独立出来

环境、账号、浏览器和数据池全写死在任务里，平台复杂度会迅速失控。

4. 结果产物不完整

没有截图、没有 trace、没有失败分类，平台无法真正帮助定位问题。

5. 没有治理层

平台只展示红灯，不做噪声识别和告警降级，最终用户会被结果淹没。

十一、怎么判断平台是不是做成了

通常不看页面是否好看，而看这些结果：

  • 是否降低了对少数脚本维护者的依赖
  • 是否让测试和研发能更低门槛地消费 UI 自动化能力
  • 是否能直接从平台看到失败现场和历史趋势
  • 是否能识别长期高噪声脚本并推动治理
  • 是否让 smoke、回归、巡检三类任务共用同一套执行内核
  • 是否让平台本身成为“分析与治理中心”，而不只是“执行入口”

如果这些没实现，那平台大概率只是换了一个更重的入口。

十二、结语

UI 自动化平台建设的重点，从来不是“网页上也能点一下执行”，而是把任务模型、资源模型、执行器、结果产物、趋势分析和治理闭环组织成一套基础设施。真正的平台不是为了看起来先进，而是为了让 UI 自动化从少数人的脚本能力，升级成团队长期可以消费、可以分析、可以治理的系统能力。

本章延伸阅读