UI 自动化：Selenium 自动化测试的优缺点复盘

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

Selenium 这些年很容易被一句话概括掉：老、重、没有 Playwright 顺手。这个评价不完全错，但也太粗。

更贴近实战的判断是，Selenium 的核心问题不是“不能做 UI 自动化”，而是它对工程纪律的要求高很多。等待写不好、页面分层做不好、失败留痕做不好，它就会显得特别脆；但如果项目已经基于它沉淀了大量资产，贸然推翻重写，也未必是最优解。

所以我一直不把 Selenium 当成“应该立刻淘汰的老框架”，而是把它看成：在历史资产丰富、兼容诉求强、团队经验完整的条件下，依然值得保留和治理的执行底座。

一、我什么时候还会继续用 Selenium

即使现在，如果遇到下面这些情况，我依然会认真考虑 Selenium。

1. 已经有大量成熟脚本资产

有些项目已经积累了几十到上百条 case，外面还包着：

  • Jenkins Job
  • Allure 报告
  • 页面对象层
  • 失败截图和日志

这时候一刀切换技术栈，收益不一定覆盖重写成本。

2. 兼容性需求比较重

一些企业内网系统、老旧浏览器环境、混合前端技术栈项目，团队已经围绕 Selenium 摸透了很多坑，继续保留会更现实。

3. 团队经验结构已经固化

如果团队里 Java、Python 测试开发都长期用 Selenium，相关治理经验是现成的，那它的“总拥有成本”不一定比新框架更高。

二、我在真实项目里怎么搭 Selenium

如果是 Python 技术栈，我比较常见的组合是：

  • selenium
  • webdriver-manager 或固定驱动版本
  • pytest / unittest
  • Allure 或 HTML 报告
  • Jenkins 调度

如果是 Java 项目，则会更常见：

  • Selenium + TestNG / JUnit
  • Maven
  • Allure

这些组合本身都不是问题。真正决定项目质量的，仍然是你有没有把等待、定位、页面对象、截图留痕这些东西做成统一能力。

三、Selenium 真正强在哪里

1. 生态成熟

驱动管理、远程执行、Selenium Grid、报告生态、历史问题沉淀，都很完整。很多“怎么做”的问题，你都能找到成熟经验。

2. 多语言支持广

Python、Java、JS、C# 都能较完整使用，对于多语言团队来说协作成本更低。

3. 历史项目兼容性强

这一点非常现实。很多老项目不是你能随时重构的，而 Selenium 往往已经和这些项目磨合了很久。

四、它真正的成本在哪里

Selenium 最大的问题，不是 API 老，而是很多高频成本没有像 Playwright 那样帮你处理掉。

1. 等待成本高

如果团队没有明确的等待设计，代码会迅速变成：

  • sleep(2)
  • sleep(3)
  • try except
  • 再 sleep(1)

这种代码不是不能跑，而是会越来越不可信。

2. 现代前端异步场景支持不够顺手

像这些场景：

  • 虚拟列表
  • 分片加载
  • 动态挂载
  • 请求完成后延迟渲染

如果还是用很原始的等待方式，脚本会非常脆。

3. 失败调试成本高

Selenium 默认留给你的通常是异常堆栈，但真正要定位问题，至少还需要：

  • 截图
  • 当前 HTML
  • 当前 URL
  • console log
  • 最近一步操作说明

如果这些都没有，维护成本会高很多。

五、怎么把 Selenium 项目从“能跑”治理到“可维护”

接手一个 Selenium 项目时，通常会先做四件事。

1. 统一定位策略

强制收敛成：

  • id
  • data-testid
  • 稳定文本
  • 少量相对结构定位

尽量避免长 XPath 和基于顺序的定位。

2. 统一等待层

不适合让 case 自己到处写等待，而更适合统一抽到：

  • waits.py
  • 页面对象里的 wait_loaded()
  • 组件对象里的 wait_ready()

3. 页面与组件分层

很多 Selenium 项目之所以越来越乱，是因为所有动作都写在 test 里。会强制拆成：

  • Page Object
  • Component Object
  • Business Action

这样前端结构变更时，改动更集中。

4. 失败现场留痕

至少固定输出：

  • 截图
  • HTML 源码
  • 当前 URL
  • console error

这些不是附加能力，而是让脚本值得维护的前提。

六、一个真实后台系统里，怎么用 Selenium

假设我要自动化一个内部用户管理后台，流程包括：

  • 登录
  • 搜索用户
  • 编辑用户状态
  • 提交审核

test 文件不适合写成满屏页面动作，更适合这样拆：

1
2
3
4
5
6
7
8
9
ui_tests/
├── tests/
├── pages/
│   ├── login_page.py
│   ├── user_list_page.py
│   └── audit_dialog.py
├── waits/
├── reports/
└── utils/

业务 case 里只保留：

  • 登录
  • 搜索目标用户
  • 编辑状态
  • 断言结果

而不是直接写具体 XPath 和底层点击细节。

七、怎么判断 Selenium 项目该继续保留还是迁移

通常不看“这个框架新不新”，而看下面几个现实问题：

1. 当前资产量大不大

如果已经有很多稳定脚本和外围基础设施，迁移前要先算清收益。

2. 当前痛点是不是工具本身导致的

如果问题主要是：

  • 定位太乱
  • 等待太乱
  • 没有留痕

那先治理现有项目，收益往往比重写更高。

3. 后续场景是不是更适合 Playwright

如果新系统前端更现代、多人并发角色更多、需要 trace 和更好的等待体验，那新项目优先 Playwright 会更自然。

八、结语

Selenium 的问题从来不是“已经没法用了”，而是它把更多工程成本留给了使用者自己承担。等你把等待、定位、页面分层、失败留痕这些基础设施都做好，它依然能支撑很多真实业务回归。对 Selenium 最正确的态度，不是情绪化淘汰，而是先看资产、再看问题、最后看迁移收益。

本章延伸阅读