凌晨兩點半生產(chǎn)環(huán)境告警把整個值班群炸醒。我爬起來看了一眼監(jiān)控面板報錯的服務(wù)是三年前上的舊模塊提交代碼的人早就離職了當時負責(zé)測它的同事也轉(zhuǎn)崗了。屏幕上那行日志混著半截中文和全角括號旁邊還掛著一句這里后面再優(yōu)化的注釋。我盯著它看了幾秒心里冒出一個特別喪的念頭技術(shù)債這東西就像一座公墓活著的時候沒人愿意進去掃墓等它開始滲水、塌方、鬧鬼夜里被叫醒來處理的永遠是我們測試工程師。這篇文章就想聊聊在技術(shù)債纏身的項目里測試工程師到底該怎么活下來怎么從填坑的變成排雷的怎么在爛代碼庫里守住自己那點職業(yè)尊嚴。1. 技術(shù)債是怎么一步步把我們逼成守墓人的1.1 技術(shù)債的真面目不是 Bug是欠條技術(shù)債這個東西圈子里聊得很多但大部分定義都是開發(fā)視角的什么為短期交付犧牲長期質(zhì)量代碼腐化的利息之類的。站在測試的角度我想給一個更直白的描述——技術(shù)債是一個系統(tǒng)在健康狀態(tài)下本該有、但為了趕工期沒做的那部分東西。它可能是一段繞了三層的臨時邏輯可能是一張沒人維護的配置表可能是一條從未寫過的異常處理分支也可能是一份早就應(yīng)該補齊但一直有空再說的接口文檔。它不是 Bug。Bug 是這道門明明是朝左開的你寫成了朝右開而技術(shù)債是這道門為了趕進度先拿木板釘上了打算以后換鋁合金但以后再也沒人記得這回事。Bug 總有修完的一天技術(shù)債是永遠還不清的。你每修一處可能會在別的地方又欠一筆。我平時喜歡用一個裝修類比新房裝修的時候為了省時間師傅把電線全部走明線住進去確實很方便網(wǎng)絡(luò)也不會斷。但三年后你想重新刷墻、改格局、裝新風(fēng)系統(tǒng)就會發(fā)現(xiàn)當初那套明線成了最大的障礙。這時候你只會罵當時的自己為什么不多留一周工期。而測試工程師就是那個每次想刷墻都被電線擋住的人還得負責(zé)跟家里人解釋墻為什么刷不了。1.2 技術(shù)債的利息是怎么滾起來的技術(shù)債最可怕的地方其實不是債本身而是利息的復(fù)利效應(yīng)。舉一個幾乎所有項目里都見過的例子某個核心服務(wù)早期為了快速上線沒有做模塊拆分所有邏輯都堆在一個巨型單元里模塊之間靠全局變量通信。第一年還好十來個開發(fā)投入產(chǎn)出比勉強能接受。第二年加需求改一個配置項要重啟三個模塊部署工程師天天罵娘。第三年這個模塊已經(jīng)沒人敢碰了注釋里寫滿了勿動動則死人。在這個過程中測試工程師的感受是最直觀的回歸測試的用例量莫名其妙地逐年翻倍因為功能之間耦合越來越多每一次版本發(fā)布線上總會冒出一個不知道跟這次改動有什么關(guān)系的缺陷排查缺陷的時間越來越長因為代碼里沒有文檔、沒有日志規(guī)范、沒有異常兜底新人上手的時間越來越久一個簡單的功能要問五六個人才能摸清調(diào)用鏈路。這些利息不會記在任何一個 KPI 上但它會一點一點蠶食團隊的質(zhì)量。到了某個臨界點系統(tǒng)就會從能跑但難維護變成一改就炸這時候所有人都知道技術(shù)債爆了但沒人知道該怎么填只好繼續(xù)舉新債補舊債。1.3 為什么最后守墓人是我們你可能會問技術(shù)債明明是研發(fā)、架構(gòu)、產(chǎn)品一起欠下的為什么最后背鍋的總是測試這個問題我思考了很久結(jié)論其實很現(xiàn)實因為開發(fā)可以繞開爛代碼測試繞不開。開發(fā)寫新功能的時候雖然在爛地基上施工很憋屈但至少他可以挑一塊自己熟悉的領(lǐng)地。測試不一樣測試需要對整個系統(tǒng)負責(zé)。一個需求上線你得驗證新功能本身還得驗證它有沒有影響老功能、數(shù)據(jù)遷移、并發(fā)邊界、異?；謴?fù)、第三方依賴。這些地方恰恰是技術(shù)債藏得最深的地方。線上出了問題產(chǎn)品會說測試怎么沒測出來開發(fā)會說本地跑沒問題啊最后所有的壓力都會落到測試頭上。而且還有一個更隱蔽的原因測試活動本身就是技術(shù)債的曝光機。你跑一輪回歸等于把系統(tǒng)身上所有腐爛的傷口都翻了一遍你寫一份測試報告等于在給全團隊做體檢報告。那些久治不愈的病灶只有你天天看見。久而久之別人可以假裝看不見你裝不了。提示如果你在項目里也有同樣的處境別急著內(nèi)疚。技術(shù)債不是一個人欠的測試只是在替整個團隊還利息。2. 守墓人上崗指南在爛代碼庫上重建測試秩序剛接手一個技術(shù)債嚴重的項目最忌諱的就是太想做好。我見過不少測試新人一上來就立大目標我要把自動化覆蓋率干到百分之八十我要把所有歷史缺陷清理掉我要搞定整個回歸體系。結(jié)果不到兩個月人走了活沒干成。在爛項目里做測試第一課不是沖鋒是排雷——先搞清楚自己面對的是什么再決定把力氣花在哪里。2.1 先摸清墓地埋了什么做一次技術(shù)債全景盤點接手任何一個新項目我做的第一件事永遠不是寫用例而是盤點。技術(shù)債不是抽象的概念它具體分布在你需要維護的每個服務(wù)、每個界面、每張表里。你只有先把它們找出來才不會被它們突然冒出來的樣子嚇到。我的盤點是四步走第一步用代碼掃描工具把所有服務(wù)過一遍SonarQube、ESLint、Checkstyle 都行目的不是看代碼規(guī)范而是看復(fù)雜度。圈復(fù)雜度超過二十的模塊、重復(fù)率超過百分之三十的文件、大段的 TODO 注釋都是潛在的雷區(qū)。掃描結(jié)果不用太細能按服務(wù)聚合出哪里最爛就夠了。第二步翻測試報告和線上告警記錄。不是為了找具體 Bug而是找高頻故障的模塊。前一年的線上問題按服務(wù)維度聚合一下你就能畫出哪個墳頭冒煙最頻繁的分布圖。第三步找開發(fā)聊一輪。不需要組織正式會議就私下問兩三個核心開發(fā)這項目里哪些模塊你碰都不想碰為什么你會得到比任何靜態(tài)檢查都有價值的答案——每個爛代碼的核心地帶有自己的名字和故事。第四步把這些信息匯總成一張風(fēng)險矩陣橫軸是有問題的模塊縱軸是故障頻率、變更頻率、業(yè)務(wù)影響。最后圈出一個高危區(qū)比如訂單模塊半年內(nèi)變更四十次線上故障八個沒有自動化測試覆蓋。這就是你未來最需要投入精力的墳頭。提示這張矩陣別只留給自己。整理成一頁紙的文檔發(fā)給團隊哪怕只是簡單地標紅后續(xù)推動測試資源傾斜的時候會省很多口舌。2.2 測試分層策略不是所有債都值得還做完盤點接下來就是傷腦筋的地方到底怎么分配有限的測試精力。技術(shù)債嚴重的項目里人力永遠是不夠的——缺陷等著你測、新功能等著你測、歷史功能還得防退化。這時候最忌諱的是平均用力。我的原則是用 ROI 決定投入而不是用覆蓋面決定投入。核心鏈路優(yōu)先。先找出系統(tǒng)里哪幾條路徑是用戶天天走的、哪幾個模塊掛了會直接導(dǎo)致?lián)p失。這些路徑就是你的生命線必須保證自動化覆蓋。在訂單系統(tǒng)里下單-支付-出單-退款這條鏈路就算代碼再爛也要守住至于后臺管理系統(tǒng)里某個一年用一次的列表導(dǎo)出功能先別急。穩(wěn)定需求優(yōu)先。自動化測試最怕對象頻繁變。需求還在迭代、頁面還在改、接口還在調(diào)的時候別急著寫自動化腳本否則你寫完腳本改需求改完需求改腳本最后腳本跟你之間的關(guān)系就是互相折磨。等到功能穩(wěn)定了再補自動化效率要高十倍?？勺C明價值優(yōu)先。如果你做的自動化用例跑了一百個一半是永遠不過的失敗用例另一半是這個功能我壓根沒人用的成功用例那這個自動化體系的老板感知就是浪費。所以寧可做成五十個用例全綠、每個都是核心鏈路也不要貪多。這個道理同樣適用于手工測試先測改動點本身再測改動點的最鄰近模塊最后才測全量回歸。很多測試同事有個壞習(xí)慣改動一個小接口就順手把整個系統(tǒng)回歸了一遍費時費力還沒抓到重點。我曾經(jīng)在一個支付項目里見過同事為了驗證一個文案改動硬是把全鏈路回歸跑了兩個小時最后只發(fā)現(xiàn)一個跟文案毫無關(guān)系的環(huán)境噪音缺陷。她覺得自己很盡責(zé)但實際上浪費了最寶貴的時間窗口。真正合理的做法是先把改動點周圍的風(fēng)險面框出來再擴展到整體回歸——這樣哪怕時間不夠核心風(fēng)險也已經(jīng)覆蓋了。2.3 自動化測試在爛項目里的求生姿勢回到一個真實的問題技術(shù)債纏身的項目自動化測試到底怎么落地很多團隊都有過失敗的嘗試買了工具、配了框架、寫了腳本最后全部爛尾。我總結(jié)了一下爛尾項目通常有兩個共同點一是沒有選對切入點二是沒有接受灰頭土臉地運行。先說切入點。如果整個系統(tǒng)的自動化覆蓋率目前是零不要一上來就想著搭企業(yè)級框架。我的建議是直接從回歸最痛、改動最頻繁的場景下手。最典型的就是冒煙測試把核心鏈路的用例用自動化搭起來每次發(fā)版前跑一遍能擋住一半的低級回歸問題。其次是接口層的自動化。相比 UI 自動化接口自動化在爛代碼面前特別香第一它不依賴界面的頻繁調(diào)整頁面改了接口不一定改第二它跑得快可以用來做大規(guī)?；貧w第三它的斷言可以直接和數(shù)據(jù)結(jié)構(gòu)、響應(yīng)碼、數(shù)據(jù)庫記錄掛鉤定位問題更快。所以即便你的 UI 自動化剛起步接口自動化也完全可以先跑起來。我在幾個項目里都是這么干的——UI 層自動化負責(zé)守住體驗接口層自動化負責(zé)守住院子兩層一起用才能穩(wěn)住陣腳。再說接受灰頭土臉地運行。很多自動化項目死在太完美主義——腳本必須健壯、報告必須漂亮、覆蓋率必須達標。但技術(shù)債重的項目里第一版自動化跑起來一定是千瘡百孔的腳本時好時壞環(huán)境不穩(wěn)定數(shù)據(jù)不干凈。這時候別放棄先讓它跑著哪怕只有一半用例全綠也比人工回歸漏掉要害要強。后面再迭代腳本的穩(wěn)定性一點一點把黃色區(qū)域變綠。提示自動化測試的初期目標不是全自動而是比人肉靠譜。你自己心里要有數(shù)第一版只要做到測試范圍固定、可重復(fù)執(zhí)行、結(jié)果可追溯這三個最低要求就夠了。3. 和僵尸功能過日子遺留系統(tǒng)的測試生存技巧如果說技術(shù)債像公墓那遺留系統(tǒng)里那些沒文檔、沒用例、沒人在意的老功能就是躺在墓里偶爾還動一下的僵尸。你沒法把它們?nèi)客诔鰜碇匦掳苍嶂荒軐W(xué)會跟它們共存同時保證它們不會半夜爬起來咬你一口。3.1 探索性測試沒有文檔時的夜視儀技術(shù)債重的項目最典型的特征是文檔缺失。需求文檔找不到接口文檔過期測試用例幾十年沒更新。這種環(huán)境下常規(guī)的按用例執(zhí)行是不現(xiàn)實的——你連這條用例對應(yīng)的功能還存不存在都沒把握。這時候我建議把探索性測試當成主力。探索性測試的核心思想是把測試設(shè)計和測試執(zhí)行合并起來一邊探索一邊學(xué)一邊驗證。聽起來似乎很隨意但它是有方法論支撐的核心是基于風(fēng)險的探索。我習(xí)慣的做法是拿到一個功能或者一個模塊先問三個問題這個功能給誰帶來價值誰的什么任務(wù)非它不可它的輸入輸出邊界在哪正常流程之外有哪些異常、邊界、逆向的操作它與周邊模塊有哪些數(shù)據(jù)交換一個字段的格式、長度、非法值有沒有可能在別處被消費問完這三個問題再結(jié)合測試直覺去構(gòu)造場景。這個方法特別適合那種沒人清楚整個系統(tǒng)長什么樣的遺留環(huán)境你不需要一張精確的架構(gòu)圖只需要沿著數(shù)據(jù)流走幾遍就能形成自己的活地圖。當然探索性測試的產(chǎn)出不能只是我測了沒問題。每一次探索都應(yīng)該做記錄至少記下測了哪些場景、哪些地方崩潰了、哪些異常行為出現(xiàn)了。這些記錄會變成下一輪回歸的種子也會讓僵尸功能逐漸變得有文檔。3.2 把故障注入搬進測試環(huán)境別讓系統(tǒng)活得太安逸技術(shù)債重的系統(tǒng)最怕的不是功能壞而是壞得沒有預(yù)兆。與其祈禱它在線上別炸不如在測試環(huán)境主動炸一炸。混沌工程這個名字聽起來很玄乎其實落到測試日常就是故意制造故障看看系統(tǒng)會怎么反應(yīng)。給測試同學(xué)的操作建議如下第一步挑一個看起來太穩(wěn)的核心流程。比如用戶下單-支付-出單-退款在測試環(huán)境跑通。第二步手動注入故障。故障可以很簡單把下游的微服務(wù)停掉看看主服務(wù)超時邏輯扛不扛得住把數(shù)據(jù)庫的連接池調(diào)小模擬高并發(fā)下的擠兌或者干脆給測試環(huán)境加幾十毫秒網(wǎng)絡(luò)延遲感受一下真實用戶在網(wǎng)絡(luò)抖動時的體驗。第三步觀察系統(tǒng)的表現(xiàn)。最理想的情況是系統(tǒng)有超時、有重試、有兜底最終把錯誤優(yōu)雅地反饋給用戶。最糟糕的情況是系統(tǒng)直接卡死、丟數(shù)據(jù)、連環(huán)崩潰。你需要記錄的就是這些糟糕情況它們往往是技術(shù)債里最隱蔽的隱患。別擔(dān)心這些故障注入會搞壞環(huán)境。測試環(huán)境本來就是用來折騰的你在測試環(huán)境里把系統(tǒng)折騰掛了總比它上了線在凌晨兩點折騰生產(chǎn)環(huán)境強。我甚至覺得一個測試團隊如果從來沒有故意搞掛過環(huán)境那這個環(huán)境一定不夠接近真實測試的有效性一定是打折的。3.3 技術(shù)債臺賬讓債主們看得見賬單前面說的都是怎么在爛代碼里做測試但有一個問題繞不開你發(fā)現(xiàn)了債務(wù)、驗證了債務(wù)然后呢如果只是把缺陷提交進 bug 庫過兩個迭代就沒人記得了。所以我強烈建議每一個測試團隊都建一本技術(shù)債臺賬。臺賬的字段不需要很復(fù)雜我常用的就這么幾列字段說明示例模塊問題歸屬訂單服務(wù)債務(wù)類型文檔缺失/架構(gòu)腐化/測試真空/性能隱患測試真空風(fēng)險等級高/中/低按影響和概率高當前表現(xiàn)現(xiàn)在是否已經(jīng)造成問題偶發(fā)超時觸發(fā)條件什么情況下會爆雷大促峰值預(yù)計修復(fù)成本可能需要多少開發(fā)量2 人日建議償還方式重構(gòu)/補測試/寫文檔/加監(jiān)控補測試加監(jiān)控這本臺賬不會替你還債但它有兩個作用一是讓技術(shù)債從模糊的擔(dān)憂變成具體的事務(wù)二是你在跟產(chǎn)品、開發(fā)溝通的時候有了客觀依據(jù)。比如下個迭代排期你說我強烈要求加兩天測試時間因為這個模塊補完測試之前風(fēng)險太高和你說根據(jù)臺賬這個模塊三個月里已經(jīng)引發(fā)四次回歸問題修復(fù)成本至少三萬人日建議優(yōu)先處理后者明顯更有說服力。4. 讓技術(shù)債暴露在陽光下度量與推動償還你自己看得見技術(shù)債不代表團隊看得見。測試工程師要是不想讓守墓的工作白干就得學(xué)會用量化數(shù)據(jù)和推動機制讓全團隊不得不低頭看看這些墳頭。4.1 我盯著的四個測試度量指標先潑一盆冷水很多測試團隊的度量指標在技術(shù)債嚴重的項目里是自欺欺人。比如發(fā)現(xiàn)缺陷數(shù)這個指標有個天然的問題——缺陷報得多到底是測試能力強還是代碼質(zhì)量差再比如用例執(zhí)行數(shù)用例數(shù)量多、執(zhí)行得快但測的都是邊角料有什么意義我平時真正看重的指標只有四個既反映問題、又可操作第一個是線上缺陷逃逸率DRE線上發(fā)現(xiàn)的嚴重缺陷數(shù)除以總嚴重缺陷數(shù)。這個指標能直接說明回歸防線漏沒漏技術(shù)債越重這個數(shù)字越容易出現(xiàn)莫名其妙的變化。它不是用來追責(zé)的是用來對標測試投入的。第二個是高危模塊的自動化覆蓋率。別測整體覆蓋率整體覆蓋率百分之八十的數(shù)字有可能很好看但高危模塊可能還是零。把覆蓋率的定義框到高風(fēng)險模塊核心鏈路上數(shù)字才具備預(yù)警意義。第三個是缺陷從提交到關(guān)閉的平均時長。這個數(shù)字在爛項目里通常嚇死人三個月都關(guān)不掉一個缺陷很常見。它反映了端到端研發(fā)效率以及技術(shù)債導(dǎo)致的修一個壞兩個的惡性循環(huán)。第四個是回歸風(fēng)險指數(shù)——我自己習(xí)慣的叫法統(tǒng)計每次發(fā)布時回歸用例中失敗用例的占比。占比越高說明改動越容易觸發(fā)回歸也就是技術(shù)債利息最直接的體現(xiàn)。這四個指標不需要每天都看我習(xí)慣做成周報和月報按月畫趨勢。趨勢比單點更重要只要曲線在向好的方向走哪怕慢一點都是技術(shù)債在逐漸被償還的證據(jù)。4.2 一份技術(shù)債報告的正確打開方式很多測試同學(xué)對寫報告有抵觸覺得就是走形式。但我想說報告不是寫給你的領(lǐng)導(dǎo)看的是寫給假裝不知道有債的團隊看的。一份好的技術(shù)債報告要在第一屏就讓所有角色找到自己的名字。我自己常用的報告結(jié)構(gòu)是第一部分用三十個字以內(nèi)的結(jié)論開頭。比如訂單模塊仍處于高風(fēng)險狀態(tài)已連續(xù)三周出現(xiàn)回歸缺陷建議下迭代優(yōu)先補齊自動化測試。第二部分給數(shù)據(jù)。把逃逸率、覆蓋率、缺陷平均關(guān)閉時長的趨勢圖貼上去圖上要標重點事件比如5月大促后發(fā)現(xiàn)缺陷翻倍8月核心鏈路重構(gòu)后覆蓋率從 30% 升到 55%。第三部分列明細。把技術(shù)債臺賬里風(fēng)險等級為高的項逐條寫清楚每條都標注模塊、風(fēng)險原因、當前影響、建議動作。第四部分給承諾。寫下接下來一個迭代測試團隊會做什么比如本周將補齊下單鏈路接口自動化預(yù)計新增四十條用例。這樣一份報告發(fā)到項目群里效果會比那種羅列三百條 Bug 的 Excel 強太多。為什么因為 Bug 列表只能證明你測出了很多問題而技術(shù)債報告能證明你知道問題的根源和它要花多少錢解決。后者才是測試工程師在團隊里的價值。4.3 推動團隊還債不靠吼靠機制看完了報告團隊也認可了風(fēng)險然后呢如果下一個迭代還是狂塞新功能那報告就白寫了。推動技術(shù)債的償還光靠個人意志是不夠的得靠機制。這里分享幾個我在項目里實際落地過的做法。第一個是質(zhì)量門禁。發(fā)布前必須有測試通過的門檻高危模塊這塊沒有達到要求就不準發(fā)布。這個門禁可以由測試工程師來守只要你把門禁指標定得合理——比如高危模塊新增用例不足十條不予發(fā)布——開發(fā)會主動來找你討論哪些用例有價值而不是一味拍桌子。第二個是還債占排期比例。和團隊達成一個隱性的約定每個迭代技術(shù)債償還類的工作量至少要占到總工作量的百分之十到二十。這個數(shù)字不需要死板但這個意識必須有。沒有這個比例技術(shù)債在排期會議上永遠排不上號。第三個是讓開發(fā)為自己的代碼付測試成本。我給團隊帶過一個習(xí)慣改動涉及高危模塊的時候開發(fā)自己先寫一條冒煙用例測試來做深度驗證。別小看這一條用例它逼著開發(fā)去理解自己改動的邊界防止我以為沒影響結(jié)果影響了一片。第四個是用事故復(fù)盤倒逼償還。每當線上出事故復(fù)盤會不要只停留在誰改了代碼哪個環(huán)節(jié)沒測到多問一句這是不是某個已知技術(shù)債的又一次利息支付。如果是把這個技術(shù)債的風(fēng)險等級調(diào)高安排還款計劃。讓團隊發(fā)現(xiàn)原來每一次線上事故都是在給舊債交利息。說這話的時候不要帶情緒要讓數(shù)字說話大家就會明白還債比繼續(xù)欠債劃算。5. 守墓人也要進化從測試執(zhí)行者到質(zhì)量守護者技術(shù)債嚴重的項目待久了人很容易廢掉——每天被回歸、排查、填坑消耗漸漸地就會覺得自己只是個點鼠標的。但我不這么看。恰恰是這種環(huán)境才逼著測試工程師的段位快速成長。守墓人當久了看慣了腐爛和死亡你會比誰都清楚一個系統(tǒng)真正怕什么。把這些經(jīng)驗轉(zhuǎn)化為更深層的能力才是長期價值。5.1 像滲透測試工程師一樣思考技術(shù)債重的系統(tǒng)最常見的死法不是正常的 Bug而是被意想不到的輸入搞死。所以我很鼓勵測試同事學(xué)一點滲透測試的思維方式。不需要你非得去挖漏洞、打演練只需要把攻擊性測試的思想引入日常工作。什么叫攻擊性測試簡單說就是不再問這個功能應(yīng)該怎么用而是問這個功能應(yīng)該怎么被打。表單會不會被塞入超長字符串、特殊字符接口會不會收到偽造的高權(quán)限身份信息文件上傳會不會被傳一個可執(zhí)行腳本權(quán)限控制能不能被越權(quán)繞過你會發(fā)現(xiàn)這些問題里面很大一部分本質(zhì)上還是技術(shù)債因為早期的代碼沒有做輸入校驗、沒有做訪問控制、沒有做異常兜底。用滲透測試的視角去測技術(shù)債系統(tǒng)往往能批量發(fā)現(xiàn)一類以前測不出來的問題。我還建議每個測試團隊都定期做一輪紅線演練挑出核心鏈路的接口用工具構(gòu)造正常流量、異常流量、惡意流量三種情況觀察系統(tǒng)的反應(yīng)。你很快就會發(fā)現(xiàn)那些在正常用例里看起來沒問題的接口在異常流量下有多脆弱。這個過程本身不需要很深的安全知識但能把你的測試思維從驗證正確提升到挑戰(zhàn)正確。5.2 讓 AI 測試工程師當你的夜班保安這兩年 AI 測試的話題熱得不行什么智能用例生成、自動斷言、缺陷預(yù)測都出來了。我不能說這些都在實際項目里成熟了但有幾個場景AI 在技術(shù)債項目里是真好用足以讓守墓人解放一部分精力。第一個是接口變更檢測。AI 工具可以自動比對接口在不同版本之間的差異新版本接口字段變了、類型變了、默認值變了它能自動標出來。這項能力在缺失文檔的遺留系統(tǒng)里特別有價值相當于幫你自動維護了一份活接口文檔。第二個是智能回歸篩選。當你有一大批自動化用例而每次發(fā)布人力有限時AI 可以根據(jù)代碼變更影響面幫你篩出最可能受影響的一批用例先跑。我自己實測下來這個功能誤報率有點高但漏報率低也就是說它篩出的用例不一定都是關(guān)鍵的但它不會落下關(guān)鍵的部分。這已經(jīng)能顯著減少全量回歸的時間了。第三個是缺陷自動分類打標。AI 讀缺陷描述、日志、堆棧自動把缺陷歸類到模塊、原因、優(yōu)先級。這個功能初看是個小優(yōu)化但在技術(shù)債多的項目里它讓缺陷長期滯留 bug 庫這個老大難改善了不少——至少每個缺陷都有了清晰的歸屬和熱度不會爛在角落里發(fā)霉。要強調(diào)的是AI 輔助測試目前還不能替代測試工程師的判斷它更適合當你的夜班保安——你睡覺的時候它盯著第二天早上你去處理它篩出來的重點。但保安替你擋不了所有的賊最終的驗證、分析、決策還是要自己來。5.3 為簡歷打工資歷成長與技術(shù)債的另類價值說句直白的話在技術(shù)債嚴重的項目里的經(jīng)歷寫到簡歷上其實是很有價值的財富。網(wǎng)上那些熱搜詞——滲透測試工程師學(xué)習(xí)自動化測試工程師工作實戰(zhàn)AI 測試工程師——背后反映的是行業(yè)對測試工程師綜合能力的要求在上升。而你在爛項目里被迫學(xué)會的東西恰好在往這個方向靠。想想看你在腐爛的代碼庫上做風(fēng)險盤點等于做了系統(tǒng)架構(gòu)的逆向梳理這是架構(gòu)理解力你在沒文檔的環(huán)境里做探索性測試等于練出了測試思維這是測試設(shè)計力你推動團隊還債、建立度量體系等于學(xué)會了影響力這個詞真正落地的方法你引入攻擊性測試和 AI 輔助工具等于提前踩了踩下一波測試技術(shù)的坑。我在面試的時候經(jīng)常聽到候選人說我們項目技術(shù)債太多測試沒法開展他的潛臺詞是這個項目埋沒了我的能力。但如果換一個說法——我在一個技術(shù)債嚴重、風(fēng)險極高的項目里通過風(fēng)險盤點、分層測試、推動機制建設(shè)把線上逃逸率降了百分之四十——這就變成了你能力的證明。同一個經(jīng)歷前一種說法是抱怨后一種說法是戰(zhàn)績。資歷這個東西不是看你在多干凈的代碼里寫過多少用例而是看你在多爛的環(huán)境里建立過什么秩序。6. 寫在最后守墓人的心理建設(shè)和一點私心啰嗦了這么多最后分享一下真實的心態(tài)問題。做測試工程師的人多少都有完美主義傾向看到技術(shù)債天天血壓升高總覺得自己有責(zé)任把代碼變干凈。但我想說的是技術(shù)債不是一個人欠下的也不是你一個人能還清的。守墓人的職責(zé)不是把整座公墓打掃得一塵不染而是保證沒有尸體跑出來害人。在這個前提下有幾點私人心得想送給同行第一學(xué)會給自己關(guān)燈。不管項目里亂到什么程度該下班就下班。我見過太多測試同事因為線上告警、開發(fā)催測、缺陷追責(zé)把自己熬成了項目里的替補滅火隊員。這個角色你一旦當久了反而沒有人重視你的專業(yè)建議。第二記錄自己的工作輸出。不要覺得天天寫報告很煩那是你的軍功章。每一次風(fēng)險提示被驗證、每一次線上事故被你說中、每一個通過你的門禁攔下的問題都值得記下來。半年之后回看你就知道自己在這個公墓里的實際價值了。第三保持對好代碼的敏感性。天天泡在爛代碼里審美會被拉低的。我自己的習(xí)慣是每個季度至少看幾個高質(zhì)量開源項目的測試代碼或者參與一些技術(shù)社區(qū)的代碼評審。目的不是學(xué)到具體的技術(shù)而是提醒自己好系統(tǒng)的測試長什么樣以及我們做測試的長期目標是什么。最后說一句可能有點喪但很真實的話技術(shù)債公墓里的守墓人從來不能阻止有人繼續(xù)埋東西。你唯一能做的是讓每一座墳都立好墓碑記錄好死因定期巡視及時排雷然后在合適的時候推動一場有計劃的搬遷。這不光是一份工作它教會我的其實是怎么在充滿不確定性的系統(tǒng)里靠專業(yè)、數(shù)據(jù)和溝通守住一個又一個看似守不住的底線。