UI 自动化：UI 自动化到底适合哪些业务场景
第一次做 UI 自动化时，容易陷入一个非常自然但代价很高的误区：既然浏览器也能自动点，那就把所有核心功能都录进去、跑起来。结果往往是：
- 第一版看起来很热闹
- 第二个月开始大量修脚本
- 第三个月团队开始说 UI 自动化不靠谱
问题通常不在工具，而在场景选择。UI 自动化从来不是“能测的都测”，而是“哪些业务路径值得用最贵的验证方式去测”。因为和接口自动化相比，UI 自动化天然更慢、更脆、更依赖页面结构，也更依赖等待、账号、数据和浏览器环境。
所以 UI 自动化更适合先遵循一个判断：先判断值不值得做，再判断怎么做。
一、在真实项目里怎么判断一个场景值不值得上 UI 自动化
判断时不该先问“这个页面能不能自动点”，而是先看下面五个维度。
1. 这个场景回归频率高不高
如果一个业务路径每个版本都要回归，人工每次都要花很多时间，那它就值得优先评估自动化。
典型例子：
- 登录
- 搜索和筛选
- 新建核心业务对象
- 审批流关键节点
- 发布和状态切换
而如果一个功能一年只验证几次，或者只有少量边缘用户使用，UI 自动化的收益通常不高。
2. 这个场景是不是只能从 UI 视角发现问题
有些风险接口层根本看不到，例如：
- 按钮该置灰却没置灰
- 表格筛选结果展示错位
- 富文本编辑器无法输入
- 图表点击交互异常
- 弹窗流程卡住
这类问题如果不用 UI 自动化或人工验证，很容易漏掉。所以只要风险主要体现在“页面行为和页面结果”，UI 自动化价值就会明显上升。
3. 页面结构和交互是否足够稳定
如果某个页面还处在快速迭代阶段，例如：
- 每周重构组件
- DOM 结构经常变化
- 交互方案尚未稳定
那这个阶段重投入 UI 自动化，通常得不偿失。因为你会把大量时间花在追前端变更，而不是在积累可复用测试资产。
4. 这个场景能否被合理拆小
我不太赞成一上来就写超长端到端脚本。例如：
- 登录
- 创建数据
- 提交审批
- 回到列表
- 换角色审批
- 再查看详情
一条脚本串 7、8 个动作，看起来覆盖很全，实际上失败点太多，维护成本非常高。真正适合上 UI 自动化的场景，往往是能被拆成几个高信号的小链路。
5. 后续能否长期维护
这点很容易被忽视。比如一个流程需要：
- 多个第三方页面
- 随机验证码
- 高风险真实写操作
- 复杂手工前置数据
那它即使技术上能写，也不一定值得放进长期回归体系。
二、最适合优先自动化的 4 类场景
如果按收益排序，通常最先选这几类。
1. 核心高频后台流程
例如管理后台、运营后台、审批系统里最常走的主路径：
- 登录
- 列表查询
- 新建对象
- 提交审批
- 状态变更
这类场景最适合先做 smoke 和稳定回归。
2. 只能从页面视角暴露风险的交互
例如：
- 表单联动
- 按钮状态切换
- 弹窗确认流程
- 分页和筛选展示
- 富文本与图表操作
这些场景很难被接口自动化替代。
3. 人工巡检成本高的页面集合
有些系统不是单个流程复杂，而是页面数量多、权限多、人工点一轮特别费时间。这类系统非常适合做页面级 smoke 和巡检自动化。
4. 线上浏览器化探针场景
例如：
- 登录是否正常
- 首页是否可打开
- 核心列表是否能加载
这种场景更像“业务可用性哨兵”，价值很高，但设计要非常克制。
三、通常不会优先做的场景
下面这些，通常会很谨慎。
1. 变化特别快的活动页、专题页
它们结构变化太快，定位和等待逻辑会持续抖动，不适合作为长期资产沉淀。
2. 可以被接口层更稳定覆盖的逻辑
如果主要风险在状态流转、数据写入、副作用验证，那优先应该用接口自动化，UI 只保留少量展示层验证。
3. 强验证码、强风控、强第三方依赖流程
这类流程经常不适合持续无人值守执行。
4. 低频长尾流程
如果功能低频、人工验证成本不高，没必要强行用 UI 自动化增加维护负担。
四、在项目里怎么分层，而不是“全量自动化”
真实项目里，通常会把 UI 自动化拆成三层。
1. Smoke 层
只保留最核心的 5 到 10 条高信号路径，例如：
- 登录
- 核心列表打开
- 新建主业务对象
- 关键状态变更
这层的目标是：
- 每次发版前快速验证
- 每日自动检查主链路是否还活着
2. 核心回归层
覆盖业务主路径和一部分高价值交互，但不会贪多。这里更多考虑业务代表性，而不是覆盖率好看。
3. 观测与留痕层
包括：
- 截图
- video / trace
- 失败步骤
- 页面 URL
- 环境、角色、任务上下文
这一层看起来不像测试 case，但它决定了 UI 自动化失败后到底值不值得维护。
五、怎么结合工具选场景
UI 自动化适不适合一个场景，和工具也有关。更常见的判断方式是：
Playwright: 新项目、现代前端页面、需要较强等待和留痕能力Selenium: 历史资产重、兼容需求强、已有成熟 WebDriver 基础设施chromedp: Go 技术栈、内部巡检、轻量浏览器化探针
也就是说，不适合先统一工具，再硬套场景，而是先看场景，再决定工具。
六、一个真实业务系统里，怎么取舍
假设有一个运营后台，包含：
- 登录
- 活动列表查询
- 新建活动
- 审核活动
- 活动上线
- 数据看板
如果要从零开始做 UI 自动化，不适合六个全上，而更适合先选：
- 登录
- 活动列表查询
- 新建活动
- 审核通过后状态变化
为什么不先上数据看板：
- 图表断言成本高
- 页面渲染波动大
- 人工判断很多时候更直接
为什么不上“上线”：
- 写操作风险更高
- 后台副作用可能更重
- 可以先通过接口自动化覆盖核心状态流转
这也说明：UI 自动化不是“看起来重要就上”，而是“信号够强、维护成本可控才上”。
七、怎么判断一个 UI 自动化场景选对了
不该只看 case 数量，而更该关注这些结果：
- 每次回归时，人工点击量是否明显下降
- 失败时，团队是否更愿意相信结果
- 关键页面异常是否更早暴露
- 脚本维护成本是否和收益相匹配
如果这些没有发生，那大概率不是脚本写得不够多，而是场景本身就没选对。
八、结语
UI 自动化真正值钱的地方，不在于“页面也可以被自动化”，而在于它能替代那些高频、稳定、关键、人工成本高且只有用户视角才能暴露风险的验证动作。场景选对了，UI 自动化会是高价值资产；场景选错了，再先进的框架也只会变成一堆难维护的脚本。