在您的項目中,是否有遇到過這樣的問題：測試人員報的缺陷被遺忘掉；延期項目終于發布，卻遭遇用戶頻頻抱怨，管理人員將矛頭指向測試人員；書寫不規范的錯誤報告，使得開發人員不得不一次次找到測試人員來重現；地域分散的開發團隊，通過email和文檔交流，缺陷狀態混亂，相關人員無法及時獲得有關的變更信息……
那么，讓測試組織使用數據庫來部署產品缺陷的記錄和跟蹤吧！對于中小軟件開發組織，或許不太可能使用動則幾千美金一個許可證的商業軟件，但免費而又易于維護的軟件完全可以滿足您80%以上的需要。如果您的組織還陷于無窮無盡的混亂不堪的缺陷之中，不要猶豫，馬上行動，免費軟件可以很好地管理這個過程，但在實施中對管理上提出的要求則是您應該自我提高的。下面我們看看一個中小型開發組織兩年多的實施過程，或許對您有些啟發。
一、項目背景、組織架構
某公司在全球航運業信息化領先，在全球設有四個研發中心，主要為公司開發航運和物流軟件，大多給公司內部和業務有關的客戶使用，有些成熟的軟件銷售給同行或作為中立的平臺提供給同行使用。該公司的上海的研發中心使用的是免費或開源的軟件跟蹤缺陷，有獨立的測試小組，工作包括功能測試、壓力測試、質量保證和過程改進，使用的是免費軟件Buggit。
后來為了解決異地開發過程中的缺陷跟蹤問題, 開始使用Mantis 0.17.5版本（開源軟件，PHP/MySQL/Web Based），開始用一個實際的項目作試點，并根據項目組不同角色成員的反饋，測試組對系統進行配置和代碼的修改加以提高；由于效果很不錯，幾個月后就推廣到其他多個項目。
二、缺陷跟蹤流程
缺陷包括產品錯誤，需求和設計變更，新特性或擴展功能（New Feature, Enhancement）等，它存在于整個軟件開發生命周期之中。使用中心數據庫便于項目組和管理人員獲取正確、足夠的信息，簡化了地域分散的組織的信息共享流程，它還可以實現工作流程的自動化，最大限度減少重復工作。
不同的組織，缺陷跟蹤流程會有所不同，下圖是一個典型的缺陷生命周期圖。
在alpha/beta測試期間，測試人員將發現的Bug 提交到缺陷跟蹤系統，該系統至少應包含：
失敗描述：摘要、重建步驟、隔離信息；
識別信息：順序的ID號、報告作者、報告歸檔日期。
一個好的系統還需要：
嚴重性等級，以評估在測試條件下，錯誤在系統中的絕對影響；
優先級，評估顧客實際使用中發生事件的可能性，或對目標顧客的后續影響；
環境：系統軟、硬件配置，測試版本號；
附件，錯誤信息或屏幕截圖。
提交之后，Bug為"Submitted"狀態，變更控制委員會（Change Control Board，視項目規模組織，可以是不同角色的幾個人組成或一個人擔當）評審決定：
是Bug，分配給相關開發人員修復，狀態為"Assigned"；
不是Bug或其他原因，關閉，狀態為"Closed"，解決方式（Resolution）根據實際情況選擇；
是Bug，但延遲到下一個版本修復，狀態為"Postponed"。
開發人員將Bug修復后，其狀態改為"Resolved"，他們應發布到下一個測試版本（Test Build）中，測試人員測試所有"Resolved" Bug，沒有問題應關閉（"Closed"狀態），未修復則要重新打開（"Opened"狀態）。
對于用戶提交的Bug，有些系統會增加"Confirmed"的狀態，表示經測試Bug確實存在。
對其他變更（如需求改變或新增），以上流程同樣適用，但可能需要多次分配（assign），如需求變更，業務分析員要更新需求文檔，系統分析員要更新設計文檔，然后程序員改代碼。
系統最好還有以下功能：
Root Cause：根本原因分析，這需開發人員的幫助；
Close Date和Resolution：系統生成關閉日期，可選擇或輸入問題是如何解決的；
系統自動跟蹤記錄缺陷歷史，可輸入注釋；
方便的查詢功能；
可定制的報表，缺陷趨勢圖表；
Email提醒。
三、缺陷跟蹤過程實施
流程制定并評審通過后，就應該選擇合適的工具，對一個新組建的組織，也可以先選擇工具，再結合特定的工具制定流程。正式實施前應對項目組所有成員進行培訓，以提高工具使用效率和成員間的溝通效率。
最初我們選擇了一個十分簡單而又易于維護的工具Buggit，用于項目組內部的Bug跟蹤；隨著跨地域開發項目的出現，溝通交流復雜性凸現，我們適時選擇了Web Based系統。下面看看兩個系統的具體實施。
使用免費工具Buggit
Buggit 是一個十分小巧的C/S結構的Access應用軟件，僅限于intranet，十分鐘就可以配置完成，使用十分簡單，查詢簡便，能滿足基本的缺陷跟蹤功能，還有十個用戶定制域，有十二種報表輸出。
我們在一個十幾人的開發團隊，使用了兩年半時間（版本V2.20 Bld 4 for Windows 95/98 and NT ），基本沒有數據丟失，有過幾次數據庫格式錯誤，一般可恢復，Email通知和缺陷趨勢圖功能不穩定。該系統的安全性和權限控制十分薄弱，需要團隊成員按規范配合。
詳細信息請訪問Buggit主頁http://www-900.ibm.com/developerWorks/cn/linux/software_engineering/l-mantis/www.pb-sys.com下圖為Buggit主頁面和詳細缺陷報告。
使用web-based開源軟件Mantis
Mantis是PHP/MySQL/Web-based缺陷跟蹤系統，即使沒有經驗也可以在一天內配置完成。
由于我們的研發團隊是地域分布式的，有些項目是上海、硅谷和香港的研發中心合作開發，需求、設計、開發、測試和用戶反饋來自不同地區，使用電子郵件和文檔來跟蹤缺陷時，信息共享和錯誤狀態更新都費時費力，隨著項目的擴展，文檔工作量也越來越大，這時使用web-based系統、項目組共用一個中心數據庫實現工作流自動化提到議事日程。因為是選擇開源軟件，所以要考慮系統穩定性和安裝配置、維護工作量，這項工作完全由測試組實施，我們在今年一月到四月將Mantis安裝到個人工作的PC機，請不同角色的人試用，反饋效果良好，我們馬上決定將系統用于跨地域開發的項目，系統正式安裝在開發用的Server上，操作系統是Solaris，配置比Windows下稍復雜一些。使用過程中，根據開發組的反饋，由測試組通過修改源程序放寬了Assign To和缺陷更新的權限，將下一版本中的Bug History和缺陷圖表包集成到目前使用的版本0.17.5，增加了CSV Export數據域�，F在我們已將該系統推廣到其他幾個項目，總共有四十人左右使用，通過公司專線訪問，在近一年的時間里，系統運行平穩，性能也比較理想，簡化了流程，從而提高了工作效率。
Mantis特性
Mantis當前版本為0.17.5，下一版0.18.0處于Beta發布階段。
關于產品詳細信息和支持，請訪問主頁http://mantisbt.sourceforge.net/，下圖為查看所有Bug和查看詳細Bug頁面。
Mantis基本特性：
個人可定制的Email通知功能，每個用戶可根據自身的工作特點只訂閱相關缺陷狀態郵件；
支持多項目、多語言；
權限設置靈活，不同角色有不同權限，每個項目可設為公開或私有狀態，每個缺陷可設為公開或私有狀態，每個缺陷可以在不同項目間移動；
主頁可發布項目相關新聞，方便信息傳播；
方便的缺陷關聯功能，除重復缺陷外，每個缺陷都可以鏈接到其他相關缺陷；
缺陷報告可打印或輸出為CSV格式，0.18.0版：支持可定制的報表輸出，可定制用戶輸入域；
有各種缺陷趨勢圖和柱狀圖，為項目狀態分析提供依據，如果不能滿足要求，可以把數據輸出到Excel中進一步分析；
流程定制不方便，但該流程可滿足一般的缺陷跟蹤。
四、項目實施經驗教訓
測試作為項目開發的最后一環，錯誤、延時、疏忽等都可能在測試階段表現出來，如何有序管理和分析各種問題對質量控制和過程改進非常重要，使用web based系統就是一個好的實踐。
在項目組內，對Bug采用數據庫系統進行跟蹤并不困難，因為主要是測試人員提交Bug報告，測試人員使用最多，相信測試人員對使用中心數據庫的好處是很了解的了，只要項目經理支持就很好辦了。如果要對其他缺陷，如需求變更，也這樣管理就不是那么容易了，在技術上當然沒有問題，難在工作方式的改變，雖然用Email和文檔管理無法實現工作流的自動化，也不如數據庫系統提供那么多的分析和報告選項，但在小規模的項目中依靠人工管理也可以做得井井有條。我們在多個項目的實施中就遇到這樣的情況，有的項目隨時都有需求變更，而且變更的數量不少，項目組主動提出想用數據庫系統來管理；有的項目剛起步，第一個階段的開發業務功能不多，推行的時候阻力就很大。我的初級目標是有序地管理錯誤和變更，在實施手段上有沖突時，不要操之過急，融洽的關系對項目的成功是很重要的。往往是有了成功的案例后，回頭推廣又變得容易了。實施新過程時最好先局部試點，采用PDCA循環，不斷總結經驗，再推廣。
使用缺陷數據庫，可以制作得到各種缺陷分析圖表，從而預測項目風險或解釋測試結果。下面兩張圖都是Mantis生成的缺陷圖，從累積錯誤打開圖，分析錯誤生成趨勢，在發現錯誤報告未收斂時發布軟件，顯然風險很大，當然使用圖表時還應結合實際，在曲線平坦時，是否開展了測試工作，曲線上升時，錯誤的嚴重性等級如何等。從嚴重性等級的柱狀圖可分析被測系統的總體狀況。在發布管理不規范的組織中，當產品質量問題突出時，測試組可以通過解釋這些圖來闡述測試結果，從而規范發布過程。
第一部分提到的根本原因（Root Cause）域，他有助于使開發人員的注意力集中到引起最嚴重、最頻繁問題的領域，從而消耗最少的資源改進過程取得最顯著的成果，這是我在過程改進時最常用到的80/20法則。在項目實施時，實際情況并不理想，因為開發人員忙于改Bug，少有主動寫錯誤發生的根本原因的，這需要開發人員的配合和管理者的支持。
缺陷數據的使用應謹慎，不要將錯誤個人化，應保證數據的真實性，否則數據對過程改進沒有意義。
實施過程中，大家會對工具提出很多需求，應評估哪些是共同需求、核心需求，系統修改復雜程度，對當前系統和系統升級的影響。測試組在實施過程中，對不同角色人員的工作流程有了深入而準確的了解，同時可以進行工作流程的改進。
使用開源系統的利弊
由于開源系統的代碼是公開的，用戶可自行維護和定制，大家也可以提交新特性和功能擴展要求，而不必受制于商業系統的制造商。開源系統的用戶遍布世界各地，Bug反而容易發現，同時公開源代碼中低效率的程序也容易被發現和修改。當然越是流行的軟件，生命力越強，Bug清除和新特性增加越快。
開源系統與其他工具的集成比較差，不如商業系統提供整個軟件開發生命周期的工具的集成，如項目管理、需求管理、建模、自動化測試、缺陷跟蹤、配置管理等有機集成，實現整個開發流程的自動化。但一般的中小企業，大多沒有實力配置全所有系統，另外，不同廠商優勢不同，主導系統也不同，有的企業需要根據自身的特點選擇不同廠商的工具，所以即使購買商業工具也未必能將所有系統很好地集成。
開源系統是免費的，但有人提供收費的系統維護和定制服務。
五、小結
本文主要探討缺陷跟蹤管理的流程、工具和實施問題，缺陷跟蹤在技術上并不難，而是難在管理上，好的工具有利于管理和交流，優秀的項目組應意識到有效的交流方式是多種多樣的，不應該單依賴系統，這樣才有利于提高團隊的戰斗力，而不是把重點放在追求系統功能的十全十美。有些缺陷跟蹤系統有Knowledge Base 功能，這對公司知識庫的累積也很有效；有的系統對不同用戶生成相關的To-Do-List，方便日常工作；有的對每個發布版本都有詳細的缺陷報告�？傊�，花費時間和精力完善錯誤管理系統是值得的，這是質量管理和提高的基礎。
參考書目
《測試流程管理》 北京大學出版社 作者Rex Black 2001年3月第一版
《CVS開源軟件開發技術》 機械工業出版社 作者Karl Fogel 2001年6月第一版
關于作者
蔡琰，外企QA主管，有三年電子商務領域QA、測試主管經驗及多年的開發經歷。目前關注基于J2EE構架的web系統的功能測試和性能測試、自動化測試、過程改進�，F在上海，您可以通過電子郵件cindy_cai@sina.com 和她聯系。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
