楷知的測試工程師面試題流出：三輪面談裡，真正被考的不是技術

九月初，牛客網上出現一篇標題寫著「楷知軟體測試面經（已過）」的分享文。發文者是第一次參加面試的求職者，完整記下了一面導師、二面主管、三面人資的三輪題目，其中一面有個問題他當場沒答出來，最後仍錄取。這篇面經的價值不在題庫本身，而在它讓人看見：一家公司招募測試工程師時，評審的順序和大多數求職者準備的順序，剛好相反。

先看這份考卷長什麼樣子

一面的題目包括：黑白盒測試的區別、常用的測試方法、測試流程、對公司業務的了解，以及對專案的深入追問。其中有一題「測試時發現介面被限流怎麼處理」，發文者坦承未答。二面換主管上場，問的是測試人員素養、如何設計測試計畫、AI 在測試上有哪些應用、微信通話功能要怎麼測，外加一句「接受加班嗎」。三面人資只做資料核對與薪資福利溝通，發文者的理解是，二面結束基本就等於錄取。

把題目攤開來看，真正硬核的技術題其實只有一題，就是那題限流。其餘題目都有一個共同特徵：它們考的是「你有沒有一套做事的框架」，而非「你背了多少名詞」。

那題沒答出來的限流題，其實考的是什麼

「測試發現介面限流怎麼處理」，這題在留言區有人做了完整補充，值得展開講。限流聽起來技術味很重，但用一個日常比喻就懂：它像百貨公司電梯的乘載上限，人一多就強制等下一班。測試工程師撞上它，通常有兩種完全不同的情境。

第一種是「我的測試被限流擋住了」。這時正確的動作是先確認這是正常限流還是誤限流，看回應訊息和閘道日誌，核對限流的計數單位是按帳號、按 IP 還是按介面，時間窗口和閾值是多少。如果是自動化腳本沒加間隔瘋狂重試觸發的，先控制請求頻率；確實需要調整測試環境設定，要跟負責人確認並留下紀錄，不能直接把限流關掉然後算測試通過。

第二種是「我就是要測限流這個功能本身」。這時要驗證的是閾值前後的行為、時間窗口過後有沒有恢復、不同帳號之間會不會互相影響，以及被拒絕的請求有沒有留下不該存在的業務資料。

面試官想聽的，其實是求職者能不能在開口之前，先把這兩種情境分開。這跟 直播平臺招後端時考卷上寫的系統焦慮 是同一個邏輯：考題表面問技術細節，實際在看你面對真實工作狀況時，能不能先界定問題再動手。

「微信通話怎麼測」才是主管真正的關卡

二面那題最有意思。微信通話是每個人都會用的功能，正因為太日常，多數人反而說不出個所以然。

從測試設計的角度，這題可以一路往下挖。通話建立：撥打方與接收方的各種組合，線上、離線、忙碌中、被封鎖。通話品質：弱網環境、網路切換（WiFi 換行動網路）、長時間通話的穩定性。並發情境：通話中收到來電、通話中訊息轟炸、通話中切到背景。異常處理：對方中途掛斷、網路斷線重連、耳機拔插。還有資源層面：耗電、發熱、記憶體。再往下還有合規與隱私，通話錄音提示、跨區漫遊。

一個有框架的應試者不需要窮舉，只要展現出「我會從功能、效能、異常、資源幾個維度系統性地切」的思考方式。這正是測試工程師與「點一點看會不會壞」的操作員之間的分界線。主管問這題，問的是思考的結構。

AI 那題，是這份面經裡最新的訊號

三輪題目裡，「AI 在測試哪些方面應用」是唯一一題帶著時代印記的。這不是楷知獨有的現象，從測試案例生成、日誌分析、UI 自動化的元素定位，到缺陷分類與回歸範圍建議，AI 工具正在喫掉測試工作裡最重複的部分。

對求職者的實際意義是：基礎的測試方法仍然是必答題，但「知道怎麼把 AI 放進測試流程、也知道它的輸出需要人來把關」正在變成加分題。留言區裡有另一起反面案例，有人分享遠端面試中明目張膽看手機用 AI 作弊被抓包的經過。工具能輔助準備，但二面主管追問專案細節時，有沒有真的做過，三句話就會現形。

那麼，一般求職者能帶走什麼

這份面經的留言區有個提問很典型：「專案要怎麼做？要自己完完全全測一遍嗎？」發文者自己的回答其實已經給了方向：紙上得來終覺淺。他在文中提到，入職後前兩週還有階段檢測，錄取只是起點。

整理成可操作的判斷有幾條。準備自我介紹時，把專案裡「你個人做了什麼決策、遇到什麼問題、怎麼排除」講清楚，因為面試官追問專案時，驗證的就是真實性。基礎題如黑白盒、測試流程，這些是入場券，答不出來直接出局。情境題如微信通話、限流處理，練的不是背答案，而是練「先分類、再展開」的應答結構。至於加班意願這種題，它不是技術問題，是預期管理，想清楚再答。

一份通過的面經之所以值得讀，從來不是因為題目會原封不動重考，而是因為它攤開了一家公司在篩人時的優先順序。看懂那個順序，比背下任何一題的答案都值錢。