對BUG的分析與理解
bug的分類
bug，其實就是軟件期望的行為與實際行為的差異。從程序的角度來看，在軟件整個生命周期中都會有bug的出現。需求分析過程中，需求理解的不足，導致的理解錯位 ，遺漏甚至變化都可能導致bug；設計本身有好壞之分，但是bug本身還是比較隱晦，不是那么明顯。 編碼階段，也會有理解錯誤，語言特性，第三方庫框架，等等導致的bug. 后期打包，部署，運維也會產生 bug，打包的錯誤，配置錯誤，以及環境的錯位。 自己主要談談編碼引入的和環境的導致bug。這是最最經常碰到的bug。
另外也可以從其他方面開分類，比如穩定可重現的bug與不可穩定重現的bug。 比如多線程導致的競爭。數據敏感的導致的不能穩定重現的bug。 從是否與環境關聯，業務邏輯的bug，環境相關的的bug等。
一個BUG的生命周期
缺陷狀態
對於一個問題，其處理過程是一個周期，周期的不同階段，其所處的狀態也是不一樣的。不同狀態所對應的處理人也是不一樣的。
- 打開 ： 表示問題被提交等待有人處理。
- 重新指派 ： 問題被重新指派給某人處理。
- 處理 ： 問題在處理中，尚未完成。
- 固定 ： 確認此問題存在，但暫時不進行處理。
- 回歸 ： 對已經修復的問題進行回歸確認。Reopened
- 關閉 ： 問題的最后一個狀態。
提交（打開）缺陷
在提交一個缺陷的缺陷，首先盡量描述這個缺陷的屬性。Bug重現環境，bug類型，bug等級，bug的優先級以及詳細的重現步驟，結果與期望等。
當然，我們在提交一個問題之前首先應該保證，這個缺陷是沒有被提過的，以免造成重復缺陷單。
如果是回歸不通過的缺陷，其狀態又會變為打開狀態。
分配（轉交）缺陷
這一步不是必須的，跟項目模式有關，有些公司測試部門與開發部門獨立，那么測試人員就不確定自己測試的模塊是由哪位開發人員負責的，在這種情況下，測試人員統一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認后再次分配給相應的開發人員。
有些測試人員是穿插到不同研發團隊中的，所以對不同的開人發員負責的開發模塊非常清楚，這個時候就可以將問題直接指派給相應的開發人員。
也有一種情況，本來此問題應該由A開發人員負責，但由於A開發人員的調離或辭職，些問題為轉交給其它人員處理。“分配”強調是上級對下級；“轉交”強調的是平級之間。
確認缺陷
當開發人員接到一個缺陷時，首先是對其進行分析與重現，如果對其進行分析發現不是缺陷（可能由於測試人員不了解需求）或無法對此問題進行重現，那么就需要將此問題反回給測試人員，並注明原因。如果確認為缺陷則需要對其進行處理。
推遲處理
在處理問題之后，還需要進行一次判斷，是否需要推遲處理，有些需求已經確認了是問題，由於其可能在極端情況下才會出現，或需要對系統架構進行改動，或其優先級非常低，所以暫時不需要對此問題進行處理（或到下個版本進再進行修復）。
固定
對於推遲處理的問題可以暫時進行固定（“固定”為QC中的叫法。）一般固定的問題需要經過項目經理與測試經理協商后才能固定。
處理缺陷
開發人員在確認完一個問題需要處理時，那么就對其進行處理工作。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，當然，對於短時間內可以修復的問題就沒必要時時的去更新處理進度。）
回歸缺陷
回歸缺陷對於測試人員來說是非常重要的工作，其有三個入口兩個出口。
確認非缺陷問題：對於提交的一個缺陷，開人員處理為非問題或無法重現，然后直接轉交給測試人員回歸。測試人員再次確認，如果真如開發人員所說，則將問題關閉。如果非開發人員所說，是由於問題描述模糊或其它原因喂重現問題，則再次注明原因轉給開發人員。
確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次打開並轉給開發人員。
確認固定問題：有計划的對固定問題進行確認，有些固定問題隨着時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對於這類問題應該及時打開交給開發人員處理。
關閉缺陷
對於已經修復的缺陷進行關閉，這也是一個缺陷的最后一個狀態。
過程描述
- 測試工程師開始執行測試，發現bug則新建bug，這時bug是新建狀態。
- 測試組負責人把bug修改為打開狀態，表明開發人員可以修改該bug了。之所以會有打開這一步有兩點目的：第一是測試組負責人對bug進行確認工作，避免提交錯誤的bug，第二是對bug進行一次篩選操作，告訴開發組本次需要修復哪些bug。（這一步需要測試組的負責人驗證所有的bug，有些麻煩，我經歷過的項目都是新建完bug后，由提bug的人直接打開，如果確實不應該提，大不了增加一個無效bug，影響不大）
- 開發工程師找到狀態為打開的bug，不會立即進行修復，也需要判斷是否接受該bug，接受則修改bug，修改完成后把bug狀態置為已修復。如果不接受則置為拒絕。
- 測試工程師找到已修復的bug，在下一版本驗證bug，如果確實已經修改正確，則把bug狀態置為關閉，該bug生命周期結束。
- 拒絕的bug必須由項目組的負責人判斷拒絕是否有效，如果無效，則重新打開，進入修復過程。如果確實無效，則添加備注說明信息，該bug生命周期到此結束。（關於拒絕這一步，還可以新增一個無效狀態。在項目負責人確認bug無效后，改為此狀態，表明開發人員拒絕操作是合理的。只有項目組負責人有置無效的權限。）