這是《落葉》文集里第 210 片落葉，希望你能喜歡誓斥，不為別的综看，只為這份堅(jiān)持。
【背景】
老師岖食，我想問一下红碑，bug 應(yīng)該是見一個(gè)回歸一個(gè)，還是集中一大串 bug 回歸好呢？我喜歡見一個(gè)殺一個(gè)析珊，但問題是他如果后面的代碼改出問題的話就很麻煩羡鸥。集中一起回歸的話，又很浪費(fèi)時(shí)間忠寻。怎么辦好呢惧浴？
【你問】
什么才是驗(yàn)證 bug 的正確姿勢？
【我答】
驗(yàn)證 bug 是測試工程師最基本的工作之一奕剃，是在發(fā)現(xiàn) bug 之后衷旅，提交給開發(fā)工程師修復(fù)之后，在新的測試包里需要做的事情纵朋，一般包括兩部分內(nèi)容：第一柿顶，先按照 bug 的重現(xiàn)步驟執(zhí)行一下，確認(rèn) bug 不存在了操软，已經(jīng)被修復(fù)了嘁锯；第二，再根據(jù)開發(fā)提供的測試建議和你自己分析判斷出的范圍進(jìn)行回歸測試聂薪；
當(dāng)這兩部分都完成后家乘，bug 驗(yàn)證工作才算全部完成。一般的測試項(xiàng)目藏澳，每個(gè)測試包提交到測試這邊時(shí)仁锯，都是要求先完成 bug 的驗(yàn)證和回歸測試，再開始繼續(xù)其他功能或需求的測試翔悠，目的就是要先確保這個(gè)測試包沒有太多因?yàn)樾迯?fù) bug 而引發(fā)的回歸性問題扑馁。
就這個(gè) bug 是改一個(gè)就驗(yàn)證一個(gè)，還是等改了一批再一起驗(yàn)證的問題凉驻，其實(shí)各有利弊。
首先复罐，從測試細(xì)度上看的話涝登，前者肯定細(xì)于后者，但前者需要測試跟開發(fā)有較為頻繁的溝通效诅，因?yàn)槊恳粋€(gè) bug 修復(fù)的影響范圍都需要被確定胀滚。
其次，從工作量上看的話乱投，前者肯定大于后者咽笼，因?yàn)榍罢呤歉囊粋€(gè)驗(yàn)證一個(gè)，而后者可以集中驗(yàn)證戚炫，按修復(fù)的范圍整體回歸測試剑刑。
再者，前者遺漏回歸性 bug 的幾率也大于后者，因?yàn)殚_發(fā)也不可能百分之百給出準(zhǔn)確的修復(fù)影響范圍施掏，所以钮惠，可能在后面修復(fù)某個(gè) bug 的時(shí)候，影響到了前面已經(jīng)回歸過的一個(gè)功能點(diǎn)七芭，而開發(fā)和測試都沒有想到素挽，這樣就會(huì)遺漏。
另外狸驳，補(bǔ)充一點(diǎn)预明，就是不管是什么類型的產(chǎn)品，或者是什么類型的項(xiàng)目耙箍。一定需要有測試版本管理撰糠，哪怕是有持續(xù)集成支撐的項(xiàng)目，都不建議只要開發(fā)有 checkin code究西，就會(huì) build 一個(gè)測試包部署到測試環(huán)境供測試工程師測試窗慎，而是要計(jì)劃好每天或者每周的 build 頻率。
我們之前最快也就做到了 Daily Build卤材，因?yàn)樽詣?dòng)化測試腳本也無法百分之百覆蓋所有的回歸性測試遮斥，如果無計(jì)劃無節(jié)奏的 build，測試工程師很難保證每個(gè) build 的所有功能都是正常的扇丛。
只有一種情況需要 build 計(jì)劃外的測試包术吗，那就是某個(gè)測試包存在 block bug，不修復(fù)的話帆精，某個(gè)功能或者有一大片功能點(diǎn)都無法正常繼續(xù)測試了较屿，這時(shí)候必須要求立即修復(fù)，然后 build 一個(gè)測試包出來給測試工程師卓练。
從效率上說隘蝎，如果有幾個(gè) bug 是一條業(yè)務(wù)流程路徑上的，可以通過走一條用例襟企，就完成了幾個(gè) bug 的驗(yàn)證和回歸測試嘱么，而如果分開驗(yàn)證，同一條路徑顽悼，有幾個(gè) bug 就需要執(zhí)行幾次曼振。
從注意力上說，你集中幾個(gè)屬于一個(gè)功能模塊或業(yè)務(wù)流程路徑上的 bug 做驗(yàn)證蔚龙，注意力會(huì)比你一個(gè)個(gè) bug 驗(yàn)證冰评，頻繁的在不同的功能模塊或路徑上切換，來的更集中木羹，質(zhì)量更好甲雅。
《測試路上你問我答》里的 Q&A 68，如果是你要的，甚好务荆！如果不是妆距，你問，我答函匕！
作者簡介：14 年測試 + 11 年項(xiàng)目管理 + 11 年團(tuán)隊(duì)管理 = 一個(gè)測試?yán)媳?/p>
