谷歌面试官：5年经验工程师在这5道题上翻车率超60%

去年硅谷某大厂放出一份内部数据：资深QA工程师面试通过率仅34%，其中栽在基础题上的占六成。不是算法太难，是思路太偏。

我整理了5道让5年+经验者集体踩坑的题目。它们不考框架熟练度，专测你有没有被工具驯化。

第一题：设计测试框架，先从工具聊起？

面试官问"怎么设计一个UI测试框架"，九成候选人开口就是Selenium、Playwright、Cypress三件套对比。

这是陷阱。工具选型是第五步，不是第一步。

某谷歌L6工程师在复盘帖里写：「我花了10分钟讲Playwright的auto-wait机制，面试官打断我问——你的被测系统是什么架构？我愣了。」

正确打开方式：先问被测产品的技术栈、发布频率、团队规模、失败容忍度。微服务单体架构的测试策略完全不同，日发百次和月发一次的稳定性要求天差地别。

工具是解决方案的副产品，不是起点。

第二题：面对故障页面，先写测试还是先排查？

场景：生产环境订单结算页白屏，给你30分钟。

新手本能：打开IDE写复现脚本。老手陷阱：直接抓日志看报错。

某Meta面试官透露，他们期待的路径是：先确认影响范围（哪些用户？哪个区域？）、再判断是前端渲染还是API超时、最后才决定要不要补自动化。

「很多人把自动化当成万能药，」一位从业8年的SDET说，「但自动化是验证假设的手段，不是发现问题的眼睛。」

这道题测的是：你能不能区分"需要快速止血"和"需要长期预防"。

第三题：给你源码，怎么选最小测试集实现全覆盖？

这是道数学题披着代码的外衣。

候选人拿到一个用户注册模块的源码，里面有邮箱验证、密码强度检查、手机号格式校验、短信验证码四个分支。面试官要求：用最少用例覆盖所有路径。

常见翻车现场：把每个分支单独测一遍，得出8个用例。更隐蔽的翻车：忽略了分支之间的组合爆炸——邮箱格式对但密码弱、密码强但手机号错。

正确答案涉及等价类划分和边界值分析的基本功。一位通过这道题的工程师回忆：「我画了张决策树，面试官眼睛亮了。」

覆盖率的敌人不是漏测，是冗余。

第四题：测试报告怎么写才算"有用"？

听起来像送分题，实际是送命题。

面试官展示两份报告：A报告列出200条用例，187通过13失败；B报告只有一句话"支付模块存在严重缺陷，建议阻断发布"。

选A的候选人被追问：13个失败里几个是阻塞性bug？哪些可以降级？开发修复优先级怎么排？

选B的候选人被追问：严重缺陷的证据链在哪？影响用户量估算了吗？有没有临时规避方案？

某亚马逊Principal Engineer的评判标准：「好的测试报告要让项目经理能决策，让开发能定位，让运维能回滚。三缺一就是不及格。」

第五题：你的框架怎么保证"可维护性"？

这是道开放题，也是面经重灾区。

背答案的候选人会提Page Object模式、数据驱动、配置外置。面试官接着问：你们团队上次重构测试代码是什么时候？为什么重构？重构前后维护成本差多少？

答不上来的，基本都是照搬网上最佳实践，没在自己项目里摔过跤。

一位通过Netflix面试的工程师分享：「我说我们曾用3个月把3000行测试代码压到800行，面试官追问细节，我讲了具体哪个抽象层设计错了、怎么逐步替换、怎么保证替换期间CI不挂。」

可维护性不是设计出来的，是迭代出来的。

这五道题的共同点：它们不考你知道多少，考你知不知道"为什么"。

工具会过时，Playwright可能取代Selenium，但"先理解问题再选方案"的思维不会。面试市场正在惩罚那些把自动化当成流水线操作的工程师，奖励那些能讲清楚决策链条的人。

某大厂招聘负责人透露，他们今年加了道新题：「如果明天公司决定砍掉所有UI自动化，你会怎么证明测试团队的价值？」

你的答案是什么？