面试官让我讲一下自动化框架，我说"用的POM模式"。
对面沉默了两秒，然后问："就这样？"
面了10多家以后我才搞明白——UI自动化的面试，从来不考你会不会写脚本。框架怎么设计的、稳定性怎么保证的、CI/CD怎么接的，能不能把这几件事讲清楚，才是真正拉开差距的地方。
以下是我被问到最多的几个点，全是真题，每个都附上我踩完坑以后的答法。
面试官问"说一下你的自动化框架"，很多人就说"用了POM"。这三个字等于没说。
面试官想听的是你怎么分层的，以及为什么这么分。
我的框架分了四层：
用例层：负责业务流程的编排和断言。这一层只管"测什么"和"对不对"。
业务封装层：负责跨页面的流程组合。比如"创建一个直播并开始推流"这种多步操作，封装在这一层。
页面对象层：负责单个页面的元素定位和基础操作。页面改了只动这一层，不影响上面。
通用基础层：报告、截图、日志、配置管理这些公共能力。
为什么这么分？一句话：改了页面不用改用例，改了业务不用改定位。每一层只管自己的事，维护成本才能控制住。
面试的时候这么讲，比干说"POM模式"有说服力得多。
追问1：Playwright和Selenium怎么选？这道题我被问了不下5次。
很多人只会说"Playwright比Selenium快"，面试官一追问"快在哪里"就卡住了。
两者的核心差异有几个点：
等待机制：Selenium需要你手动封装显式等待，漏了就容易flaky。Playwright每个操作自带auto-wait，会自动检查元素是否可见、可交互，不需要你额外处理。这一个差异就能减掉大量不稳定的用例。
执行原理：Selenium通过WebDriver协议，经过浏览器驱动中转。Playwright是直接跟浏览器内核通信，少了中间层，执行效率和稳定性都更好。
调试排查：Selenium失败了你只有截图和日志。Playwright有trace回放——像录屏一样还原每一步操作、每一个网络请求、每一次DOM变化。定位flaky用例的效率完全不是一个量级。
并行执行：Selenium做并行需要配Grid或自己搞多进程，配置比较重。Playwright的BrowserContext天然隔离，配合pytest多worker跑并行非常简单，每个worker一个独立上下文，互不干扰。
面试结论怎么说？新项目建议选Playwright，老项目如果用例库已经很大可以继续用Selenium维护。 不要只说"Playwright好"，说出选型依据，面试官才知道你真的用过。
这个问题几乎每家都会追问。
Playwright官方推荐的定位优先级是这样的：
第一优先：语义定位——`get_by_role`、`get_by_text`。基于元素的语义角色去定位，最不容易受页面结构变动影响。
第二优先：test-id定位——`get_by_test_id`。推动前端在关键元素上加`data-testid`属性，专门给自动化用，稳定且语义清晰。
第三优先：CSS选择器。用相对路径的CSS，不要写太长的绝对路径。
最后才是XPath。XPath最脆弱，页面结构一改就废。
但实际项目中，很多前端框架（比如Element Plus）的ARIA支持不完善，`get_by_role`不一定好使。这时候务实的做法是推动前端加`data-testid`，或者用`get_by_text`+相对CSS组合。
面试的时候，先说官方推荐的优先级，再说你实际项目的务实选择，这样既展示你知道最佳实践，又说明你有落地经验。
"加个重试不就行了？"——这句话在面试里只值20分。
Flaky用例要先分类，再按根因治理：
环境问题：测试环境不稳定、服务挂了、网络抖动。这种不是用例的问题，要从环境侧解决。
等待不足：页面还没加载完就去操作了。用Playwright的auto-wait能解决大部分，但异步数据加载的场景可能还需要额外等待状态就绪。
数据依赖：用例之间共享数据导致相互影响。每条用例应该有独立的数据准备和清理，通过fixture管理初始化和清除。
定位失效：前端改了结构导致定位挂了。靠前面说的定位优先级策略来降低这类问题的概率。
治理的方式不是无脑加重试，而是建一个flaky分类统计表，按根因归类，逐个击破。重试只是兜底，不是解法。
面试的时候说出这个分类治理的思路，比说"加重试"有说服力太多了。
"我们接了Jenkins"——这句话等于没说。
面试官想听的是：什么时候跑、跑什么、跑不过怎么处理。
我的做法是分层执行：
PR提交触发冒烟：开发提PR自动跑P0级别的核心用例，控制在5-10分钟内跑完。跑不过的PR不允许合并到主干。
定时任务跑全量回归：每天定时跑一轮完整回归，覆盖面广但不阻塞发布流程。失败了生成Allure报告推送到群里，需要人工确认是真bug还是环境问题。
版本发布前跑冒烟验证：上线前再跑一轮冒烟确认，全部通过才放行。
这个分层策略的核心是：既要保证质量门禁，又不能让不稳定的用例拖慢发布节奏。
| 维度 | Selenium | Playwright |
|---|---|---|
| 等待 | 需手动封装显式等待 | 自带auto-wait |
| 执行 | WebDriver协议，经驱动中转 | 直接与浏览器内核通信 |
| 调试 | 截图+日志 | trace回放+codegen |
| 并行 | 依赖Grid/多进程，配置重 | BrowserContext天然隔离 |
| 定位 | CSS/XPath为主 | 语义定位优先(get_by_role) |
这些题全是我被问到的真题，UI自动化的技术面基本绕不开这几个方向。建议存下来面试前过一遍。
光看不够，如果有条件，自己搭一套框架跑通一遍——面试官两句话就能分出背的和做过的。
你面试的时候被追问过哪些UI自动化的问题？有没有被问住的？
评论区聊聊，我在评论区等你。
接下来更想看哪类内容？
A. 接口自动化面试题整理
B. 性能测试/JMeter面试题整理
C. 继续写面试经历踩坑系列
留个字母就行，我按投票写下一篇。
