先說明一下軟件測試面試題這個東西網(wǎng)上一搜一大把但九成都是八股文堆砌背下來用處不大。我做過面試官也陪跑過不少轉(zhuǎn)行的朋友一個很深的感受是——面試官問的從來不是題本身而是題背后的思考方式。這篇我按自己的經(jīng)驗把高頻題重新梳理了一遍每個題都寫了答案思路還加了一些“為什么這么答”的說明希望能幫你真正理解面試官在想什么。1. 面試官到底在考察什么——先搞清楚題目的底層邏輯很多人準(zhǔn)備面試習(xí)慣把網(wǎng)上的題庫從頭背到尾結(jié)果一到現(xiàn)場就露餡。原因很簡單你背的是答案面試官要的是思路。我做過一段時間的技術(shù)面試官自己面試時也有一個習(xí)慣就是不管對方答得對不對都會追問一句“還有嗎”。這一追問基本就能分辨出哪些人是真做過哪些人只是在背題。面試官出題通常只有四個目的驗證基礎(chǔ)是否扎實。測試?yán)碚?、用例設(shè)計方法這些是你的基本功不要求你背書一樣背概念但要能用自己的話講清楚并且能舉出實際例子?？疾爝壿嬍欠袂逦?。面對一個功能你能不能快速拆解出測試點能不能按優(yōu)先級排列能不能考慮到異常場景——這是測試思維的核心。檢驗項目真實度。談到項目經(jīng)歷你的表述細(xì)節(jié)、數(shù)據(jù)、遇到的問題決定了你是有真實經(jīng)驗還是在編故事。編的很容易被連續(xù)追問擊穿。評估潛力和匹配度。面對不會的問題你的反應(yīng)是“這個我沒接觸過”還是“雖然沒做過但我會從XX角度去理解”這決定了你入職后的帶教成本。理解了這四點你會發(fā)現(xiàn)所謂面試題其實都圍繞著一個核心能力展開對一個具體事物你能不能系統(tǒng)性地找出所有可能出問題的點并設(shè)計出有效的驗證方法。心態(tài)上還要注意一點遇到不會的題很正常關(guān)鍵是你怎么處理。我最建議的回答模板是——“這個方向我了解但不是特別深基于我目前的理解我會從XX角度分析大致思路是……”。這樣既誠實又展示了你的思考過程遠(yuǎn)比硬編一個答案要好得多。2. 理論篇——測試基礎(chǔ)與用例設(shè)計的經(jīng)典問答2.1 “給你一個登錄頁面你怎么設(shè)計測試用例”這基本是面試必問也是區(qū)分新手和老手的一道分水嶺。新手的典型回答是“輸入正確的賬號密碼能登錄成功輸入錯誤的提示錯誤信息?！蓖炅?。這只能算是功能路徑的第一層。我建議的回答框架是分層展開功能測試正確賬號密碼登錄成功正確賬號錯誤密碼、錯誤賬號正確密碼、賬號密碼都錯誤分別驗證提示是否準(zhǔn)確空賬號/空密碼時登錄按鈕是否置灰或提示密碼是否可見或可切換明文輸入框是否有長度限制通常6-20位超長是否被截斷或提示是否支持用戶名、郵箱、手機號三種登錄方式記住密碼功能是否生效。界面測試排版是否錯亂按鈕是否對齊不同分辨率下是否正常顏色是否符合設(shè)計稿。兼容性測試要覆蓋不同瀏覽器如Chrome、Firefox、Safari、Edge、不同操作系統(tǒng)、不同手機型號和屏幕尺寸。主流應(yīng)用最少要覆蓋前兩種瀏覽器和兩個主流手機型號。安全測試密碼傳輸是否加密抓包看是密文還是明文錯誤登錄是否有次數(shù)限制連續(xù)輸錯是否鎖定或出現(xiàn)驗證碼是否支持SQL注入比如在密碼框中輸入 or 11這類內(nèi)容看系統(tǒng)是否被繞過登錄狀態(tài)下的URL是否可被直接訪問越權(quán)問題。性能測試多人同時登錄是否卡頓通常在200個虛擬用戶并發(fā)登錄時平均響應(yīng)時間不應(yīng)該超過3秒錯誤率不應(yīng)該超過1%。異常場景斷網(wǎng)時點擊登錄是否有提示服務(wù)器返回超時比如等待超過5秒時的提示文案是否友好快速重復(fù)點擊登錄按鈕是否會產(chǎn)生重復(fù)提交。大家感受一下同樣一道題這種答法和“輸入正確密碼能登錄”之間差的不是題量而是測試思維的體系化程度。面試官聽到這種答案基本能確認(rèn)你有獨立負(fù)責(zé)模塊測試的能力。平時自己練的時候可以拿微信、淘寶這種日常應(yīng)用當(dāng)靶子隨手打開一個功能在紙上拆測試點練多了自然就成條件反射。2.2 “說說你熟悉的測試用例設(shè)計方法并舉例”這個問題注意一個坑不要只報菜名。很多人的回答是“等價類、邊界值、因果圖、正交表、場景法”然后就沒然后了面試官只能繼續(xù)追問“具體怎么用”。建議的口訣是“一個核心三個必答”。等價類劃分法把無窮的輸入數(shù)據(jù)劃分成有限類從每類中取一個代表值測試。舉例年齡輸入框規(guī)定是18-60歲那有效等價類就是18至60之間的任意值比如35無效等價類就是小于18比如17和大于60比如61取一個代表值即可。邊界值分析法大量bug發(fā)生在邊界上所以取邊界及邊界兩側(cè)的值。上點剛好在邊界上的值如18和60、離點緊挨邊界的值如17和61、內(nèi)點邊界范圍內(nèi)的值如35測這三個點基本就夠了。場景法從用戶使用流程的角度出發(fā)設(shè)計用例比如購買流程加入購物車→提交訂單→支付→查收電子發(fā)票。正常流之外還要考慮備選流和異常流如支付超時、庫存被搶空、重復(fù)支付等。因果圖和正交表也最好作為補充提一下當(dāng)輸入條件較多、組合爆炸時比如3個條件每個2種取值全組合是8種條件一多就指數(shù)級上漲用正交表抽樣替代全組合能極大減少用例數(shù)量。你可以說“我在某模塊配置項測試中用正交表把原本上百條組合用例精簡到了20多條”這樣才有說服力。2.3 “怎么理解測試計劃、測試策略和測試用例的關(guān)系”這道題考察你有沒有做過測試負(fù)責(zé)人的角色或者說你對自己工作在整個研發(fā)鏈路中的位置是否有認(rèn)知。一句話可以概括測試計劃解決“做什么、誰來做、什么時候做”的問題測試策略解決“怎么做、做到什么程度”的問題測試用例解決“具體檢查什么”的問題。展開講測試計劃講的是管理維度。范圍是什么排除哪些資源怎么分配里程碑怎么定風(fēng)險有哪些。比如一個版本發(fā)了要上線一個支付模塊測試周期只有5天——計劃里會寫清楚優(yōu)先保證主流程和資金安全相關(guān)用例的自動化執(zhí)行花3天做功能測試1天做性能回歸1天做兼容性抽查剩余時間留作緩沖。測試策略講的是方法決策。比如哪些功能適合用自動化回歸哪些模塊需要做安全測試哪些場景需要上性能壓測。策略的依據(jù)通常是風(fēng)險評估——用戶量大的核心鏈路哪怕改動小也要全量回歸邊緣功能可能只做冒煙。測試用例是具體執(zhí)行層面的產(chǎn)物前面第2.1題的登錄用例就是一個例子。這類題沒有標(biāo)準(zhǔn)答案考察的是項目視角。你可以結(jié)合自己參與過的項目來展開比如你是如何從計劃落到策略再落到用例的如果有偏差當(dāng)時是怎么調(diào)整的。2.4 “Bug的生命周期是什么你提的Bug被開發(fā)打回了怎么辦”這是理論題也是情商題。前半部分很好答新建New→ 指派Open/Assigned→ 修復(fù)Fixed→ 回歸驗證Verify/Retest→ 關(guān)閉Closed中間還會有拒絕Rejected、延期Deferred、重新打開Reopen幾個狀態(tài)。后半部分才是關(guān)鍵。Bug被開發(fā)打回先不要情緒上頭按下面這個順序處理第一步重新確認(rèn)操作步驟是否寫清楚了環(huán)境是否有特殊配置。很多打回是因為步驟不完整開發(fā)復(fù)現(xiàn)不了。第二步把日志、截圖、錄屏、接口返回數(shù)據(jù)這一類的證據(jù)補齊。一口咬定“就是有bug”不如甩出一條報錯日志有說服力。第三步如果證據(jù)齊全還是被拒跟開發(fā)當(dāng)面或拉會溝通不要在企業(yè)群里反復(fù)來回。有時候是認(rèn)知差異比如開發(fā)認(rèn)為這是需求之外的行為那就要拉產(chǎn)品經(jīng)理一起確認(rèn)到底按現(xiàn)狀做還是按預(yù)期做評審一下定個結(jié)論。第四步如果是低概率、難復(fù)現(xiàn)的bug寧可多花點時間做排除測試也別輕易關(guān)閉。真的復(fù)現(xiàn)不了寫明現(xiàn)象、頻率和猜測原因后再掛起絕不能直接刪掉。我在實際項目里遇到過這樣一個case有個偶現(xiàn)的崩潰bug開發(fā)一直說復(fù)現(xiàn)不了拒絕修復(fù)。我沒有直接在bug單里跟他對線而是約了會議室?guī)先罩痉治龉ぞ攥F(xiàn)場一邊操作一邊抓日志終于在第17次操作的時候復(fù)現(xiàn)了。開發(fā)當(dāng)場就無話可說了下午就定位到了問題。這事的經(jīng)驗就是復(fù)現(xiàn)bug比說服人更有效。3. 實戰(zhàn)篇——面試中躲不開的場景題與手寫用例3.1 “如果上線前發(fā)現(xiàn)嚴(yán)重Bug但產(chǎn)品經(jīng)理堅持準(zhǔn)時上線你怎么處理”這道題考察的是風(fēng)險意識、溝通能力、原則性。常見錯誤回答是“那就提缺陷讓產(chǎn)品決定”太被動了。綜合素質(zhì)高一些的答法是把方案講清楚先評估這個Bug的嚴(yán)重等級和影響范圍。如果屬于P0級比如支付金額算錯了、主流程走不通我的建議是必須攔下但不能只丟一句“不能上線”就完事而是要給決策層提供帶風(fēng)險分析的替代方案。比如“這個Bug影響的是XX渠道的YY場景占比約X%如果明天必須上線建議上線后立即關(guān)閉該渠道入口同時準(zhǔn)備好緊急回滾預(yù)案我這邊也會在這個窗口內(nèi)持續(xù)驗證修復(fù)方案?！奔夹g(shù)層面你會被追問“線上出現(xiàn)緊急bug怎么處理”回答的套路是止血 → 定位 → 修復(fù) → 復(fù)盤。止血通常是回滾版本或者下掉某個功能入口定位靠日志監(jiān)控和鏈路追蹤修復(fù)后先跑核心回歸再切量灰度最后復(fù)盤改進(jìn)流程補充測試用例和監(jiān)控告警確保同類問題不再出現(xiàn)。態(tài)度上要守住一個原則上線這件事質(zhì)量底線可以由測試來兜底但最終拍板一定是集體決策。你負(fù)責(zé)把風(fēng)險和選項擺清楚而不是替產(chǎn)品做決定。這個回答既體現(xiàn)了專業(yè)度也避免了“測試故意卡上線”的刻板印象。3.2 “寫一條簡單的接口測試用例你會怎么寫”有些面試官會直接給你一個接口文檔示例比如“獲取用戶信息接口/api/user/infoGET方法參數(shù)userId”讓你當(dāng)場口述用例。這時候不要只寫“userId傳1返回成功”這種單一路徑。接口測試用例的核心維度是參數(shù)正確性必填參數(shù)傳正常值返回200和正確body。參數(shù)缺失userId不傳預(yù)期返回400或提示“userId為必填項”。參數(shù)類型異常userId傳字符串“abc”預(yù)期返回參數(shù)類型錯誤。參數(shù)邊界userId傳0、傳負(fù)數(shù)、傳一個超大整數(shù)如99999999999各自預(yù)期是什么。鑒權(quán)校驗不帶token請求預(yù)期返回401token過期、token偽造是否被攔截。異常場景模擬接口超時、服務(wù)端500錯誤客戶端是否能夠處理并給出友好提示。敏感信息返回內(nèi)容中是否包含過多敏感字段如手機號、身份證號日志中是否打印了明文密碼。一條接口用例別拘泥于“給一個輸入看一個輸出”而是把所有可能出現(xiàn)的問題都當(dāng)成系統(tǒng)的一部分去驗證。另外提一嘴現(xiàn)在很多團(tuán)隊已經(jīng)用自動化工具做接口測試了所以面試中關(guān)于接口的題很少脫離工具和框架來單獨問詳見下一節(jié)。3.3 “給你一個余額提現(xiàn)功能你怎么做測試”這題比登錄頁面的題更進(jìn)階因為涉及資金安全特別考察綜合能力。建議從下面幾個維度展開功能流程正常提現(xiàn)路徑申請→確認(rèn)→到賬通知重復(fù)點擊提現(xiàn)按鈕是否會重復(fù)提交訂單提現(xiàn)過程中取消狀態(tài)是否正確回滾。金額邊界最小提現(xiàn)金額比如1元、最大提現(xiàn)金額、余額剛好等于提現(xiàn)金額、余額不足、提現(xiàn)手續(xù)費是否計算正確。并發(fā)場景余額只有100元兩個設(shè)備同時發(fā)起提現(xiàn)80元只能有一筆成功同一賬號在手機端和網(wǎng)頁端同時操作是否會出現(xiàn)超提超提是資金類系統(tǒng)的核心風(fēng)險。冪等性網(wǎng)絡(luò)超時后重試提現(xiàn)會不會產(chǎn)生兩筆訂單這是接口測試?yán)锖苤匾囊粋€點也就是系統(tǒng)要用全局唯一請求號比如用UUID或雪花ID來判斷是否是同一筆請求防止重復(fù)扣款。數(shù)據(jù)一致性提現(xiàn)成功之后賬戶余額、流水記錄、訂單狀態(tài)三者的數(shù)據(jù)應(yīng)該保持一致?？梢杂脭?shù)據(jù)庫事務(wù)的ACID特性去思考發(fā)起提現(xiàn)時余額扣減和訂單生成必須在一個事務(wù)里任何一個失敗都要整體回滾。異?；謴?fù)提現(xiàn)過程中斷網(wǎng)、斷點續(xù)傳、服務(wù)器宕機恢復(fù)后系統(tǒng)狀態(tài)是否仍是正確的。面試中遇到這種資金類題目只要你能主動提到“冪等”“事務(wù)一致性”“并發(fā)鎖”這些詞并且說得有理有據(jù)面試官基本就覺得你有過真實項目經(jīng)驗了。4. 進(jìn)階篇——自動化、性能與工具類問題4.1 “你會搭建接口自動化框架嗎”這道題沒有標(biāo)準(zhǔn)答案即使你只用過Postman也可以聊得很有價值。關(guān)鍵是你對框架的理解要成體系。比較標(biāo)準(zhǔn)的一套接口自動化方案長這樣工具選型接口調(diào)試時用Postman或Apifox做單接口調(diào)試斷言和導(dǎo)出測試集生產(chǎn)級自動化可以用Python的Requests庫或Java的Rest Assured做二次封裝或者直接用現(xiàn)成的平臺比如JMeter、MeterSphere這類工具團(tuán)隊成員通過平臺協(xié)作?？蚣芊謱踊A(chǔ)層封裝通用的請求方法POST/GET/PUT/DELETE統(tǒng)一處理Header、超時、SSL校驗用例層用數(shù)據(jù)文件Excel、YAML、JSON驅(qū)動用例不寫死代碼測試執(zhí)行層用pytestPython或TestNGJava做組織管理數(shù)據(jù)校驗層用Json Schema或自定義斷言不只校驗狀態(tài)碼還要校驗關(guān)鍵字段和數(shù)據(jù)庫落地。數(shù)據(jù)隔離測試環(huán)境造數(shù)要自動化——接口依賴的測試數(shù)據(jù)通過初始化SQL或調(diào)用數(shù)據(jù)工廠接口預(yù)置跑完用例后清理保證用例可重復(fù)執(zhí)行。持續(xù)集成用Jenkins/GitLab CI定時觸發(fā)測試任務(wù)結(jié)果推送到企業(yè)微信群或釘釘群、郵件失敗時自動截取調(diào)用鏈數(shù)據(jù)和響應(yīng)報文。框架搭建的思路說完面試官一般會接著問你“如何保證框架的穩(wěn)定性和執(zhí)行效率”。你可以回答a. 用例之間盡量獨立不要依賴執(zhí)行順序b. 跑批量任務(wù)時開啟并發(fā)執(zhí)行把執(zhí)行時間從半小時壓到5分鐘c. 高頻接口加上測試結(jié)果自動重試機制避免偶發(fā)網(wǎng)絡(luò)抖動造成的誤報d. 關(guān)注誤報率接口本身的mock數(shù)據(jù)要通過接口文檔和開發(fā)對齊。4.2 “性能測試你都做過哪些指標(biāo)怎么看性能測試報告”性能測試相關(guān)的題很多候選人都會答散。其實核心就四個指標(biāo)響應(yīng)時間RT從發(fā)請求到收到完整響應(yīng)的時間。一般接口要求P9595%的請求響應(yīng)時間在200毫秒以內(nèi)超過1秒用戶就能感覺到卡頓。要注意的是平均響應(yīng)時間很容易被少量長尾請求拉高所以通常更關(guān)注P90、P95、P99P99超過3秒就要警惕了。吞吐量TPS/QPS每秒能處理的請求數(shù)或事務(wù)數(shù)。比如支付接口的TPS目標(biāo)值是500壓測到2000并發(fā)時如果TPS不能繼續(xù)上升就要排查瓶頸。并發(fā)用戶數(shù)系統(tǒng)在同一時刻能承載多少在線操作而不崩潰。注意“并發(fā)用戶數(shù)”和“在線用戶數(shù)”是兩碼事很多人喜歡混淆這兩個概念來解讀報告。資源利用率壓測過程中CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)IO的占用情況。一般CPU超過80%要開始優(yōu)化代碼內(nèi)存持續(xù)增長可能有泄漏磁盤IO過高多半有慢查詢?？吹揭环菪阅軋蟾嫖业淖x法是這樣第一步看TPS曲線如果隨著并發(fā)數(shù)上升TPS先升后平甚至下降說明系統(tǒng)已經(jīng)出現(xiàn)性能瓶頸第二步看響應(yīng)時間分布P95是否達(dá)標(biāo)第三步看瓶頸點是Web服務(wù)器連接數(shù)滿、數(shù)據(jù)庫連接池打滿還是慢SQL拖垮整體最后看資源水位定位是CPU計算密集還是IO等待密集。面試時把這個順序講出來比背概念強得多。4.3 “你做過哪些UI自動化Selenium定位元素失敗你怎么排查”UI自動化的核心價值是回歸測試而不是替代手工測試這個定位要先說清楚。市面上主流是SeleniumWeb端和Appium移動端現(xiàn)在也有很多人用Playwright、Cypress做Web自動化選型思路可以從穩(wěn)定性、執(zhí)行速度、社區(qū)生態(tài)三個維度來比較。關(guān)于定位元素失敗這是UI自動化最常見的日常問題回答思路很明確按順序排查第一步看元素是否在iframe中如果頁面結(jié)構(gòu)里有iframe但沒有切換進(jìn)去那不管用什么選擇器都定位不到。這是新手漲經(jīng)驗最快的一個坑。第二步看頁面是否還沒加載完成元素是動態(tài)渲染的腳本跑得太快元素還沒出現(xiàn)。處理方式是顯式等待WebDriverWait expected_conditions而不是粗暴地sleep固定時間。第三步看元素屬性是不是動態(tài)變化的比如id每次刷新都變那就改用CSS或者相對XPath定位。第四步看是不是頁面出現(xiàn)了遮擋層比如彈窗蓋住了元素點擊時報“element not clickable”。第五步如果是class屬性里有空格等特殊字符用XPath配合contains函數(shù)來模糊匹配。我曾遇到過一個詭異case腳本在本地跑得好好的一上CI就掛排查了很久才發(fā)現(xiàn)是測試環(huán)境Chrome版本跟docker里的chromedriver版本不匹配。后來把鏡像里的瀏覽器版本固定住才解決。自動化的坑基本都是這類環(huán)境層面的問題面試時能講出一兩個真實排障場景會非常加分。5. 軟技能與開放題——“三句話”穩(wěn)住項目介紹和HR面5.1 “介紹下你最近負(fù)責(zé)的一個項目”這幾乎是每場面試必有的題但掛在這道題上的人比想象中多。要么說得太細(xì)面試官聽不到重點要么說得太泛像是在背宣傳文案。我建議用結(jié)構(gòu)化的方式來講一句話背景“我負(fù)責(zé)的是某電商平臺用戶端和訂單中臺的數(shù)據(jù)一致性測試覆蓋了下單、支付、庫存扣減、退款這四個核心鏈路?！蹦愕慕巧妥龅氖虑椤拔抑饕?fù)責(zé)接口自動化框架的搭建和核心鏈路的回歸策略設(shè)計另外獨立負(fù)責(zé)了訂單模塊的異常場景測試比如重復(fù)支付、部分退款、超時關(guān)單這類業(yè)務(wù)分支。”過程中的挑戰(zhàn)“支付回調(diào)因為網(wǎng)絡(luò)超時導(dǎo)致訂單狀態(tài)不一致我們在線下壓測中很難復(fù)現(xiàn)后來通過分析日志和主動注入故障才定位到問題并補齊了對應(yīng)的場景用例。”量化結(jié)果“把回歸測試的時間從1天壓縮到2小時核心鏈路的線上故障在3個月內(nèi)為零?！边@四段邏輯不是背給你聽的而是讓你在講的時候心里有數(shù)每個環(huán)節(jié)都可能被追問細(xì)節(jié)。所以講的一定是自己真實做過的東西多小都行別編。5.2 “你最大的缺點是什么”和“你為什么離開上一家公司”說“我最大的缺點是太追求完美”這類答案面試官幾乎聽膩了幾乎沒有效果。我比較推薦的是講一個真實的、正在改進(jìn)的缺點。舉例模板“我以前不太擅長拒絕需求測試范圍總是不自覺地膨脹導(dǎo)致該深測的地方淺測了。后來我學(xué)會基于風(fēng)險評估來劃定測試范圍在計劃階段就明確優(yōu)先級并在周報中同步風(fēng)險現(xiàn)在個人測試效率提升了不少。”關(guān)鍵是缺點要真實、可接受改進(jìn)方法和結(jié)果要具體?！盀槭裁措x開”這道題的原則是不說前東家和前同事壞話不抱怨只說現(xiàn)實的合理原因。比如“上一份工作做的內(nèi)容比較單一成長見頂了希望接觸更復(fù)雜的業(yè)務(wù)場景”或者“公司業(yè)務(wù)線調(diào)整崗位發(fā)展方向和我的規(guī)劃不太匹配了”。注意不要說“之前公司加班太多了”這種話除非你想去的公司明確不加班否則這句話就是減分項。5.3 “如果開發(fā)不按你提的用例去修改你怎么辦”這題跟前面被拒bug有點像但更偏向協(xié)作場景。我的回答思路是先搞清楚開發(fā)不修改的背后原因。是覺得優(yōu)先級不高是工期排不滿還是認(rèn)為測試用例覆蓋的場景根本不存在不同原因處理方式不同——優(yōu)先級問題拉產(chǎn)品經(jīng)理排期工期問題評估自動化和風(fēng)險后給出一個“當(dāng)前修復(fù)哪些、后續(xù)優(yōu)化哪些”的建議認(rèn)知分歧就當(dāng)場演示bug復(fù)現(xiàn)路徑拿事實說話。另外一個容易被忽略的點用例寫得好不好直接影響開發(fā)的接受度。用例描述里除了步驟和預(yù)期最好帶上“復(fù)現(xiàn)概率、影響用戶量、關(guān)聯(lián)模塊、參考日志”這些信息。開發(fā)接到一條信息量充足的用例配合度會高很多。6. 面試現(xiàn)場的幾個真實加分細(xì)節(jié)6.1 別把“用例設(shè)計”和“執(zhí)行測試”混為一談面試官問你“你怎么測”的時候他最想看的是你設(shè)計測試的出發(fā)邏輯而不是你點了什么按鈕?！笆褂玫葍r類和邊界值設(shè)計用例”和“打開頁面、輸入數(shù)據(jù)、看結(jié)果”是兩個完全不同的層次。平時你可以試著把所有功能測試都拆成“設(shè)計用例—執(zhí)行—再設(shè)計”三輪循環(huán)練的是思維。6.2 聊項目時主動拋出你踩過的坑面試官如果問“項目中有遇到什么困難嗎”不要只報喜不報憂。主動講坑是一種自信的表現(xiàn)——例如你做了很久的自動化用例最終發(fā)現(xiàn)穩(wěn)定性不足你如何分析失敗原因、怎么從固定等待改成顯式等待、怎么處理測試數(shù)據(jù)和測試環(huán)境之間的耦合——這比只講“我搭建了自動化框架”更有說服力。面試官想看到的不是你一切順利而是你遇到問題時解決問題的路徑。6.3 準(zhǔn)備一個“三分鐘技能圖譜”面試快結(jié)束時通常會讓你反問。建議不要一開口就問薪資和加班而是用這幾分鐘展示你的思考深度。例如問“咱們團(tuán)隊目前接口自動化的覆蓋率大概是多少主要痛點是在用例穩(wěn)定性還是維護(hù)成本上”或者“新人入職后團(tuán)隊更希望他先補齊哪塊能力”這些問題不是為了套話而是讓面試官覺得你入職后會快速產(chǎn)生價值。6.4 白紙手寫用例時注意規(guī)范有些面試官會現(xiàn)場發(fā)一張白紙讓你寫用例這時候要注意**先寫模塊名、編寫人、日期、優(yōu)先級這些頭部信息用例編號要有規(guī)律前置條件寫清楚每個用例只驗證一個點操作步驟要有數(shù)字標(biāo)號預(yù)期結(jié)果要具體可驗證最后補一條異常場景。**我見過太多候選人邏輯沒問題但格式一塌糊涂——真實的測試團(tuán)隊是很看重規(guī)范性的因為用例是多人協(xié)作產(chǎn)物規(guī)范就是溝通語言。7. 面試后的復(fù)盤與offer選擇——最后一公里的坑面試結(jié)束不是終點復(fù)盤才是漲經(jīng)驗的關(guān)鍵節(jié)點。我的習(xí)慣是每面完一場立刻在手機上記下三類信息——被問了哪些題、哪些答得磕絆、面試官追問的方向是什么。一個星期后回頭看你會發(fā)現(xiàn)自己其實有非常明確的短板清單比盲目刷題有效得多。拿到offer之后選擇時除了看薪資我會重點關(guān)注三件事團(tuán)隊的測試基礎(chǔ)設(shè)施怎么樣。有沒有自動化框架沉淀有沒有獨立的測試環(huán)境有沒有灰度發(fā)布體系如果這些都沒有說明你進(jìn)去可以搞建設(shè)但也說明會比較累。誰來帶你。面試時會聊二十分鐘以上的人他的技術(shù)水平和溝通風(fēng)格基本決定了你入職后的成長速度。業(yè)務(wù)復(fù)雜度是否足夠。純后臺管理系統(tǒng)和涉及資金、供應(yīng)鏈、大數(shù)據(jù)處理的系統(tǒng)可學(xué)的東西完全是兩個量級。對一個測試來說業(yè)務(wù)理解能力的成長往往比工具鏈技術(shù)更值錢。還有一點很多人會忽略面試時加一個技術(shù)負(fù)責(zé)人的微信講禮貌地發(fā)一句感謝之后偶爾請教一個問題保持聯(lián)系。這個圈子其實很小你未來的機會往往就藏在這些善緣里。最后再分享一個我個人的實用小技巧接到面試通知后別光顧著刷題用一小時把對方產(chǎn)品的核心頁面從上到下點一遍不管你是面功能測試還是自動化測試面試中只要你能說出“你們這個結(jié)算流程的XX狀態(tài)好像缺個預(yù)警機制”對面基本會眼前一亮。測試的本質(zhì)是找茬你提前演練了找茬上一考場就已經(jīng)贏了一半。