在項目過程中，測試同學會發現大量的bug，但同時也不可避免的會存在一些遺漏的bug。為了能夠減少遺漏bug的現象，我們需要針對遺漏的問題進行總結，從教訓中積累經驗，總結方法，從而提高測試的覆蓋度，提升產品的整體質量。
什么樣的bug需要進行總結？
1.線上遺漏的bug
沒有被測試發現而遺漏到線上的bug。其影響不言而喻，會直接影響用戶的體驗，影響產品的口碑，勢必需要進行總結。
2.非線上遺漏的bug。
沒有在規定的測試階段發現，從而導致發現晚的bug，例如XX模塊已經測試完畢，結果后來又發現該模塊的新bug。這類bug會導致增加bug修改和驗證的時間，從而有可能影響項目的整體進度，甚至導致項目delay。
什么時機進行bug總結？
1.項目上線后，應盡快進行bug總結，否則時間一長會出現遺忘的情況，包括測試和開發兩方面，給總結操作帶來不便。
2.遇到嚴重的或非常重要的遺漏bug，可隨時進行單獨總結，比如線上發現的嚴重問題。
總結什么內容？
總結bug的核心，是為了后續減少遺漏bug，提高測試覆蓋度，提升項目質量。想要達到這個目的，首先需要分析bug的原因，尤其是遺漏原因；其次是確定后續的改進方案，避免類似的問題再次發生。
原因分析：
bug遺漏的原因一般分為幾大類：
-
非遺漏問題：bug總結時，出現概率最高的可能就是非遺漏問題，這類問題並不需要進行具體的總結，其中主要包含三類：
-
不是問題：例如用戶反饋的問題，但符合產品的需求要求，這種就屬於不是問題。
-
開發引入：例如我們測試完成的模塊，開發修改bug，或在測試不知情的情況下修改了代碼，引入的新bug。
-
需變引入：例如我們測試完成的模塊，發生了需變，導致新的bug產生。
-
用例設計遺漏：bug是用例設計時沒有覆蓋到的場景，又可以細分為幾類：
-
基礎用例設計不足：例如需求中詳細說明的內容，沒有在用例中提現。
-
需求理解錯誤：例如需求理解錯誤，導致測試用例的預期結果不正確，而開發實現正好符合錯誤預期。
-
模塊間影響考慮不足：例如沒有A模塊與B模塊有關聯，會對B模塊產生影響，但B模塊的用例中未涉及到相應的場景。
-
復雜路徑無法覆蓋：路徑過於復雜，或者涉及較多層級的操作，例如經過10步操作后才會出現的bug。
-
復雜場景考慮不足：例如兩個或多個看似完全沒有關系的場景，結合起來產生的bug。
-
適配問題考慮不足：例如在某些特定的機型上出現的bug。
-
用例執行遺漏：bug是執行用例過程中出現過，但沒有被發現，可細分為2類：
-
純執行遺漏：測試用例中涵蓋，但沒有執行；或者執行了用例，也出現了問題，發現了問題但沒有提交bug。
-
敏感度不足：測試用例中涵蓋，但沒有明確說明，遇到了問題，但沒有意識到是bug。例如同樣都是頭像，在A頁面是個圓的，在B頁面是個方的。
-
重現率低的問題：重現幾率較低的bug，無穩定復現的步驟。
-
體驗性或性能問題未關注到：需求中沒有明確說明，也未在用例中涉及，但對用戶體驗有影響，后經其他方指出的bug。例如產品logo不夠明確、使用過程中設備發熱等。
改進方案：
針對bug遺漏的不同原因，也有不同的改進方案。
-
非遺漏問題：這種類型，與測試無關，無需改進。
-
用例設計遺漏：
-
補充對應模塊的測試用例，這個是基礎。
-
補充后的case是否具有通用性，如果有，那么需要應用到所有相關的模塊中，並作為后續用例設計的經驗積累。例如：鎖屏后再解鎖會導致某個頁面控件的功能失效，那么各個頁面都應該添加“鎖屏后再解鎖，檢查控件可用”的case。
-
用例執行遺漏：
-
純執行遺漏不可饒恕，除了自己做好備忘外，沒什么更好的改進辦法，這個層面出現問題，更多的應該是自我反思。
-
如果是敏感度不足導致的遺漏，那么可以持續進行經驗積累，提升自己對bug的認知。
-
重現率低的問題：
-
如果是能夠找到具體原因的bug，那么應該深入挖掘，找到問題的本質原因以及重現步驟，然后再進行分析，對遺漏原因進行歸類，然后再進行針對性的改進。
-
如果是無法找到具體原因的bug，這塊暫無有效的改進方法。
-
體驗性或性能問題未關注到：這類問題的改進方案跟敏感度不足的改進方案類似，需要持續的進行積累，提升自己的產品感覺。
其實對於bug總結，應該正面認識，並不是一味的追討責任，而是更好的改進測試方法、提升測試是能力。認真做好bug總結，對測試團隊、測試個人的能力提升，都有很大的幫助。
尊重原創，轉載於搜狗測試公眾號！