测试开发岗位常见的 UI 自动化面试题
UI 自动化是测试开发岗位里非常常见的一类面试内容。
但很多同学在准备时容易走偏，要么只背工具 API，要么只会说“我会 Selenium”“我会 Playwright”，一到深入追问就答不上来。
实际上，面试官真正想考察的，通常不是你会不会写一两行脚本，而是：
- 你是否真正做过 UI 自动化
- 你是否理解 UI 自动化的价值和边界
- 你是否知道怎么设计稳定的自动化方案
- 你是否具备排查问题和落地工程化的能力
这篇文章就整理一份测试开发岗位里非常常见的 UI 自动化面试题，并给出相对实用的答题思路。
一、UI 自动化到底有什么价值
面试题
你觉得 UI 自动化测试的价值是什么？
参考答法
UI 自动化的核心价值，是用少量高价值脚本覆盖关键主流程，降低人工回归成本，并在发版前尽早发现页面交互和端到端流程问题。
它特别适合验证用户真实操作路径，比如登录、下单、审批这类核心流程。
但它不适合覆盖所有场景，因为维护成本通常比接口自动化更高。
面试官想听什么
- 你知道 UI 自动化有价值
- 但你也知道它不是万能的
二、为什么很多团队不会把所有功能都做成 UI 自动化
面试题
为什么 UI 自动化不能覆盖全部回归？
参考答法
因为 UI 自动化执行慢、维护成本高、容易受页面结构变化和异步加载影响。
如果把所有功能都放到 UI 自动化里，后期维护压力会非常大。
所以实际项目里更常见的做法是：接口自动化做大部分回归，UI 自动化覆盖核心主流程。
加分点
如果你能补一句：
UI 自动化更适合做“少而精”
面试官通常会觉得你比较有实战感。
三、Selenium 和 Playwright 有什么区别
面试题
你用过 Selenium 吗？和 Playwright 相比你怎么选？
参考答法
Selenium 生态成熟、历史沉淀多，很多企业老项目都在使用。
Playwright 对现代前端支持更友好，自动等待、调试、录屏和 trace 能力通常更强。
如果是已有 Selenium 体系的老项目，我会优先考虑延续和优化；如果是新项目从零开始，通常会更倾向于 Playwright。
面试官想听什么
- 你理解两者差异
- 你不会只会机械站队
- 你有选型思维
四、UI 自动化框架通常怎么设计
面试题
你做过 UI 自动化框架吗？一般怎么设计？
参考答法
常见设计思路是分层。
比如配置层管理环境和浏览器，基础层封装 driver 和公共操作，页面对象层管理元素和页面行为，业务流程层封装跨页面操作，用例层只保留测试场景和断言。
同时还要配套日志、截图、报告、测试数据管理和 CI 集成。
加分点
如果你能主动提到：
- POM
- BasePage
- 业务流程层
- 截图和日志
- Jenkins/CI
通常会比较加分。
五、什么是 POM
面试题
Page Object Model 是什么？有什么好处？
参考答法
POM 就是页面对象模型，核心思想是一个页面对应一个类，把页面元素和页面操作都封装到这个类里。
这样可以把页面变化和测试用例隔离开，提高可维护性和复用性。
当前端页面元素变化时，通常只需要修改页面对象层，而不需要改所有用例。
常见追问
POM 有什么缺点？
可以答：
如果页面对象职责划分不清，或者把太多业务逻辑塞进页面类里，也会导致页面对象越来越臃肿，所以通常需要配合业务流程层一起设计。
六、页面元素定位有哪些最佳实践
面试题
你平时是怎么做元素定位的？
参考答法
我会优先选择稳定、唯一、语义明确的定位方式。
比如优先使用稳定的 id、name 或 data-testid 这类测试专用属性。
如果必须使用 CSS 或 XPath，也会尽量避免过深层级和绝对路径，降低前端改版带来的影响。
面试官想听什么
- 你知道定位稳定性的重要性
- 你知道哪些定位方式更推荐
- 你知道哪些定位方式容易踩坑
七、为什么你的 UI 自动化脚本会不稳定
面试题
UI 自动化脚本不稳定，常见原因有哪些？
参考答法
常见原因包括元素定位不稳定、页面异步加载处理不好、过度依赖固定等待、测试数据不稳定、环境波动，以及流程本身依赖太多上下游服务。
真正要提高稳定性，通常要从定位策略、等待机制、数据管理和框架设计几个方面一起优化。
这题很重要
因为它非常能区分“只会写脚本”和“真正做过自动化”的人。
八、你怎么处理页面等待
面试题
元素还没加载出来怎么办？你一般怎么处理等待？
参考答法
我一般不推荐直接写死
sleep，因为这种方式在不同环境下不稳定。
更推荐使用显式等待或条件等待，比如等待元素可见、可点击、页面 URL 变化、关键文本出现等。
核心思想是等待“条件成立”，而不是固定等几秒。
加分点
如果你能补一句：
固定等待只是临时调试手段，不应该成为长期方案
会更有说服力。
九、UI 自动化失败了你怎么排查
面试题
如果一条 UI 自动化用例失败了，你会怎么排查？
参考答法
我会先看失败步骤和错误日志，再结合失败截图确认页面实际状态。
然后判断是定位问题、等待问题、数据问题、环境问题，还是业务本身出了问题。
如果是偶发失败，我还会结合执行视频、trace 或重跑结果，判断是不是脚本稳定性问题。
面试官想听什么
- 你有排查思路
- 你知道看日志、截图、trace
- 你不是只会说“脚本挂了”
十、你怎么做测试数据管理
面试题
UI 自动化经常依赖数据，你们是怎么管理测试数据的？
参考答法
测试数据管理非常关键。
我们通常会准备独立测试账号，尽量让数据和用例解耦。
对于有前置状态要求的场景，会在执行前初始化数据，执行后视情况做清理。
否则数据污染会直接影响自动化稳定性。
十一、UI 自动化怎么接入 CI
面试题
你们的 UI 自动化有没有接入持续集成？怎么做的？
参考答法
常见做法是把核心冒烟用例接入 Jenkins 或 GitLab CI，在代码合并后或定时任务中自动执行。
执行完成后产出报告、截图和日志，如果失败再通知相关人员。
这样 UI 自动化才不只是“本地能跑”，而是能真正参与质量保障。
加分点
如果你能补充：
- 定时执行
- 发版前执行
- 失败通知
- 报告归档
会更完整。
十二、UI 自动化和接口自动化怎么分工
面试题
如果一个项目里同时有接口自动化和 UI 自动化，你会怎么分工？
参考答法
我的思路通常是接口自动化承担大部分业务回归，因为它执行更快、更稳定。
UI 自动化则重点覆盖少量关键主流程，验证用户真实操作和页面集成效果。
两者不是替代关系，而是分工协作关系。
十三、你会怎么选自动化场景
面试题
哪些场景适合做 UI 自动化，哪些不适合？
参考答法
适合做 UI 自动化的通常是业务价值高、流程稳定、人工回归成本高的主流程，比如登录、下单、支付、审批。
不太适合做 UI 自动化的，往往是变化频繁、收益不高、维护成本很大的页面细节场景。
选型时我会更关注投入产出比。
十四、常见追问小抄
1. 为什么不建议大量使用绝对 XPath
因为它过度依赖页面结构，前端稍微改一下 DOM 层级就容易失效。
2. 为什么不建议大量使用 sleep
因为固定等待不稳定，也会拖慢执行速度，应该优先等待条件成立。
3. 为什么 UI 自动化很难做到 100% 稳定
因为它依赖页面、浏览器、网络、环境、数据和上下游服务，天然比接口自动化受影响因素更多。
4. UI 自动化最核心的能力是什么
我觉得不是写脚本本身，而是设计稳定方案、定位问题和持续落地的能力。
十五、写在最后
准备 UI 自动化面试时，最忌讳的就是只背 API。
因为面试官真正想看到的，不是你会不会写：
driver.find_element(...).click()
而是你是否真正理解：
- UI 自动化为什么做
- 适合做什么
- 不适合做什么
- 怎么设计框架
- 怎么提升稳定性
- 怎么接入工程化流程
如果用一句话总结这类面试的答题方向，我会这样说：
面试官想要的不是“会写脚本的人”，而是“能把 UI 自动化真正落地的人”。
