• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
    • 軟件測試技術
    • 軟件測試博客
    • 軟件測試視頻
    • 開源軟件測試技術
    • 軟件測試論壇
    • 軟件測試沙龍
    • 軟件測試資料下載
    • 軟件測試雜志
    • 軟件測試人才招聘
      暫時沒有公告

    字號: | 推薦給好友 上一篇 | 下一篇

    使用開源軟件 Mantis 實施缺陷跟蹤的成功實踐

    發布: 2008-2-02 17:56 | 作者: 蔡琰 | 來源: developerWorks中國 | 查看: 272次 | 進入軟件測試論壇討論

    領測軟件測試網 缺陷管理貫穿于整個軟件開發生命周期中, 是不可缺少的環節,但在國內一些中小型開發商中沒有得到足夠得重視。本文結合實際應用,系統地介紹了缺陷跟蹤開源軟件 Buggit 和 Mantis, 以期拋磚引玉,引起重視。
    在您的項目中,是否有遇到過這樣的問題:測試人員報的缺陷被遺忘掉;延期項目終于發布,卻遭遇用戶頻頻抱怨,管理人員將矛頭指向測試人員;書寫不規范的錯誤報告,使得開發人員不得不一次次找到測試人員來重現;地域分散的開發團隊,通過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/

    TAG: bug mantis 工具 缺陷跟蹤 BUG


    關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
    版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
    北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
    技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

    軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>