軟件測試中測試工作中的缺陷跟蹤管理

軟件測試中測試工作中的缺陷跟蹤管理

論文摘要：本文介紹了基于B/S模式的軟件缺陷跟蹤管理系統的設計與實現。軟件缺陷是在軟件生命周期中不可避免的對象。缺陷跟蹤管理是軟件管理的重要組成?，F有管理方法是將進入到系統中的問題,都認為是軟件缺陷進行處理。但是實際情況卻可能有虛假或重復的缺陷報告。不及時處理這些問題,它本身又可能形成新的缺陷。從軟件系統考慮,應將軟件缺陷跟蹤管理納入到項目管理信息系統之中,成為項目管理信息系統的一個子系統。對維護人員提交的缺陷報告認真鑒定、篩選、分類,進入不同的處理流程,以獲得真正的缺陷跟蹤數據。本文在分析討論這些問題的基礎上,提出新的軟件缺陷跟蹤管理系統的總體結構。

　　軟件缺陷跟蹤管理系統在現代軟件開發中已經占據了很重要的位置。每一個軟件組織都知道必須妥善處理軟件中的缺陷。這是關系到軟件組織生存、發展的質量根本?？蛇z憾的是，并非所有的軟件組織都知道如何有效地管理自己軟件中的缺陷。CMM及CMMI都對軟件缺陷跟蹤給予了關注并做出了相關規定。作為軟件工程專業的本科畢業論文，本文的側重點放在了討論這個程序的需求分析、設計、實現及所用到的項目管理知識。借著實現這個簡單的缺陷跟蹤系統，探討了個人軟件開發過程當中遇到的各種問題，以及解決它們的方法，展示了個人軟件開發的一般過程。內容瑣碎，難免會牽扯到當前流行的各種Java Web編程技術的細節。

缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發現軟件系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發現的缺陷都能夠及時得到處理是測試工作的一項重要內容。

    1、 缺陷跟蹤管理的目標

    缺陷能夠引起軟件運行時產生的一種不希望或不可接受的外部行為結果，軟件測試過程簡單說就是圍繞缺陷進行的，對缺陷的跟蹤管理一般而言需要達到以下的目標：

    確保每個被發現的缺陷都能夠被解決；這里解決的意思不一定是被修正，也可能是其他處理方式（例如，在下一個版本中修正或是不修正），總之，對每個被發現的BUG的處理方式必須能夠在開發組織中達到一致；

    收集缺陷數據并根據缺陷趨勢曲線識別測試過程的階段；決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結束是常用并且較為有效的一種方式。

    收集缺陷數據并在其上進行數據分析，作為組織的過程財富。

    上述的第一條是最受到重視的一點，在談到缺陷跟蹤管理時，一般人都會馬上想到這一條，然而對第二和第三條目標卻很容易忽視。其實，在一個運行良好的組織中，缺陷數據的收集和分析是很重要的，從缺陷數據中可以得到很多與軟件質量相關的數據。

    2、 缺陷的描述

    對缺陷的描述應該包含以下的內容： 可追蹤信息
 缺陷ID
 唯一的缺陷ID，可以根據該ID追蹤缺陷
 
缺陷基本信息
 缺陷狀態
 缺陷的狀態，分為“待分配”、“待修正”、“待驗證”、“待評審”、“關閉”
 
缺陷標題
 描述缺陷的標題
 
缺陷的嚴重程度
 描述缺陷的嚴重程度，一般分為“致命”、“嚴重”、“一般”、“建議”四種
 
缺陷的緊急程度
 描述缺陷的緊急程度，從1－4，1是優先級最高的等級，4是優先級最低的等級
 
缺陷提交人
 缺陷提交人的名字（郵件地址）
 
缺陷提交時間
 缺陷提交的時間
 
缺陷所屬項目/模塊
 缺陷所屬的項目和模塊，最好能較精確的定位至模塊
 
缺陷指定解決人
 缺陷指定的解決人，在缺陷“提交”狀態為空，在缺陷“分發”狀態下由項目經理指定相關開發人員修改
 
缺陷指定解決時間
 項目經理指定的開發人員修改此缺陷的deadline
 
缺陷處理人
 最終處理缺陷的處理人
 
缺陷處理結果描述
 對處理結果的描述，如果對代碼進行了修改，要求在此處體現出修改
 
缺陷處理時間
 缺陷處理的時間
 
缺陷驗證人
 對被處理缺陷驗證的驗證人
 
缺陷驗證結果描述
 對驗證結果的描述（通過、不通過）
 
缺陷驗證時間
 對缺陷驗證的時間
 
缺陷的詳細描述
 　 對缺陷的詳細描述；之所以把這項單獨列出來，是因為對缺陷描述的詳細程度直接影響開發人員對缺陷的修改，描述應該盡可能詳細
 
測試環境說明
 　 對測試環境的描述
 
必要的附件
 　 對于某些文字很難表達清楚的缺陷，使用圖片等附件是必要的
 
缺陷的描述項中用淡紫色描述的是缺陷在處理階段填寫的內容；用淡青色描述的是缺陷在驗證階段填寫的內容。除上述描述項外，從統計的角度出發，還可以添加上“缺陷引入階段”、“缺陷修正工作量”等項目。
3、 缺陷管理的一般流程

    缺陷管理的流程比較簡單，圖1是一個缺陷狀態圖。

    流程中的角色：

    1、 測試人員：進行測試的人員，缺陷的發起者；

    2、 項目經理：對整個項目負責，對產品質量負責的人員；

    3、 開發人員：執行開發任務的人員，完成實際的設計和編碼工作；

    4、 評審委員會：對缺陷進行最終確認，在項目成員對缺陷達不成一致意見時，行使仲裁權力。

    缺陷的狀態

    1、 初始化：缺陷的初始狀態；

    2、 待分配：缺陷等待分配給相關開發人員處理；

    3、 待修正：缺陷等待開發人員修正；

    4、 待驗證：開發人員已完成修正，等待測試人員驗證；

    5、 待評審：開發人員拒絕修改缺陷，需要評審委員會評審；

    6、 關閉：缺陷已被處理完成。

    4、 缺陷數據統計

    如前所述，缺陷數據統計也是缺陷跟蹤管理系統的目標。一般而言，生成的缺陷數據統計圖表包括缺陷趨勢圖、缺陷分布圖、缺陷及時處理情況統計表等。

    5、 缺陷跟蹤管理系統

    目前已有的缺陷跟蹤管理軟件包括Compuware公司的TrackRecord軟件（商業軟件）、Mozilla公司的Buzilla軟件（免費軟件），以及國內的微創公司的BMS軟件，這些軟件在功能上各有特點，可以根據實際情況選用。當然，也可以自己開發缺陷跟蹤軟件，例如基于Notes或是ClearQuese開發缺陷跟蹤管理軟件。我公司采用的是自己開發的基于Notes的缺陷跟蹤系統，除了具有上述功能外，還能夠通過Notes的郵件系統方便地向相關人員發送提醒信息（缺陷處理超時提醒、缺陷待處理提醒等）。

    除此之外，作為一個缺陷跟蹤管理系統，還必須注意權限分配的問題。缺陷記錄作為軟件開發過程中的重要數據，不能輕易被刪除；對于已經關閉的缺陷，也不能隨意進行修改。因此，缺陷跟蹤管理系統必須設置嚴格的管理權限，非相關人員不得進行相應操作，修改相應數據。在這一點上，通過Notes也很容易控制。

原文轉自：http://www.anti-gravitydesign.com