缺陷管理貫穿於整個軟件開發生命周期中 是不可缺少的環節但在國內一些中小型開發商中沒有得到足夠得重視本文結合實際應用系統地介紹了缺陷跟蹤開源軟件 Buggit 和 Mantis 以期拋磚引玉引起重視在您的項目中是否有遇到過這樣的問題測試人員報的缺陷被遺忘掉;延期項目終於發布卻遭遇用戶頻頻抱怨管理人員將矛頭指向測試人員;書寫不規范的錯誤報告使得開發人員不得不一次次找到測試人員來重現;地域分散的開發團隊通過email和文檔交流缺陷狀態混亂相關人員無法及時獲得有關的變更信息…… 那麼讓測試組織使用數據庫來部署產品缺陷的記錄和跟蹤吧!對於中小軟件開發組織或許不太可能使用動則幾千美金一個許可證的商業軟件但免費而又易於維護的軟件完全可以滿足您%以上的需要如果您的組織還陷於無窮無盡的混亂不堪的缺陷之中不要猶豫馬上行動免費軟件可以很好地管理這個過程但在實施中對管理上提出的要求則是您應該自我提高的下面我們看看一個中小型開發組織兩年多的實施過程或許對您有些啟發
一項目背景組織架構
某公司在全球航運業信息化領先在全球設有四個研發中心主要為公司開發航運和物流軟件大多給公司內部和業務有關的客戶使用有些成熟的軟件銷售給同行或作為中立的平台提供給同行使用該公司的上海的研發中心使用的是免費或開源的軟件跟蹤缺陷有獨立的測試小組工作包括功能測試壓力測試質量保證和過程改進使用的是免費軟件Buggit 後來為了解決異地開發過程中的缺陷跟蹤問題 開始使用Mantis 版本(開源軟件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十分鐘就可以配置完成使用十分簡單查詢簡便能滿足基本的缺陷跟蹤功能還有十個用戶定制域有十二種報表輸出
我們在一個十幾人的開發團隊使用了兩年半時間(版本V Bld for Windows / and NT )基本沒有數據丟失有過幾次數據庫格式錯誤一般可恢復Email通知和缺陷趨勢圖功能不穩定該系統的安全性和權限控制十分薄弱需要團隊成員按規范配合
詳細信息請訪問Buggit主頁http://www ibmcom/developerWorks/cn/linux/software_engineering/lmantis/wwwpb syscom下圖為Buggit主頁面和詳細缺陷報告
使用 webbased開源軟件Mantis
Mantis是PHP/MySQL/Webbased缺陷跟蹤系統即使沒有經驗也可以在一天內配置完成
由於我們的研發團隊是地域分布式的有些項目是上海硅谷和香港的研發中心合作開發需求設計開發測試和用戶反饋來自不同地區使用電子郵件和文檔來跟蹤缺陷時信息共享和錯誤狀態更新都費時費力隨著項目的擴展文檔工作量也越來越大這時使用webbased系統項目組共用一個中心數據庫實現工作流自動化提到議事日程因為是選擇開源軟件所以要考慮系統穩定性和安裝配置維護工作量這項工作完全由測試組實施我們在今年一月到四月將 Mantis安裝到個人工作的PC機請不同角色的人試用反饋效果良好我們馬上決定將系統用於跨地域開發的項目系統正式安裝在開發用的Server 上操作系統是Solaris配置比Windows下稍復雜一些使用過程中根據開發組的反饋由測試組通過修改源程序放寬了Assign To和缺陷更新的權限將下一版本中的Bug History和缺陷圖表包集成到目前使用的版本增加了CSV Export數據域現在我們已將該系統推廣到其他幾個項目總共有四十人左右使用通過公司專線訪問在近一年的時間裡系統運行平穩性能也比較理想簡化了流程從而提高了工作效率
Mantis特性
Mantis當前版本為下一版處於Beta發布階段
關於產品詳細信息和支持請訪問主頁http://mantisbtsourceforgenet/下圖為查看所有Bug和查看詳細Bug頁面
Mantis基本特性
個人可定制的Email通知功能每個用戶可根據自身的工作特點只訂閱相關缺陷狀態郵件;
支持多項目多語言;
權限設置靈活不同角色有不同權限每個項目可設為公開或私有狀態每個缺陷可設為公開或私有狀態每個缺陷可以在不同項目間移動;
主頁可發布項目相關新聞方便信息傳播;
方便的缺陷關聯功能除重復缺陷外每個缺陷都可以鏈接到其他相關缺陷;
缺陷報告可打印或輸出為CSV格式版支持可定制的報表輸出可定制用戶輸入域;
有各種缺陷趨勢圖和柱狀圖為項目狀態分析提供依據如果不能滿足要求可以把數據輸出到Excel中進一步分析;
流程定制不方便但該流程可滿足一般的缺陷跟蹤
四項目實施經驗教訓
測試作為項目開發的最後一環錯誤延時疏忽等都可能在測試階段表現出來如何有序管理和分析各種問題對質量控制和過程改進非常重要使用web based系統就是一個好的實踐
在項目組內對Bug采用數據庫系統進行跟蹤並不困難因為主要是測試人員提交Bug報告測試人員使用最多相信測試人員對使用中心數據庫的好處是很了解的了只要項目經理支持就很好辦了如果要對其他缺陷如需求變更也這樣管理就不是那麼容易了在技術上當然沒有問題難在工作方式的改變雖然用 Email和文檔管理無法實現工作流的自動化也不如數據庫系統提供那麼多的分析和報告選項但在小規模的項目中依靠人工管理也可以做得井井有條我們在多個項目的實施中就遇到這樣的情況有的項目隨時都有需求變更而且變更的數量不少項目組主動提出想用數據庫系統來管理;有的項目剛起步第一個階段的開發業務功能不多推行的時候阻力就很大我的初級目標是有序地管理錯誤和變更在實施手段上有沖突時不要操之過急融洽的關系對項目的成功是很重要的往往是有了成功的案例後回頭推廣又變得容易了實施新過程時最好先局部試點采用PDCA循環不斷總結經驗再推廣
使用缺陷數據庫可以制作得到各種缺陷分析圖表從而預測項目風險或解釋測試結果下面兩張圖都是Mantis生成的缺陷圖從累積錯誤打開圖分析錯誤生成趨勢在發現錯誤報告未收斂時發布軟件顯然風險很大當然使用圖表時還應結合實際在曲線平坦時是否開展了測試工作曲線上升時錯誤的嚴重性等級如何等從嚴重性等級的柱狀圖可分析被測系統的總體狀況在發布管理不規范的組織中當產品質量問題突出時測試組可以通過解釋這些圖來闡述測試結果從而規范發布過程
第一部分提到的根本原因(Root Cause)域他有助於使開發人員的注意力集中到引起最嚴重最頻繁問題的領域從而消耗最少的資源改進過程取得最顯著的成果這是我在過程改進時最常用到的/法則在項目實施時實際情況並不理想因為開發人員忙於改Bug少有主動寫錯誤發生的根本原因的這需要開發人員的配合和管理者的支持
缺陷數據的使用應謹慎不要將錯誤個人化應保證數據的真實性否則數據對過程改進沒有意義
實施過程中大家會對工具提出很多需求應評估哪些是共同需求核心需求系統修改復雜程度對當前系統和系統升級的影響測試組在實施過程中對不同角色人員的工作流程有了深入而准確的了解同時可以進行工作流程的改進
使用開源系統的利弊
由於開源系統的代碼是公開的用戶可自行維護和定制大家也可以提交新特性和功能擴展要求而不必受制於商業系統的制造商開源系統的用戶遍布世界各地 Bug反而容易發現同時公開源代碼中低效率的程序也容易被發現和修改當然越是流行的軟件生命力越強Bug清除和新特性增加越快
開源系統與其他工具的集成比較差不如商業系統提供整個軟件開發生命周期的工具的集成如項目管理需求管理建模自動化測試缺陷跟蹤配置管理等有機集成實現整個開發流程的自動化但一般的中小企業大多沒有實力配置全所有系統另外不同廠商優勢不同主導系統也不同有的企業需要根據自身的特點選擇不同廠商的工具所以即使購買商業工具也未必能將所有系統很好地集成
開源系統是免費的但有人提供收費的系統維護和定制服務
五小結
本文主要探討缺陷跟蹤管理的流程工具和實施問題缺陷跟蹤在技術上並不難而是難在管理上好的工具有利於管理和交流優秀的項目組應意識到有效的交流方式是多種多樣的不應該單依賴系統這樣才有利於提高團隊的戰斗力而不是把重點放在追求系統功能的十全十美有些缺陷跟蹤系統有Knowledge Base 功能這對公司知識庫的累積也很有效;有的系統對不同用戶生成相關的ToDoList方便日常工作;有的對每個發布版本都有詳細的缺陷報告總之花費時間和精力完善錯誤管理系統是值得的這是質量管理和提高的基礎
參考書目
《測試流程管理》 北京大學出版社 作者Rex Black 年月第一版
《CVS開源軟件開發技術》 機械工業出版社 作者Karl Fogel 年月第一版
關於作者
蔡琰外企QA主管有三年電子商務領域QA測試主管經驗及多年的開發經歷目前關注基於JEE構架的web系統的功能測試和性能測試自動化測試過程改進現在上海您可以通過電子郵件cindy_cai@sinacom 和她聯系
From:http://tw.wingwit.com/Article/program/Java/ky/201311/29215.html
