微軟的缺陷管理方式(2)

　　登記時間

　　缺陷來源

　　解決方案

　　運行環境

　　缺陷關聯

　　附件

　　附圖

　　缺陷細節

　　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