《測試路上你問我答》什麼才是驗證 bug 的正確姿勢？

【背景】

老師，我想問一下，bug 應該是見一個回歸一個，還是集中一大串 bug 回歸好呢？我喜歡見一個殺一個，但問題是他如果後面的代碼改出問題的話就很麻煩。集中一起回歸的話，又很浪費時間。怎麼辦好呢？

【你問】

什麼才是驗證 bug 的正確姿勢？

【我答】

驗證 bug 是測試工程師最基本的工作之一，是在發現 bug 之後，提交給開發工程師修復之後，在新的測試包里需要做的事情，一般包括兩部分內容：第一，先按照 bug 的重現步驟執行一下，確認 bug 不存在了，已經被修復了；第二，再根據開發提供的測試建議和你自己分析判斷出的範圍進行回歸測試；

當這兩部分都完成後，bug 驗證工作才算全部完成。一般的測試項目，每個測試包提交到測試這邊時，都是要求先完成 bug 的驗證和回歸測試，再開始繼續其他功能或需求的測試，目的就是要先確保這個測試包沒有太多因為修復 bug 而引發的回歸性問題。

就這個 bug 是改一個就驗證一個，還是等改了一批再一起驗證的問題，其實各有利弊。

首先，從測試細度上看的話，前者肯定細於後者，但前者需要測試跟開發有較為頻繁的溝通，因為每一個 bug 修復的影響範圍都需要被確定。

其次，從工作量上看的話，前者肯定大於後者，因為前者是改一個驗證一個，而後者可以集中驗證，按修復的範圍整體回歸測試。

再者，前者遺漏回歸性 bug 的幾率也大於後者，因為開發也不可能百分之百給出準確的修復影響範圍，所以，可能在後面修復某個 bug 的時候，影響到了前面已經回歸過的一個功能點，而開發和測試都沒有想到，這樣就會遺漏。

另外，補充一點，就是不管是什麼類型的產品，或者是什麼類型的項目。一定需要有測試版本管理，哪怕是有持續集成支撐的項目，都不建議只要開發有 checkin code，就會 build 一個測試包部署到測試環境供測試工程師測試，而是要計劃好每天或者每周的 build 頻率。

我們之前最快也就做到了 Daily Build，因為自動化測試腳本也無法百分之百覆蓋所有的回歸性測試，如果無計劃無節奏的 build，測試工程師很難保證每個 build 的所有功能都是正常的。

只有一種情況需要 build 計劃外的測試包，那就是某個測試包存在 block bug，不修復的話，某個功能或者有一大片功能點都無法正常繼續測試了，這時候必須要求立即修復，然後 build 一個測試包出來給測試工程師。

從效率上說，如果有幾個 bug 是一條業務流程路徑上的，可以通過走一條用例，就完成了幾個 bug 的驗證和回歸測試，而如果分開驗證，同一條路徑，有幾個 bug 就需要執行幾次。

從注意力上說，你集中幾個屬於一個功能模塊或業務流程路徑上的 bug 做驗證，注意力會比你一個個 bug 驗證，頻繁的在不同的功能模塊或路徑上切換，來的更集中，質量更好。

《測試路上你問我答》里的 Q&A 68，如果是你要的，甚好！如果不是，你問，我答！

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！