車2023秋招測試筆試題B卷超全解析：從用例設(shè)計到業(yè)務(wù)場景)
途虎養(yǎng)車2023秋招測試筆試試卷B這份卷子在圈子里流傳度不算低。我第一時間拿到手做完一遍之后最大的感受是它不只是考“會不會寫代碼、會不會點按鈕”更是在篩“有沒有用測試思維解決實際業(yè)務(wù)問題的習(xí)慣”。尤其途虎本身是汽車后市場賽道線上App加線下工場店、供應(yīng)鏈、物流倉儲全鏈路打通這種“線上線下硬件設(shè)備”結(jié)合的業(yè)務(wù)形態(tài)決定了它的測試筆試題目一定不會只停留在純軟件層面。下面我按自己的解題過程把試卷B的題型結(jié)構(gòu)、核心考點、做題思路完整拆一遍希望能給正在準(zhǔn)備秋招春招的同學(xué)一些參考。1. 試卷整體結(jié)構(gòu)與出題邏輯先說結(jié)論試卷B約60道題考試時間90分鐘題型包含單選題、多選題、判斷題、簡答題和1道場景用例設(shè)計大題。整體難度中等偏上但真正的難點不在知識深度而在“業(yè)務(wù)場景的理解速度”和“測試思維的完整度”。整份卷子按內(nèi)容分布大致可以分成四個模塊測試基礎(chǔ)與用例設(shè)計約30%等價類、邊界值、場景法、判定表以及基礎(chǔ)的用例編寫規(guī)范。Linux與數(shù)據(jù)庫操作約25%日志查看、進(jìn)程處理、shell基礎(chǔ)操作、SQL查詢與數(shù)據(jù)校驗。接口與自動化測試約25%HTTP協(xié)議、接口測試工具使用、自動化框架理解、Appium移動端測試基礎(chǔ)。業(yè)務(wù)場景綜合題約20%圍繞途虎養(yǎng)車App的養(yǎng)車預(yù)約、到店服務(wù)、配件購買、優(yōu)惠券使用等真實業(yè)務(wù)出題。這里我特別想強(qiáng)調(diào)一個容易被忽略的點試卷B里出現(xiàn)了一些“看起來像軟件測試實際上是在考業(yè)務(wù)流程閉環(huán)”的題目。比如優(yōu)惠券下單時庫存扣減失敗怎么排查這種題如果只盯著接口返回做分析很容易漏掉“線下門店庫存同步”這個環(huán)節(jié)。做這套題的時候建議始終帶著一個前提——途虎不是單純的電商App而是連接用戶、門店、倉庫、物流的復(fù)雜系統(tǒng)。另外試卷B里多選題占比不低而且很多是“選出所有正確選項”的玩法少選多選都不得分。這意味著你對知識點的理解必須邊界清晰不能有模糊地帶平時如果習(xí)慣了“記住大概意思”這種題會非常吃虧。2. 核心題型逐一拆解與解題思路2.1 測試用例設(shè)計等價類與邊界值不是背概念是算出來的試卷B里有一道很典型的題目某功能允許用戶輸入“車牌號”進(jìn)行綁定要求車牌號格式為7位字符第一位是漢字省份簡稱第二位是發(fā)證機(jī)關(guān)字母后五位是字母和數(shù)字的組合。問使用等價類劃分法至少需要設(shè)計多少條有效等價類和無效等價類測試用例這道題看著簡單但錯誤率很高。很多人會直接回答“有效1條無效4條”理由是“一個有效類加每個無效條件各一條”。實際上正確思路是有效等價類方面7位字符、首字為指定省份漢字、第二位為字母、后五位允許字母數(shù)字混合這些條件同時滿足時屬于“單個有效等價類”因為它們是組合后構(gòu)成合法輸入的整體所以有效等價類只需要1條用例覆蓋。無效等價類則要按“每個破壞一個條件”的原則分別設(shè)計長度不等于7位、首位不是合法省份漢字、第二位不是字母、后五位包含非法字符如中文、特殊符號這樣至少4條無效用例。再把邊界值加上長度邊界是6位、7位、8位也就是至少要各測一次。所以這道題的完整回答應(yīng)該是“有效等價類1條無效等價類4條邊界值用例3條合計至少8條”。答題時一定要把計算過程寫出來閱卷人看的不只是答案更是你“有沒有把一個模糊需求拆成明確條件”的能力。2.2 Linux操作題定位問題是第一能力Linux題目里有一道很務(wù)實的問題測試環(huán)境出現(xiàn)接口響應(yīng)緩慢需要登錄服務(wù)器查看某個Java應(yīng)用進(jìn)程的CPU和內(nèi)存占用情況并輸出最近100行日志請寫出完整命令。這道題綜合考了進(jìn)程管理和日志查看兩個能力點。我的答案是這樣的# 先找到Java進(jìn)程的PID并查看CPU和內(nèi)存占用 ps aux | grep java | grep -v grep # 如果進(jìn)程較多用top動態(tài)查看按CPU使用率排序 top -c -o %CPU # 用PID查看該進(jìn)程的具體線程占用情況 top -Hp PID # 輸出最近100行日志并持續(xù)跟蹤 tail -n 100 /opt/app/logs/application.log # 如果日志文件有滾動用通配符匹配最新的那個文件 tail -n 100 /opt/app/logs/application-$(date %Y%m%d).log這里有幾個加分細(xì)節(jié)。第一ps aux找到PID后一定要再top -Hp看一下線程級別的占用因為Java應(yīng)用CPU飆升通常需要定位到具體線程再做線程dump分析。第二如果日志文件名帶日期用$(date %Y%m%d)可以確保tail到當(dāng)天的文件這樣寫比手動拼文件名更可靠。第三真實場景下接口慢不一定是應(yīng)用本身問題我還會習(xí)慣性先ping一下數(shù)據(jù)庫地址telnet一下端口排除網(wǎng)絡(luò)鏈路問題再往深了查。這類題目在試卷里出現(xiàn)的目的很直接——測試工程師要具備獨立排查環(huán)境問題的能力不能什么問題都直接甩給開發(fā)或運維。2.3 數(shù)據(jù)庫校驗題SQL不只是能跑通還要能校驗對試卷B里有一道SQL題給定兩張表user表用戶id、手機(jī)號、注冊時間和order表訂單id、用戶id、訂單金額、下單時間查詢“2023年1月1日之后注冊、且下過訂單總金額超過500元”的用戶id和總金額按總金額降序排列。這道題核心考的是聚合函數(shù)、JOIN和HAVING的組合使用。我的寫法是SELECT u.user_id, SUM(o.order_amount) AS total_amount FROM user u INNER JOIN order o ON u.user_id o.user_id WHERE u.register_time 2023-01-01 GROUP BY u.user_id HAVING SUM(o.order_amount) 500 ORDER BY total_amount DESC;這里有幾個關(guān)鍵點必須注意HAVING后面不能直接寫total_amount 500因為SELECT子句里的別名在部分?jǐn)?shù)據(jù)庫的HAVING階段不可用穩(wěn)妥的寫法是重復(fù)寫SUM(o.order_amount)。另外需求里說的是“下過訂單的用戶”所以INNER JOIN是合適的如果用LEFT JOIN就可能把沒下過單的用戶也查出來然后被HAVING過濾掉雖然結(jié)果一樣但邏輯上不夠嚴(yán)謹(jǐn)。這道題還有個小陷阱下單時間字段需不需要加條件題目只要求“注冊后下過訂單”并沒有限定訂單日期必須大于注冊日期所以不用加o.order_time u.register_time。但實際業(yè)務(wù)里可能會存在歷史訂單被補錄的情況如果你在答案里主動說明“這里我假設(shè)訂單都是注冊后產(chǎn)生的如果業(yè)務(wù)上有補單場景還需要額外加時間過濾”這反而是加分的因為展現(xiàn)了業(yè)務(wù)思考。2.4 接口測試題HTTP狀態(tài)碼背后的業(yè)務(wù)邏輯接口測試相關(guān)題目里有一道很有意思用戶使用優(yōu)惠券提交訂單接口返回HTTP 500請問可能的原因有哪些你如何一步步排查這道題沒有標(biāo)準(zhǔn)答案但考察的維度很全。我的回答邏輯分了四層第一層先看返回內(nèi)容。500表示服務(wù)器內(nèi)部錯誤但有些框架會同時返回JSON格式的錯誤信息比如異常堆?；蝈e誤碼。先抓包或者看響應(yīng)體往往能直接定位。第二層看服務(wù)端日志。重點查下單接口所在服務(wù)的error日志看拋出的異常類型。常見的可能是空指針、數(shù)據(jù)庫連接池滿、Redis緩存key過期、下游接口超時等。第三層定位是單點問題還是共性問題。用同一賬號、同一優(yōu)惠券再提交一次如果必現(xiàn)大概率是這單業(yè)務(wù)數(shù)據(jù)的問題如果偶現(xiàn)可能是并發(fā)導(dǎo)致庫存超賣、Redis分布式鎖失效、接口冪等性問題。第四層結(jié)合業(yè)務(wù)鏈路排查。途虎的下單鏈路涉及優(yōu)惠券核銷、庫存扣減、支付單創(chuàng)建、門店接單通知等多個環(huán)節(jié)。任何一環(huán)異常都可能返回500。特別是優(yōu)惠券和庫存之間往往不是同一個服務(wù)涉及分布式事務(wù)一旦某個子事務(wù)回滾失敗就會暴露成500。這套回答好在哪里它是“從現(xiàn)象到原因、從單點到整體”的遞進(jìn)結(jié)構(gòu)而不是東一榔頭西一棒子地羅列可能原因。面試官要看到的是你遇到線上問題時有一套穩(wěn)定的排查動作而不是靠猜。2.5 業(yè)務(wù)場景題車輛維保預(yù)約的核心流程測試試卷最后的大題是一道典型的業(yè)務(wù)場景設(shè)計題大致背景是途虎養(yǎng)車App上線“到店保養(yǎng)預(yù)約”功能用戶選擇門店、選擇保養(yǎng)套餐、選擇到店時間、提交預(yù)約門店確認(rèn)后生成預(yù)約單。題目要求設(shè)計該功能的測試用例覆蓋功能、接口、兼容性、異常場景四個方面。這道題分值最高也是最容易拉開差距的一道題。我當(dāng)時的思路是分四塊來寫功能測試方面我分成主流程、分支流程和異常流程。主流程是“選擇城市→選擇門店→選擇套餐→選擇時間→填寫車輛信息→提交→預(yù)約成功→門店確認(rèn)”。分支流程包括用戶有多個車輛時切換默認(rèn)車輛、門店支持的服務(wù)類型篩選、套餐更換時價格聯(lián)動計算。異常流程覆蓋預(yù)約時間已滿、門店休息日不可約、車輛信息未綁定、提交時斷網(wǎng)、重復(fù)點擊提交按鈕等。接口測試方面重點是預(yù)約提交接口的冪等性測試、并發(fā)預(yù)約同一時間段的處理、門店可預(yù)約時間段列表接口的準(zhǔn)確性、優(yōu)惠券抵扣金額與套餐金額的一致性校驗。這里尤其要關(guān)注冪等性——用戶因網(wǎng)絡(luò)超時重復(fù)點擊提交系統(tǒng)不能生成兩筆預(yù)約單這種用例在業(yè)務(wù)型公司里非常受重視。兼容性測試方面覆蓋iOS和Android兩大平臺的不同版本、不同屏幕尺寸。考慮到途虎用戶群體里有相當(dāng)一部分是中老年車主低端Android機(jī)和舊版本iOS的兼容性尤為重要不能只測最新機(jī)型。異常場景方面除了常規(guī)的無網(wǎng)絡(luò)、弱網(wǎng)、服務(wù)端異常外我還補充了“門店關(guān)店前30分鐘提交預(yù)約”這種帶業(yè)務(wù)時間屬性的邊界場景以及“保養(yǎng)套餐下架后用戶已提交預(yù)約但尚未確認(rèn)”的狀態(tài)沖突場景。最后我在每個測試分類下面都注明了一條“優(yōu)先級標(biāo)記規(guī)則”P0級用例是阻塞發(fā)布的問題P1級是主流程功能異常P2級是次要功能問題。這能向閱卷人傳遞一個信息——你不是只會列用例而是知道如何把控測試節(jié)奏。3. 實操環(huán)節(jié)模擬與完整解題過程復(fù)盤3.1 模擬一道完整的“優(yōu)惠券使用”綜合題試卷里有一道綜合題把好幾個知識點串在一起了用戶在途虎App選擇“199元小保養(yǎng)套餐”使用一張“滿199減50”優(yōu)惠券下單時應(yīng)付金額為149元但實際支付后賬戶被扣款199元。請分析問題可能出在哪里并設(shè)計驗證方案。這道題我在做的時候沒有急著寫結(jié)論而是先在草稿紙上畫了一條資金鏈路用戶端展示金額→提交訂單時后端計算金額→支付網(wǎng)關(guān)扣款金額→訂單系統(tǒng)記賬金額。任何一環(huán)出現(xiàn)偏差都會導(dǎo)致用戶實付和應(yīng)付不一致。最可能的三個原因我按概率排序一是前端展示與后端計算不一致。前端頁面展示了優(yōu)惠券抵扣后的149元但提交訂單時后端沒有正確匹配優(yōu)惠券或者優(yōu)惠券狀態(tài)異常導(dǎo)致后端計算金額仍為原價199元。判斷方法是抓包看下單接口的請求參數(shù)里有沒有正確攜帶優(yōu)惠券ID再看后端返回的訂單金額。二是優(yōu)惠券在支付環(huán)節(jié)沒生效。有些老系統(tǒng)會把優(yōu)惠分?jǐn)偡旁谥Ц冻晒蟮幕卣{(diào)里處理如果回調(diào)處理異常就會出現(xiàn)“支付時按原價扣款訂單里卻顯示已優(yōu)惠”的情況。這需要查看支付回調(diào)日志和訂單狀態(tài)變更記錄。三是并發(fā)場景下優(yōu)惠券被重復(fù)使用或狀態(tài)未鎖住。比如用戶在其他設(shè)備上已經(jīng)把這張券用了但當(dāng)前設(shè)備頁面未刷新仍然顯示可用。提交訂單時后端發(fā)現(xiàn)券已被用但沒有報錯攔截而是直接走了原價邏輯。這就是典型的“并發(fā)下的狀態(tài)校驗缺失”。設(shè)計驗證方案時我建議先通過接口測試復(fù)現(xiàn)再定位到具體模塊。具體步驟是先準(zhǔn)備一張測試優(yōu)惠券和一個測試賬號分別用“正常領(lǐng)取”“不領(lǐng)取券”“領(lǐng)取券但支付前在另一設(shè)備核銷”三種場景跑一遍下單接口對比返回的應(yīng)付金額是否都是199元。再用數(shù)據(jù)庫直接看優(yōu)惠券表的狀態(tài)和訂單表的實付金額如果券狀態(tài)已是“已核銷”但訂單金額是原價就能基本定位為后端狀態(tài)校驗問題。這道題整體考察的是定位問題的分析能力?；卮饡r要讓閱卷人看到你有“先分模塊、再逐個排除”的思路而不是直接給出一堆可能性。3.2 動手實操用Charles抓包模擬弱網(wǎng)環(huán)境測試筆試?yán)镞€有一道弱網(wǎng)測試的簡答題問的是如何模擬弱網(wǎng)環(huán)境驗證App在2G/3G網(wǎng)絡(luò)下的表現(xiàn)。我在這里提供一個最常用的實操方案用Charles抓包工具模擬弱網(wǎng)這也是移動端測試最基礎(chǔ)的一項技能。打開Charles在菜單欄找到Proxy → Throttle Settings勾選Enable Throttling然后在Throttle Preset里選擇預(yù)設(shè)的網(wǎng)速檔位。如果預(yù)設(shè)中沒有想要的檔位可以手動設(shè)置帶寬、延遲、丟包率等參數(shù)。比如模擬3G網(wǎng)絡(luò)常用的參數(shù)是帶寬780kbps、延遲100ms、丟包率2%模擬弱2G網(wǎng)絡(luò)可以設(shè)置帶寬20kbps、延遲400ms、丟包率5%。設(shè)置完成后手機(jī)連上代理打開途虎App重點觀察以下場景首頁圖片是否懶加載失敗、保養(yǎng)套餐詳情頁是否長時間白屏、預(yù)約提交時是否出現(xiàn)超時彈窗、斷網(wǎng)恢復(fù)后是否有重試機(jī)制。每個場景都要記錄出現(xiàn)問題的頁面和時間點。這里分享一個實測中容易踩的坑很多同學(xué)開了弱網(wǎng)模擬后發(fā)現(xiàn)App完全打不開然后以為是自己配置有問題。實際上是因為Charles默認(rèn)只對HTTP流量生效如果App用的是HTTPS且沒有配置SSL代理就會出現(xiàn)頁面空白。解決辦法是在Charles的SSL Proxying Settings里添加*:443并保證手機(jī)安裝了Charles的CA證書。否則你測出來的“弱網(wǎng)問題”其實只是“證書驗證失敗”不是真實的弱網(wǎng)表現(xiàn)。3.3 自動化測試實操Appium連接模擬器跑通一條業(yè)務(wù)流試卷里自動化相關(guān)題目比重不小其中有一道問的是使用Appium編寫一條自動化腳本的步驟。對于平時只寫過腳本沒跑過真機(jī)的同學(xué)來說這道題容易寫得很虛。我在這里給出一個最小可運行的全流程從配置到代碼大家可以直接照著試。環(huán)境準(zhǔn)備部分需要安裝Node.js、Appium Desktop或命令行版Appium、Android SDK以及一個Android模擬器或真機(jī)。然后用Python寫腳本的話還需要安裝Appium-Python-Client庫。一個最小示例腳本如下from appium.webdriver import Remote from appium.webdriver.common.appiumby import AppiumBy desired_caps { platformName: Android, platformVersion: 12.0, deviceName: emulator-5554, app: /path/to/tuhu.apk, noReset: True, automationName: UiAutomator2 } driver Remote(http://127.0.0.1:4723/wd/hub, desired_caps) # 等待首頁加載 driver.implicitly_wait(10) # 定位“保養(yǎng)”入口并點擊 el driver.find_element(AppiumBy.ID, com.tuhu.auto:id/tab_maintenance) el.click() # 斷言頁面出現(xiàn)“選擇門店”按鈕 assert driver.find_element(AppiumBy.ID, com.tuhu.auto:id/btn_select_store).is_displayed() driver.quit()這段腳本跑通后就可以往里面加斷言、加數(shù)據(jù)參數(shù)化。但筆試?yán)锶绻屇恪霸O(shè)計自動化測試方案”你要展現(xiàn)的就不只是一段代碼而是更完整的框架思維用例分層頁面對象層、業(yè)務(wù)流層、數(shù)據(jù)層、失敗截圖與日志收集、與Jenkins集成做定時任務(wù)、測試報告生成。把這幾塊寫出來才能體現(xiàn)出你具備獨立搭建自動化框架的能力而不只是會調(diào)API。實際工作中自動化腳本維護(hù)成本最高的是元素定位所有App的UI改動都可能導(dǎo)致腳本大面積報錯。所以我在方案里還會建議優(yōu)先使用穩(wěn)定的resource-id定位少用xpath在頁面對象層做元素封裝后續(xù)UI變更時只改一處。4. 高頻考點速查與避坑清單4.1 常見失分點對照表結(jié)合我自己的做題過程以及和幾位同樣參加過途虎筆試的同學(xué)交流復(fù)盤整理了一份高頻失分點表格大家可以對照自查?？键c模塊常見失分點正確做法用例設(shè)計只寫有效等價類漏無效等價類每個非法的獨立條件都要覆蓋一次測試方法選擇看到輸入框就只想到等價類和邊界值根據(jù)需求復(fù)雜度選有多個條件組合用判定表流程類用場景法Linux命令忘記加grep -v grepps aux之后一定過濾grep自身進(jìn)程SQL聚合在HAVING里使用SELECT別名重復(fù)書寫聚合函數(shù)不依賴別名接口測試只關(guān)注狀態(tài)碼不關(guān)注響應(yīng)體內(nèi)容先看響應(yīng)體再看服務(wù)端日志最后看鏈路移動端測試忽略弱網(wǎng)和中斷場景重點覆蓋弱網(wǎng)、斷網(wǎng)、來電、切后臺等中斷場景自動化測試只寫腳本不寫維護(hù)方案補充元素封層、失敗截圖、數(shù)據(jù)驅(qū)動設(shè)計4.2 時間分配建議試卷B總共90分鐘我的實際時間分配是這樣的選擇題和判斷題控制在35分鐘以內(nèi)這些題大部分是概念題想太久反而容易改錯。多選題控制在10分鐘猶豫不決的題先標(biāo)記不要戀戰(zhàn)。簡答題大約25分鐘每題控制在8分鐘左右答到點子上就行不需要長篇大論。最后一道場景設(shè)計大題留20分鐘這部分一定要寫結(jié)構(gòu)化的編號方便閱卷人看出你的思路。4.3 關(guān)于試卷B的一個獨家觀察整套卷子做下來一個很明顯的傾向是——凡是涉及業(yè)務(wù)閉環(huán)的題幾乎沒有一道是“背過就會”的全是需要現(xiàn)場分析場景。這反映出途虎對測試工程師的期望不是“執(zhí)行者”而是“質(zhì)量owner”你不僅要能執(zhí)行測試用例還要能主動分析業(yè)務(wù)邏輯里可能存在的漏洞并對測試結(jié)果負(fù)責(zé)。這一點在最后那道場景設(shè)計題里體現(xiàn)得最充分。設(shè)計用例時除了常規(guī)的功能用例我額外補了一條看似邊緣、實際非常關(guān)鍵的用例“用戶已提交預(yù)約但尚未到店且期間門店修改了營業(yè)時間系統(tǒng)是否會自動推送變更通知”。這種用例在標(biāo)準(zhǔn)測試用例模板里不會出現(xiàn)但真正做過業(yè)務(wù)測試的人會知道這類“狀態(tài)變更通知”場景在真實業(yè)務(wù)中往往就是投訴重災(zāi)區(qū)。5. 一套完整的備考策略與實用建議筆試只是整個秋招流程的其中一環(huán)考完之后還有面試。從試卷B的難度和風(fēng)格來看后續(xù)面試大概率會圍繞“項目經(jīng)歷”和“場景題”展開不太會問特別偏門的概念題。所以備考重心應(yīng)該放在三件事上第一把測試基礎(chǔ)概念吃透到能隨手舉例的程度第二Linux和SQL要達(dá)到“不看文檔能直接寫”的熟練度第三結(jié)合途虎的業(yè)務(wù)形態(tài)提前積累“線上App線下門店”場景的測試經(jīng)驗。關(guān)于第二點我多說一句很多計算機(jī)專業(yè)的同學(xué)平時用Windows比較多Linux命令全靠記憶一到寫命令的時候就會混。我的建議是不要死記硬背在自己電腦上裝個虛擬機(jī)或者用云服務(wù)器搭一個Linux環(huán)境把常用的日志查看、進(jìn)程管理、權(quán)限修改、網(wǎng)絡(luò)排查命令都實際操作一遍兩周時間基本就能形成肌肉記憶。SQL同樣如此沒必要刷特別復(fù)雜的題目就把關(guān)聯(lián)查詢、聚合函數(shù)、子查詢、窗口函數(shù)這幾類吃透。筆試中的SQL基本不會超過這個范圍。關(guān)于第三點坦白說沒有實際項目經(jīng)驗的同學(xué)在這類題目上會比較吃虧。我給出一個可操作的替代方案在工作日晚上打開途虎App把用戶能走的核心路徑都完整走一遍包括注冊、選門店、選套餐、下單、支付、查看訂單詳情、取消訂單、申請退款。每走一步都記錄下可能出現(xiàn)問題的地方然后設(shè)想“如果我是測試會怎么設(shè)計用例來保障這個流程”。這不花太多時間但對理解業(yè)務(wù)型測試的思維模式很有幫助。另外給你一個提升簡歷通過率的小建議如果時間允許可以在GitHub上維護(hù)一個小的測試項目比如把自己寫的接口自動化腳本和測試用例設(shè)計文檔放上去形成“需求分析→用例設(shè)計→腳本實現(xiàn)→測試報告”的完整閉環(huán)。面試官看項目經(jīng)歷時看重的不只是技術(shù)棧更是“你有沒有把一件事做完整的意識”。這套試卷B整體上不難但信息量不小。只要基礎(chǔ)扎實、業(yè)務(wù)場景想得足夠多拿高分并不難。踏踏實實把上面幾個模塊過一遍這套題基本就能穩(wěn)住了。 途虎養(yǎng)車2023秋招測試筆試題B卷超全解析：從用例設(shè)計到業(yè)務(wù)場景
途虎養(yǎng)車2023秋招測試筆試試卷B這份卷子在圈子里流傳度不算低。我第一時間拿到手做完一遍之后最大的感受是它不只是考“會不會寫代碼、會不會點按鈕”更是在篩“有沒有用測試思維解決實際業(yè)務(wù)問題的習(xí)慣”。尤其途虎本身是汽車后市場賽道線上App加線下工場店、供應(yīng)鏈、物流倉儲全鏈路打通這種“線上線下硬件設(shè)備”結(jié)合的業(yè)務(wù)形態(tài)決定了它的測試筆試題目一定不會只停留在純軟件層面。下面我按自己的解題過程把試卷B的題型結(jié)構(gòu)、核心考點、做題思路完整拆一遍希望能給正在準(zhǔn)備秋招春招的同學(xué)一些參考。1. 試卷整體結(jié)構(gòu)與出題邏輯先說結(jié)論試卷B約60道題考試時間90分鐘題型包含單選題、多選題、判斷題、簡答題和1道場景用例設(shè)計大題。整體難度中等偏上但真正的難點不在知識深度而在“業(yè)務(wù)場景的理解速度”和“測試思維的完整度”。整份卷子按內(nèi)容分布大致可以分成四個模塊測試基礎(chǔ)與用例設(shè)計約30%等價類、邊界值、場景法、判定表以及基礎(chǔ)的用例編寫規(guī)范。Linux與數(shù)據(jù)庫操作約25%日志查看、進(jìn)程處理、shell基礎(chǔ)操作、SQL查詢與數(shù)據(jù)校驗。接口與自動化測試約25%HTTP協(xié)議、接口測試工具使用、自動化框架理解、Appium移動端測試基礎(chǔ)。業(yè)務(wù)場景綜合題約20%圍繞途虎養(yǎng)車App的養(yǎng)車預(yù)約、到店服務(wù)、配件購買、優(yōu)惠券使用等真實業(yè)務(wù)出題。這里我特別想強(qiáng)調(diào)一個容易被忽略的點試卷B里出現(xiàn)了一些“看起來像軟件測試實際上是在考業(yè)務(wù)流程閉環(huán)”的題目。比如優(yōu)惠券下單時庫存扣減失敗怎么排查這種題如果只盯著接口返回做分析很容易漏掉“線下門店庫存同步”這個環(huán)節(jié)。做這套題的時候建議始終帶著一個前提——途虎不是單純的電商App而是連接用戶、門店、倉庫、物流的復(fù)雜系統(tǒng)。另外試卷B里多選題占比不低而且很多是“選出所有正確選項”的玩法少選多選都不得分。這意味著你對知識點的理解必須邊界清晰不能有模糊地帶平時如果習(xí)慣了“記住大概意思”這種題會非常吃虧。2. 核心題型逐一拆解與解題思路2.1 測試用例設(shè)計等價類與邊界值不是背概念是算出來的試卷B里有一道很典型的題目某功能允許用戶輸入“車牌號”進(jìn)行綁定要求車牌號格式為7位字符第一位是漢字省份簡稱第二位是發(fā)證機(jī)關(guān)字母后五位是字母和數(shù)字的組合。問使用等價類劃分法至少需要設(shè)計多少條有效等價類和無效等價類測試用例這道題看著簡單但錯誤率很高。很多人會直接回答“有效1條無效4條”理由是“一個有效類加每個無效條件各一條”。實際上正確思路是有效等價類方面7位字符、首字為指定省份漢字、第二位為字母、后五位允許字母數(shù)字混合這些條件同時滿足時屬于“單個有效等價類”因為它們是組合后構(gòu)成合法輸入的整體所以有效等價類只需要1條用例覆蓋。無效等價類則要按“每個破壞一個條件”的原則分別設(shè)計長度不等于7位、首位不是合法省份漢字、第二位不是字母、后五位包含非法字符如中文、特殊符號這樣至少4條無效用例。再把邊界值加上長度邊界是6位、7位、8位也就是至少要各測一次。所以這道題的完整回答應(yīng)該是“有效等價類1條無效等價類4條邊界值用例3條合計至少8條”。答題時一定要把計算過程寫出來閱卷人看的不只是答案更是你“有沒有把一個模糊需求拆成明確條件”的能力。2.2 Linux操作題定位問題是第一能力Linux題目里有一道很務(wù)實的問題測試環(huán)境出現(xiàn)接口響應(yīng)緩慢需要登錄服務(wù)器查看某個Java應(yīng)用進(jìn)程的CPU和內(nèi)存占用情況并輸出最近100行日志請寫出完整命令。這道題綜合考了進(jìn)程管理和日志查看兩個能力點。我的答案是這樣的# 先找到Java進(jìn)程的PID并查看CPU和內(nèi)存占用 ps aux | grep java | grep -v grep # 如果進(jìn)程較多用top動態(tài)查看按CPU使用率排序 top -c -o %CPU # 用PID查看該進(jìn)程的具體線程占用情況 top -Hp PID # 輸出最近100行日志并持續(xù)跟蹤 tail -n 100 /opt/app/logs/application.log # 如果日志文件有滾動用通配符匹配最新的那個文件 tail -n 100 /opt/app/logs/application-$(date %Y%m%d).log這里有幾個加分細(xì)節(jié)。第一ps aux找到PID后一定要再top -Hp看一下線程級別的占用因為Java應(yīng)用CPU飆升通常需要定位到具體線程再做線程dump分析。第二如果日志文件名帶日期用$(date %Y%m%d)可以確保tail到當(dāng)天的文件這樣寫比手動拼文件名更可靠。第三真實場景下接口慢不一定是應(yīng)用本身問題我還會習(xí)慣性先ping一下數(shù)據(jù)庫地址telnet一下端口排除網(wǎng)絡(luò)鏈路問題再往深了查。這類題目在試卷里出現(xiàn)的目的很直接——測試工程師要具備獨立排查環(huán)境問題的能力不能什么問題都直接甩給開發(fā)或運維。2.3 數(shù)據(jù)庫校驗題SQL不只是能跑通還要能校驗對試卷B里有一道SQL題給定兩張表user表用戶id、手機(jī)號、注冊時間和order表訂單id、用戶id、訂單金額、下單時間查詢“2023年1月1日之后注冊、且下過訂單總金額超過500元”的用戶id和總金額按總金額降序排列。這道題核心考的是聚合函數(shù)、JOIN和HAVING的組合使用。我的寫法是SELECT u.user_id, SUM(o.order_amount) AS total_amount FROM user u INNER JOIN order o ON u.user_id o.user_id WHERE u.register_time 2023-01-01 GROUP BY u.user_id HAVING SUM(o.order_amount) 500 ORDER BY total_amount DESC;這里有幾個關(guān)鍵點必須注意HAVING后面不能直接寫total_amount 500因為SELECT子句里的別名在部分?jǐn)?shù)據(jù)庫的HAVING階段不可用穩(wěn)妥的寫法是重復(fù)寫SUM(o.order_amount)。另外需求里說的是“下過訂單的用戶”所以INNER JOIN是合適的如果用LEFT JOIN就可能把沒下過單的用戶也查出來然后被HAVING過濾掉雖然結(jié)果一樣但邏輯上不夠嚴(yán)謹(jǐn)。這道題還有個小陷阱下單時間字段需不需要加條件題目只要求“注冊后下過訂單”并沒有限定訂單日期必須大于注冊日期所以不用加o.order_time u.register_time。但實際業(yè)務(wù)里可能會存在歷史訂單被補錄的情況如果你在答案里主動說明“這里我假設(shè)訂單都是注冊后產(chǎn)生的如果業(yè)務(wù)上有補單場景還需要額外加時間過濾”這反而是加分的因為展現(xiàn)了業(yè)務(wù)思考。2.4 接口測試題HTTP狀態(tài)碼背后的業(yè)務(wù)邏輯接口測試相關(guān)題目里有一道很有意思用戶使用優(yōu)惠券提交訂單接口返回HTTP 500請問可能的原因有哪些你如何一步步排查這道題沒有標(biāo)準(zhǔn)答案但考察的維度很全。我的回答邏輯分了四層第一層先看返回內(nèi)容。500表示服務(wù)器內(nèi)部錯誤但有些框架會同時返回JSON格式的錯誤信息比如異常堆?；蝈e誤碼。先抓包或者看響應(yīng)體往往能直接定位。第二層看服務(wù)端日志。重點查下單接口所在服務(wù)的error日志看拋出的異常類型。常見的可能是空指針、數(shù)據(jù)庫連接池滿、Redis緩存key過期、下游接口超時等。第三層定位是單點問題還是共性問題。用同一賬號、同一優(yōu)惠券再提交一次如果必現(xiàn)大概率是這單業(yè)務(wù)數(shù)據(jù)的問題如果偶現(xiàn)可能是并發(fā)導(dǎo)致庫存超賣、Redis分布式鎖失效、接口冪等性問題。第四層結(jié)合業(yè)務(wù)鏈路排查。途虎的下單鏈路涉及優(yōu)惠券核銷、庫存扣減、支付單創(chuàng)建、門店接單通知等多個環(huán)節(jié)。任何一環(huán)異常都可能返回500。特別是優(yōu)惠券和庫存之間往往不是同一個服務(wù)涉及分布式事務(wù)一旦某個子事務(wù)回滾失敗就會暴露成500。這套回答好在哪里它是“從現(xiàn)象到原因、從單點到整體”的遞進(jìn)結(jié)構(gòu)而不是東一榔頭西一棒子地羅列可能原因。面試官要看到的是你遇到線上問題時有一套穩(wěn)定的排查動作而不是靠猜。2.5 業(yè)務(wù)場景題車輛維保預(yù)約的核心流程測試試卷最后的大題是一道典型的業(yè)務(wù)場景設(shè)計題大致背景是途虎養(yǎng)車App上線“到店保養(yǎng)預(yù)約”功能用戶選擇門店、選擇保養(yǎng)套餐、選擇到店時間、提交預(yù)約門店確認(rèn)后生成預(yù)約單。題目要求設(shè)計該功能的測試用例覆蓋功能、接口、兼容性、異常場景四個方面。這道題分值最高也是最容易拉開差距的一道題。我當(dāng)時的思路是分四塊來寫功能測試方面我分成主流程、分支流程和異常流程。主流程是“選擇城市→選擇門店→選擇套餐→選擇時間→填寫車輛信息→提交→預(yù)約成功→門店確認(rèn)”。分支流程包括用戶有多個車輛時切換默認(rèn)車輛、門店支持的服務(wù)類型篩選、套餐更換時價格聯(lián)動計算。異常流程覆蓋預(yù)約時間已滿、門店休息日不可約、車輛信息未綁定、提交時斷網(wǎng)、重復(fù)點擊提交按鈕等。接口測試方面重點是預(yù)約提交接口的冪等性測試、并發(fā)預(yù)約同一時間段的處理、門店可預(yù)約時間段列表接口的準(zhǔn)確性、優(yōu)惠券抵扣金額與套餐金額的一致性校驗。這里尤其要關(guān)注冪等性——用戶因網(wǎng)絡(luò)超時重復(fù)點擊提交系統(tǒng)不能生成兩筆預(yù)約單這種用例在業(yè)務(wù)型公司里非常受重視。兼容性測試方面覆蓋iOS和Android兩大平臺的不同版本、不同屏幕尺寸。考慮到途虎用戶群體里有相當(dāng)一部分是中老年車主低端Android機(jī)和舊版本iOS的兼容性尤為重要不能只測最新機(jī)型。異常場景方面除了常規(guī)的無網(wǎng)絡(luò)、弱網(wǎng)、服務(wù)端異常外我還補充了“門店關(guān)店前30分鐘提交預(yù)約”這種帶業(yè)務(wù)時間屬性的邊界場景以及“保養(yǎng)套餐下架后用戶已提交預(yù)約但尚未確認(rèn)”的狀態(tài)沖突場景。最后我在每個測試分類下面都注明了一條“優(yōu)先級標(biāo)記規(guī)則”P0級用例是阻塞發(fā)布的問題P1級是主流程功能異常P2級是次要功能問題。這能向閱卷人傳遞一個信息——你不是只會列用例而是知道如何把控測試節(jié)奏。3. 實操環(huán)節(jié)模擬與完整解題過程復(fù)盤3.1 模擬一道完整的“優(yōu)惠券使用”綜合題試卷里有一道綜合題把好幾個知識點串在一起了用戶在途虎App選擇“199元小保養(yǎng)套餐”使用一張“滿199減50”優(yōu)惠券下單時應(yīng)付金額為149元但實際支付后賬戶被扣款199元。請分析問題可能出在哪里并設(shè)計驗證方案。這道題我在做的時候沒有急著寫結(jié)論而是先在草稿紙上畫了一條資金鏈路用戶端展示金額→提交訂單時后端計算金額→支付網(wǎng)關(guān)扣款金額→訂單系統(tǒng)記賬金額。任何一環(huán)出現(xiàn)偏差都會導(dǎo)致用戶實付和應(yīng)付不一致。最可能的三個原因我按概率排序一是前端展示與后端計算不一致。前端頁面展示了優(yōu)惠券抵扣后的149元但提交訂單時后端沒有正確匹配優(yōu)惠券或者優(yōu)惠券狀態(tài)異常導(dǎo)致后端計算金額仍為原價199元。判斷方法是抓包看下單接口的請求參數(shù)里有沒有正確攜帶優(yōu)惠券ID再看后端返回的訂單金額。二是優(yōu)惠券在支付環(huán)節(jié)沒生效。有些老系統(tǒng)會把優(yōu)惠分?jǐn)偡旁谥Ц冻晒蟮幕卣{(diào)里處理如果回調(diào)處理異常就會出現(xiàn)“支付時按原價扣款訂單里卻顯示已優(yōu)惠”的情況。這需要查看支付回調(diào)日志和訂單狀態(tài)變更記錄。三是并發(fā)場景下優(yōu)惠券被重復(fù)使用或狀態(tài)未鎖住。比如用戶在其他設(shè)備上已經(jīng)把這張券用了但當(dāng)前設(shè)備頁面未刷新仍然顯示可用。提交訂單時后端發(fā)現(xiàn)券已被用但沒有報錯攔截而是直接走了原價邏輯。這就是典型的“并發(fā)下的狀態(tài)校驗缺失”。設(shè)計驗證方案時我建議先通過接口測試復(fù)現(xiàn)再定位到具體模塊。具體步驟是先準(zhǔn)備一張測試優(yōu)惠券和一個測試賬號分別用“正常領(lǐng)取”“不領(lǐng)取券”“領(lǐng)取券但支付前在另一設(shè)備核銷”三種場景跑一遍下單接口對比返回的應(yīng)付金額是否都是199元。再用數(shù)據(jù)庫直接看優(yōu)惠券表的狀態(tài)和訂單表的實付金額如果券狀態(tài)已是“已核銷”但訂單金額是原價就能基本定位為后端狀態(tài)校驗問題。這道題整體考察的是定位問題的分析能力?；卮饡r要讓閱卷人看到你有“先分模塊、再逐個排除”的思路而不是直接給出一堆可能性。3.2 動手實操用Charles抓包模擬弱網(wǎng)環(huán)境測試筆試?yán)镞€有一道弱網(wǎng)測試的簡答題問的是如何模擬弱網(wǎng)環(huán)境驗證App在2G/3G網(wǎng)絡(luò)下的表現(xiàn)。我在這里提供一個最常用的實操方案用Charles抓包工具模擬弱網(wǎng)這也是移動端測試最基礎(chǔ)的一項技能。打開Charles在菜單欄找到Proxy → Throttle Settings勾選Enable Throttling然后在Throttle Preset里選擇預(yù)設(shè)的網(wǎng)速檔位。如果預(yù)設(shè)中沒有想要的檔位可以手動設(shè)置帶寬、延遲、丟包率等參數(shù)。比如模擬3G網(wǎng)絡(luò)常用的參數(shù)是帶寬780kbps、延遲100ms、丟包率2%模擬弱2G網(wǎng)絡(luò)可以設(shè)置帶寬20kbps、延遲400ms、丟包率5%。設(shè)置完成后手機(jī)連上代理打開途虎App重點觀察以下場景首頁圖片是否懶加載失敗、保養(yǎng)套餐詳情頁是否長時間白屏、預(yù)約提交時是否出現(xiàn)超時彈窗、斷網(wǎng)恢復(fù)后是否有重試機(jī)制。每個場景都要記錄出現(xiàn)問題的頁面和時間點。這里分享一個實測中容易踩的坑很多同學(xué)開了弱網(wǎng)模擬后發(fā)現(xiàn)App完全打不開然后以為是自己配置有問題。實際上是因為Charles默認(rèn)只對HTTP流量生效如果App用的是HTTPS且沒有配置SSL代理就會出現(xiàn)頁面空白。解決辦法是在Charles的SSL Proxying Settings里添加*:443并保證手機(jī)安裝了Charles的CA證書。否則你測出來的“弱網(wǎng)問題”其實只是“證書驗證失敗”不是真實的弱網(wǎng)表現(xiàn)。3.3 自動化測試實操Appium連接模擬器跑通一條業(yè)務(wù)流試卷里自動化相關(guān)題目比重不小其中有一道問的是使用Appium編寫一條自動化腳本的步驟。對于平時只寫過腳本沒跑過真機(jī)的同學(xué)來說這道題容易寫得很虛。我在這里給出一個最小可運行的全流程從配置到代碼大家可以直接照著試。環(huán)境準(zhǔn)備部分需要安裝Node.js、Appium Desktop或命令行版Appium、Android SDK以及一個Android模擬器或真機(jī)。然后用Python寫腳本的話還需要安裝Appium-Python-Client庫。一個最小示例腳本如下from appium.webdriver import Remote from appium.webdriver.common.appiumby import AppiumBy desired_caps { platformName: Android, platformVersion: 12.0, deviceName: emulator-5554, app: /path/to/tuhu.apk, noReset: True, automationName: UiAutomator2 } driver Remote(http://127.0.0.1:4723/wd/hub, desired_caps) # 等待首頁加載 driver.implicitly_wait(10) # 定位“保養(yǎng)”入口并點擊 el driver.find_element(AppiumBy.ID, com.tuhu.auto:id/tab_maintenance) el.click() # 斷言頁面出現(xiàn)“選擇門店”按鈕 assert driver.find_element(AppiumBy.ID, com.tuhu.auto:id/btn_select_store).is_displayed() driver.quit()這段腳本跑通后就可以往里面加斷言、加數(shù)據(jù)參數(shù)化。但筆試?yán)锶绻屇恪霸O(shè)計自動化測試方案”你要展現(xiàn)的就不只是一段代碼而是更完整的框架思維用例分層頁面對象層、業(yè)務(wù)流層、數(shù)據(jù)層、失敗截圖與日志收集、與Jenkins集成做定時任務(wù)、測試報告生成。把這幾塊寫出來才能體現(xiàn)出你具備獨立搭建自動化框架的能力而不只是會調(diào)API。實際工作中自動化腳本維護(hù)成本最高的是元素定位所有App的UI改動都可能導(dǎo)致腳本大面積報錯。所以我在方案里還會建議優(yōu)先使用穩(wěn)定的resource-id定位少用xpath在頁面對象層做元素封裝后續(xù)UI變更時只改一處。4. 高頻考點速查與避坑清單4.1 常見失分點對照表結(jié)合我自己的做題過程以及和幾位同樣參加過途虎筆試的同學(xué)交流復(fù)盤整理了一份高頻失分點表格大家可以對照自查?？键c模塊常見失分點正確做法用例設(shè)計只寫有效等價類漏無效等價類每個非法的獨立條件都要覆蓋一次測試方法選擇看到輸入框就只想到等價類和邊界值根據(jù)需求復(fù)雜度選有多個條件組合用判定表流程類用場景法Linux命令忘記加grep -v grepps aux之后一定過濾grep自身進(jìn)程SQL聚合在HAVING里使用SELECT別名重復(fù)書寫聚合函數(shù)不依賴別名接口測試只關(guān)注狀態(tài)碼不關(guān)注響應(yīng)體內(nèi)容先看響應(yīng)體再看服務(wù)端日志最后看鏈路移動端測試忽略弱網(wǎng)和中斷場景重點覆蓋弱網(wǎng)、斷網(wǎng)、來電、切后臺等中斷場景自動化測試只寫腳本不寫維護(hù)方案補充元素封層、失敗截圖、數(shù)據(jù)驅(qū)動設(shè)計4.2 時間分配建議試卷B總共90分鐘我的實際時間分配是這樣的選擇題和判斷題控制在35分鐘以內(nèi)這些題大部分是概念題想太久反而容易改錯。多選題控制在10分鐘猶豫不決的題先標(biāo)記不要戀戰(zhàn)。簡答題大約25分鐘每題控制在8分鐘左右答到點子上就行不需要長篇大論。最后一道場景設(shè)計大題留20分鐘這部分一定要寫結(jié)構(gòu)化的編號方便閱卷人看出你的思路。4.3 關(guān)于試卷B的一個獨家觀察整套卷子做下來一個很明顯的傾向是——凡是涉及業(yè)務(wù)閉環(huán)的題幾乎沒有一道是“背過就會”的全是需要現(xiàn)場分析場景。這反映出途虎對測試工程師的期望不是“執(zhí)行者”而是“質(zhì)量owner”你不僅要能執(zhí)行測試用例還要能主動分析業(yè)務(wù)邏輯里可能存在的漏洞并對測試結(jié)果負(fù)責(zé)。這一點在最后那道場景設(shè)計題里體現(xiàn)得最充分。設(shè)計用例時除了常規(guī)的功能用例我額外補了一條看似邊緣、實際非常關(guān)鍵的用例“用戶已提交預(yù)約但尚未到店且期間門店修改了營業(yè)時間系統(tǒng)是否會自動推送變更通知”。這種用例在標(biāo)準(zhǔn)測試用例模板里不會出現(xiàn)但真正做過業(yè)務(wù)測試的人會知道這類“狀態(tài)變更通知”場景在真實業(yè)務(wù)中往往就是投訴重災(zāi)區(qū)。5. 一套完整的備考策略與實用建議筆試只是整個秋招流程的其中一環(huán)考完之后還有面試。從試卷B的難度和風(fēng)格來看后續(xù)面試大概率會圍繞“項目經(jīng)歷”和“場景題”展開不太會問特別偏門的概念題。所以備考重心應(yīng)該放在三件事上第一把測試基礎(chǔ)概念吃透到能隨手舉例的程度第二Linux和SQL要達(dá)到“不看文檔能直接寫”的熟練度第三結(jié)合途虎的業(yè)務(wù)形態(tài)提前積累“線上App線下門店”場景的測試經(jīng)驗。關(guān)于第二點我多說一句很多計算機(jī)專業(yè)的同學(xué)平時用Windows比較多Linux命令全靠記憶一到寫命令的時候就會混。我的建議是不要死記硬背在自己電腦上裝個虛擬機(jī)或者用云服務(wù)器搭一個Linux環(huán)境把常用的日志查看、進(jìn)程管理、權(quán)限修改、網(wǎng)絡(luò)排查命令都實際操作一遍兩周時間基本就能形成肌肉記憶。SQL同樣如此沒必要刷特別復(fù)雜的題目就把關(guān)聯(lián)查詢、聚合函數(shù)、子查詢、窗口函數(shù)這幾類吃透。筆試中的SQL基本不會超過這個范圍。關(guān)于第三點坦白說沒有實際項目經(jīng)驗的同學(xué)在這類題目上會比較吃虧。我給出一個可操作的替代方案在工作日晚上打開途虎App把用戶能走的核心路徑都完整走一遍包括注冊、選門店、選套餐、下單、支付、查看訂單詳情、取消訂單、申請退款。每走一步都記錄下可能出現(xiàn)問題的地方然后設(shè)想“如果我是測試會怎么設(shè)計用例來保障這個流程”。這不花太多時間但對理解業(yè)務(wù)型測試的思維模式很有幫助。另外給你一個提升簡歷通過率的小建議如果時間允許可以在GitHub上維護(hù)一個小的測試項目比如把自己寫的接口自動化腳本和測試用例設(shè)計文檔放上去形成“需求分析→用例設(shè)計→腳本實現(xiàn)→測試報告”的完整閉環(huán)。面試官看項目經(jīng)歷時看重的不只是技術(shù)棧更是“你有沒有把一件事做完整的意識”。這套試卷B整體上不難但信息量不小。只要基礎(chǔ)扎實、業(yè)務(wù)場景想得足夠多拿高分并不難。踏踏實實把上面幾個模塊過一遍這套題基本就能穩(wěn)住了。