去年硅谷某大厂放出一份内部数据：资深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自动化，你会怎么证明测试团队的价值？」
你的答案是什么？
热门跟贴