微軟Bug管理(2)

　　強大的查詢功能，有效地跟蹤項目的狀態

　　所有的記錄無法刪除，對于每個記錄只能一直添加內容

　　豐富的報表功能，為產品發布提供判斷標準

　　3.Bug 記錄中的有效信息 狀態

　　負責人

　　問題種類

　　嚴重級

　　優先級

　　修改時間

　　登記時間

　　缺陷來源

　　解決方案

　　運行環境

　　缺陷關聯

　　附件

　　附圖

　　缺陷細節

　　4.Bug 的嚴重程度

　　死機，數據丟失，主要功能組完全喪失，系統懸掛

　　主要功能喪失，導致嚴重的問題，或致命的錯誤聲明

　　次要功能喪失， 不太嚴重，如提示信息不太準確

　　微小的問題，對功能幾乎沒有影響，產品及屬性仍可使用. 如有個錯別字

　　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.微軟的做法解決了那些常見問題?

　　質量問題

　　以前解決過的問題發布時又出現了，需要返工

　　無法預估發布時間 過早發布，帶來質量和維護問題

　　測試發現的問題被忘卻或不了了之

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