發現的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都這麼詳細。