4．Bug 的嚴重程度
死機，數(shù)據(jù)丟失，主要功能組完全喪失，系統(tǒng)懸掛
主要功能喪失，導(dǎo)致嚴重的問題，或致命的錯誤聲明
次要功能喪失， 不太嚴重，如提示信息不太準確
微小的問題，對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用. 如有個錯別字
5．激活的Bug數(shù)量的趨勢
代碼完成前：很少
代碼完成后：增長很快
接近Beta: 下降
接近RC: 奔向零
產(chǎn)品質(zhì)量和里程碑的信號
每天新建的Bug 與 修正的 Bug 相比較
Active 狀態(tài) Bug 的總數(shù)
四．微軟的
1． 讓我們看看項目中每個角色的是如何度過的
開發(fā)
測試
項目經(jīng)理
注：里程碑的每個階段每個角色的工作有不同側(cè)重點，我們以“完成功能”階段為例
微軟的從幾點開始？
答案：半夜
為什么？
因為Daily Build是所有工作的核心，而且是在半夜自動啟動。
每日構(gòu)造Daily Build
你知道自己所用Windows的版本號嗎？
Daily Build的意義：
模塊得以及時整合
要求程序員及時把新代碼放入代碼庫
用腳本語言和編譯/鏈接工具實現(xiàn)
BVT Build Verification Test
對Build進行驗證
Blocking Bug
讓Build無法完成的問題
BVT中發(fā)現(xiàn)的問題
2．程序員每天上班前擔心什么？
答案：因為自己昨天的代碼check-in，造成Blocking Bug.
為什么？
因為每天的Build是所有人當天工作的基礎(chǔ)：
程序員需要Build驗證與其他模塊的接口
測試需要Build發(fā)現(xiàn)新Bug，并驗證新Build中已解決的Bug
有Blocking Bug怎么辦？
解決問題，并對的Build打Patch。
開發(fā)人員的正事
經(jīng)歷對Build的提心吊膽和爭分奪秒之后，第一件事做什么
答案：打開缺陷跟蹤工具，查看指定給自己的Bug，解決高優(yōu)先度的Bug。因為質(zhì)量重于新功能。
接下來，開發(fā)人員會…
從版本控制工具中Check out代碼
修改代碼（解決Bug或?qū)崿F(xiàn)新功能）
取得版本工具中新變化，在本機Build和單元測試
請開發(fā)組同事作Code Review
Check in代碼
