07 UI 与 App 自动化

狂师2026/8/25...大约 5 分钟

UI 自动化能做，但不要一上来就把所有回归都押在 UI 上。它更贵、更脆、更难维护。

为什么重要

UI 自动化是测试岗的「刻板印象技能」，面试必问，但它的真实定位需要先摆正：

工具	定位	说明
Playwright	2026 年新学首选	微软出品，自动等待、多浏览器、并行执行、Trace 调试体验好，支持 Python / Java / JS / C#
Selenium	企业存量大、面试常问原理	WebDriver 协议事实标准，生态最老最全
Cypress	前端团队用得多	跑在浏览器里，前端栈团队的 E2E 选择

如果从 2026 年开始新学，优先学 Playwright，再了解 Selenium。Selenium 的生态和面试价值仍然在（面试常问 WebDriver 原理、显式等待和隐式等待区别），但新项目的稳定性和开发体验，Playwright 往往更舒服。

选择器策略：优先 get_by_role / get_by_test_id（推荐让团队加 data-testid），少依赖脆弱的 CSS / XPath 层级。
自动等待机制：理解它为什么比 sleep 可靠。
网络拦截与 Mock：route 拦截请求，测前端时 mock 后端异常。
调试三件套：Trace Viewer、截图、录屏——失败回放定位问题的核心。
多浏览器与移动视口：Chromium / Firefox / WebKit 一套代码跑三引擎。

主力是 Appium。要理解：

UI/App 自动化和接口自动化拉开差距的地方：

Page Object Model（POM）：页面元素和操作封装成页面对象，业务步骤调用页面对象。别把定位和步骤全写一个文件里——页面改版时你要改 50 个文件。
稳定等待：用条件等待（元素可见、可点击、网络空闲），少用固定 sleep。
失败现场留存：截图、视频、Trace、页面 HTML 快照、console 日志，失败自动收集。
测试数据隔离：每条用例独立账号 / 独立数据，避免互相污染。
并行执行与失败重试：并行提速，重试只对「环境性抖动」开，且重试要留痕——盲目重试会掩盖真实问题（flaky 用例治理是高级话题，面试加分项）。
用例分级：冒烟集（每天 / 每次提交）、核心回归集（每天）、全量（每周），分级执行控制时长。

但记住：UI 自动化的稳定性来自工程设计（POM、等待、数据隔离），脚本生成速度只是开始。

选一个真实系统练：开源后台管理系统（如若依 RuoYi、vue-element-admin 的 demo）是绝佳靶场，有登录、表格、表单、弹窗、上传等典型组件。把「登录 → 建用户 → 改角色 → 删用户」做成稳定的主流程用例，比跑 100 个 demo 页面有价值。
先把 10 条用例做稳定，再谈 100 条。判断标准：连续 7 天在 CI 上跑，0 次误报。做不到就先治理稳定性，别扩量。
误区一：录制的脚本直接用。 录制工具（Playwright codegen）是学习工具，录出来的是「操作序列」不是「工程」。一定要重构进 POM 结构。
误区二：XPath 全靠绝对路径。 /html/body/div[2]/div[3]/... 这种定位，前端改个布局全挂。用语义化定位（role、test_id、文本）。
误区三：用 sleep 解决一切不稳定。 sleep(5) 堆多了，用例集又慢又不稳。定位每个不稳定点的真实原因：是等待不足、数据竞争还是环境问题。
误区四：UI 自动化追求覆盖率。 UI 层求的是「核心流程不坏」，覆盖率交给接口层和单元测试层。