去年硅谷某大廠放出一份內(nèi)部數(shù)據(jù)：資深QA工程師面試通過率僅34%，其中栽在基礎(chǔ)題上的占六成。不是算法太難，是思路太偏。

我整理了5道讓5年+經(jīng)驗者集體踩坑的題目。它們不考框架熟練度，專測你有沒有被工具馴化。

第一題：設(shè)計測試框架，先從工具聊起？

面試官問"怎么設(shè)計一個UI測試框架"，九成候選人開口就是Selenium、Playwright、Cypress三件套對比。

這是陷阱。工具選型是第五步，不是第一步。

某谷歌L6工程師在復(fù)盤帖里寫：「我花了10分鐘講Playwright的auto-wait機制，面試官打斷我問——你的被測系統(tǒng)是什么架構(gòu)？我愣了?！?/p>

正確打開方式：先問被測產(chǎn)品的技術(shù)棧、發(fā)布頻率、團隊規(guī)模、失敗容忍度。微服務(wù)單體架構(gòu)的測試策略完全不同，日發(fā)百次和月發(fā)一次的穩(wěn)定性要求天差地別。

工具是解決方案的副產(chǎn)品，不是起點。

第二題：面對故障頁面，先寫測試還是先排查？

場景：生產(chǎn)環(huán)境訂單結(jié)算頁白屏，給你30分鐘。

新手本能：打開IDE寫復(fù)現(xiàn)腳本。老手陷阱：直接抓日志看報錯。

某Meta面試官透露，他們期待的路徑是：先確認影響范圍（哪些用戶？哪個區(qū)域？）、再判斷是前端渲染還是API超時、最后才決定要不要補自動化。

「很多人把自動化當(dāng)成萬能藥，」一位從業(yè)8年的SDET說，「但自動化是驗證假設(shè)的手段，不是發(fā)現(xiàn)問題的眼睛?！?/p>

這道題測的是：你能不能區(qū)分"需要快速止血"和"需要長期預(yù)防"。

第三題：給你源碼，怎么選最小測試集實現(xiàn)全覆蓋？

這是道數(shù)學(xué)題披著代碼的外衣。

候選人拿到一個用戶注冊模塊的源碼，里面有郵箱驗證、密碼強度檢查、手機號格式校驗、短信驗證碼四個分支。面試官要求：用最少用例覆蓋所有路徑。

常見翻車現(xiàn)場：把每個分支單獨測一遍，得出8個用例。更隱蔽的翻車：忽略了分支之間的組合爆炸——郵箱格式對但密碼弱、密碼強但手機號錯。

正確答案涉及等價類劃分和邊界值分析的基本功。一位通過這道題的工程師回憶：「我畫了張決策樹，面試官眼睛亮了。」

覆蓋率的敵人不是漏測，是冗余。

第四題：測試報告怎么寫才算"有用"？

聽起來像送分題，實際是送命題。

面試官展示兩份報告：A報告列出200條用例，187通過13失敗；B報告只有一句話"支付模塊存在嚴(yán)重缺陷，建議阻斷發(fā)布"。

選A的候選人被追問：13個失敗里幾個是阻塞性bug？哪些可以降級？開發(fā)修復(fù)優(yōu)先級怎么排？

選B的候選人被追問：嚴(yán)重缺陷的證據(jù)鏈在哪？影響用戶量估算了嗎？有沒有臨時規(guī)避方案？

某亞馬遜Principal Engineer的評判標(biāo)準(zhǔn)：「好的測試報告要讓項目經(jīng)理能決策，讓開發(fā)能定位，讓運維能回滾。三缺一就是不及格?！?/p>

第五題：你的框架怎么保證"可維護性"？

這是道開放題，也是面經(jīng)重災(zāi)區(qū)。

背答案的候選人會提Page Object模式、數(shù)據(jù)驅(qū)動、配置外置。面試官接著問：你們團隊上次重構(gòu)測試代碼是什么時候？為什么重構(gòu)？重構(gòu)前后維護成本差多少？

答不上來的，基本都是照搬網(wǎng)上最佳實踐，沒在自己項目里摔過跤。

一位通過Netflix面試的工程師分享：「我說我們曾用3個月把3000行測試代碼壓到800行，面試官追問細節(jié)，我講了具體哪個抽象層設(shè)計錯了、怎么逐步替換、怎么保證替換期間CI不掛。」

可維護性不是設(shè)計出來的，是迭代出來的。

這五道題的共同點：它們不考你知道多少，考你知不知道"為什么"。

工具會過時，Playwright可能取代Selenium，但"先理解問題再選方案"的思維不會。面試市場正在懲罰那些把自動化當(dāng)成流水線操作的工程師，獎勵那些能講清楚決策鏈條的人。

某大廠招聘負責(zé)人透露，他們今年加了道新題：「如果明天公司決定砍掉所有UI自動化，你會怎么證明測試團隊的價值？」

你的答案是什么？