“简历上写了‘主导Playwright自动化框架搭建，覆盖800+用例’，结果三面被五个问题问穿，HR直接结束了流程。”
这是最近一个大厂测开岗的真实反馈。面试官后来跟我复盘，说了一句话：“他那行字，经不起五个追问。”
我翻了2025到2026年字节、腾讯、美团测开岗的公开面经和面试指南，Playwright相关的追问高度集中。面试官不是在考你API记没记住，是在考你有没有真在生产环境里被这些机制坑过、修过、总结过。 下面这五道，答不好，简历上那行Playwright就等于白写。
第一题：“page.route() 和 page.waitForResponse() 有什么区别？”
这道题在字节、腾讯的网络控制轮里出现频率极高，很多人第一反应是“route用来Mock，waitForResponse用来等响应”。面试官听完不会追问，但心里已经给你降档了——这个回答说明你用过，但没想过为什么要有两个API。
面试官在听什么： 他要你区分“拦截”和“观察”是两种完全不同的意图。page.route() 是拦截层，你能改请求、改响应、模拟500、直接abort，请求不会到达真实服务器。page.waitForResponse() 是观察层，真实请求照常发生，你只是在旁路捕获响应，不改它。前者像交警改道，后者像路人在终点等车。
更关键的是执行顺序。route必须在触发动作之前注册，否则请求已经发出去了，拦截器才挂上，等于没挂。waitForResponse的Promise也必须在点击之前创建——如果先点再等，响应可能已经回来了，测试会一直挂到超时。
拿分答法： “route是控制，waitForResponse是观察。route提前注册改请求，waitForResponse和点击用Promise.all并发起来。顺序写反，一个不生效，一个等不到。”
第二题：“怎么验证‘点击提交之后，接口真的被调用了’？”
这道题最能区分“写过脚本”和“做过工程”。普通答法是点完之后等页面出现“提交成功”，然后断言文案可见。面试官会追问：“前端乐观更新了，接口根本没发出去呢？”
面试官在听什么： 他要你证明“页面说成功”和“接口真的发了并返回了正确结果”是两件事。Playwright的UI断言只证明用户看到了什么，waitForResponse才证明系统做了什么。前端可以先弹Toast再发请求，也可以请求发了但返回500——只看Toast，两种情况都会绿。
拿分答法分两层。 第一层，在点击之前创建响应等待，用Promise.all并发：
async with page.expect_response(
lambda r: "/api/order/submit" in r.url and r.request.method == "POST"
) as resp_info:
await page.get_by_role("button", name="提交").click()
response = await resp_info.value
assert response.status == 200
第二层，断言不能停在状态码。看响应体的业务code、关键字段，涉及订单和支付的场景再通过接口或数据库确认最终状态。一句话收尾给面试官： “UI断言证明用户看到了，网络断言证明系统做了，业务断言证明结果对了。少一层就是在赌。”
第三题：“React页面class是随机生成的，你怎么定位？”
腾讯和美团的元素定位轮很爱问这个。答“用XPath”或者“用CSS选择器”的，基本就停在这里了。React的class是哈希值，每次构建都可能变，拿它做定位等于把脚本绑在一次构建上。
面试官在听什么： 他要知道你有没有“定位稳定性”的工程意识，以及你有没有推动前端配合的意识——这是测开和普通自动化的分界线。
拿分答法分优先级。 首选getByRole配合可访问名称，比如getByRole("button", name="提交订单")——它走的是浏览器的可访问性树，class怎么变都不影响。退一步用getByText，因为文本是产品需求，不是技术实现，前端能改id和class，但按钮叫什么名字通常是产品决定的。需要绝对稳定时用getByTestId，但这需要前端加data-testid。
加分点在“推动”上： “getByTestId最稳，但前端不配合就用不了。我会在PR评论里建议加testid，把自动化覆盖的诉求提前到开发阶段，而不是等挂了再回来求人。”
第四题：“多个测试并行跑，登录态冲突怎么处理？”
字节和美团的面经里反复出现，因为它是工程实践的分水岭。答“每个测试重新登录”的，面试官会算一笔账：800条用例，每条登录几秒，光登录就吃掉大量时间，而且并行worker之间会互相踢下线。
面试官在听什么： 他要知道你懂storageState，更要知道你懂浏览器上下文隔离和按worker隔离状态。
拿分答法： 在setup阶段登录一次，把cookies和localStorage存成storageState文件，后续测试直接加载，跳过重复登录。并行时，每个worker用独立的browser.newContext()，上下文之间cookies完全隔离。但共享同一份storageState文件是有风险的——一个worker的登出或会话失效会连带拖垮其他worker。
拉开差距的一句： “如果多worker共享一个账号，要按worker生成独立的state文件，或者给每个worker分配独立账号。storageState文件本身要当凭据对待，不能提交到仓库，不能出现在CI日志里。”
第五题：“你说你搭了Playwright框架，那框架底层怎么定位元素的？”
这是字节飞书面经里原话级别的追问。简历上写“搭建框架”的人，一定会被问到这一层。很多人到这里就虚了，因为他的“搭框架”其实是“把demo改吧改吧”。
面试官在听什么： 他要确认“搭建”两个字背后，你理解了多少层。Playwright通过CDP（Chromium）、DevTools协议（Firefox）或WebKit原生协议建立持久双向连接，不是WebDriver的HTTP请求-响应轮询。定位器每次动作前会做可操作性检查——元素在不在、可见不可见、稳不稳定、能不能接收事件、有没有被遮挡——这些检查内建在动作生命周期里，不是轮询DOM，稳定性检查甚至用的是requestAnimationFrame来检测动画，不是sleep循环。getByRole底层走的是可访问性树，不是CSS选择器匹配。
拿分答法： 不用背源码，但要能说清楚“定位器每次重新解析、动作前做可操作性检查、等待的是状态信号而不是固定时间”。收尾一句： “如果我说不清底层，简历上该写‘使用过Playwright’，而不是‘搭建了框架’。搭框架的前提是知道每一层在替你做什么。”
这五题背后是同一条线
page.route和waitForResponse考的是控制和观察的边界；验证接口被调用考的是UI成功和业务成功的边界；React定位考的是定位稳定性和工程推动的边界；登录态并行考的是状态隔离和污染的边界；框架底层考的是“使用”和“搭建”的边界。
面试官用这五个追问，验证的是同一件事：你简历上那行Playwright，是跑通过demo，还是在生产环境里被它坑过、修过、想明白了为什么。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
