微軟Bug管理

來(lái)自：微軟   蔡锫

一．團(tuán)隊(duì)組織

1．常見(jiàn)問(wèn)題

• 沒(méi)有人愿意做測(cè)試
• 覺(jué)得養(yǎng)不起那么多測(cè)試人員
• 開(kāi)發(fā)人員不遵循規(guī)范，隨心所欲
• 項(xiàng)目經(jīng)理事必躬親，分身乏術(shù)

2．微軟團(tuán)隊(duì)模型

各角色的職責(zé)

二．項(xiàng)目管理

1．常見(jiàn)問(wèn)題

• 無(wú)法決定項(xiàng)目所需的資源（人力和預(yù)算）
• 無(wú)法決定項(xiàng)目的進(jìn)度表
• 無(wú)法控制外包項(xiàng)目的進(jìn)度和質(zhì)量

2．微軟項(xiàng)目管理-- 多里程碑式流程

• 每個(gè)里程碑完成部分功能
• 便于團(tuán)隊(duì)集中力量完成一個(gè)又一個(gè)功能
• 提供多個(gè)機(jī)會(huì)以適應(yīng)需求的更改

如何完成一個(gè)里程碑

• 步驟一： 達(dá)成共識(shí)

• 基本完成需求調(diào)研和分析 （產(chǎn)品經(jīng)理負(fù)責(zé)）
• 確定大方向和長(zhǎng)中短期目標(biāo)
• 所有角色都參與討論并真正認(rèn)同結(jié)論
• 產(chǎn)生的文檔：
  • 常見(jiàn)用戶情景：覆蓋80%以上功能
  • Vision：言簡(jiǎn)意賅地說(shuō)明大方向，并有激勵(lì)團(tuán)隊(duì)的作用

• 步驟二： 完成項(xiàng)目計(jì)劃
  • 編寫(xiě)詳細(xì)的功能規(guī)范（項(xiàng)目經(jīng)理負(fù)責(zé)）
  • 在編程前想清楚所有功能流程，并引導(dǎo)用戶明確需求
  • 所有角色都參與審閱功能規(guī)范
  • 制訂開(kāi)發(fā)計(jì)劃和進(jìn)度表（開(kāi)發(fā)團(tuán)隊(duì)）
  • 制訂測(cè)試計(jì)劃和進(jìn)度表（測(cè)試團(tuán)隊(duì)）
  • 分配資源（人力和預(yù)算）
  • 形成項(xiàng)目綜合計(jì)劃和綜合進(jìn)度表
  • 產(chǎn)生的文檔：
    功能規(guī)范，開(kāi)發(fā)計(jì)劃，測(cè)試計(jì)劃（用例），項(xiàng)目綜合計(jì)劃
    開(kāi)發(fā)進(jìn)度表，測(cè)試進(jìn)度表，綜合進(jìn)度表

• 步驟三： 完成功能

• 開(kāi)發(fā)人員分別完成自己的功能
• 使用版本控制工具
• 使程序員及時(shí)check out和check in，避免積累大量代碼
• 及時(shí)進(jìn)行模塊間的整合，及時(shí)發(fā)現(xiàn)問(wèn)題（daily build）
• 對(duì)每一項(xiàng)可測(cè)試的功能進(jìn)行測(cè)試，無(wú)需等待
• 使用測(cè)試用例工具，對(duì)功能進(jìn)行完整和重復(fù)的檢驗(yàn)
• 使用BMS進(jìn)行缺陷跟蹤
• 記錄所有程序問(wèn)題
• 實(shí)現(xiàn)解決Bug的自動(dòng)流程
• 按照綜合進(jìn)度表不斷檢查進(jìn)度
  　
• 使用的工具：
  • 版本控制工具 VSS
  • 缺陷跟蹤工具 Raid/BMS
  • 測(cè)試用例管理工具

• 步驟四： 穩(wěn)定與發(fā)布

• 測(cè)試組全面地測(cè)試功能，包括性能和穩(wěn)定性
• 開(kāi)發(fā)組全力配合解決Bug
• 使用BMS進(jìn)行
  • 監(jiān)測(cè)質(zhì)量情況
  • 預(yù)測(cè)發(fā)布日期
• 專(zhuān)家會(huì)診機(jī)制：
  • 決定Bug的優(yōu)先度
  • 決定哪些Bug可以等到下個(gè)里程碑或版本中解決
  • 決定由誰(shuí)解決某個(gè)Bug
    　
• 使用的工具：
  • 版本控制工具 VSS
  • 缺陷跟蹤工具 BMS
  • 測(cè)試用例管理工具

三． 微軟的開(kāi)發(fā)管理經(jīng)驗(yàn)：100%以Bug為核心

1．Bug 及常見(jiàn)類(lèi)型

• 功能未實(shí)現(xiàn)，和規(guī)格說(shuō)明書(shū)不一致
• 不能工作：死機(jī)，沒(méi)反應(yīng)
• 不兼容
• 邊界條件
• 界面、消息、提示不夠準(zhǔn)確，不友好
• 把尚未完成的工作也作為一個(gè)Bug
• 文檔與幫助信息中的缺陷也是Bug

2．RAID/BMS的基本功能

• 完整的Bug數(shù)據(jù)庫(kù)
• 整個(gè)產(chǎn)品組的中央記錄和控制
• 強(qiáng)大的查詢功能，有效地跟蹤項(xiàng)目的狀態(tài)
• 所有的記錄無(wú)法刪除，對(duì)于每個(gè)記錄只能一直添加內(nèi)容
• 豐富的報(bào)表功能，為產(chǎn)品發(fā)布提供判斷標(biāo)準(zhǔn)

3．Bug 記錄中的有效信息

狀態(tài) 負(fù)責(zé)人 問(wèn)題種類(lèi) 嚴(yán)重級(jí) 優(yōu)先級(jí) 修改時(shí)間 登記時(shí)間

缺陷來(lái)源 解決方案 運(yùn)行環(huán)境 缺陷關(guān)聯(lián) 附件 附圖 缺陷細(xì)節(jié)

4．Bug 的嚴(yán)重程度

1. 死機(jī)，數(shù)據(jù)丟失，主要功能組完全喪失，系統(tǒng)懸掛
2. 主要功能喪失，導(dǎo)致嚴(yán)重的問(wèn)題，或致命的錯(cuò)誤聲明
3. 次要功能喪失， 不太嚴(yán)重，如提示信息不太準(zhǔn)確
4. 微小的問(wèn)題，對(duì)功能幾乎沒(méi)有影響，產(chǎn)品及屬性仍可使用. 如有個(gè)錯(cuò)別字

5．激活的Bug數(shù)量的趨勢(shì)

• 代碼完成前：很少
• 代碼完成后：增長(zhǎng)很快
• 接近Beta: 下降
• 接近RC: 奔向零
• 產(chǎn)品質(zhì)量和里程碑的信號(hào)
• 每天新建的Bug 與 修正的 Bug 相比較
• Active 狀態(tài) Bug 的總數(shù)

四．微軟的一天

1． 讓我們看看項(xiàng)目中每個(gè)角色的一天是如何度過(guò)的

• 開(kāi)發(fā)
• 測(cè)試
• 項(xiàng)目經(jīng)理

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

微軟的一天從幾點(diǎn)開(kāi)始？

答案：半夜

為什么？

因?yàn)镈aily Build是所有工作的核心，而且是在半夜自動(dòng)啟動(dòng)。

每日構(gòu)造Daily Build

• 你知道自己所用Windows的版本號(hào)嗎？
• Daily Build的意義：
  • 模塊得以及時(shí)整合
  • 要求程序員及時(shí)把最新代碼放入代碼庫(kù)
• 用腳本語(yǔ)言和編譯/鏈接工具實(shí)現(xiàn)
• BVT Build Verification Test
  • 對(duì)Build進(jìn)行驗(yàn)證
• Blocking Bug
  • 讓Build無(wú)法完成的問(wèn)題
  • BVT中發(fā)現(xiàn)的問(wèn)題

2．程序員每天上班前最擔(dān)心什么？

答案：因?yàn)樽约鹤蛱斓拇acheck-in，造成Blocking Bug.

為什么？

因?yàn)槊刻斓腂uild是所有人當(dāng)天工作的基礎(chǔ)：
程序員需要Build驗(yàn)證與其他模塊的接口
測(cè)試需要Build發(fā)現(xiàn)新Bug，并驗(yàn)證新Build中已解決的Bug

有Blocking Bug怎么辦？

解決問(wèn)題，并對(duì)今天的Build打Patch。

開(kāi)發(fā)人員的正事

經(jīng)歷對(duì)Build的提心吊膽和爭(zhēng)分奪秒之后，第一件事做什么
答案：打開(kāi)缺陷跟蹤工具，查看指定給自己的Bug，解決高優(yōu)先度的Bug。因?yàn)橘|(zhì)量重于新功能。

接下來(lái)，開(kāi)發(fā)人員會(huì)…

從版本控制工具中Check out代碼
修改代碼（解決Bug或?qū)崿F(xiàn)新功能）
取得版本工具中最新變化，在本機(jī)Build和單元測(cè)試
請(qǐng)開(kāi)發(fā)組同事作Code Review
Check in代碼



3．測(cè)試人員第一件事做什么？

答案：打開(kāi)Raid/BMS，查看指定給自己的Bug，驗(yàn)證已解決的Bug。

接下來(lái)，測(cè)試人員會(huì)…

• 根據(jù)測(cè)試用例檢驗(yàn)今天的Build
• 在Raid/BMS中記錄新發(fā)現(xiàn)的Bug

4．專(zhuān)家會(huì)診

• 參加者：項(xiàng)目經(jīng)理和開(kāi)發(fā)組長(zhǎng)、測(cè)試組長(zhǎng)
• 通過(guò)Raid/BMS評(píng)估每個(gè)未解決的Bug
  • 決定Bug優(yōu)先度
  • 可否等到下個(gè)里程碑或版本解決？
  • 誰(shuí)來(lái)解決
• 預(yù)測(cè)項(xiàng)目實(shí)際進(jìn)度和發(fā)布時(shí)間

缺陷走勢(shì)圖

5．回顧微軟的一天

• 構(gòu)造: daily build
• 開(kāi)發(fā): 解決blocking bugs, 實(shí)現(xiàn)功能, check-out, code review, check-in
• 測(cè)試: BVT, 使用測(cè)試用例進(jìn)行測(cè)試
• 項(xiàng)目經(jīng)理/組長(zhǎng): 專(zhuān)家會(huì)診

6．微軟的做法解決了那些常見(jiàn)問(wèn)題？

質(zhì)量問(wèn)題

• 以前解決過(guò)的問(wèn)題發(fā)布時(shí)又出現(xiàn)了，需要返工
• 無(wú)法預(yù)估發(fā)布時(shí)間 過(guò)早發(fā)布，帶來(lái)質(zhì)量和維護(hù)問(wèn)題
• 測(cè)試發(fā)現(xiàn)的問(wèn)題被忘卻或不了了之
• 無(wú)法衡量測(cè)試員和開(kāi)發(fā)員的工作
• 程序中的問(wèn)題往往在發(fā)布后才發(fā)現(xiàn)

文檔管理問(wèn)題

• 文檔與程序脫節(jié)，文檔成為程序結(jié)果的描述
• 項(xiàng)目組把寫(xiě)文檔看成負(fù)擔(dān)

團(tuán)隊(duì)協(xié)調(diào)問(wèn)題

• 開(kāi)發(fā)人員各自為戰(zhàn)，進(jìn)行整合時(shí)發(fā)現(xiàn)模塊銜接中的嚴(yán)重問(wèn)題 需要作大的改動(dòng)
• 沒(méi)有保管好公司以往的版本和代碼，無(wú)法滿足用戶對(duì)舊版本的更改要求
• 開(kāi)發(fā)人員離職對(duì)項(xiàng)目帶來(lái)很大沖擊，沒(méi)有人知道代碼在哪，或無(wú)法讀懂

五．提高軟件管理的步驟

1. 使用Raid/BMS，將流程管理自動(dòng)化
2. 使用測(cè)試用例管理工具
3. 使用文檔管理工具
4. 使用版本控制工具，進(jìn)行Daily Build
5. 建立代碼標(biāo)準(zhǔn)
6. 建立Code Review機(jī)制
7. 建立專(zhuān)家會(huì)診機(jī)制
8. 建立團(tuán)隊(duì)溝通機(jī)制
9. 根據(jù)需要調(diào)整團(tuán)隊(duì)結(jié)構(gòu)