微軟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數據庫
• 整個產品組的中央記錄和控制
• 強大的查詢功能，有效地跟蹤項目的狀態
• 所有的記錄無法刪除，對于每個記錄只能一直添加內容
• 豐富的報表功能，為產品發布提供判斷標準

3．Bug 記錄中的有效信息

狀態 負責人 問題種類 嚴重級 優先級 修改時間 登記時間

缺陷來源 解決方案 運行環境 缺陷關聯 附件 附圖 缺陷細節

4．Bug 的嚴重程度

1. 死機，數據丟失，主要功能組完全喪失，系統懸掛
2. 主要功能喪失，導致嚴重的問題，或致命的錯誤聲明
3. 次要功能喪失， 不太嚴重，如提示信息不太準確
4. 微小的問題，對功能幾乎沒有影響，產品及屬性仍可使用. 如有個錯別字

5．激活的Bug數量的趨勢

• 代碼完成前：很少
• 代碼完成后：增長很快
• 接近Beta: 下降
• 接近RC: 奔向零
• 產品質量和里程碑的信號
• 每天新建的Bug 與 修正的 Bug 相比較
• Active 狀態 Bug 的總數

四．微軟的一天

1． 讓我們看看項目中每個角色的一天是如何度過的

• 開發
• 測試
• 項目經理

注：里程碑的每個階段每個角色的工作有不同側重點，我們以“完成功能”階段為例

微軟的一天從幾點開始？

答案：半夜

為什么？

因為Daily Build是所有工作的核心，而且是在半夜自動啟動。

每日構造Daily Build

• 你知道自己所用Windows的版本號嗎？
• Daily Build的意義：
  • 模塊得以及時整合
  • 要求程序員及時把最新代碼放入代碼庫
• 用腳本語言和編譯/鏈接工具實現
• BVT Build Verification Test
  • 對Build進行驗證
• Blocking Bug
  • 讓Build無法完成的問題
  • BVT中發現的問題

2．程序員每天上班前最擔心什么？

答案：因為自己昨天的代碼check-in，造成Blocking Bug.

為什么？

因為每天的Build是所有人當天工作的基礎：
程序員需要Build驗證與其他模塊的接口
測試需要Build發現新Bug，并驗證新Build中已解決的Bug

有Blocking Bug怎么辦？

解決問題，并對今天的Build打Patch。

開發人員的正事

經歷對Build的提心吊膽和爭分奪秒之后，第一件事做什么
答案：打開缺陷跟蹤工具，查看指定給自己的Bug，解決高優先度的Bug。因為質量重于新功能。

接下來，開發人員會…

從版本控制工具中Check out代碼
修改代碼（解決Bug或實現新功能）
取得版本工具中最新變化，在本機Build和單元測試
請開發組同事作Code Review
Check in代碼



3．測試人員第一件事做什么？

答案：打開Raid/BMS，查看指定給自己的Bug，驗證已解決的Bug。

接下來，測試人員會…

• 根據測試用例檢驗今天的Build
• 在Raid/BMS中記錄新發現的Bug

4．專家會診

• 參加者：項目經理和開發組長、測試組長
• 通過Raid/BMS評估每個未解決的Bug
  • 決定Bug優先度
  • 可否等到下個里程碑或版本解決？
  • 誰來解決
• 預測項目實際進度和發布時間

缺陷走勢圖

5．回顧微軟的一天

• 構造: daily build
• 開發: 解決blocking bugs, 實現功能, check-out, code review, check-in
• 測試: BVT, 使用測試用例進行測試
• 項目經理/組長: 專家會診

6．微軟的做法解決了那些常見問題？

質量問題

• 以前解決過的問題發布時又出現了，需要返工
• 無法預估發布時間 過早發布，帶來質量和維護問題
• 測試發現的問題被忘卻或不了了之
• 無法衡量測試員和開發員的工作
• 程序中的問題往往在發布后才發現

文檔管理問題

• 文檔與程序脫節，文檔成為程序結果的描述
• 項目組把寫文檔看成負擔

團隊協調問題

• 開發人員各自為戰，進行整合時發現模塊銜接中的嚴重問題 需要作大的改動
• 沒有保管好公司以往的版本和代碼，無法滿足用戶對舊版本的更改要求
• 開發人員離職對項目帶來很大沖擊，沒有人知道代碼在哪，或無法讀懂

五．提高軟件管理的步驟

1. 使用Raid/BMS，將流程管理自動化
2. 使用測試用例管理工具
3. 使用文檔管理工具
4. 使用版本控制工具，進行Daily Build
5. 建立代碼標準
6. 建立Code Review機制
7. 建立專家會診機制
8. 建立團隊溝通機制
9. 根據需要調整團隊結構