實施測試活動過程中，針對缺陷開展有效跟蹤管理是測試工程師質量保證活動的重點，因此，在一個成熟的測試團隊或組織內，缺陷管理流程的完善與否直接決定測試活動的質量。

缺陷管理流程通常由角色定義、流程定義、工具應用、缺陷分析模型等幾個關鍵因素構成。

 

角色定義表述了在缺陷管理流程中所涉及的若干角色及其職責內容，從而清晰明確定義每個流程節(jié)點中角色所需完成的事務。流程定義規(guī)定了在項目或產品實施測試活動時所需遵循的流程規(guī)則。

 

工具應用則從項目或產品規(guī)模、團隊流程、成本控制、風險防范等多個角度考慮，選擇何種缺陷管理工具更能提升測試效果，提高缺陷管理效率。缺陷分析模型是針對缺陷進行綜合判斷，分析缺陷風險的科學方法，目前業(yè)內常用的模型有ODC、四象限、Gompertz等。

一、角色定義

缺陷管理流程活動一般包括測試工程師、測試負責人、開發(fā)負責人、開發(fā)人員、項目經理等若干角色。

1. 測試工程師

測試工程師負責實施測試活動，發(fā)現(xiàn)缺陷，及時提交缺陷，確認校驗缺陷，實施回歸測試。

2. 測試負責人

測試負責人評審缺陷，檢查測試工程師新增的缺陷是否符合規(guī)范，是否因為不熟悉需求、理解偏差而引起的誤提，并負責缺陷產生爭議后的協(xié)調處理。

3. 開發(fā)負責人

開發(fā)負責人負責缺陷分配活動，將需修復的缺陷根據(jù)缺陷修復任務分配給對應的開發(fā)人員，協(xié)調解決爭議缺陷。

4. 開發(fā)工程師

當缺陷提交給開發(fā)人員后，開發(fā)人員負責缺陷的確認及修復活動。

5. 項目經理

當對提交的缺陷有分歧、被拒絕時，可由項目經理、測試負責人、開發(fā)負責人等進行缺陷評審活動，商定問題如何處理，是否保留或當前版本不做處理等結論。

二、流程定義

不同公司因組織結構不同，所采用的管理流程亦不相同。大部分公司使用流程如圖5-5所示。

 

圖5-5通用缺陷管理流程

注：流程中操作關鍵詞以HP商用的項目管理工具Application Lifecycle Management為范例

1. 測試工程師或其他人員發(fā)現(xiàn)缺陷，經過確認后提交缺陷，缺陷狀態(tài)設置為“新建（New）”，“指派（Assign）”下步處理人為測試負責人。

2. 測試負責人針對需要自己處理的缺陷進行“評審（Review）”操作。檢查測試工程師提交的缺陷是否符合缺陷報告規(guī)范，如語言描述是否清晰、問題定位是否準確等，或者判斷該問題是否確實是一個缺陷，還是因測試工程師不熟悉需求、理解偏差而引起的誤提。如有問題，將該缺陷“指派（Assign）”至測試工程師，讓其修改后再提交，此時缺陷狀態(tài)為“新建（New）”。如無問題，確定是缺陷，則將該缺陷提交給開發(fā)負責人，缺陷狀態(tài)為“打開（Open）”。

3. 如果測試負責人“評審（Review）”后，缺陷“指派（Assign）”至測試工程師處，測試工程師則需再次確認缺陷是否誤提，是則“關閉（Close）”缺陷，并注明缺陷關閉原因，否則再次“指派（Assign）”至測試負責人處，缺陷狀態(tài)為“新建（New）”，并注明原因。測試負責人重復步驟2。

4. 開發(fā)負責人將測試負責人“評審（Review）”后的缺陷根據(jù)缺陷修復任務分配給相應的開發(fā)人員，開發(fā)負責人一般僅分配缺陷，不再過濾缺陷，此時缺陷狀態(tài)為“打開（Open）”。

5. 開發(fā)人員根據(jù)缺陷描述確認是否是缺陷，如果是，則進行缺陷修復活動，修復完成后，缺陷狀態(tài)置為“修復（Fix）”，并將對應缺陷“指派（Assign）”至缺陷發(fā)現(xiàn)者。如果不是缺陷，則將缺陷狀態(tài)置為“拒絕（Reject）”，由測試工程師再次確認處理。

6. 測試工程師針對“拒絕（Reject）”的缺陷進行再次確認驗證，如果確認缺陷屬于誤提或不再存在，則可“關閉（Close）”對應缺陷，并注明關閉原因，若確認是缺陷，則需“重新打開（Reopen）”缺陷至開發(fā)人員處，并注明“重新打開（Reopen）”原因。開發(fā)人員重復步驟5。

7. 當缺陷無法確認或產生爭執(zhí)時，由測試、開發(fā)負責人及項目經理評審確認并給出最終處理結果。測試工程師及開發(fā)人員原則上不直接溝通，避免產生無效溝通。一般來講，缺陷處理是一個循環(huán)反復的過程。當出現(xiàn)爭議時，必須由項目經理參與缺陷處理活動，而不能由開發(fā)組或者測試組單方面決定缺陷的處理方式。

上述流程可根據(jù)測試流程及時間進度適當調整，一般適用于5~10人的團隊，可精簡為適合3~5人團隊的流程，也可細化為適合10~15人的中型測試團隊。

三、工具應用

缺陷管理早期最通用的工具是Excel，簡單方便，但隨著缺陷管理流程的復雜化，對缺陷管理工具的要求越來越高，一般而言，缺陷管理工具需要具備以下幾個特征。

1. 缺陷提交便捷。

2. 可細分角色、權限。

3. 可定制流程。

4. 可進行缺陷數(shù)據(jù)分析。

5. 支持郵件收發(fā)功能。

目前市面上大部分缺陷管理工具都具備上述特征，較為常用的工具有以下幾種。

1. 開源免費工具

（1）Bugzilla

Bugzilla起源于UNIX，后續(xù)版本可安裝在Linux、Windows平臺，使用便捷，分析功能、流程定制功能一般。

（2）BugFree

BugFree借鑒微軟研發(fā)流程和Bug管理理念，使用PHP+MySQL獨立設計的Bug管理系統(tǒng)，簡單實用。

（3）禪道

禪道是國內一款優(yōu)秀的項目管理工具，提供了完善的測試工作平臺，其中包括缺陷管理功能。目前國內眾多軟件研發(fā)公司在用。

2. 商業(yè)工具

（1）TestTrack

TestTrack是SeaPine公司生產的軟件缺陷管理工具，除了常規(guī)缺陷管理功能外，流程定制是其一大特色，甚至優(yōu)于HP的QualityCenter，是目前業(yè)內專業(yè)的缺陷跟蹤工具之一，支持B/S和C/S兩種架構。

（2）Application Lifecycle Management（ALM）

HP的Application Lifecycle Management（ALM），前身是Quality Center，采用B/S結構，可在廣泛的應用環(huán)境下自動執(zhí)行軟件質量測試和管理，是目前應用較為廣泛的商用測試管理工具。

四、缺陷分析

針對缺陷的關鍵字段，運用數(shù)據(jù)分析的統(tǒng)計方法，發(fā)掘軟件系統(tǒng)的缺陷分布、密度及發(fā)展趨勢，在此基礎上追溯軟件生產過程中引發(fā)缺陷的根本原因，為軟件質量分析提供基礎真實的數(shù)據(jù)依據(jù)。

缺陷分析活動中常用的度量字段有嚴重度、所屬模塊、產生原因、所屬版本、持續(xù)周期、缺陷性質等。常用的缺陷分析模型有ODC、四象限、Gompertz等。

1. ODC

ODC由IBM推出，將一個缺陷在生命周期各環(huán)節(jié)的屬性組織起來，從單維度、多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用于評估測試活動、指導測試改進和整個研發(fā)流程的改進；同時根據(jù)各階段缺陷分布得到缺陷去除過程特征模型，用于對測試活動進行評估和預測。ODC結構如圖5-6所示。

 

圖5-6　ODC模型示意圖

2. 四象限

根據(jù)軟件內部各模塊、子系統(tǒng)、特性測試所累積時間和缺陷去除情況，與累積時間和缺陷去除情況的基線進行比較，得到各個模塊、子系統(tǒng)、特性測試分別位于的區(qū)間，從而判斷哪些部分測試可以退出，哪些測試還需加強，用于指導測試計劃和策略的調整。

3. Gompertz

根據(jù)測試的累積投入時間和累積缺陷增長情況，擬合得到符合自己過程能力的缺陷增長Gompertz曲線，用來評估軟件測試的充分性、預測軟件極限缺陷數(shù)和退出測試所需時間、作為測試退出的判斷依據(jù)、指導測試計劃和策略的調整。