構建高效軟件開發流程
發布: 2008-8-21 10:00 | 作者: 不詳 | 來源: 領測軟件測試網采編 | 查看: 11次 | 進入領測軟件測試網論壇討論
7. BUG管理
由于我們每天進行著測試，因此經常有BUG被測試部門發現，一旦發現了新的BUG，就會被添加進BUG Tracking System中。目前較流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是開發人員和QA之間的紐帶，開發人員和QA通過BUG tracking system聯系著。每個BUG有其類型和級別，預定的類型有Crash-Data Loss, Crash-No Data Loss, Incorrect functionality, Cosmetic, Feature request等, 級別有P1、P2一直到P6，它們分別代表了重要性及緊急程度，P1的BUG需要很快fix，P5之前的BUG在本版本release之前必須fix掉，若真的不能或不重要則由QA確定并降低優先級進入到下一個版本中去fix。QA發現一個BUG后在BUG Track中增加一個BUG，同時填入相關信息并assign給相應的開發人員，開發人員收到BUG分析并fix后assign給QA去verify，其中要填上分析的結果以及如何解決的詳細說明。若QA對此BUG verify通過則close BUG，否則verify failed并重新assign給開發人員并等待其fix。每星期在Status Meeting上會進行BUG狀況報告，主要由QA組長報告BUG的狀況，主要是新增BUG數，fix掉多少，還有多少處于open狀態，有多少處于等待verify的狀態，據此可以了解開發及測試情況。有時在Status Meeting上我們也會進行BUG Review，BUG Review有時是單獨一個小組內進行，其主要作用是重新明確每個人頭上的BUG以及了解每個BUG的狀況，如開發人員對此BUG將作何處理等，以此來了解開發中是否有碰到比較棘手的問題，增加了產品發布風險。在QA增加BUG和開發人員fix BUG的游戲中，BUG的數量曲線圖會象股市曲線一樣上下波動，但總體趨勢一般是前期BUG放量攀升，后期震蕩下挫，若到了后期新open的BUG數量一直上升則說明風險在增大，有可能無法控制，也就是說fix了一個BUG導致了多個新的BUG產生。在量化開發進度中也可以用代碼數量的曲線圖來粗略的呈現。在有大量新功能增加時可能代碼量的增加會較快，當在fix bug階段，代碼的修改較多，因此代碼數量的增幅會降低，依據代碼量可以看出開發的狀況處于何種階段。
需要指出的是我們對BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過這些BUG級別比較低，讓它們進入到下一個版本中去實現。因此BUG的創建者也可以是技術支持人員、市場人員甚至開發人員本身。關于開發人員本身，因為他可能會找出一些BUG，有些是其他開發者的，有些可能是此開發者本身的，把這個BUG添加進BUG庫中可以幫助開發人員在以后產生新問題時或類似的BUG時有一個借鑒和思路，但此BUG的verify必須要讓測試本模塊的測試人員來verify。
8. Code Freeze