字體: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推薦標簽： Bug 軟件測試 缺陷管理
微博上拋出一個討論話題：下午一test lead問到，有些測試的 bug會在A版本里出現，然后記錄它；但開發人員在當前B版本試圖重現時發現不能重現，故reject它。那么測試就郁悶了，待到下一輪回歸測試可能是C 版D版本，如果再出現自然reopen，但如果不復現是否真的應該關掉它嗎？各位對這種sometimes bug怎么處理的啊？
這個問題可能每個測試人員都會遇到，我說說我個人觀點，供大家討論。
1、在A版本發現的bug應該在A版本進行重現
我們知道，有很多原因會導致A版本的bug可能不能在B版本重現：1）開發人員自己偷偷解了bug，以免受到KPI考核；2）環境差異，可能B版本的代 碼在A版本的環境也會出問題，但是在開發環境可能就不能復現；3）代碼變更，也許是其他的代碼引起的bug，B版本時其他開發已經修改，此類可以歸納為相 關聯功能引起的bug；4）AB兩版本進行復現的前置條件及步驟已不同。
既然有這么多可能性，那我們就應該排除影響，讓問題簡單化，保持環境和代碼一致的情況下進行復現。A版本的bug如果在B版本不能復現，時間和條件允許的話，那就回退代碼到A版本，有個前提不用回退，那就是已準確定位問題了，并且確定在B版本已經解決它了。
2、項目時間允許的情況下，開發人員應大力協作復現bug
對于”疑難雜癥“，開發人員應大力配合測試人員進行復現：1）如果對于不好調試的代碼就打印更多log；2）可以通過連接測試環境數據庫并 回滾代碼到A版本，根據獲悉的已有情況添加斷點調試代碼；3）做更細致的code review等等方式。在自己負責的那部分代碼確定完沒有問題，這時候就需要考慮到接口，是否在接口數據處理上的問題，就需要其他開發人員配合。而測試人 員需要盡最大努力來還原當時的場景：環境，數據，前置條件及測試步驟等。
3、測試人員要再次確認用例設計的覆蓋度及周密性
有幾種情況會導致不可復現：1）環境；2）代碼；3）數據。而數據又可以歸納到代碼容錯性處理上，環境其實是可以很好還原的，那出現不容易復現的bug就大多數是歸于代碼和數據上了，對于測試而言，用例設計的覆蓋不夠，不夠嚴謹就會導致bug不在我們的掌握中。
這個時候，我們有兩種情況：一是原本用例就沒有好好設計過，未經評審過，大家測試時就很隨意，勿容置疑，趕緊把用例好好琢磨琢磨，再叫上項目相關人員進行評審，這么做的目的也是為了保證測試用例得到了項目相關人員的認可，各種情況大家都討論過，保證在需求上大家的一致性，保證軟件覆蓋度能滿足本次項目需求的要求，做到需求100%覆蓋，開發人員若再提出更多建議，那也可以彌補一些黑盒測試時可能遺漏的情況；二是該項目已經經過嚴格的需求評審及用例評審了。當然，即便如此也不能避免漏測以及對特殊情況的考慮。
當然，要這么做的前提是這個bug很嚴重，影響了版本的發布，有必要召集大家協力解決掉它。
4、絞盡腦汁，它仍然不能復現時，保持關注
我相信，通過以上步驟的努力，仍然不能復現的bug一定是優先級不高的，那就再評估重要度，若通過項目組決定不影響版本發布，就密切關注此bug，在發 布后驗證時也重點關注下。而且該bug不能關閉，依次往以后版本中順延，并且每輪測試時都要嘗試再次復現。那何時可以關閉呢？也許3，5個版本發布后，沒 有出問題就可以決定關閉它了。
5、思考測試流程及測試規范，及時更正走過的彎路，制定提交bug的規范，便于開發及我們自己復現
有一次，就會有第二次，我們應該及時響應，即便不能亡羊補牢，也要防患未然。 提交bug的規范，這個可能每個公司情況不一樣，有些公司木有限制，提交的bug也是千人千面，這對于開發人員理解bug和復現bug無疑增加了難度。而 規范了bug提交，若記錄了此bug的前置條件，使用的數據及操作步驟，可能會大有益處。當然，此處不是說每個bug都這么詳細。
版權聲明：本文出自 zzzmmmkkk 的51Testing軟件測試博客：http://www.51testing.com/?258885
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。