微軟Bug管理

　　一.團隊組織

　　1.常見問題

　　沒有人愿意做測試

　　覺得養不起那么多測試人員

　　開發人員不遵循規范，隨心所欲

　　項目經理事必躬親，分身乏術

　　2.微軟團隊模型

　　各角色的職責

　　二.項目管理

　　1.常見問題

　　無法決定項目所需的資源(人力和預算)

　　無法決定項目的進度表

　　無法控制外包項目的進度和質量

　　2.微軟項目管理-- 多里程碑式流程

　　每個里程碑完成部分功能

　　便于團隊集中力量完成一個又一個功能

　　提供多個機會以適應需求的更改

　　如何完成一個里程碑

　　步驟一： 達成共識

　　基本完成需求調研和分析 (產品經理負責)

　　確定大方向和長中短期目標

　　所有角色都參與討論并真正認同結論

　　產生的文檔：

　　常見用戶情景：覆蓋80%以上功能

　　Vision：言簡意賅地說明大方向，并有激勵團隊的作用

　　步驟二： 完成項目計劃

　　編寫詳細的功能規范(項目經理負責)

　　在編程前想清楚所有功能流程，并引導用戶明確需求

　　所有角色都參與審閱功能規范

　　制訂開發計劃和進度表(開發團隊)

　　制訂測試計劃和進度表(測試團隊)

　　分配資源(人力和預算)

　　形成項目綜合計劃和綜合進度表

　　產生的文檔：

　　功能規范，開發計劃，測試計劃(用例)，項目綜合計劃

　　開發進度表，測試進度表，綜合進度表

　　步驟三： 完成功能

　　開發人員分別完成自己的功能

　　使用版本控制工具

　　使程序員及時check out和check in，避免積累大量代碼

　　及時進行模塊間的整合，及時發現問題(daily build)

　　對每一項可測試的功能進行測試，無需等待

　　使用測試用例工具，對功能進行完整和重復的檢驗

　　使用BMS進行缺陷跟蹤

　　記錄所有程序問題

　　實現解決Bug的自動流程

　　按照綜合進度表不斷檢查進度

　　使用的工具：

　　版本控制工具 VSS

　　缺陷跟蹤工具 Raid/BMS

　　測試用例管理工具

　　步驟四： 穩定與發布

　　測試組全面地測試功能，包括性能和穩定性

　　開發組全力配合解決Bug

　　使用BMS進行

　　監測質量情況

　　預測發布日期

　　專家會診機制：

　　決定Bug的優先度

　　決定哪些Bug可以等到下個里程碑或版本中解決

　　決定由誰解決某個Bug

　　使用的工具：

　　版本控制工具 VSS

　　缺陷跟蹤工具 BMS

　　測試用例管理工具

　　三. 微軟的開發管理經驗：100%以Bug為核心

　　1.Bug 及常見類型

　　功能未實現，和規格說明書不一致

　　不能工作：死機，沒反應

　　不兼容

　　邊界條件

　　界面、消息、提示不夠準確，不友好

　　把尚未完成的工作也作為一個Bug

　　文檔與幫助信息中的缺陷也是Bug

　　2.RAID/BMS的基本功能

　　完整的Bug數據庫

　　整個產品組的中央記錄和控制

原文轉自：http://www.uml.org.cn/Test/200410191.htm