谷歌面試官：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自動化，你會怎么證明測試團隊的價值？」

你的答案是什么？