1. 為什么測(cè)試做久了反而會(huì)怕“修不完的Bug”先聊一個(gè)場(chǎng)景。很多剛?cè)胄械臏y(cè)試工程師會(huì)覺(jué)得測(cè)試工作的核心就是“找Bug”——只要我能在系統(tǒng)里多找出幾個(gè)問(wèn)題就算把活干好了。但真正在一線干上兩三年之后你會(huì)發(fā)現(xiàn)事情遠(yuǎn)沒(méi)那么簡(jiǎn)單。最典型的困境是Bug越提越多開發(fā)修不完產(chǎn)品上線一拖再拖同一個(gè)模塊的問(wèn)題反復(fù)出現(xiàn)今天修了A處、明天又冒出來(lái)B處更扎心的是有些Bug你好不容易寫清楚了步驟開發(fā)卻回你一句“無(wú)法復(fù)現(xiàn)關(guān)了吧”。這個(gè)時(shí)候你就會(huì)意識(shí)到測(cè)試的價(jià)值從來(lái)不是“發(fā)現(xiàn)Bug”本身而是如何讓缺陷被系統(tǒng)性地管理起來(lái)、被高效地推動(dòng)解決、被沉淀成可復(fù)盤的經(jīng)驗(yàn)。這部分能力在業(yè)界有個(gè)很明確的叫法——缺陷工程Defect Engineering。缺陷工程這個(gè)詞聽起來(lái)好像很學(xué)術(shù)但拆開看就是兩件事一是“怎么管缺陷”二是“怎么用缺陷反推質(zhì)量改進(jìn)”。它屬于測(cè)試技術(shù)體系里承上啟下的那一環(huán)向下承接測(cè)試執(zhí)行階段產(chǎn)出的發(fā)現(xiàn)向上支撐版本質(zhì)量評(píng)估和過(guò)程改進(jìn)。如果說(shuō)測(cè)試執(zhí)行是“從系統(tǒng)里找問(wèn)題”那缺陷工程就是“讓每個(gè)問(wèn)題都發(fā)揮最大價(jià)值”——該修的修、該排期的排期、該分析的復(fù)盤、該預(yù)防的預(yù)防。這篇內(nèi)容我打算圍繞缺陷工程的第一階段展開也就是把最核心的基礎(chǔ)概念、分類體系、生命周期和報(bào)告標(biāo)準(zhǔn)講透。對(duì)剛接觸測(cè)試、或者做了幾年測(cè)試但主要靠經(jīng)驗(yàn)干活的朋友來(lái)說(shuō)這部分是把“提Bug”從體力活變成技術(shù)活的關(guān)鍵一步。讀完你會(huì)有一套清晰的框架之后再看那些流程規(guī)范、工具配置、度量指標(biāo)就都能對(duì)號(hào)入座了。2. 缺陷到底是什么一個(gè)Bug的本質(zhì)拆解2.1 從產(chǎn)品視角到代碼視角的認(rèn)知差異在正式聊缺陷工程之前必須先把“缺陷”這個(gè)詞的定義搞清楚。因?yàn)槲以趯?shí)際工作中發(fā)現(xiàn)很多爭(zhēng)議的根源是大家對(duì)“什么叫缺陷”的理解根本不在一個(gè)維度上。從最嚴(yán)謹(jǐn)?shù)能浖こ潭x來(lái)看缺陷是“系統(tǒng)或組件中存在的、可能導(dǎo)致其無(wú)法滿足預(yù)期需求的問(wèn)題”。這句話里有幾個(gè)關(guān)鍵詞需要細(xì)品?！邦A(yù)期需求”這四個(gè)字其實(shí)是最大的分歧點(diǎn)。開發(fā)眼里的預(yù)期需求是需求文檔里寫的那幾條功能描述產(chǎn)品經(jīng)理眼里的預(yù)期需求是用戶調(diào)研得出的使用期望而用戶心里的預(yù)期需求往往是他壓根沒(méi)說(shuō)出口的“這玩意兒應(yīng)該這樣用才對(duì)”。舉一個(gè)我經(jīng)歷過(guò)的真實(shí)例子。有一次我們做一個(gè)后臺(tái)管理系統(tǒng)需求文檔里明確寫了“導(dǎo)出數(shù)據(jù)功能”開發(fā)照著做了點(diǎn)按鈕確實(shí)能導(dǎo)出Excel功能驗(yàn)收也通過(guò)了。但上線之后用戶大量投訴說(shuō)導(dǎo)出功能“不好用”。后來(lái)一追查才知道用戶期望的是導(dǎo)出的文件能保留表格里的篩選條件、字段順序和顏色標(biāo)記——這些需求文檔里一個(gè)字都沒(méi)寫。從代碼角度看系統(tǒng)沒(méi)錯(cuò)從用戶角度看這就是缺陷。所以做缺陷工程的第一課就是要建立這樣一個(gè)認(rèn)知缺陷不是開發(fā)“寫錯(cuò)了代碼”的專屬產(chǎn)物而是所有“實(shí)際表現(xiàn)偏離了合理預(yù)期”的情況。這個(gè)預(yù)期可能來(lái)自需求文檔、來(lái)自行業(yè)慣例、來(lái)自用戶習(xí)慣也可能來(lái)自系統(tǒng)自身的規(guī)則一致性。2.2 缺陷與錯(cuò)誤、故障、失效之間的關(guān)系很多資料會(huì)把Error、Defect、Fault、Failure這幾個(gè)詞混著用新手很容易看迷糊。我在講缺陷工程時(shí)習(xí)慣用一條鏈路把它們串起來(lái)人為失誤Error→ 在代碼中埋入缺陷Defect/Fault→ 程序運(yùn)行到該缺陷時(shí)產(chǎn)生異常行為Failure也就是故障/失效這個(gè)鏈路是什么意思呢舉個(gè)例子。程序員寫代碼時(shí)把“大于等于”寫成了“大于”這是一個(gè)失誤這個(gè)失誤以代碼的形式存在于系統(tǒng)里就形成了缺陷某天用戶輸入了一個(gè)恰好等于臨界值的數(shù)據(jù)系統(tǒng)執(zhí)行到這個(gè)判斷分支給出了錯(cuò)誤的結(jié)果——這就是故障/失效。這條鏈路的現(xiàn)實(shí)意義在于測(cè)試人員能直接觀察到的是“失效”能提交的是“缺陷”而要去追溯的根源是“失誤”。缺陷工程里做的很多分析工作本質(zhì)就是在沿著這條鏈路往上找源頭。比如線上出了大故障常規(guī)做法是修復(fù)、重啟、補(bǔ)償數(shù)據(jù)但缺陷工程要求你繼續(xù)往下問(wèn)為什么這個(gè)失誤會(huì)發(fā)生是需求表達(dá)不清還是評(píng)審沒(méi)發(fā)現(xiàn)還是編碼規(guī)范缺失還是自測(cè)不充分找到每一層的原因才有辦法在下個(gè)迭代里避開同類問(wèn)題。2.3 缺陷的三個(gè)基本屬性類型、嚴(yán)重程度、優(yōu)先級(jí)缺陷工程之所以要研究分類是因?yàn)椴煌愋偷娜毕萏幚矸绞酵耆煌I(yè)界雖然沒(méi)有絕對(duì)統(tǒng)一的標(biāo)準(zhǔn)但主流的分類思路是共通的通常從三個(gè)維度去描述一個(gè)缺陷維度一缺陷類型說(shuō)的是“這問(wèn)題屬于哪一類”是功能不對(duì)、界面問(wèn)題、性能瓶頸、還是數(shù)據(jù)錯(cuò)誤。維度二嚴(yán)重程度說(shuō)的是“這問(wèn)題對(duì)系統(tǒng)和使用者的影響有多大”是崩潰級(jí)的、還是只是體驗(yàn)瑕疵。維度三優(yōu)先級(jí)說(shuō)的是“這問(wèn)題需要多快被解決”是馬上停線修還是可以等著攢一批再發(fā)版。這三個(gè)維度經(jīng)常被混為一談但實(shí)際上是兩個(gè)完全不同的判斷維度。嚴(yán)重程度判斷的是“影響有多大”優(yōu)先級(jí)判斷的是“什么時(shí)候該處理”。高嚴(yán)重程度的問(wèn)題通常優(yōu)先級(jí)也高但兩者并不總是強(qiáng)綁定的。比如一個(gè)只在極端罕見場(chǎng)景下才會(huì)觸發(fā)的崩潰嚴(yán)重程度雖然很高但優(yōu)先級(jí)完全可以排到后面去反過(guò)來(lái)一個(gè)很淺顯的表單按鈕錯(cuò)位問(wèn)題如果影響到關(guān)鍵客戶走合同審批流程優(yōu)先級(jí)就得拉高。弄清楚這三者的區(qū)別是后面所有缺陷管理動(dòng)作的基礎(chǔ)。因?yàn)檎麄€(gè)缺陷工程流程的第一步就是從這三項(xiàng)屬性的準(zhǔn)確判定開始的。3. 缺陷分類體系與嚴(yán)重級(jí)別判定最常見的吵架源頭3.1 一個(gè)實(shí)用主義的分類框架關(guān)于缺陷分類我見過(guò)兩種極端。一種是什么都不分所有Bug一鍋燴提了就修修了就關(guān)另一種是搞了一個(gè)極其復(fù)雜的分類樹幾百個(gè)標(biāo)簽大家提Bug時(shí)光是選類別就要折騰半天最后統(tǒng)計(jì)出來(lái)的數(shù)據(jù)反而毫無(wú)意義。我的建議是分類體系要服務(wù)于你的管理目標(biāo)而不是為了看起來(lái)專業(yè)而存在。在缺陷工程的第一階段一個(gè)實(shí)用主義的分類框架只需要能回答幾個(gè)問(wèn)題問(wèn)題出在哪個(gè)環(huán)節(jié)、屬于什么性質(zhì)、影響有多大。在環(huán)節(jié)維度上按缺陷來(lái)源可以分成需求缺陷、設(shè)計(jì)缺陷、編碼缺陷、集成缺陷、環(huán)境缺陷、數(shù)據(jù)缺陷幾類。這里注意并不是所有缺陷都是“代碼寫錯(cuò)了”。需求缺陷和設(shè)計(jì)缺陷在項(xiàng)目里的占比往往比大家想象的高得多——需求描述含混、邏輯分支遺漏、交互方案本身不合理這些問(wèn)題在編碼之前就埋下了測(cè)試階段暴露出來(lái)時(shí)定位和修復(fù)成本已經(jīng)翻了倍。在性質(zhì)維度上按功能維度、性能維度、安全維度、兼容性維度、易用性維度來(lái)分。這個(gè)維度主要是為后續(xù)的統(tǒng)計(jì)分析服務(wù)的——比如這個(gè)版本里性能類缺陷特別多那就說(shuō)明架構(gòu)層面或者數(shù)據(jù)量預(yù)判上出了問(wèn)題光靠提Bug是解決不了根本矛盾的。3.2 嚴(yán)重程度的五級(jí)判定標(biāo)準(zhǔn)嚴(yán)重程度的判定是缺陷工程里爭(zhēng)吵最多的地方。測(cè)試覺(jué)得是致命問(wèn)題開發(fā)覺(jué)得只是小毛病產(chǎn)品覺(jué)得不影響主線流程可這個(gè)bug在用戶現(xiàn)場(chǎng)就是卡住了業(yè)務(wù)的命門。吵的原因往往是“標(biāo)準(zhǔn)太模糊”——你說(shuō)“嚴(yán)重”就嚴(yán)重嗎總得有個(gè)共同的尺子。這里分享一套我在多個(gè)項(xiàng)目里用過(guò)、磨合得比較順的五級(jí)標(biāo)準(zhǔn)你可以直接作為團(tuán)隊(duì)的打分依據(jù)級(jí)別名稱判定標(biāo)準(zhǔn)典型場(chǎng)景S0阻斷/致命系統(tǒng)無(wú)法啟動(dòng)、核心功能不可用、數(shù)據(jù)丟失或損壞、存在嚴(yán)重安全漏洞必須立即修復(fù)登錄后白屏、支付金額算錯(cuò)、用戶隱私數(shù)據(jù)泄露S1嚴(yán)重主要功能受影響但有臨時(shí)規(guī)避方案或影響范圍較大但非核心鏈路某個(gè)核心流程報(bào)錯(cuò)但有替代入口可用大量用戶無(wú)法查看某頁(yè)面數(shù)據(jù)S2一般功能有瑕疵但正常主流程可走通有變通辦法某個(gè)篩選條件不生效、彈窗文案錯(cuò)別字、邊界值處理不完整S3輕微不影響功能僅影響體驗(yàn)或美觀的細(xì)節(jié)問(wèn)題界面布局輕微錯(cuò)位、提示語(yǔ)語(yǔ)氣生硬、無(wú)傷大雅的樣式差異S4建議非缺陷性質(zhì)但值得后續(xù)優(yōu)化的事項(xiàng)操作流程可簡(jiǎn)化、頁(yè)面加載時(shí)間雖然達(dá)標(biāo)但還有優(yōu)化空間這里面最需要統(tǒng)一認(rèn)知的是S0和S1的邊界。我的經(jīng)驗(yàn)是關(guān)鍵判斷點(diǎn)在于“有沒(méi)有可用的繞過(guò)路徑”和“影響范圍是不是核心鏈路”。如果用戶繞兩步還能完成操作那可以定為S1如果繞不過(guò)去或者數(shù)據(jù)已經(jīng)錯(cuò)了那就是S0沒(méi)有商量余地。3.3 優(yōu)先級(jí)與嚴(yán)重程度的聯(lián)動(dòng)邏輯搞定了嚴(yán)重程度再來(lái)看優(yōu)先級(jí)。這里我建議用“嚴(yán)重程度 × 影響范圍 × 暴露風(fēng)險(xiǎn)”的乘積思路來(lái)定優(yōu)先級(jí)而不是像很多團(tuán)隊(duì)那樣直接把嚴(yán)重程度當(dāng)成優(yōu)先級(jí)用。影響范圍包括受影響的功能使用頻率、用戶數(shù)量、業(yè)務(wù)關(guān)鍵程度暴露風(fēng)險(xiǎn)包括問(wèn)題觸發(fā)的概率、當(dāng)前是否已在生產(chǎn)環(huán)境出現(xiàn)、是否處于新上線的敏感期。一個(gè)S0級(jí)的問(wèn)題如果壓根沒(méi)有用戶能走到那條路上它再嚴(yán)重也不該排在S1的前面一個(gè)S2級(jí)的問(wèn)題如果在雙十一大促期間影響了主流程的一個(gè)高頻操作優(yōu)先級(jí)就得提到最高。優(yōu)先級(jí)一般分P0緊急、P1高、P2中、P3低四檔。P0代表“當(dāng)前版本必須立即停線修復(fù)”P1代表“本迭代必須修復(fù)”P2是“可排入下迭代”P3是“有空再處理”。在實(shí)際操作中我通常會(huì)在評(píng)審會(huì)上讓測(cè)試、開發(fā)、產(chǎn)品三方對(duì)優(yōu)先級(jí)做一次對(duì)齊——測(cè)試基于嚴(yán)重程度和技術(shù)影響給出建議開發(fā)評(píng)估修復(fù)成本產(chǎn)品評(píng)估業(yè)務(wù)價(jià)值最后定出的優(yōu)先級(jí)才是大家共同認(rèn)同的后面推進(jìn)起來(lái)會(huì)順暢得多。這里特別想提醒一句別讓缺陷優(yōu)先級(jí)變成測(cè)試單方面說(shuō)了算。一旦測(cè)試在優(yōu)先級(jí)上“一言堂”開發(fā)很可能產(chǎn)生對(duì)抗心理——反正你覺(jué)得著急你自己上。反而是拉齊標(biāo)準(zhǔn)、共同決策大家才會(huì)為結(jié)果共同負(fù)責(zé)。這是缺陷工程能不能在團(tuán)隊(duì)里跑起來(lái)的關(guān)鍵前提之一。4. 缺陷生命周期一條Bug的完整旅程4.1 從New到Closed的狀態(tài)流轉(zhuǎn)缺陷一旦被提交就進(jìn)入了一條有固定狀態(tài)的生命周期。業(yè)界各家的命名略有不同但主流程大同小異。我用一套通用的狀態(tài)機(jī)來(lái)說(shuō)明New新建→ Assigned已分配→ Open/Fixing修復(fù)中→ Fixed已修復(fù)→ 驗(yàn)證關(guān)閉/重開這條主線看著簡(jiǎn)單實(shí)際操作中會(huì)衍生出幾個(gè)旁路狀態(tài)每一個(gè)旁路狀態(tài)背后都藏著管理和溝通的成本。Rejected/Reopen拒絕/重開開發(fā)看完了認(rèn)為不是缺陷、或者無(wú)法復(fù)現(xiàn)會(huì)拒掉。如果測(cè)試不認(rèn)同就重新打開進(jìn)入一個(gè)“爭(zhēng)議仲裁”的過(guò)程。Deferred延期確認(rèn)是缺陷但當(dāng)前版本不修推遲到后續(xù)版本。Duplicate重復(fù)和已有的某個(gè)Bug重復(fù)關(guān)閉并關(guān)聯(lián)到原單。Question待溝通信息不足、描述不清退回發(fā)起人補(bǔ)充材料。我不止一次看到團(tuán)隊(duì)在狀態(tài)流轉(zhuǎn)上栽跟頭——因?yàn)闋顟B(tài)沒(méi)有明確的流轉(zhuǎn)規(guī)則Bug從一個(gè)狀態(tài)被隨手拖到另一個(gè)狀態(tài)最后連它到底在誰(shuí)手上、下一步該干什么都說(shuō)不清。缺陷工程的核心價(jià)值之一就是讓這條狀態(tài)流轉(zhuǎn)變成有約束、有職責(zé)、有時(shí)效的管理規(guī)則。4.2 各環(huán)節(jié)的責(zé)任人與核心動(dòng)作我們不能只是把狀態(tài)畫出來(lái)就完事得明確每個(gè)狀態(tài)下的角色和動(dòng)作否則流程畫得再漂亮也是紙面上的。我梳理了一個(gè)狀態(tài)責(zé)任矩陣你在團(tuán)隊(duì)里可以直接套用狀態(tài)責(zé)任人核心動(dòng)作New測(cè)試/提報(bào)人保證缺陷信息完整、可復(fù)現(xiàn)、分類分級(jí)準(zhǔn)確Assigned測(cè)試負(fù)責(zé)人/開發(fā)負(fù)責(zé)人確認(rèn)缺陷歸屬分配給對(duì)應(yīng)開發(fā)Fixing開發(fā)定位原因、實(shí)施修復(fù)、做自測(cè)Fixed開發(fā)修復(fù)完成后提交驗(yàn)證通知注明修復(fù)方式和影響范圍Verified測(cè)試在對(duì)應(yīng)版本環(huán)境上回歸驗(yàn)證通過(guò)則關(guān)閉失敗則重新打開Deferred產(chǎn)品/項(xiàng)目負(fù)責(zé)人評(píng)估后確認(rèn)延期記錄延期原因定期回訪Rejected開發(fā)寫明拒絕理由返回測(cè)試確認(rèn)或仲裁Duplicate測(cè)試/開發(fā)均可關(guān)聯(lián)到主單避免重復(fù)統(tǒng)計(jì)和重復(fù)勞動(dòng)這個(gè)矩陣?yán)镒钊菀壮鰡?wèn)題的一環(huán)是“Assigned”到“Fixing”的中間地帶。很多時(shí)候測(cè)試把Bug派給了開發(fā)負(fù)責(zé)人負(fù)責(zé)人在忙別的事Bug就躺在“已分配”狀態(tài)里沒(méi)人動(dòng)彈。要解決這個(gè)問(wèn)題最好的辦法是定一個(gè)明確的時(shí)效規(guī)則——比如“分到個(gè)人手里之后24小時(shí)內(nèi)必須更新處理意見”這樣流程才不會(huì)被卡在中間環(huán)節(jié)。4.3 缺陷生命周期中的三種異常流轉(zhuǎn)做過(guò)幾年測(cè)試的人或多或少都遇到過(guò)下面這幾種異常流轉(zhuǎn)它們是缺陷工程“管理含量”最高的地方。第一種異常是無(wú)效重開。Bug修完了驗(yàn)證也通過(guò)了上線之后用戶又踩到同一個(gè)坑。這種重開通常說(shuō)明兩種可能要么修復(fù)不徹底只堵住了當(dāng)時(shí)的復(fù)現(xiàn)路徑問(wèn)題根因還藏在更深層要么是回歸驗(yàn)證的環(huán)境和場(chǎng)景和生產(chǎn)環(huán)境有差異測(cè)了等于沒(méi)測(cè)。遇到這種情況我建議不要急著重新分配而是先做一次根因確認(rèn)搞清楚是不是上次修復(fù)方案本身就是個(gè)“創(chuàng)可貼”。第二種異常是修復(fù)引入新缺陷。這是軟件工程里很經(jīng)典的“副作用”。改了一個(gè)Bug結(jié)果連帶把另外一個(gè)正常功能搞壞了。尤其是項(xiàng)目里代碼耦合度比較高、又沒(méi)有完善的自動(dòng)化回歸用例時(shí)這個(gè)問(wèn)題會(huì)特別猖獗。應(yīng)對(duì)上除了依賴回歸測(cè)試缺陷工程還強(qiáng)調(diào)一個(gè)動(dòng)作——修復(fù)時(shí)必須注明影響分析。開發(fā)在提交修復(fù)時(shí)要說(shuō)明“我改了哪幾個(gè)文件、這塊邏輯牽涉到哪些上下游”測(cè)試拿到這個(gè)信息后才能做針對(duì)性的回歸而不是全量亂點(diǎn)。第三種異常是長(zhǎng)期掛起的僵尸缺陷。狀態(tài)一直停在“延期”或“待溝通”一停就是一兩個(gè)月。這類問(wèn)題往往是團(tuán)隊(duì)回避決策的表現(xiàn)——沒(méi)人愿意拍板說(shuō)這功能我們不做了于是就讓Bug躺在清單里發(fā)霉。我個(gè)人的處理習(xí)慣是每個(gè)月做一次僵尸清單清理會(huì)超過(guò)30天狀態(tài)未變動(dòng)的缺陷全部拎出來(lái)過(guò)一遍該關(guān)閉的關(guān)閉、該升級(jí)的升級(jí)、該砍需求的砍需求。寧可做減項(xiàng)決策也不要留著一堆“半死不活”的尾巴消耗團(tuán)隊(duì)注意力。4.4 在實(shí)踐中優(yōu)化狀態(tài)流減少無(wú)效環(huán)節(jié)關(guān)于生命周期我還要多啰嗦一句流程不是越復(fù)雜越好。有的團(tuán)隊(duì)為了“精細(xì)管理”在狀態(tài)機(jī)上加了各種過(guò)渡態(tài)比如“修復(fù)驗(yàn)證中”“回歸中”“已確認(rèn)準(zhǔn)備修復(fù)”聽著挺縝密實(shí)際用起來(lái)大家根本懶得去區(qū)分最后狀態(tài)數(shù)據(jù)一塌糊涂統(tǒng)計(jì)分析也無(wú)從談起。缺陷工程的經(jīng)驗(yàn)法則是狀態(tài)機(jī)越短越好夠用就行。每個(gè)狀態(tài)都應(yīng)該對(duì)應(yīng)一個(gè)“明確的待辦動(dòng)作”如果某個(gè)狀態(tài)描述不出“當(dāng)前階段具體在等什么、誰(shuí)在干活”那就是多余的狀態(tài)直接刪掉。我經(jīng)歷過(guò)最順暢的一套流程其實(shí)只有六個(gè)狀態(tài)——New、Assigned、Fixing、Fixed、Verified、Closed加上Rejected和Deferred兩個(gè)旁路。團(tuán)隊(duì)用順手之后缺陷流轉(zhuǎn)效率反而明顯提升因?yàn)榇蠹也辉偌m結(jié)細(xì)節(jié)分類注意力都集中在推動(dòng)事情往前走。5. 缺陷報(bào)告的八大要素為什么你寫的Bug單沒(méi)人理5.1 一份能“一次通過(guò)”的缺陷報(bào)告長(zhǎng)什么樣在缺陷工程這個(gè)框架里缺陷報(bào)告Bug單不僅僅是一條“問(wèn)題記錄”它更像是測(cè)試人員和開發(fā)人員之間的技術(shù)溝通協(xié)議。一份寫得好的缺陷報(bào)告開發(fā)拿到就能定位、就能復(fù)現(xiàn)、就能判斷影響范圍不需要再拉著測(cè)試問(wèn)東問(wèn)西一份寫得差的缺陷報(bào)告開發(fā)看完一頭霧水來(lái)回追問(wèn)幾次之后這個(gè)Bug很可能就被人為地降級(jí)處理了。這不是在危言聳聽。我觀察過(guò)很多團(tuán)隊(duì)開發(fā)處理Bug的效率差異很大一部分來(lái)自缺陷報(bào)告的質(zhì)量。報(bào)告寫得清楚一個(gè)Bug從分配到修復(fù)可能只要半天報(bào)告寫得模糊光上下文溝通就要花掉兩三倍時(shí)間。那什么才算“質(zhì)量過(guò)關(guān)”我提煉了八個(gè)要素你拿著這個(gè)清單去對(duì)照自己的缺陷報(bào)告基本不會(huì)有遺漏。第一是標(biāo)題要能“一句話定位”。不要寫“首頁(yè)報(bào)錯(cuò)”“數(shù)據(jù)不對(duì)”這種模糊標(biāo)題而是寫成“后臺(tái)管理-用戶列表-點(diǎn)擊導(dǎo)出按鈕后頁(yè)面報(bào)500錯(cuò)誤”。一個(gè)合格的標(biāo)題應(yīng)該包含模塊、頁(yè)面/接口、操作動(dòng)作、現(xiàn)象這幾個(gè)要素讓開發(fā)瞄一眼就知道大概是哪塊代碼的事。第二是前置條件要寫完整。包括測(cè)試環(huán)境、數(shù)據(jù)準(zhǔn)備、賬號(hào)權(quán)限、系統(tǒng)狀態(tài)。比如你用的是一個(gè)只有特定權(quán)限的賬號(hào)或者必須提前造好某類訂單數(shù)據(jù)不寫清楚的話開發(fā)復(fù)現(xiàn)的時(shí)候就會(huì)卡在第一步。第三是復(fù)現(xiàn)步驟要細(xì)到不可再拆。這是缺陷報(bào)告里最關(guān)鍵的部分。步驟要按順序編號(hào)每一步都寫清“做了什么、看到了什么”。我尤其強(qiáng)調(diào)要寫“在哪里停的”——也就是用戶最終展示出的異常狀態(tài)這樣開發(fā)才能精確走到那一步去觀察。第四是期望結(jié)果與實(shí)際結(jié)果對(duì)比。必須明確寫出“按照預(yù)期應(yīng)該是什么樣”和“現(xiàn)在實(shí)際變成了什么樣”。這兩個(gè)結(jié)果一對(duì)比問(wèn)題邊界就出來(lái)了開發(fā)能迅速判斷定位方向。第五是嚴(yán)重程度和優(yōu)先級(jí)這個(gè)前面已經(jīng)詳細(xì)說(shuō)過(guò)標(biāo)準(zhǔn)提交時(shí)按照統(tǒng)一標(biāo)準(zhǔn)填上就行。第六是環(huán)境信息包括操作系統(tǒng)、瀏覽器版本、分辨率、設(shè)備型號(hào)、App版本/后臺(tái)版本等。如果是兼容性相關(guān)的缺陷環(huán)境信息更是決定性的排查線索。第七是附件證據(jù)包括截圖、錄屏、日志、調(diào)用鏈信息。這里我要特別說(shuō)一句截圖里要標(biāo)注出問(wèn)題區(qū)域用紅框或者箭頭把異常點(diǎn)圈出來(lái)節(jié)省開發(fā)辨別的時(shí)間日志要截取“異常發(fā)生前后”的片段而不是整屏亂傳。第八是關(guān)聯(lián)信息比如相關(guān)聯(lián)的需求編號(hào)、版本號(hào)、代碼分支、是否為回歸引入等。這些信息能給缺陷的分析和追溯提供背景支撐。5.2 復(fù)現(xiàn)步驟的寫作技巧與常見誤區(qū)復(fù)現(xiàn)步驟這部分值得單獨(dú)拿出來(lái)說(shuō)因?yàn)樗荁ug單里被寫得最敷衍、也是最影響效率的部分。我自己見過(guò)太多的Bug單復(fù)現(xiàn)步驟寫著“輸入數(shù)據(jù)點(diǎn)擊保存然后就報(bào)錯(cuò)了”“隨便填一下信息頁(yè)面就崩了”。這種描述等于什么都沒(méi)說(shuō)。合格的步驟應(yīng)該精確到參數(shù)級(jí)別——輸入了哪個(gè)賬號(hào)、哪幾個(gè)字段、填了什么值、經(jīng)過(guò)哪些頁(yè)面跳轉(zhuǎn)、點(diǎn)的是哪個(gè)顏色/位置的按鈕。這里有個(gè)小技巧我一直在用寫復(fù)現(xiàn)步驟時(shí)把“操作”和“觀察結(jié)果”交替著寫。每一步都用兩句話描述——“我做了什么操作操作之后我看到了什么”。這個(gè)習(xí)慣能逼著自己留意每一步的反饋很多時(shí)候?qū)懲瓴襟E自己就能發(fā)現(xiàn)前面漏了關(guān)鍵前提。另外還要注意復(fù)現(xiàn)步驟要能建立一個(gè)“最小可復(fù)現(xiàn)路徑”。如果問(wèn)題需要操作五步才能暴露那要想想是不是前四步里有某一步其實(shí)可以省略。在Bug單中提供最精簡(jiǎn)的觸發(fā)路徑對(duì)開發(fā)定位效率和開發(fā)自測(cè)時(shí)的復(fù)現(xiàn)成功概率都有決定性影響。開發(fā)能快速?gòu)?fù)現(xiàn)一個(gè)Bug它的修復(fù)速度和修復(fù)質(zhì)量都會(huì)上一個(gè)臺(tái)階。5.3 缺陷報(bào)告也是評(píng)審對(duì)象把Bug單的質(zhì)量管起來(lái)既然說(shuō)缺陷報(bào)告是“協(xié)議”那它就得被評(píng)審。在很多成熟團(tuán)隊(duì)里測(cè)試負(fù)責(zé)人會(huì)抽檢Bug單質(zhì)量每周挑幾份做評(píng)審看是否滿足信息完整度要求。這個(gè)動(dòng)作看起來(lái)多了一道管理手續(xù)實(shí)際是性價(jià)比極高的投入。你會(huì)發(fā)現(xiàn)Bug單質(zhì)量問(wèn)題往往不是個(gè)人能力問(wèn)題而是組織對(duì)“信息質(zhì)量”這件事本身沒(méi)有要求。一旦測(cè)試負(fù)責(zé)人開始定期反饋“這周的Bug單有哪些描述不清、哪些缺少環(huán)境信息”整個(gè)團(tuán)隊(duì)的提報(bào)水平會(huì)很快上一個(gè)臺(tái)階。這也是缺陷工程和“隨手提Bug”之間一個(gè)最明顯的分水嶺。6. 缺陷數(shù)據(jù)分析入門從Bug數(shù)量到質(zhì)量信號(hào)6.1 基礎(chǔ)度量指標(biāo)缺陷密度、缺陷移除率與遺留缺陷率缺陷工程做到一定程度就必須開始和數(shù)字打交道了。因?yàn)橹话袯ug管起來(lái)、關(guān)掉還只是“止血”真正有價(jià)值的動(dòng)作是把缺陷數(shù)據(jù)變成管理和改進(jìn)的輸入——這就要靠度量指標(biāo)了。初學(xué)缺陷工程我會(huì)建議先掌握三個(gè)最基礎(chǔ)的指標(biāo)它們能回答三個(gè)核心問(wèn)題這次交付的質(zhì)量底子怎么樣、測(cè)試活動(dòng)到底有沒(méi)有效、上線之后的風(fēng)險(xiǎn)還有多大。缺陷密度Defect Density計(jì)算公式是“缺陷總數(shù) ÷ 功能模塊規(guī)模通常是代碼行數(shù)或功能點(diǎn)數(shù)”。它衡量的是“每單位代碼量里藏著多少缺陷”。這個(gè)指標(biāo)適合模塊之間做橫向?qū)Ρ取绻硞€(gè)模塊的缺陷密度顯著高于其他模塊那這個(gè)模塊大概率存在設(shè)計(jì)或管理上的隱患需要專項(xiàng)質(zhì)量加固。缺陷移除率Defect Removal Efficiency簡(jiǎn)稱DRE計(jì)算公式是“測(cè)試階段發(fā)現(xiàn)的缺陷 ÷測(cè)試階段發(fā)現(xiàn)的缺陷 用戶反饋的缺陷”。它衡量的是測(cè)試活動(dòng)“攔住問(wèn)題”的能力。這個(gè)指標(biāo)我特別看重因?yàn)樗苤苯臃从硿y(cè)試投入的產(chǎn)出比。如果上線后用戶持續(xù)反饋問(wèn)題、DRE偏低那就要反思測(cè)試設(shè)計(jì)是否覆蓋了真實(shí)用戶的使用路徑。遺留缺陷率Outstanding Defect Rate指發(fā)布時(shí)仍未修復(fù)的缺陷占缺陷總量的比例通常按嚴(yán)重級(jí)別分檔統(tǒng)計(jì)。這個(gè)指標(biāo)直接支撐“是否達(dá)到發(fā)布標(biāo)準(zhǔn)”的決策——比如S0和S1級(jí)別遺留為零、S2級(jí)別遺留不超過(guò)三個(gè)且都有明確延期理由那就可以判斷為具備發(fā)布條件。6.2 缺陷趨勢(shì)分析識(shí)別版本的“收斂拐點(diǎn)”比絕對(duì)數(shù)量更有價(jià)值的是趨勢(shì)。我習(xí)慣在每個(gè)迭代/版本周期里按天統(tǒng)計(jì)“新發(fā)現(xiàn)缺陷數(shù)”和“關(guān)閉缺陷數(shù)”兩條曲線放在同一張圖里觀察。最理想的狀態(tài)是版本前期新發(fā)現(xiàn)數(shù)量快速攀升中后期開始下降同時(shí)關(guān)閉數(shù)持續(xù)走高兩條曲線出現(xiàn)交叉。這個(gè)交叉點(diǎn)就是“收斂拐點(diǎn)”。過(guò)了這個(gè)點(diǎn)如果新發(fā)現(xiàn)的趨勢(shì)高于關(guān)閉趨勢(shì)、或者又出現(xiàn)反彈那就說(shuō)明測(cè)試暴露問(wèn)題的節(jié)奏慢于修復(fù)節(jié)奏或者新引入的缺陷在持續(xù)制造增量版本并沒(méi)有真正趨于穩(wěn)定。根據(jù)曲線形態(tài)還能判斷測(cè)試策略本身的問(wèn)題。比如一個(gè)版本到了后期新發(fā)現(xiàn)缺陷曲線突然再次上揚(yáng)那往往意味著前面的測(cè)試執(zhí)行有遺漏補(bǔ)測(cè)才剛開始發(fā)力。這種“質(zhì)量信號(hào)”對(duì)項(xiàng)目經(jīng)理和測(cè)試負(fù)責(zé)人來(lái)說(shuō)比看任何匯總報(bào)表都直觀。6.3 缺陷根因分析為什么有的模塊永遠(yuǎn)在填坑缺陷數(shù)據(jù)分析的進(jìn)階玩法是根因歸類Root Cause Category。每次關(guān)閉一個(gè)缺陷時(shí)可以在缺陷記錄里加一個(gè)字段——“問(wèn)題產(chǎn)生的根因?qū)儆谀囊活悺毙枨罄斫馄?、編碼邏輯錯(cuò)誤、接口協(xié)議不一致、數(shù)據(jù)遷移遺漏、并發(fā)場(chǎng)景考慮不足……這些類別就是缺陷工程的“病灶圖譜”。當(dāng)數(shù)據(jù)積累到一定量級(jí)后你會(huì)發(fā)現(xiàn)一個(gè)殘酷的事實(shí)團(tuán)隊(duì)里反復(fù)出問(wèn)題的地方往往總集中在某幾類根因上。有的模塊頻繁出Bug不是開發(fā)不努力而是每次都在同一個(gè)根因上翻車——比如接口變更沒(méi)有通知到位、數(shù)據(jù)結(jié)構(gòu)調(diào)整沒(méi)有同步消費(fèi)方。這時(shí)候缺陷工程的重點(diǎn)就從“處理單條Bug”升級(jí)成了“處理整類問(wèn)題”——推動(dòng)接口文檔規(guī)范、建立變更通知機(jī)制、增加契約測(cè)試。這才是缺陷分析真正的價(jià)值所在不只讓單條缺陷被修復(fù)而是讓一類缺陷不再產(chǎn)生。到這個(gè)階段你已經(jīng)從“缺陷管理者”變成了“質(zhì)量改進(jìn)者”。這一步的跨越才是缺陷工程這門學(xué)問(wèn)最迷人的地方。7. 缺陷工程1的核心框架收尾先立規(guī)矩再談工具寫到這兒缺陷工程第一階段的基礎(chǔ)框架就鋪完了。最后想結(jié)合我個(gè)人在幾個(gè)項(xiàng)目里的實(shí)際經(jīng)驗(yàn)做幾點(diǎn)補(bǔ)充收尾——不是總結(jié)而是給剛想在自己團(tuán)隊(duì)里推這套東西的朋友一些親身感悟。第一點(diǎn)不要上來(lái)就上一堆管理工具。工具只是流程的載體先把分類標(biāo)準(zhǔn)、嚴(yán)重程度定義、狀態(tài)流轉(zhuǎn)規(guī)則、報(bào)告規(guī)范這四個(gè)基礎(chǔ)規(guī)則和團(tuán)隊(duì)對(duì)齊了工具那頭填什么字段都心中有數(shù)了再引入缺陷管理系統(tǒng)才不會(huì)變成“為了填表而填表”。很多團(tuán)隊(duì)工具用得極其復(fù)雜但流程規(guī)則一塌糊涂最后所有人都在遷就工具而不是讓工具輔助管理——這完全是本末倒置。第二點(diǎn)從“最痛的那個(gè)點(diǎn)”切開推行。如果你們團(tuán)隊(duì)現(xiàn)在最大的痛是“開發(fā)不看Bug單”那就別急著搞度量指標(biāo)先磨報(bào)告質(zhì)量把八大要素立起來(lái)如果最大的痛是“Bug狀態(tài)永遠(yuǎn)是一筆糊涂賬”那就先做狀態(tài)流轉(zhuǎn)規(guī)范明確每步責(zé)任人。缺陷工程覆蓋面很廣一次全上必然消化不良切一個(gè)點(diǎn)、打出效果、讓團(tuán)隊(duì)感受到便利后續(xù)推起來(lái)才有群眾基礎(chǔ)。第三點(diǎn)容忍前期效率變低。新流程上線的頭一兩個(gè)月團(tuán)隊(duì)因?yàn)椴皇煜ぬ嵋粋€(gè)Bug可能比過(guò)去多花一倍時(shí)間Bug周期也未必立刻變短。這時(shí)候最忌動(dòng)搖只要狀態(tài)數(shù)據(jù)開始變干凈、報(bào)告質(zhì)量開始提升后面能沉淀出來(lái)的分析價(jià)值一定會(huì)翻倍回報(bào)。我自己在各項(xiàng)目里反復(fù)驗(yàn)證過(guò)這一點(diǎn)——缺陷工程是前期投入、中期見效、后期滾雪球的管理動(dòng)作它不負(fù)責(zé)立竿見影但會(huì)在跨版本的質(zhì)量對(duì)比里給你越來(lái)越清晰的決策依據(jù)。下一篇等講缺陷工程2時(shí)我會(huì)把缺陷追蹤流程的考核策略、跨團(tuán)隊(duì)協(xié)作中的缺陷爭(zhēng)議仲裁、以及缺陷預(yù)防工程Defect Prevention常用的頭腦風(fēng)暴法展開細(xì)聊。到時(shí)候你會(huì)發(fā)現(xiàn)當(dāng)缺陷工程從“管理單條Bug”走向“驅(qū)動(dòng)質(zhì)量改進(jìn)”它對(duì)測(cè)試團(tuán)隊(duì)能力建設(shè)的價(jià)值會(huì)遠(yuǎn)超你的預(yù)期。