無論採用何種測試形式、執行何種測試任務，都會產生一系列的bug。而開發團隊需要乙個健全的bug管理的機制。一般來說，乙個bug的生命週期大致要經過如下幾個過程：
圖4 bug的生命週期
這裡大多數的階段都比較易懂，需要解釋一下的可能就是triage過程。bug在建立出來以後，首先要經過triage小組討論決定是否需要修復。triage小組一般由專案管理、開發和測試三方的代表組成。對於每乙個bug，小組快速的根據重現步驟、結果等資訊，估計其嚴重程度、可能的原因、修復的代價和風險，以決定是否要修復這個bug。如果bug中提供的資訊量不足以判斷，triage小組會將其發還給建立者要求補充更多的資訊。如果triage小組無法在短時間內對bug的成因、修復等做出估計，那麼就會將bug指派給乙個相關的開發/測試人員進行調查，並要求他將調查結果附上之後，重新提交triage。
另外，如果乙個bug被拒絕修復，但是建立者卻堅持己見的話，可以進一步在bug中新增理由：對使用者影響、可能的嚴重後果等，然後重新提交triage。類似的，如果乙個bug被批准修復，但是被指派修復的人員認為沒有必要修復、修復難度/代價太大時，也可以將理由附上，要求triage小組重新裁定。
triage會的頻率在整個產品開發過程中是不相同的。在產品開發的開始階段，團隊的主要活動就是開發新功能，此時可能數天甚至數週才能簽入乙個功能，triage會一周一次就足夠了，保證本週在大掃除中所發現的bug都會被及時處理。而當產品逐漸進入開發周期的末尾時，團隊主要的活動就是修復bug，此時就最好能每天triage，迅速對bug做出反應，以便能更好的管理專案的進度。
除了triage會的頻率會隨著產品開發而改變外，triage的標準也會隨之調整。在新功能剛簽入的時候，可能很小的問題或者改進建議都會被批准，以幫助更好的完善該功能。而當功能相對穩定時，就要開始考慮修復的代價/風險以及為使用者帶來的價值之間的平衡點了。到產品週期的末尾階段，此時triage的標準將會非常嚴格，只有對使用者影響非常大，且修復的代價/風險都比較小的bug才會被批准修復了。
triage的意義在於在較短的時間內，專案管理/開發/測試三方都對團隊現有的bug有整體的了解，並提供各自的意見，快速的剔除重複的、不值得修復的問題，且保證了整個團隊對bug是否需要修復有乙個統一的標準。
我們的團隊採用tfs的作為bug的管理工具。團隊成員可以輕鬆在visual studio或是test manager介面中建立、查詢、修改bug。值得一提的是，tfs提供的預設的bug模板並不一定能滿足團隊的需要。這裡就可以用到tfs提供的修改工作項定義的功能（匯出工作項定義->修改->匯入工作項定義），將bug改造為合適的樣子。在我們的團隊中使用的bug模板就是我們自己定製的。
1. 子狀態（sub status）bug的狀態一般就只有active、resolved和closed三種，但這並不足以表示針對該bug的具體工作的執行狀態。所以我們新增了乙個子狀態域，它包括以下幾種子狀態：
2. 回歸（regression）
3. triage
4. 測試用例狀態（tc status）
對於任何乙個bug，作為測試人員都應該問的問題是：這個bug已經被我們的測試計畫覆蓋了麼？如果沒有，值得我們為它新增乙個新的測試用例或是修改已有的測試用例麼？這就是「測試用例狀態」域的作用。在建立bug或是triage的時候應該標註該域為以下幾種可能：
林俊彥
本文精簡版收錄於《程式設計師》7月刊。
用Visual Studio實踐敏捷測試（二）上
本文的第一部分 上 下 著重介紹了測試人員在敏捷開發過程中，需要完成的一些測試準備工作。對於讀者來說，這些工作項可能會比較陌生，但在敏捷開發中卻對保證開發的質量和速度起到了很重要的作用。在這一部分中，我們將進入大家較為熟悉的實際測試階段，為大家介紹測試任務的執行以及bug的管理。在整個敏捷軟體開發流...
用Visual Studio 2005進行程式開發
vc 2005快速入門之復合賦值操作符 前面講過如何使用算術操作符來建立新值。全文閱讀 visual c 2005影象程式設計之預備知識 影象處理過程中，有很多需要我們掌握或者注意的方方面面。這裡我先簡單介紹一些比較基礎的 重要的知識。全文閱讀 vs2005和asp.net2.0中使用強型別資料 作...
用Visual Studio 編譯64位程式
由於硬體的公升級，目前伺服器處在乙個從x86到x64的過渡時期。如果用vs2008在x64位機上編譯程式，有時候會遇到 試圖載入格式不正確的程式 的錯誤資訊。如下圖所示 幾乎可以肯定是遇到了 x86和 x64位 dll混編的錯誤。所謂 x86和 x64位 dll混編 是指 32位程式集與 64位程式...