說到攜程2019屆秋招的專業(yè)筆試尤其是測試方向很多當年一起備戰(zhàn)秋招的同學都有同樣的感受這場筆試不像是在考“某個知識點”而是把軟件測試崗位需要的基本功壓縮到兩個小時里挨個過了一遍。哪怕放在今天我依然建議準備測試崗校招的同學把它當作一套完整的能力自測題因為里面的題型分布、考點側重和答題思路基本就是國內(nèi)互聯(lián)網(wǎng)公司測試方向筆試的一個縮影。這篇文章不打算做那種“真題答案匯編”而是從備考者的視角復盤一下這類筆試到底考什么哪些知識點值得花時間哪些題型看著簡單卻最容易丟分。適合正在準備測試崗校招的學生、想從開發(fā)崗轉(zhuǎn)測試的工程師也適合那些想了解測試筆試到底有多深的人。我會把現(xiàn)場答題的經(jīng)驗、后來復盤時發(fā)現(xiàn)的不足、以及面試時被追問過的細節(jié)都寫出來盡量做到讓你看完能直接照著執(zhí)行。1. 筆試整體設計與備考思路1.1 為什么這場筆試值得反復研究先說結論測試方向的筆試重點不是“考倒你”而是篩選出具備計算機基礎、測試思維和工程意識的人。攜程2019屆秋招測試方向的筆試題目結構其實很典型大致由四類組成選擇、填空題覆蓋數(shù)據(jù)結構、計算機網(wǎng)絡、數(shù)據(jù)庫、操作系統(tǒng)等基礎內(nèi)容。簡答題考察軟件測試理論、測試流程、測試用例設計方法。場景題給一個線上問題或業(yè)務功能讓你分析測試重點、排查思路。編程題一般不會很難但要求寫出邏輯完整、邊界考慮充分的代碼。這種結構現(xiàn)在很多公司在測試崗筆試里依然在用所以把它當作備考模板來研究完全沒問題。復盤這份題時不要只盯分數(shù)更要看題目背后映射的能力模型基礎是否扎實、用例設計是否有章法、遇到問題是否能分層排查。這才是筆試真正的價值所在。1.2 備考路上最容易走偏的三個方向第一個誤區(qū)是只刷題不梳理知識體系。市面上流傳的軟件測試面試八股文很多但如果你只是把它們背下來遇到場景題照樣懵。筆試題是會變的知識體系不會變。建議以“測試基礎、數(shù)據(jù)庫、Linux、網(wǎng)絡、數(shù)據(jù)結構、編程語言”為框架把知識點填進去再配合刷題鞏固。第二個誤區(qū)是只背測試理論不練用例設計。很多人能把“等價類、邊界值、因果圖”的定義倒背如流但拿到一個具體的“航班搜索”功能寫出來的用例東一塊西一塊。筆試里簡答題的給分點通常很細用例維度全、有邊界、有異常場景才算合格。這個只能靠練不能靠背。第三個誤區(qū)是編程題眼高手低。測試崗筆試的編程題往往比開發(fā)崗簡單但簡單不等于拿滿分。見過不少同學思路一說全對一寫代碼就忘了判空、忘了邊界、忘了注釋。筆試環(huán)境里沒人聽你講思路代碼就是你的表達能力平時一定要自己動手寫。1.3 時間分配和復習節(jié)奏如果你從現(xiàn)在開始準備我建議留出三到四周時間按三輪來復習。第一輪用一周時間過基礎。不要試圖把所有計算機基礎課都啃完而是抓與測試強相關的部分數(shù)據(jù)結構里的數(shù)組、鏈表、棧、隊列和常見排序計算機網(wǎng)絡里的HTTP、TCP、DNS數(shù)據(jù)庫里的增刪改查、連表查詢、聚合函數(shù)Linux里常用的日志分析和進程排查命令。這一輪的目標是“提到一個知識點你能說出它是干什么的”。第二輪用一周半時間專項突破。核心就是測試理論和用例設計。每天至少做兩道用例設計題覆蓋登錄、搜索、下單、支付、退款這類常見業(yè)務模塊。同時練習場景題重點鍛煉分層排查的思路。第三輪用剩下的時間全真模擬。找一套往年測試方向筆試題嚴格按考試時間來做做完之后逐題復盤。不要只對答案要研究每個選項為什么對、為什么錯。錯題本在這個階段比新題更重要。我當年吃過的虧就是“題刷了不少但復盤太少”導致同類考點反復丟分。2. 核心知識點拆解與答題要點2.1 測試基礎不只是背概念測試基礎的簡答題考察的是你對軟件測試的理解深度。常見的問題包括什么是黑盒測試和白盒測試軟件測試流程包含哪些階段什么是回歸測試什么是冒煙測試這些概念并不難但很多人答得很干癟只寫一句話。我建議用“一句話概念加一句話場景加一句話個人理解”的結構來答。舉個例子問你“什么是回歸測試”。你可以這樣答回歸測試是在代碼修改后重新執(zhí)行已有測試用例確認原有功能沒有被破壞的測試過程。它通常出現(xiàn)在缺陷修復、需求變更、版本迭代之后。實際工作中我一般會先抽出與本次改動相關的核心用例做快速回歸全量回歸則放到版本發(fā)布前執(zhí)行。這樣回答既說清楚了概念又讓面試官看到你真的用過它。另一個容易考的點是測試用例的核心要素。不管你是寫用例還是評價用例都要記住用例編號、用例名稱、前置條件、輸入數(shù)據(jù)、操作步驟、預期結果這六要素缺一不可。筆試里如果要求你設計測試用例光是逐條寫出這六項就已經(jīng)能拿到不少基礎分了。2.2 測試用例設計等價類和邊界值是主力測試用例設計方法里筆試出現(xiàn)頻率最高的是等價類劃分和邊界值分析。原因很簡單它們最實用也最能考察一個人的邏輯是否嚴密。所謂等價類就是把你認為輸入后結果相同的一類數(shù)據(jù)歸到一起每個等價類里取一個代表數(shù)據(jù)來測試。而邊界值是在等價類的基礎上專門去測邊界附近的那些值因為大量bug都出在邊界上。舉個例子某個功能的年齡輸入框要求“18到60歲之間有效”用等價類劃分可以得到三個集合有效等價類“18到60”無效等價類“小于18”和“大于60”。但如果你只測這三個值還遠遠不夠。這時候要用邊界值分析測17、18、60、61這四個值再加上空值、非數(shù)字字符、負數(shù)、超長數(shù)字。筆試里如果能在一個用例設計題里寫出這些維度基本就能把分數(shù)拿穩(wěn)。測試數(shù)據(jù)類型預期結果18有效邊界通過60有效邊界通過17無效邊界拒絕并提示年齡不合法61無效邊界拒絕并提示年齡不合法空值異常輸入提示年齡不能為空abc異常輸入提示年齡必須為數(shù)字除了等價類和邊界值場景法也值得重視。場景法強調(diào)的是“從用戶操作路徑出發(fā)”把一個完整業(yè)務流程串起來設計用例。比如“用戶搜索機票-選擇航班-填寫乘客信息-支付-出票”這條主路徑要測每條路徑上分支出來的異常情況也要測。筆試里如果只是零散地寫幾條用例沒有按業(yè)務流程組織印象分會差很多。2.3 數(shù)據(jù)庫與Linux測試工程師的日常武器數(shù)據(jù)庫幾乎是測試方向筆試必考的內(nèi)容而且多半是給你一張或多張表讓你寫SQL。重點包括帶條件的查詢、排序、分組、聚合函數(shù)、多表連接、去重。給你一個建議不要只背SQL語法要能說清楚你寫的SQL查出來的結果是什么。比如一個經(jīng)典問題統(tǒng)計每個城市的訂單數(shù)量篩選出訂單數(shù)大于100的城市。你至少應該能寫出類似這樣的語句SELECT city, COUNT(*) AS order_cnt FROM orders GROUP BY city HAVING COUNT(*) 100;注意GROUP BY和HAVING的配合很多人會在這里寫成WHERE這是筆試里很常見的錯誤。你要記住WHERE是用來在分組前過濾數(shù)據(jù)的HAVING才是用來過濾分組后結果的。答這種題的時候最好順便在注釋里寫一句你的理解讓閱卷人看到你不是死記硬背。Linux命令也一樣不需要你掌握所有命令但高頻的那些必須熟練。我建議重點準備tail、grep、awk、sed、find、ps、top、netstat、curl。比如“查看日志文件最后100行并過濾ERROR”一般人會寫tail -100 app.log | grep ERROR這已經(jīng)很好了。但如果你能更進一步用awk把錯誤信息和時間字段提取出來在場景題里會非常加分。測試工程師每天的工作幾乎都離不開查日志和查數(shù)據(jù)。筆試考Linux和SQL不是故意刁難你而是希望招進來的人能直接上手干活。所以你在復習的時候不要光看最好自己搭個環(huán)境實際跑一遍命令和SQL印象會深刻很多。2.4 計算機網(wǎng)絡接口測試繞不開的基礎電腦網(wǎng)絡中HTTP相關的知識在測試筆試里考察頻率極高因為當前絕大多數(shù)業(yè)務都是前后端分離、通過接口通信。你需要掌握GET和POST的區(qū)別、常見HTTP狀態(tài)碼的含義、Cookie和Session的區(qū)別、HTTP與HTTPS的區(qū)別、TCP三次握手的基本過程。如果考到接口測試你要能說出四個最基本的檢查點接口的返回狀態(tài)碼是否正確、返回數(shù)據(jù)格式是否符合約定、關鍵字段的取值是否正確、異常輸入時接口是否返回了合理的錯誤信息。如果時間允許還可以補充并發(fā)下的表現(xiàn)以及接口鑒權是否有漏洞。這里說一個很多人忽略的點筆試里涉及網(wǎng)絡協(xié)議時不光是記結論還要會用生活化的例子解釋。比如Cookie相當于你身上貼了一張寫著會員編號的標簽每次進店服務員都看一眼就知道你是誰Session則更像是你在店里辦了一張臨時卡卡里記錄著你的信息卡由店里保管。這樣解釋不僅自己能理解得更透面試時說出來也更容易打動面試官。3. 高頻題目實戰(zhàn)與思路復盤3.1 一個完整的測試用例設計題答題模板筆試里最常見的簡答題就是給你一個功能讓你設計測試用例。很多同學一看到這種題就開始憑感覺列列出十幾條看起來很豐富其實沒有邏輯。我后來總結出一個相對穩(wěn)定的答題套路遇到這類題可以直接套。第一步明確被測對象。比如“酒店預訂功能”你要先界定范圍是從搜索酒店開始還是從選定酒店、填寫訂單開始范圍不一樣用例的重點也不一樣。筆試里如果題目沒寫清楚建議在開頭先寫一句“假設該功能從選擇酒店、填寫入住信息開始”避免答偏。第二步拆解正常流程。按照用戶操作路徑把“選擇房型-填寫入住人-選擇入住日期-提交訂單-支付-確認預訂成功-收到確認短信”這條主線寫出來每步都至少有一條用例。正常流程用例不需要太多但一定要完整。第三步補全異常流程。包括入住日期早于當天、離店日期早于入住日期、超過可預訂天數(shù)、房型已滿、入住人姓名包含特殊字符、支付超時、支付成功但訂單狀態(tài)沒更新等。異常流程是拉開分數(shù)差距的關鍵你考慮得越細越能體現(xiàn)測試思維。第四步補充非功能測試點。比如同時多個用戶預訂同一間房是否有超賣風險、弱網(wǎng)環(huán)境下提交訂單是否會重復下單、不同瀏覽器和手機型號下頁面是否正常。筆試里把這些寫進去通常能拿到額外分。最后用表格組織用例。每一條都要包含編號、名稱、前置條件、輸入步驟、預期結果。比如用例編號用例名稱前置條件輸入/步驟預期結果TC_HTL_001正常提交酒店訂單用戶已登錄目標酒店有房選擇房型填寫入住人點擊提交訂單訂單生成成功跳轉(zhuǎn)支付頁TC_HTL_002離店日期早于入住日期用戶已登錄選擇入住日期為10日離店日期為9日點擊查詢提示離店日期不能早于入住日期TC_HTL_003并發(fā)預訂同一房間目標酒店僅剩1間房兩個用戶同時提交該房間訂單只有一個用戶預訂成功另一用戶提示房間已滿這樣的答案層次清楚評分的人一眼就能看出你的思路比零散寫幾十條用例要有效得多。3.2 場景題線上支付失敗怎么排查場景題是測試方向筆試里最能拉開差距的題型。它不是問你“怎么測”而是拋給你一個線上問題讓你說出排查思路。典型問題比如用戶反饋在App上下單后一直支付失敗請問你怎么排查我推薦用“先定位影響范圍再分層排查”的思路來回答這也是我在實際工作中用的方式。第一步是復現(xiàn)并收集信息。不要上來就查代碼先問清楚用戶用的什么手機型號和App版本是Wi-Fi還是流量支付失敗是彈出了什么錯誤提示還是一直轉(zhuǎn)圈是只有這個用戶失敗還是有大量用戶都失敗這些問題看起來瑣碎但能幫你快速縮小問題范圍。第二步是快速判斷影響范圍。如果只有單一用戶失敗大概率是賬號、支付方式或本地緩存問題如果是某個渠道的所有用戶失敗可能是支付渠道或后端服務出了問題如果全站用戶都失敗那就是壓測、網(wǎng)絡或服務宕機級別的問題了。第三步是分層排查。先看客戶端有沒有把請求發(fā)出去再看網(wǎng)絡層是否超時然后看后端接口的返回日志最后看數(shù)據(jù)庫里訂單狀態(tài)和支付流水。一個很經(jīng)典的現(xiàn)象是“用戶已經(jīng)支付成功但訂單仍顯示待支付”這種情況通常不是支付沒成功而是支付回調(diào)沒有正確更新訂單狀態(tài)。排查時先查訂單表再去查支付回調(diào)日志最后檢查回調(diào)接口是否做了冪等處理。第四步是給出回歸建議。問題修復后不能只驗證“支付成功”這一條主流程還要驗證“重復回調(diào)”“回調(diào)延遲”“退款”“取消訂單”等關聯(lián)場景。筆試里能把回歸范圍說清楚說明你有閉環(huán)思維。我當時在這類題上踩過的坑是把所有精力都放在“為什么會失敗”上沒有先說明排查順序。面試官后來告訴我他要看的不是你能不能立刻找到根因而是你有沒有一套穩(wěn)定的排查方法。把順序講清楚比直接說出正確答案更重要。3.3 編程題不追求花哨追求穩(wěn)定測試崗筆試的編程題難度通常不高但很多人在這里翻了車。原因不是不會寫而是寫得太隨意邊界條件全沒考慮。比如讓寫一個“判斷字符串是否是回文”很多人的第一反應是反轉(zhuǎn)字符串再比較這沒問題但要注意空字符串、大小寫、空格、標點符號等情況。給你一個建議拿到編程題先花兩分鐘想清楚輸入邊界再開始寫代碼。代碼結構最好清晰一點關鍵步驟加上注釋哪怕只是簡單一句“這里先判空”也說明你有工程意識。舉個簡單的例子def is_palindrome(s): # 先處理空值和類型異常 if s is None: return False # 只保留字母和數(shù)字并轉(zhuǎn)小寫 cleaned .join(ch.lower() for ch in s if ch.isalnum()) return cleaned cleaned[::-1]這段代碼雖然簡單但包含了判空、字符過濾、大小寫歸一化三個邊界處理比直接return s s[::-1]要穩(wěn)妥得多。筆試里常見的編程題還有字符串反轉(zhuǎn)、數(shù)組去重、查找數(shù)組中的重復元素、判斷括號是否匹配等。我的建議是不要用太冷門的技巧用你能保證正確性的寫法就好。畢竟測試崗考察的重點是你的代碼能不能被測試而不是你的算法有多炫。寫完之后自己默默在心里跑兩個用例正常輸入和邊界輸入確認沒問題再交。4. 常見問題與避坑經(jīng)驗4.1 這些扣分點一秒鐘都不能忘我復盤過自己和身邊人的筆試答卷發(fā)現(xiàn)測試方向的失分點其實比較集中很多不是不會而是細節(jié)丟分。最典型的是用例設計題里只寫操作步驟不寫預期結果。你要知道沒有預期結果的用例別人根本沒法判斷是否通過這種基礎錯誤在閱卷人眼里非常扎眼。第二個容易踩的坑是場景題只寫結論不寫過程。比如問你“支付失敗怎么排查”有人直接寫“可能是支付接口超時”這相當于沒有回答。哪怕你的結論是對的閱卷人也看不到你的分析過程自然給不了高分。正確做法是把排查步驟一步一步列出來哪怕最后沒有找到根因過程完整也能拿到大部分分數(shù)。第三個坑是編程題不檢查邊界條件。這一點前面已經(jīng)說過但值得反復強調(diào)。還有的選擇題過于糾結一題卡了好幾分鐘導致后面的簡答題和編程題時間不夠。筆試題量大不是要求你每道題都滿分而是要求你在有限時間內(nèi)拿到盡可能多的分該跳過的題就要果斷跳過。4.2 時間分配與臨場答題策略如果筆試總時長是兩小時我建議按30分鐘做選擇題和填空題40分鐘做簡答題40分鐘做編程題最后10分鐘檢查填空和選擇。場景題如果和簡答混在一起可以根據(jù)分值靈活調(diào)整但一定要給編程題留足時間因為一道能運行的代碼題分值占比往往很高。答題順序上我習慣先做有把握的題再回頭對付難題。這樣做的目的很樸素先把能拿的分拿穩(wěn)再去沖不確定的分。如果一上來就被一道難題卡住后面的答題節(jié)奏很容易崩。簡答題和場景題盡量用“分點”的方式作答。不需要寫一大段話而是把思路拆成1、2、3、4條。閱卷人在一堆試卷里看到結構清晰的答案好感度會明顯提高。我甚至建議你在動筆前先把關鍵詞寫在草稿紙上比如“邊界值、異常輸入、弱網(wǎng)、并發(fā)、冪等”然后圍繞關鍵詞展開這樣不容易漏點。4.3 從筆試到面試怎么把答案變成談資筆試結束不是終點而是一輪更重要的復盤機會。我會在交卷后趁記憶還熱立刻把自己能回憶起來的題目整理一遍重點看兩類一類是答得很順的另一類是沒把握的。答得順的題目要想想能不能在面試里主動展示沒把握的題目要第一時間查資料搞懂因為面試官很可能會追問。比如你筆試里設計了一個“退款”功能的測試用例面試時就可以主動說“筆試里我重點考慮了退款金額與訂單金額不一致、退款失敗后重試、重復點擊退款按鈕這三個場景后來我查資料發(fā)現(xiàn)退款回調(diào)的冪等性其實比我想的更復雜。”這段話一出來面試官會立刻覺得你有復盤能力而且愿意深挖問題。再說一個很多人不知道的點近幾年測試崗面試越來越關注你對AI測試工具的敏感度比如AI輔助生成測試用例、AI自動定位缺陷、AI生成測試腳本等。即便是2019屆那場筆試當時也已經(jīng)有少量涉及自動化測試的題目。我的建議是在準備筆試基礎的同時花點時間了解一下AI軟件測試的發(fā)展趨勢哪怕只是在簡歷項目里提一句“用自動化腳本替代了重復性回歸測試”也能讓你比同齡人多一個話題。最后再分享一個小經(jīng)驗。筆試里遇到不會的題千萬不要留白。選擇題可以結合排除法蒙一個簡答題哪怕只寫出幾個關鍵詞也能拿到一點步驟分。測試崗本身就是一個“面對不確定性問題”的崗位你能在不會的情況下盡量給出一個合理的探索路徑這種行為本身就是測試思維的體現(xiàn)。把那場筆試當成一次真實的問題排查心態(tài)會穩(wěn)很多。