缺陷管理貫穿于整個(gè)軟件開發(fā)生命周期中， 是不可缺少的環(huán)節(jié)，但在國內(nèi)一些中小型開發(fā)商中沒有得到足夠得重視。本文結(jié)合實(shí)際應(yīng)用，系統(tǒng)地介紹了缺陷跟蹤開源軟件 Buggit 和 Mantis， 以期拋磚引玉，引起重視。
在您的項(xiàng)目中，是否有遇到過這樣的問題：測(cè)試人員報(bào)的缺陷被遺忘掉；延期項(xiàng)目終于發(fā)布，卻遭遇用戶頻頻抱怨，管理人員將矛頭指向測(cè)試人員；書寫不規(guī)范的錯(cuò)誤報(bào)告，使得開發(fā)人員不得不一次次找到測(cè)試人員來重現(xiàn)；地域分散的開發(fā)團(tuán)隊(duì)，通過email和文檔交流，缺陷狀態(tài)混亂，相關(guān)人員無法及時(shí)獲得有關(guān)的變更信息……
那么，讓測(cè)試組織使用數(shù)據(jù)庫來部署產(chǎn)品缺陷的記錄和跟蹤吧！對(duì)于中小軟件開發(fā)組織，或許不太可能使用動(dòng)則幾千美金一個(gè)許可證的商業(yè)軟件，但免費(fèi)而又易于維護(hù)的軟件完全可以滿足您80%以上的需要。如果您的組織還陷于無窮無盡的混亂不堪的缺陷之中，不要猶豫，馬上行動(dòng)，免費(fèi)軟件可以很好地管理這個(gè)過程，但在實(shí)施中對(duì)管理上提出的要求則是您應(yīng)該自我提高的。下面我們看看一個(gè)中小型開發(fā)組織兩年多的實(shí)施過程，或許對(duì)您有些啟發(fā)。
一、項(xiàng)目背景、組織架構(gòu)
某公司在全球航運(yùn)業(yè)信息化，在全球設(shè)有四個(gè)研發(fā)中心，主要為公司開發(fā)航運(yùn)和物流軟件，大多給公司內(nèi)部和業(yè)務(wù)有關(guān)的客戶使用，有些成熟的軟件銷售給同行或作為中立的平臺(tái)提供給同行使用。該公司的上海的研發(fā)中心使用的是免費(fèi)或開源的軟件跟蹤缺陷，有獨(dú)立的測(cè)試小組，工作包括功能測(cè)試、壓力測(cè)試、質(zhì)量保證和過程改進(jìn)，使用的是免費(fèi)軟件Buggit。
后來為了解決異地開發(fā)過程中的缺陷跟蹤問題， 開始使用Mantis 0.17.5版本（開源軟件，PHP/MySQL/Web Based），開始用一個(gè)實(shí)際的項(xiàng)目作試點(diǎn)，并根據(jù)項(xiàng)目組不同角色成員的反饋，測(cè)試組對(duì)系統(tǒng)進(jìn)行配置和代碼的修改加以提高；由于效果很不錯(cuò)，幾個(gè)月后推廣到其他多個(gè)項(xiàng)目。
二、缺陷跟蹤流程
缺陷包括產(chǎn)品錯(cuò)誤，需求和設(shè)計(jì)變更，新特性或擴(kuò)展功能（New Feature， Enhancement）等，它存在于整個(gè)軟件開發(fā)生命周期之中。使用中心數(shù)據(jù)庫便于項(xiàng)目組和管理人員獲取正確、足夠的信息，簡化了地域分散的組織的信息共享流程，它還可以實(shí)現(xiàn)工作流程的自動(dòng)化，大限度減少重復(fù)工作。
不同的組織，缺陷跟蹤流程會(huì)有所不同，下圖是一個(gè)典型的缺陷生命周期圖。

在alpha/beta測(cè)試期間，測(cè)試人員將發(fā)現(xiàn)的Bug 提交到缺陷跟蹤系統(tǒng)，該系統(tǒng)至少應(yīng)包含：
失敗描述：摘要、重建步驟、隔離信息；
識(shí)別信息：順序的ID號(hào)、報(bào)告作者、報(bào)告歸檔日期。
一個(gè)好的系統(tǒng)還需要：
嚴(yán)重性等級(jí)，以評(píng)估在測(cè)試條件下，錯(cuò)誤在系統(tǒng)中的影響；
優(yōu)先級(jí)，評(píng)估顧客實(shí)際使用中發(fā)生事件的可能性，或?qū)δ繕?biāo)顧客的后續(xù)影響；
環(huán)境：系統(tǒng)軟、硬件配置，測(cè)試版本號(hào)；
附件，錯(cuò)誤信息或屏幕截圖。
提交之后，Bug為"Submitted"狀態(tài)，變更控制委員會(huì)（Change Control Board，視項(xiàng)目規(guī)模組織，可以是不同角色的幾個(gè)人組成或一個(gè)人擔(dān)當(dāng)）評(píng)審決定：
是Bug，分配給相關(guān)開發(fā)人員修復(fù)，狀態(tài)為"Assigned"；
不是Bug或其他原因，關(guān)閉，狀態(tài)為"Closed"，解決方式（Resolution）根據(jù)實(shí)際情況選擇；
是Bug，但延遲到下一個(gè)版本修復(fù)，狀態(tài)為"Postponed"。
開發(fā)人員將Bug修復(fù)后，其狀態(tài)改為"Resolved"，他們應(yīng)發(fā)布到下一個(gè)測(cè)試版本（Test Build）中，測(cè)試人員測(cè)試所有"Resolved" Bug，沒有問題應(yīng)關(guān)閉（"Closed"狀態(tài)），未修復(fù)則要重新打開（"Opened"狀態(tài)）。
對(duì)于用戶提交的Bug，有些系統(tǒng)會(huì)增加"Confirmed"的狀態(tài)，表示經(jīng)測(cè)試Bug確實(shí)存在。
對(duì)其他變更（如需求改變或新增），以上流程同樣適用，但可能需要多次分配（assign），如需求變更，業(yè)務(wù)分析員要更新需求文檔，系統(tǒng)分析員要更新設(shè)計(jì)文檔，然后程序員改代碼。
系統(tǒng)好還有以下功能：
Root Cause：根本原因分析，這需開發(fā)人員的幫助；
Close Date和Resolution：系統(tǒng)生成關(guān)閉日期，可選擇或輸入問題是如何解決的；
系統(tǒng)自動(dòng)跟蹤記錄缺陷歷史，可輸入注釋；
方便的查詢功能；
可定制的報(bào)表，缺陷趨勢(shì)圖表；
Email提醒。
三、缺陷跟蹤過程實(shí)施
流程制定并評(píng)審?fù)ㄟ^后，應(yīng)該選擇合適的工具，對(duì)一個(gè)新組建的組織，也可以先選擇工具，再結(jié)合特定的工具制定流程。正式實(shí)施前應(yīng)對(duì)項(xiàng)目組所有成員進(jìn)行培訓(xùn)，以提高工具使用效率和成員間的溝通效率。
初我們選擇了一個(gè)十分簡單而又易于維護(hù)的工具Buggit，用于項(xiàng)目組內(nèi)部的Bug跟蹤；隨著跨地域開發(fā)項(xiàng)目的出現(xiàn)，溝通交流復(fù)雜性凸現(xiàn)，我們適時(shí)選擇了Web Based系統(tǒng)。下面看看兩個(gè)系統(tǒng)的具體實(shí)施。