軟體測試工程師必會：BUG分類及推進解決方案

Bug，中文名缺陷。一個讓軟體測試員興奮，讓開發人員頭疼的詞。來源二次大戰期間，一個稱為“馬克二型”的計算機，由於天氣過熱，硬體跟不上導致當機。最後發現是因為飛蛾，被繼電器電死，將其註明“第一個發現蟲子的例項”。人們將計算機錯誤戲稱為蟲子(bug)，而把找尋錯誤的工作稱為debug，即捉蟲子!加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

軟體bug可以分為幾個類別：

第一類bug可能是隨機的，它們通常是因為一時的疏忽造成的。儘管這些bug可能由於其隨機性很難預防，但是，適當的分析將有助於避免這些bug。自動化測試工具TestWriter進行用例測試，實現無需值守，實時檢視執行情況。

另一類的bug來自於需求的誤解、開發環境的錯誤或者純粹由於缺乏解決問題的相關技術。這類bug共同的特點是都來自於開發人員。除非被發現，否則這些bug將一直存在。如果bug發現和修正越早，開發成本越少，那麼在第一時間就避免bug引入是不是成本消耗得更少?如果bug可以被完全預防，那麼在開發過程中就不會出現重複工作的情況。

那麼bug又分為哪些類呢?

有一些初始的小測試團隊，對BUG單可能會進行重要程度的劃分，但並不會進行型別劃分，其實，如果不對BUG進行錯誤型別定義，專案經理或測試經理並不好確認後續質量提升在哪方面進行改進，具體研發的哪個環節更需要進行改進。故此合理的對BUG單進行分類也是提交BUG的前提。以下是我整理的BUG型別分類情況：

進行BUG型別分類僅是第一步，作為WEB類的專案，一般情況下，明面上的二、三類問題，自測時容易發現且會完成修改，留到測試去提出的機率相對會少一點;而其它類問題常常因為開發時間不夠或不重視等原因，大量的留給了測試階段去提出;對於這類現象，負責的專案經理有時候是心有餘而力不足;而不太負責的專案經理，有可能就睜一隻眼閉一隻眼;作為測試團隊，想要提高提交版本質量，可以用以下幾種方式去做嘗試：

1.與專案組，確認清楚接收版本的準則，即讓專案組成員都清楚存在哪些問題，版本是會打被回。

2.提供P0用例給到開發，提高開發的自測質量;

3.整理不同開發重複出現的問題，與專案經理商議每個問題的具體程式碼上的處理方案，整理為專案組內的知識點，在開發團隊中進行宣導或組織專題會議進行講解。

4.對於嚴重影響測試工作效率或反覆出現的問題單，可以適當的提高問題單的嚴重程度，以引起專案組的重視。

以上，是個人愚見，歡迎大家一起留言交流!