1. 為什么勸你現(xiàn)在入行軟件測(cè)試先聊點(diǎn)實(shí)在的。這兩年就業(yè)環(huán)境大家心里都有數(shù)很多崗位投了簡(jiǎn)歷石沉大海但軟件測(cè)試這個(gè)方向反而一直有穩(wěn)定的招聘需求。原因很簡(jiǎn)單只要系統(tǒng)還要上線就一定要有人為質(zhì)量把關(guān)。我見過(guò)太多想轉(zhuǎn)行的朋友第一反應(yīng)是去學(xué)編程結(jié)果被 Java、算法、數(shù)據(jù)結(jié)構(gòu)勸退。其實(shí)軟件測(cè)試是一個(gè)性價(jià)比很高的切入點(diǎn)——入行門檻比開發(fā)低但天花板并不低。從功能測(cè)試做起往后可以走自動(dòng)化測(cè)試、性能測(cè)試、測(cè)試開發(fā)薪資空間是逐步拉開的。更重要的是軟件測(cè)試不只是點(diǎn)點(diǎn)點(diǎn)。一個(gè)合格的測(cè)試工程師需要懂業(yè)務(wù)邏輯、懂用例設(shè)計(jì)、懂缺陷管理、懂?dāng)?shù)據(jù)庫(kù)還得會(huì)寫自動(dòng)化腳本。這套技能組合恰恰是很多半路出家的人通過(guò)系統(tǒng)學(xué)習(xí)能夠掌握的。還有一點(diǎn)值得注意AI 時(shí)代測(cè)試崗位沒有消失反而在升級(jí)。現(xiàn)在的企業(yè)招測(cè)試越來(lái)越多要求懂接口測(cè)試、懂自動(dòng)化框架、懂持續(xù)集成。那些只會(huì)手工點(diǎn)頁(yè)面的測(cè)試員確實(shí)在被淘汰但掌握系統(tǒng)方法論的測(cè)試工程師議價(jià)能力在變強(qiáng)。所以如果你正在猶豫要不要入行我的建議是先別管天賦先把路數(shù)走對(duì)。這篇教程就是按照零基礎(chǔ)可執(zhí)行的標(biāo)準(zhǔn)來(lái)寫的把軟件測(cè)試基礎(chǔ)、測(cè)試流程、用例設(shè)計(jì)、項(xiàng)目實(shí)戰(zhàn)、面試準(zhǔn)備串成一條完整的學(xué)習(xí)鏈路7天時(shí)間足夠你入門后面能不能就業(yè)看的是你能不能堅(jiān)持把項(xiàng)目做透。2. 軟件測(cè)試到底是什么先建立正確的認(rèn)知框架2.1 從“找 Bug”說(shuō)起很多人對(duì)軟件測(cè)試的理解就是“幫開發(fā)找 Bug”這個(gè)理解沒錯(cuò)但太淺了。找 Bug 只是測(cè)試工作的表象測(cè)試的本質(zhì)是質(zhì)量保障。一個(gè)測(cè)試工程師的核心價(jià)值不是“挑毛病”而是通過(guò)系統(tǒng)化的手段讓團(tuán)隊(duì)在交付前對(duì)軟件質(zhì)量有足夠的信心。這句話等你真正進(jìn)入項(xiàng)目組之后會(huì)深有體會(huì)。從定義上講軟件測(cè)試是在規(guī)定的條件下對(duì)程序進(jìn)行操作以發(fā)現(xiàn)程序錯(cuò)誤、衡量軟件質(zhì)量并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過(guò)程。這里面有幾個(gè)關(guān)鍵詞規(guī)定的條件測(cè)試不是隨機(jī)亂點(diǎn)需要在特定環(huán)境、特定數(shù)據(jù)、特定步驟下進(jìn)行。發(fā)現(xiàn)錯(cuò)誤測(cè)試的 immediate 目標(biāo)是暴露問(wèn)題而不是證明程序沒問(wèn)題。衡量質(zhì)量通過(guò)測(cè)試結(jié)果量化評(píng)估軟件的功能、性能、兼容性、安全性等維度。評(píng)估是否滿足設(shè)計(jì)驗(yàn)證軟件是否符合需求文檔和驗(yàn)收標(biāo)準(zhǔn)。新手最容易犯的錯(cuò)誤是把測(cè)試當(dāng)成“隨意用用”。正規(guī)的測(cè)試工作從需求評(píng)審就開始了不是等開發(fā)把代碼寫完了才介入。2.2 軟件測(cè)試的分類軟件測(cè)試的分類方式很多新手不需要一次背完但常用的幾組分類一定要分清按階段劃分階段說(shuō)明執(zhí)行角色單元測(cè)試針對(duì)代碼最小單元函數(shù)、方法進(jìn)行驗(yàn)證開發(fā)人員為主集成測(cè)試驗(yàn)證模塊與模塊之間的接口和交互測(cè)試人員配合開發(fā)系統(tǒng)測(cè)試對(duì)整個(gè)系統(tǒng)進(jìn)行全流程驗(yàn)證測(cè)試人員主導(dǎo)驗(yàn)收測(cè)試由用戶或業(yè)務(wù)方確認(rèn)系統(tǒng)是否滿足需求用戶/業(yè)務(wù) 測(cè)試按是否運(yùn)行程序劃分靜態(tài)測(cè)試不運(yùn)行程序通過(guò)代碼審查、文檔評(píng)審發(fā)現(xiàn)缺陷比如 Alibaba 的 Java 開發(fā)規(guī)范掃描就屬于靜態(tài)分析。動(dòng)態(tài)測(cè)試運(yùn)行程序并輸入數(shù)據(jù)通過(guò)實(shí)際執(zhí)行來(lái)發(fā)現(xiàn)缺陷。按技術(shù)手段劃分黑盒測(cè)試把軟件當(dāng)成黑盒子不關(guān)心內(nèi)部實(shí)現(xiàn)只關(guān)注輸入和輸出是否符合預(yù)期。功能測(cè)試大部分屬于黑盒。白盒測(cè)試關(guān)注代碼內(nèi)部邏輯、分支覆蓋、路徑覆蓋通常需要閱讀代碼。灰盒測(cè)試介于黑白之間既關(guān)注外部功能也關(guān)注部分內(nèi)部邏輯接口測(cè)試通常屬于灰盒。按執(zhí)行方式劃分手工測(cè)試測(cè)試人員手動(dòng)執(zhí)行用例適合探索性測(cè)試、UI 測(cè)試。自動(dòng)化測(cè)試通過(guò)腳本或工具自動(dòng)執(zhí)行用例適合回歸測(cè)試、性能測(cè)試。半自動(dòng)化測(cè)試部分環(huán)節(jié)自動(dòng)化部分依賴人工確認(rèn)。2.3 常見的測(cè)試類型除了按階段和手段劃分還有一組按測(cè)試目標(biāo)劃分的類型面試時(shí)非常愛考功能測(cè)試驗(yàn)證系統(tǒng)功能是否符合需求是測(cè)試工作的核心。性能測(cè)試驗(yàn)證系統(tǒng)在高并發(fā)、高負(fù)載下的響應(yīng)時(shí)間、吞吐量、資源占用包含負(fù)載測(cè)試、壓力測(cè)試、穩(wěn)定性測(cè)試。兼容性測(cè)試驗(yàn)證軟件在不同操作系統(tǒng)、瀏覽器、設(shè)備、分辨率下的表現(xiàn)。安全測(cè)試驗(yàn)證系統(tǒng)的身份認(rèn)證、授權(quán)、數(shù)據(jù)加密、防 SQL 注入、防 XSS 等安全能力。易用性測(cè)試從用戶角度評(píng)估軟件是否易學(xué)、易用、操作是否符合直覺?？煽啃詼y(cè)試驗(yàn)證系統(tǒng)在特定條件下的穩(wěn)定運(yùn)行能力比如長(zhǎng)時(shí)間不宕機(jī)?；貧w測(cè)試在代碼修改后重新執(zhí)行原有用例確保修改沒有引入新缺陷。冒煙測(cè)試在版本提測(cè)后先快速驗(yàn)證主流程是否暢通如果冒煙不通過(guò)直接打回開發(fā)修復(fù)。2.4 軟件測(cè)試的原則面試和實(shí)際工作中有幾句經(jīng)典原則你需要刻在腦子里測(cè)試證明軟件存在缺陷不能證明軟件沒有缺陷——哪怕測(cè)試全部通過(guò)也不代表程序絕對(duì)正確。窮盡測(cè)試是不可能的——輸入數(shù)據(jù)、路徑組合幾乎是無(wú)限的測(cè)試一定要基于風(fēng)險(xiǎn)來(lái)取舍。測(cè)試應(yīng)盡早介入——缺陷發(fā)現(xiàn)得越晚修復(fù)成本越高。需求階段的一個(gè)理解偏差可能到上線后要花幾十倍代價(jià)才能彌補(bǔ)。缺陷具有集群性——二八原則在測(cè)試中同樣成立往往 80% 的問(wèn)題集中在 20% 的模塊里重點(diǎn)模塊要重點(diǎn)測(cè)。測(cè)試活動(dòng)要基于用戶視角——測(cè)試的最終標(biāo)準(zhǔn)是用戶是否滿意不是開發(fā)是否覺得“自己代碼沒問(wèn)題”。殺蟲劑悖論——同一個(gè)測(cè)試用例反復(fù)執(zhí)行發(fā)現(xiàn)缺陷的能力會(huì)逐漸下降需要不斷更新維護(hù)用例。這些原則不只是理論知識(shí)它們會(huì)直接影響你怎么設(shè)計(jì)用例、怎么分配測(cè)試時(shí)間、怎么跟開發(fā)溝通。3. 軟件測(cè)試流程一個(gè)完整項(xiàng)目的測(cè)試是怎么跑的3.1 測(cè)試流程全景圖先看一張簡(jiǎn)化的流程圖文字版需求評(píng)審 → 測(cè)試計(jì)劃 → 測(cè)試設(shè)計(jì) → 測(cè)試執(zhí)行 → 缺陷管理 → 測(cè)試報(bào)告 → 上線驗(yàn)證這個(gè)流程不是固定的不同公司會(huì)根據(jù)項(xiàng)目規(guī)模裁剪但核心環(huán)節(jié)基本一致。下面逐個(gè)拆解。3.2 需求評(píng)審階段測(cè)試人員在需求評(píng)審階段就要介入而不是等開發(fā)提測(cè)了才開始看需求。需求評(píng)審階段測(cè)試要做什么理解業(yè)務(wù)背景和用戶場(chǎng)景。確認(rèn)需求是否完整、可測(cè)。識(shí)別需求中的歧義和矛盾點(diǎn)。評(píng)估測(cè)試范圍和工作量。提出補(bǔ)充建議比如某些異常場(chǎng)景在需求文檔里沒有定義。新手常見誤區(qū)認(rèn)為需求評(píng)審是產(chǎn)品和開發(fā)的事自己只要等著執(zhí)行就行。實(shí)際上需求評(píng)審是你理解業(yè)務(wù)的黃金窗口很多深層的測(cè)試思路都來(lái)自這個(gè)階段。3.3 測(cè)試計(jì)劃階段測(cè)試計(jì)劃的核心產(chǎn)出是一份測(cè)試計(jì)劃文檔內(nèi)容包括測(cè)試范圍測(cè)什么、不測(cè)什么。測(cè)試策略功能測(cè)試為主還是需要接口測(cè)試、性能測(cè)試、兼容性測(cè)試。資源安排誰(shuí)來(lái)測(cè)、需要什么環(huán)境、什么工具。時(shí)間節(jié)點(diǎn)提測(cè)時(shí)間、首輪測(cè)試完成時(shí)間、回歸完成時(shí)間。風(fēng)險(xiǎn)與應(yīng)對(duì)比如開發(fā)延期、環(huán)境不穩(wěn)定、測(cè)試數(shù)據(jù)缺失。對(duì)新手來(lái)說(shuō)寫測(cè)試計(jì)劃可能有點(diǎn)虛但至少要能回答三個(gè)問(wèn)題測(cè)什么、怎么測(cè)、什么時(shí)候測(cè)完。3.4 測(cè)試設(shè)計(jì)與用例編寫階段這是測(cè)試工作的核心環(huán)節(jié)也是新手最需要花時(shí)間打磨的地方。測(cè)試設(shè)計(jì)的產(chǎn)出是測(cè)試用例也就是一份詳細(xì)說(shuō)明“如何執(zhí)行測(cè)試”的文檔。一個(gè)標(biāo)準(zhǔn)的測(cè)試用例包含字段說(shuō)明示例用例編號(hào)唯一標(biāo)識(shí)TC-LOGIN-001所屬模塊用例歸屬的功能模塊登錄模塊用例標(biāo)題一句話描述測(cè)試場(chǎng)景驗(yàn)證正確用戶名密碼可以登錄前置條件執(zhí)行用例前需要滿足的條件用戶已注冊(cè)系統(tǒng)已部署測(cè)試步驟一步步執(zhí)行的操作1. 打開登錄頁(yè) 2. 輸入用戶名 3. 輸入密碼 4. 點(diǎn)擊登錄測(cè)試數(shù)據(jù)輸入的具體數(shù)據(jù)用戶名admin密碼123456預(yù)期結(jié)果測(cè)試通過(guò)的標(biāo)準(zhǔn)登錄成功跳轉(zhuǎn)首頁(yè)顯示用戶昵稱優(yōu)先級(jí)用例的重要程度P0 / P1 / P2實(shí)際結(jié)果執(zhí)行后的真實(shí)表現(xiàn)待填寫測(cè)試狀態(tài)通過(guò)/失敗/阻塞待執(zhí)行3.5 測(cè)試執(zhí)行階段測(cè)試執(zhí)行不是簡(jiǎn)單跑一遍用例就完事需要注意按優(yōu)先級(jí)執(zhí)行先跑 P0 用例保證核心流程沒問(wèn)題再逐步擴(kuò)大范圍。記錄實(shí)際結(jié)果每個(gè)用例執(zhí)行后要填寫實(shí)際結(jié)果失敗的要關(guān)聯(lián)缺陷。探索式測(cè)試除了按用例執(zhí)行還要結(jié)合業(yè)務(wù)理解進(jìn)行探索發(fā)現(xiàn)用例之外的缺陷。回歸測(cè)試開發(fā)修復(fù)缺陷后要重新執(zhí)行相關(guān)用例同時(shí)關(guān)注修改的代碼是否影響了其他功能。3.6 缺陷管理階段缺陷Bug是測(cè)試人員最重要的產(chǎn)出物之一。一個(gè)規(guī)范的缺陷報(bào)告至少要包含缺陷標(biāo)題簡(jiǎn)潔描述問(wèn)題。缺陷優(yōu)先級(jí)/嚴(yán)重程度緊急、高、中、低。復(fù)現(xiàn)步驟能讓他人按步驟復(fù)現(xiàn)問(wèn)題。實(shí)際結(jié)果與預(yù)期結(jié)果一目了然。環(huán)境信息操作系統(tǒng)、瀏覽器、版本號(hào)。附件截圖、日志、錄屏。好的缺陷報(bào)告能顯著降低開發(fā)和測(cè)試的溝通成本。很多新手寫的 Bug 描述含糊不清比如“頁(yè)面打不開”“數(shù)據(jù)不對(duì)”這類缺陷會(huì)被開發(fā)直接打回。3.7 測(cè)試報(bào)告與上線驗(yàn)證測(cè)試執(zhí)行結(jié)束后需要輸出測(cè)試報(bào)告總結(jié)測(cè)試的通過(guò)率、遺留缺陷、風(fēng)險(xiǎn)項(xiàng)并給出是否可以上線的結(jié)論。系統(tǒng)上線后測(cè)試人員還需要進(jìn)行線上冒煙驗(yàn)證確認(rèn)核心流程在真實(shí)環(huán)境中工作正常。這個(gè)環(huán)節(jié)很容易被忽略但非常重要——本地環(huán)境和線上環(huán)境往往存在差異代碼包部署問(wèn)題、配置問(wèn)題可能只在線上暴露。4. 測(cè)試用例設(shè)計(jì)方法從“瞎點(diǎn)”到“系統(tǒng)測(cè)”4.1 為什么不能用“瞎點(diǎn)”代替用例設(shè)計(jì)很多零基礎(chǔ)的朋友覺得測(cè)試就是打開軟件到處點(diǎn)點(diǎn)什么出問(wèn)題就是發(fā)現(xiàn)了 Bug。這種想法在小型 demo 里似乎有用一旦面對(duì)真實(shí)項(xiàng)目系統(tǒng)有幾十個(gè)功能、上百個(gè)字段、復(fù)雜的業(yè)務(wù)規(guī)則“瞎點(diǎn)”只會(huì)導(dǎo)致兩種情況大量重復(fù)勞動(dòng)每次測(cè)試都是隨機(jī)探索無(wú)法形成可回歸的資產(chǎn)。漏測(cè)嚴(yán)重測(cè)試覆蓋主要依賴個(gè)人經(jīng)驗(yàn)沒有系統(tǒng)方法很難覆蓋全面。測(cè)試用例設(shè)計(jì)方法論就是解決“怎么測(cè)才全面”的問(wèn)題。4.2 等價(jià)類劃分法核心思想把輸入數(shù)據(jù)劃分成若干等價(jià)類每個(gè)等價(jià)類中的數(shù)據(jù)對(duì)測(cè)試目的來(lái)說(shuō)是等效的只要從每個(gè)等價(jià)類中取一個(gè)代表值就能代表該類別的情況。等價(jià)類分為有效等價(jià)類滿足需求規(guī)則的輸入。無(wú)效等價(jià)類不滿足需求規(guī)則的輸入。示例用戶名長(zhǎng)度要求為 6~18 位。有效等價(jià)類長(zhǎng)度在 6 到 18 位之間的字符串比如test123。無(wú)效等價(jià)類長(zhǎng)度小于 6 位的字符串如abc長(zhǎng)度大于 18 位的字符串如 19 個(gè)a。測(cè)試時(shí)有效等價(jià)類測(cè)一個(gè)每個(gè)無(wú)效等價(jià)類分別測(cè)一次因?yàn)椴煌臒o(wú)效輸入可能對(duì)應(yīng)不同的錯(cuò)誤提示。4.3 邊界值分析法核心思想大量的缺陷往往發(fā)生在輸入的邊界附近比如最大長(zhǎng)度、最小值、臨界值。示例用戶名長(zhǎng)度要求為 6~18 位。邊界值5、6、7、17、18、19。5小于最小值、6最小值、7大于最小值、17小于最大值、18最大值、19大于最大值。邊界值分析法是等價(jià)類劃分法的有力補(bǔ)充兩者通常配合使用。4.4 判定表法核心思想適合處理多種條件組合的場(chǎng)景。通過(guò)列出所有條件及其取值組合得到完整的測(cè)試組合。示例登錄功能的條件包括“用戶名是否正確”和“密碼是否正確”組合出四種情況用戶名正確密碼正確預(yù)期結(jié)果是是登錄成功是否提示密碼錯(cuò)誤否是提示用戶名錯(cuò)誤否否提示用戶名或密碼錯(cuò)誤當(dāng)條件和動(dòng)作較多時(shí)判定表能幫助你系統(tǒng)化地覆蓋所有組合而不是憑感覺挑幾個(gè)來(lái)測(cè)。4.5 場(chǎng)景法核心思想從用戶的實(shí)際使用場(chǎng)景出發(fā)模擬用戶完成一個(gè)完整的業(yè)務(wù)操作流程。示例購(gòu)物流程的場(chǎng)景包括基本流用戶登錄 → 瀏覽商品 → 加入購(gòu)物車 → 提交訂單 → 支付 → 收貨。備選流購(gòu)物車商品庫(kù)存不足支付超時(shí)優(yōu)惠券已過(guò)期。場(chǎng)景法特別適合做集成測(cè)試和端到端測(cè)試能發(fā)現(xiàn)模塊間銜接時(shí)的缺陷。4.6 錯(cuò)誤推測(cè)法核心思想基于測(cè)試人員的經(jīng)驗(yàn)和直覺推測(cè)程序可能在哪類地方出錯(cuò)針對(duì)性地設(shè)計(jì)用例。比如輸入框可能出現(xiàn)空值、超長(zhǎng)字符、特殊字符、SQL 注入語(yǔ)句、XSS 腳本上傳功能可能出現(xiàn)超大文件、空文件、非指定格式的文件、文件名超長(zhǎng)、并發(fā)上傳。錯(cuò)誤推測(cè)法沒有固定的公式更多依賴經(jīng)驗(yàn)積累。新手可以多參考 Bug 庫(kù)和線上故障案例來(lái)提升直覺。5. 七天學(xué)習(xí)路線圖零基礎(chǔ)到項(xiàng)目實(shí)戰(zhàn)5.1 整體規(guī)劃說(shuō)明先說(shuō)明一下“7天學(xué)會(huì)軟件測(cè)試”不是說(shuō) 7 天之后你就是資深測(cè)試專家而是通過(guò) 7 天的高強(qiáng)度系統(tǒng)學(xué)習(xí)建立起完整的知識(shí)框架掌握核心技能完成一個(gè)可以寫進(jìn)簡(jiǎn)歷的實(shí)戰(zhàn)項(xiàng)目達(dá)到初級(jí)測(cè)試工程師/實(shí)習(xí)測(cè)試工程師的入門水位。建議每天投入5~6 小時(shí)中斷時(shí)間不要太長(zhǎng)保持學(xué)習(xí)節(jié)奏。5.2 Day 1軟件測(cè)試基礎(chǔ)概念與流程學(xué)習(xí)目標(biāo)理解軟件測(cè)試的定義、目的和原則。掌握測(cè)試的分類階段、手段、目標(biāo)。理解軟件測(cè)試的完整流程。學(xué)習(xí)任務(wù)閱讀本文第 2 節(jié)和第 3 節(jié)的內(nèi)容。獨(dú)立畫一張軟件測(cè)試流程圖手寫或用畫圖工具。搜索 3 個(gè)真實(shí)的軟件缺陷案例如某 App 的線上故障分析它們屬于哪個(gè)測(cè)試環(huán)節(jié)沒做到位。5.3 Day 2測(cè)試用例設(shè)計(jì)方法與文檔編寫學(xué)習(xí)目標(biāo)掌握等價(jià)類、邊界值、判定表、場(chǎng)景法、錯(cuò)誤推測(cè)法。能獨(dú)立編寫標(biāo)準(zhǔn)格式的測(cè)試用例。學(xué)習(xí)任務(wù)針對(duì)一個(gè)“用戶注冊(cè)”功能用等價(jià)類和邊界值設(shè)計(jì)至少 20 條用例。用 Excel 或在線表格整理成標(biāo)準(zhǔn)測(cè)試用例文檔。這里有兩條用例供你參考用例編號(hào)模塊標(biāo)題前置條件測(cè)試步驟測(cè)試數(shù)據(jù)預(yù)期結(jié)果優(yōu)先級(jí)TC-REG-001注冊(cè)驗(yàn)證手機(jī)號(hào)格式不合法時(shí)提示錯(cuò)誤打開注冊(cè)頁(yè)面1. 輸入手機(jī)號(hào) 2. 輸入密碼 3. 點(diǎn)擊注冊(cè)手機(jī)號(hào)12345提示“手機(jī)號(hào)格式不正確”P1TC-REG-002注冊(cè)驗(yàn)證密碼為空時(shí)提示錯(cuò)誤打開注冊(cè)頁(yè)面1. 輸入手機(jī)號(hào) 2. 密碼留空 3. 點(diǎn)擊注冊(cè)手機(jī)號(hào)13800138000密碼空提示“請(qǐng)輸入密碼”P15.4 Day 3測(cè)試環(huán)境搭建與工具使用學(xué)習(xí)目標(biāo)能獨(dú)立完成測(cè)試環(huán)境的搭建。掌握常用的測(cè)試工具。推薦做三件事安裝 VMware 或 VirtualBox創(chuàng)建一個(gè) Windows 虛擬機(jī)用于搭建純凈測(cè)試環(huán)境。安裝禪道或 Jira學(xué)習(xí)缺陷管理流程。禪道是國(guó)產(chǎn)開源工具對(duì)新手更友好下載安裝后自己創(chuàng)建一個(gè)項(xiàng)目提交幾條測(cè)試缺陷體驗(yàn)完整的跟蹤流程。安裝 Postman學(xué)習(xí)接口測(cè)試基礎(chǔ)。錄入一個(gè)公開 API 接口發(fā)送 GET/POST 請(qǐng)求查看響應(yīng)。5.5 Day 4數(shù)據(jù)庫(kù)與 Linux 基礎(chǔ)軟件測(cè)試人員不一定要會(huì)寫復(fù)雜的 SQL但必須掌握基本的數(shù)據(jù)庫(kù)查詢能力因?yàn)闇y(cè)試過(guò)程中經(jīng)常需要驗(yàn)證數(shù)據(jù)是否入庫(kù)。構(gòu)造測(cè)試數(shù)據(jù)。清理臟數(shù)據(jù)。需要掌握的 MySQL 基礎(chǔ)包括-- 查詢用戶表 SELECT * FROM user; -- 條件查詢 SELECT username, phone FROM user WHERE status 1; -- 模糊查詢 SELECT * FROM order WHERE order_no LIKE 2026%; -- 統(tǒng)計(jì)查詢 SELECT COUNT(*) FROM user WHERE register_time 2026-01-01;同時(shí)Linux 基礎(chǔ)命令也要過(guò)一遍特別是日志查看# 動(dòng)態(tài)查看日志 tail -f /opt/logs/app.log # 查看最近100行日志 tail -100 /opt/logs/app.log # 在日志中搜索關(guān)鍵字 grep ERROR /opt/logs/app.log # 查看端口占用 netstat -tlnp | grep 8080這些技能在排查 Bug、定位問(wèn)題時(shí)非常實(shí)用。5.6 Day 5接口測(cè)試與 Postman 實(shí)戰(zhàn)接口測(cè)試是當(dāng)前測(cè)試崗位面試的高頻考點(diǎn)。為什么重要因?yàn)楝F(xiàn)在的前后端分離架構(gòu)下很多功能問(wèn)題在接口層就能被提前發(fā)現(xiàn)等到 UI 層再去測(cè)成本已經(jīng)高了。用 Postman 請(qǐng)求一個(gè)公開測(cè)試接口的完整流程打開 Postman點(diǎn)擊“New Collection”命名為“Demo API”。點(diǎn)擊“Add Request”命名為“獲取用戶信息”。選擇請(qǐng)求方法為 GET輸入接口地址例如https://jsonplaceholder.typicode.com/users/1。點(diǎn)擊“Send”查看響應(yīng)結(jié)果。響應(yīng)應(yīng)該是一個(gè) JSON 格式的用戶數(shù)據(jù)。你再試試修改請(qǐng)求方式為 POST發(fā)送https://jsonplaceholder.typicode.com/posts并添加 JSON Body體驗(yàn)接口測(cè)試的完整流程。接口測(cè)試的核心檢查點(diǎn)包括狀態(tài)碼200 表示成功404 表示資源不存在500 表示服務(wù)器異常。響應(yīng)體返回的 JSON 結(jié)構(gòu)是否符合接口文檔。業(yè)務(wù)字段關(guān)鍵字段是否在預(yù)期取值范圍。響應(yīng)時(shí)間是否超過(guò)預(yù)期閾值。5.7 Day 6項(xiàng)目實(shí)戰(zhàn)——登錄功能全流程測(cè)試這一天要真正跑一個(gè)完整的項(xiàng)目測(cè)試流程。建議找一個(gè)開源項(xiàng)目或者自己搭一個(gè)簡(jiǎn)單的 Web 系統(tǒng)。下面是一個(gè)用 Python Flask 寫的簡(jiǎn)易登錄系統(tǒng)可作為測(cè)試對(duì)象# 文件路徑app.py from flask import Flask, request, jsonify app Flask(__name__) # 模擬用戶數(shù)據(jù) users { admin: 123456, test: abc123 } app.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username, ) password data.get(password, ) if not username or not password: return jsonify({code: 400, msg: 用戶名和密碼不能為空}), 400 if username in users and users[username] password: return jsonify({code: 200, msg: 登錄成功}), 200 else: return jsonify({code: 401, msg: 用戶名或密碼錯(cuò)誤}), 401 if __name__ __main__: app.run(host0.0.0.0, port5000)運(yùn)行項(xiàng)目pip install flask python app.py此時(shí)訪問(wèn)http://localhost:5000/login即可。針對(duì)這個(gè)登錄接口你需要完成以下任務(wù)閱讀接口邏輯理解功能規(guī)則。設(shè)計(jì)測(cè)試用例正確用戶名和密碼 → 登錄成功。用戶名錯(cuò)誤 → 提示錯(cuò)誤。密碼錯(cuò)誤 → 提示錯(cuò)誤。用戶名為空 → 提示不能為空。密碼為空 → 提示不能為空。用戶名不存在 → 提示錯(cuò)誤。發(fā)送非 JSON 格式請(qǐng)求 → 看系統(tǒng)反應(yīng)。用 Postman 執(zhí)行以上用例記錄實(shí)際結(jié)果。接著編寫 Python 自動(dòng)化測(cè)試腳本用 unittest 或 requests 庫(kù)# 文件路徑test_login.py import requests import unittest class TestLogin(unittest.TestCase): BASE_URL http://localhost:5000/login def test_login_success(self): payload {username: admin, password: 123456} resp requests.post(self.BASE_URL, jsonpayload) self.assertEqual(resp.status_code, 200) self.assertEqual(resp.json()[code], 200) def test_login_wrong_password(self): payload {username: admin, password: wrong} resp requests.post(self.BASE_URL, jsonpayload) self.assertEqual(resp.status_code, 401) def test_login_empty_username(self): payload {username: , password: 123456} resp requests.post(self.BASE_URL, jsonpayload) self.assertEqual(resp.status_code, 400) if __name__ __main__: unittest.main()運(yùn)行自動(dòng)化腳本python -m unittest test_login.py預(yù)期輸出類似... ---------------------------------------------------------------------- Ran 3 tests in 0.045s OK多設(shè)計(jì)一些用例并跑通再把結(jié)果整理到測(cè)試報(bào)告中。這個(gè)項(xiàng)目就可以寫入簡(jiǎn)歷。5.8 Day 7整理簡(jiǎn)歷與面試準(zhǔn)備最后一天重點(diǎn)做三件事整理項(xiàng)目經(jīng)驗(yàn)把登錄功能測(cè)試項(xiàng)目寫進(jìn)簡(jiǎn)歷重點(diǎn)寫清楚你負(fù)責(zé)的測(cè)試范圍、設(shè)計(jì)了多少條用例、發(fā)現(xiàn)了什么缺陷、是否用自動(dòng)化腳本執(zhí)行了回歸。刷面試題軟件測(cè)試面試的高頻題包括什么是軟件測(cè)試它的目的是什么黑盒測(cè)試和白盒測(cè)試的區(qū)別測(cè)試用例設(shè)計(jì)方法有哪些如何編寫高質(zhì)量的缺陷報(bào)告接口測(cè)試的核心內(nèi)容是什么一個(gè)登錄功能你怎么測(cè)自動(dòng)化測(cè)試和手工測(cè)試怎么選如果開發(fā)不認(rèn)為你提的 Bug 是 Bug你怎么處理模擬面試自己對(duì)著鏡子講一遍項(xiàng)目或者找個(gè)朋友扮演面試官提問(wèn)。6. 零基礎(chǔ)常見誤區(qū)與避坑建議6.1 誤區(qū)一軟件測(cè)試就是“點(diǎn)點(diǎn)點(diǎn)”這是最大的誤解。單純手工點(diǎn)擊是測(cè)試最基礎(chǔ)的形態(tài)但企業(yè)真正需要的是能設(shè)計(jì)用例、分析缺陷、沉淀自動(dòng)化腳本、推動(dòng)質(zhì)量改進(jìn)的測(cè)試工程師。如果你只是機(jī)械地點(diǎn)鼠標(biāo)既沒有方法也沒有產(chǎn)出很容易被淘汰。正確做法從第一天就建立“測(cè)試設(shè)計(jì)”的意識(shí)每測(cè)一個(gè)功能先問(wèn)自己需求規(guī)則是什么重點(diǎn)場(chǎng)景有哪些邊界條件在哪里怎么用最少的用例覆蓋最多的場(chǎng)景6.2 誤區(qū)二只學(xué)工具不學(xué)理論很多新手急著學(xué) LoadRunner、Selenium、JMeter以為學(xué)會(huì)工具就能找到工作。工具只是術(shù)測(cè)試設(shè)計(jì)、缺陷分析、業(yè)務(wù)理解才是道。工具可以短時(shí)間內(nèi)學(xué)會(huì)但測(cè)試思維的建立需要系統(tǒng)的學(xué)習(xí)和練習(xí)。正確做法先掌握測(cè)試流程和用例設(shè)計(jì)方法再選擇一個(gè)工具深挖做到“會(huì)用”并“懂原理”。6.3 誤區(qū)三忽視業(yè)務(wù)理解有些測(cè)試人員技術(shù)能力不錯(cuò)但對(duì)業(yè)務(wù)一知半解測(cè)試過(guò)程中經(jīng)常提出“邏輯正確但業(yè)務(wù)不合理”的用例甚至漏掉關(guān)鍵業(yè)務(wù)場(chǎng)景。在銀行、醫(yī)療、電商這些業(yè)務(wù)復(fù)雜的行業(yè)業(yè)務(wù)理解能力往往是測(cè)試人員的核心競(jìng)爭(zhēng)力。正確做法測(cè)試前認(rèn)真閱讀需求文檔參加需求評(píng)審遇到不理解的地方主動(dòng)問(wèn)產(chǎn)品經(jīng)理不要帶病執(zhí)行。6.4 誤區(qū)四不重視缺陷描述“這個(gè)頁(yè)面有問(wèn)題”“點(diǎn)了一下就報(bào)錯(cuò)了”這類缺陷描述在真實(shí)項(xiàng)目中會(huì)被開發(fā)拒收。一個(gè)規(guī)范的缺陷描述要能讓開發(fā)按步驟復(fù)現(xiàn)、快速定位。正確做法提交缺陷前先問(wèn)自己——如果我是一個(gè)不了解這個(gè)功能的開發(fā)看這條缺陷能否看懂步驟是否完整預(yù)期結(jié)果是否寫清楚是否附上了截圖和日志6.5 誤區(qū)五簡(jiǎn)歷里堆砌“精通”有些零基礎(chǔ)求職者在簡(jiǎn)歷上寫“精通 Selenium、精通性能測(cè)試”結(jié)果面試時(shí)一問(wèn)三不知反而減分。正確做法如實(shí)地寫“了解”“熟悉”“掌握”。簡(jiǎn)歷可以包裝但不能造假面試官幾輪追問(wèn)就能測(cè)試出真實(shí)水平。把登錄測(cè)試項(xiàng)目做透、能講清楚設(shè)計(jì)思路和缺陷分析遠(yuǎn)比堆砌工具名詞更有說(shuō)服力。7. 軟件測(cè)試面試高頻題與答題思路7.1 概念類問(wèn)題問(wèn)說(shuō)說(shuō)什么是軟件測(cè)試。答軟件測(cè)試是在規(guī)定的條件下對(duì)程序進(jìn)行操作以發(fā)現(xiàn)程序錯(cuò)誤、衡量軟件質(zhì)量并評(píng)估它是否能滿足設(shè)計(jì)要求的過(guò)程。它不僅僅是找 Bug更是質(zhì)量保障的重要手段貫穿需求評(píng)審到上線驗(yàn)證的全過(guò)程。問(wèn)說(shuō)說(shuō)黑盒測(cè)試和白盒測(cè)試的區(qū)別。答黑盒測(cè)試不關(guān)注內(nèi)部實(shí)現(xiàn)只驗(yàn)證輸入輸出是否符合預(yù)期功能測(cè)試通常是黑盒白盒測(cè)試需要理解代碼邏輯驗(yàn)證分支、路徑、條件覆蓋單元測(cè)試通常是白盒。實(shí)際項(xiàng)目中兩者往往結(jié)合使用。7.2 用例設(shè)計(jì)類問(wèn)題問(wèn)一個(gè)登錄功能你怎么測(cè)試答題思路不要只答“輸入正確的用戶名密碼能登錄”。要分維度回答功能維度正確登錄、錯(cuò)誤密碼、錯(cuò)誤用戶名、用戶名為空、密碼為空、用戶名不存在、密碼鎖定策略、記住密碼。界面維度密碼是否密文顯示、輸入框長(zhǎng)度限制、是否支持回車提交、Tab 鍵切換。安全維度SQL 注入、XSS 腳本、密碼傳輸是否加密、驗(yàn)證碼。兼容性維度不同瀏覽器、不同操作系統(tǒng)、不同分辨率。性能維度多人同時(shí)登錄、登錄響應(yīng)時(shí)間。7.3 缺陷管理類問(wèn)題問(wèn)如果開發(fā)不認(rèn)為你提的 Bug 是 Bug你怎么處理答題思路這是一個(gè)考察溝通能力和原則性的經(jīng)典題。建議回答先自查確認(rèn)缺陷描述是否清晰、復(fù)現(xiàn)步驟是否完整。對(duì)照需求文檔和設(shè)計(jì)文檔找到判定依據(jù)。如果需求本身存在歧義拉產(chǎn)品經(jīng)理一起確認(rèn)。若確認(rèn)是缺陷堅(jiān)持測(cè)試原則同時(shí)以合作的態(tài)度溝通而不是對(duì)抗。7.4 自動(dòng)化測(cè)試類問(wèn)題問(wèn)自動(dòng)化測(cè)試能完全替代手工測(cè)試嗎答不能。自動(dòng)化測(cè)試適合穩(wěn)定、重復(fù)、可回歸的場(chǎng)景比如核心流程回歸、接口測(cè)試、性能測(cè)試。但探索性測(cè)試、UI 易用性評(píng)估、復(fù)雜業(yè)務(wù)場(chǎng)景的判斷仍然需要測(cè)試人員手動(dòng)介入。自動(dòng)化的核心價(jià)值是提升回歸效率而不是取代測(cè)試思維。8. 軟件測(cè)試學(xué)習(xí)資源推薦方向8.1 經(jīng)典書籍方向《軟件測(cè)試的藝術(shù)》經(jīng)典入門書篇幅不大兩天能讀完幫你建立軟件測(cè)試的整體認(rèn)知?！盾浖y(cè)試》Ron Patton 版適合零基礎(chǔ)案例豐富通俗易懂。《單元測(cè)試的藝術(shù)》如果你是測(cè)試開發(fā)方向這本書值得反復(fù)讀。8.2 視頻與在線課程方向B 站搜索“軟件測(cè)試基礎(chǔ)”“軟件測(cè)試入門”有很多免費(fèi)的完整課程建議選擇播放量和評(píng)論口碑較好的。慕課網(wǎng)、51CTO 有系統(tǒng)的測(cè)試課程結(jié)構(gòu)更完整適合希望走完整學(xué)習(xí)路線的人。如果想走自動(dòng)化方向可以關(guān)注 Selenium、Playwright、Pytest 的官方文檔英文基礎(chǔ)好的話直接讀文檔是最快的。8.3 練習(xí)項(xiàng)目方向電商系統(tǒng)測(cè)試找一個(gè)開源的電商系統(tǒng)如 Mall、litemall跑起來(lái)后設(shè)計(jì)全流程測(cè)試用例。接口測(cè)試項(xiàng)目使用公開 API 平臺(tái)如 GitHub API、聚合數(shù)據(jù)練習(xí) Postman 和自動(dòng)化腳本。開源 Bug 管理系統(tǒng)用禪道管理你自己練習(xí)項(xiàng)目的需求、用例、缺陷。9. 寫給新手的一些大實(shí)話最后說(shuō)幾句掏心窩子的話。第一軟件測(cè)試不是避風(fēng)港。它確實(shí)入行門檻相對(duì)較低但想做好、做長(zhǎng)久需要持續(xù)學(xué)習(xí)。尤其是自動(dòng)化測(cè)試、性能測(cè)試、安全測(cè)試這些方向?qū)夹g(shù)能力的要求并不比開發(fā)低多少。如果你想著“測(cè)試比較輕松才來(lái)”大概率會(huì)失望。第二項(xiàng)目實(shí)戰(zhàn)比看教程重要一百倍。光看不練七天后你腦子里還是一片模糊。只有親手設(shè)計(jì)用例、親手提交缺陷、親手跑通自動(dòng)化腳本這些東西才真正變成你的能力。第三第一份工作不要只看薪資。零基礎(chǔ)入行第一份工作最重要的三個(gè)要素是有沒有人帶、能不能接觸到完整的測(cè)試流程、有沒有成長(zhǎng)空間。哪怕薪資低一點(diǎn)只要能在項(xiàng)目里真正鍛煉長(zhǎng)線回報(bào)會(huì)遠(yuǎn)遠(yuǎn)超出預(yù)期。第四建立自己的缺陷庫(kù)和學(xué)習(xí)筆記。平時(shí)遇到什么問(wèn)題、怎么解決的記錄下來(lái)。這不僅是面試的素材庫(kù)也是你專業(yè)能力的沉淀。軟件測(cè)試這條路入門不難但每一步都需要踏實(shí)積累。按這篇教程的節(jié)奏走完 7 天你會(huì)發(fā)現(xiàn)自己對(duì)整個(gè)測(cè)試體系有了清晰的認(rèn)識(shí)手里還有一個(gè)能講清楚的項(xiàng)目。剩下的就是持續(xù)練習(xí)然后勇敢地投出第一份簡(jiǎn)歷。