軟件缺陷管理系統(tǒng)的研究

1、優(yōu)秀學(xué)位論文作者聲明本人鄭重聲明：所呈交的學(xué)位論文是本人在導(dǎo)師的指導(dǎo)下獨(dú)立進(jìn)行研究所取得的研究成果。除了文中特別加以標(biāo)注引用的內(nèi)容外，本論文不包含任何其他個人或集體已經(jīng)發(fā)表或撰寫的成果作品。本人完全了解有關(guān)保障、使用學(xué)位論文的規(guī)定，同意學(xué)校保留并向有關(guān)學(xué)位論文管理機(jī)構(gòu)送交論文的復(fù)印件和電子版。同意省級優(yōu)秀學(xué)位論文評選機(jī)構(gòu)將本學(xué)位論文通過影印、縮印、掃描等方式進(jìn)行保存、摘編或匯編；同意本論文被編入有關(guān)數(shù)據(jù)庫進(jìn)行檢索和查閱。本學(xué)位論文內(nèi)容不涉及國家機(jī)密。論文題目：軟件缺陷管理系統(tǒng)的研究缺陷收集與跟蹤作者單位：江漢大學(xué) 數(shù)學(xué)與計(jì)算機(jī)科學(xué)學(xué)院作者簽名：董哲熙 2008 年 5 月 28 日 學(xué)士學(xué)位論

2、文論文題目 軟件缺陷管理系統(tǒng)的研究 缺陷收集與跟蹤（英 文） Research on Software Defect Management System Defect Collecting and Tracking學(xué) 院 數(shù)學(xué)與計(jì)算機(jī)科學(xué)學(xué)院 專 業(yè) 計(jì)算機(jī)科學(xué)與技術(shù) 姓 名 學(xué) 號 指導(dǎo)教師 2008 年 5 月 28 日目 錄摘 要1Abstract2文獻(xiàn)綜述3第一章 緒 論81.1 軟件缺陷管理系統(tǒng)的開發(fā)背景和意義81.2 軟件缺陷管理系統(tǒng)的研究內(nèi)容91.3 本文主要工作101.4 小結(jié)10第二章 軟件缺陷管理綜述112.1 軟件缺陷管理的目標(biāo)112.2 軟件缺陷管理的要素112.2.1

3、 缺陷收集與跟蹤112.2.2 缺陷統(tǒng)計(jì)與分析142.3 軟件缺陷管理的流程162.3.1 軟件缺陷生命周期162.3.2 軟件缺陷管理流程中的角色172.4 小結(jié)18第三章 軟件缺陷管理系統(tǒng)的開發(fā)與設(shè)計(jì)193.1 系統(tǒng)開發(fā)環(huán)境及工具193.2 可行性分析193.3 系統(tǒng)的需求分析193.4 系統(tǒng)功能設(shè)計(jì)233.4.1 系統(tǒng)流程分析233.4.2 系統(tǒng)功能描述243.5 系統(tǒng)的數(shù)據(jù)庫設(shè)計(jì)253.5.1 數(shù)據(jù)表結(jié)構(gòu)253.5.2 表間關(guān)系263.6 小結(jié)26第四章 軟件缺陷管理系統(tǒng)的實(shí)現(xiàn)與運(yùn)行274.1 CSS樣式表文件設(shè)計(jì)274.2 創(chuàng)建數(shù)據(jù)庫連接284.3 主要功能詳細(xì)設(shè)計(jì)284.3.1 用

4、戶登陸284.3.2 瀏覽缺陷294.3.3 提交缺陷334.3.4 修改缺陷344.3.5 歸檔處理394.4 小結(jié)41第五章 結(jié)束語42致 謝43參考文獻(xiàn)44 摘 要隨著現(xiàn)在計(jì)算機(jī)軟件開發(fā)規(guī)模越來越大，如何管理軟件開發(fā)中出現(xiàn)的缺陷、提高軟件質(zhì)量是軟件企業(yè)關(guān)心的問題。本文介紹了軟件缺陷的概念、屬性，利用UML分析了缺陷管理的工作流程、系統(tǒng)角色的權(quán)限，設(shè)計(jì)并實(shí)現(xiàn)了一個可對提交的缺陷進(jìn)行跟蹤、管理、統(tǒng)計(jì)和分析的軟件缺陷管理系統(tǒng)。系統(tǒng)基于B/S結(jié)構(gòu)，采用ASP，SQL Server等技術(shù)來實(shí)現(xiàn)。實(shí)踐表明，該系統(tǒng)具有一定的實(shí)用價(jià)值。關(guān)鍵詞軟件缺陷；缺陷收集；缺陷跟蹤 ；UML；ASP；SQL Ser

5、verAbstractNowadays, the scale of the software development is growing up increasingly. And people pay more attention to the numerous defects in a software system. Its important to diminish those defects to improve the quality. In this paper, we focus on design a software defect management system. It

6、 is to help developers detect software defects and assist project managers in allocating testing resources more effectively. First, we introduce the definition of software defects and discuss its attributes. Then, we use the UML to illustrate the work flow and the system roles authority of the defec

7、t management. The function of this system is to track, manage and analyze the collected defects. The system is based on B/S framework, using ASP, SQL Server and other technologies. Practice shows that the system has some practical value.KeywordsSoftware defect; Defect collecting; defect tracking; UM

8、L; ASP; SQL Server文獻(xiàn)綜述1、緒論2003年8月，數(shù)百萬人陷入黑暗，軟件缺陷顯然是造成在北美東北地區(qū)的大停電事故的元兇。2005年4月，美國航空集團(tuán)公司一些機(jī)票被錯誤地售價(jià)為1.86美元，這個軟件缺陷造成數(shù)千美元的損失。在最近一次美國總統(tǒng)大選中，在幾個地區(qū)所使用的新的電腦投票機(jī)產(chǎn)生了不正確的統(tǒng)計(jì)數(shù)1。這樣的例子舉不勝舉，軟件缺陷的危害幾乎涉及到每一個使用計(jì)算機(jī)的單位與個人。軟件缺陷(defect）指的是系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實(shí)現(xiàn)其功能的缺陷。在軟件開發(fā)的某一階段中發(fā)現(xiàn)的上一階段產(chǎn)生的錯誤，如語法錯誤、拼寫錯誤或者是一個不正確的程序語句等，一般需要返工以更正這個

9、錯誤。研究表明，在軟件的編碼測試階段遺漏編碼缺陷，如果到系統(tǒng)測試時(shí)才發(fā)現(xiàn)，那么這時(shí)糾正缺陷所花費(fèi)的成本是在編碼階段糾錯花費(fèi)的成本的7倍以上。因此，是否能及早地將缺陷信息從軟件產(chǎn)品開發(fā)過程中反饋回來是軟件質(zhì)量生存期中最重要的一步。2、問題的提出軟件缺陷是軟件質(zhì)量的對立面，缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的，有些缺陷很明顯比較容易被修復(fù)成功，有些缺陷卻很隱蔽很難被發(fā)現(xiàn)。現(xiàn)在，人們越來越重視軟件質(zhì)量問題，試圖用這樣那樣的方法來提高軟件質(zhì)量。軟件測試是檢查軟件發(fā)現(xiàn)缺陷的過程，是軟件質(zhì)量保證過程中不可或缺的一個環(huán)節(jié)，但軟件行業(yè)發(fā)展二十多年來，開發(fā)高質(zhì)量軟件均非易事。而軟件測試的目標(biāo)是找到至

10、今還未發(fā)現(xiàn)的缺陷，而不是確保沒有缺陷2。因此，不管測試工作量有多大，缺陷可能仍然存在，為了保證軟件正常運(yùn)行，必須對軟件中存在的缺陷進(jìn)行有效的管理，從而提高軟件質(zhì)量。軟件缺陷管理就是在開發(fā)中對發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個被發(fā)現(xiàn)的缺陷被關(guān)閉。從某種意義上說，軟件項(xiàng)目管理過程可以看作是軟件產(chǎn)品的缺陷管理過程，軟件過程的目的是避免將缺陷引入軟件產(chǎn)品或?qū)⒁旬a(chǎn)生的缺陷識別出來，并將其排除。軟件缺陷管理技術(shù)不僅應(yīng)用在代碼層次，還應(yīng)用于軟件工程過程的所有相關(guān)活動中。缺陷管理作為軟件質(zhì)量管理的重要組成部分，正在成為軟件開發(fā)管理過程的又一亮點(diǎn)，從國內(nèi)外越來越多的公司進(jìn)行相關(guān)管理工具的開發(fā)，到人們對缺陷管理工具的需

11、求逐漸增多而且更加明確，同時(shí)渴望能夠得到物美價(jià)廉的可用版本，軟件缺陷管理的其重要性和被人們所給予的重視程度可見一斑。3、軟件缺陷管理系統(tǒng)的發(fā)展情況軟件測試是檢查軟件發(fā)現(xiàn)缺陷的過程，統(tǒng)計(jì)表明，在典型的軟件開發(fā)項(xiàng)目中，軟件測試工作量往往占總工作量的40%以上，而根據(jù)對國際著名IT企業(yè)的統(tǒng)計(jì)，測試費(fèi)用占軟件開發(fā)的總成本的50%以上3。在國外軟件產(chǎn)業(yè)發(fā)達(dá)國家，軟件測試占有絕對重要的地位。在微軟內(nèi)部，軟件測試人員與軟件開發(fā)人員的比率一般為1比 1.52.5，微軟軟件開發(fā)的實(shí)踐過程己經(jīng)證明了這種人員結(jié)構(gòu)的合理性與正確性。從國內(nèi)最近幾年軟件測試人員的短缺情況來看，軟件測試行業(yè)正越來越得到重視。以往重開發(fā)輕測

12、試的狀況也得到改善，開發(fā)人員和測試人員也不再像以前那樣互相抵觸，現(xiàn)在，開發(fā)人員期望測試人員發(fā)現(xiàn)更多的缺陷，在整個軟件生命周期中能夠愉快的合作。越來越多的軟件公司和管理技術(shù)人員在工作中將更多的時(shí)間和資源投向了測試方面。很多優(yōu)秀企業(yè)中開發(fā)與測試的人員比例達(dá)到了3比1或2比1，許多頂尖的技術(shù)人員在從事質(zhì)量控制和軟件測試工作。軟件缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，而對軟件缺陷進(jìn)行跟蹤管理的目的是確保每個被發(fā)現(xiàn)的缺陷都能夠及時(shí)得到處理。缺陷跟蹤管理系統(tǒng)在實(shí)現(xiàn)技術(shù)層面上來看是一個數(shù)據(jù)庫應(yīng)用程序。它包括前臺用戶界面、后臺缺陷數(shù)據(jù)庫以及中間數(shù)據(jù)處理層。缺陷是影響軟

13、件質(zhì)量的所有外部因素，正確性(沒有缺陷)就是高質(zhì)量軟件的本質(zhì)屬性。邏輯上，僅有兩種主要的方法可應(yīng)用于開發(fā)低缺陷的軟件：缺陷預(yù)防(構(gòu)件軟件時(shí)防止引入缺陷)；缺陷排除(檢測并排除在構(gòu)建軟件時(shí)引入的缺陷) 4。軟件缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，而對軟件缺陷進(jìn)行跟蹤管理的目的是確保每個被發(fā)現(xiàn)的缺陷都能夠及時(shí)得到處理。軟件測試過程簡單說就是圍繞缺陷進(jìn)行的，對缺陷的跟蹤管理一般而言需要達(dá)到以下目標(biāo)：1. 確保每個被發(fā)現(xiàn)的缺陷都能夠被解決，“解決”的意思不一定是被修正，也可能是被延遲等等，總之，對每個被發(fā)現(xiàn)的bug的處理方式必須能夠在開發(fā)組織中達(dá)到一致；2.

14、 收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識別測試出于測試過程中的哪個階段；3. 決定測試過程是否結(jié)束，通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式；4. 收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織過程改進(jìn)的財(cái)富。在實(shí)際運(yùn)用中的軟件缺陷跟蹤系統(tǒng)用來描述報(bào)告所發(fā)現(xiàn)的缺陷，處理軟件缺陷屬性，跟蹤軟件缺陷的整個生命周期和生成軟件缺陷跟蹤圖表等。缺陷數(shù)據(jù)是生成各種各樣測試分析、質(zhì)量控制圖表的基礎(chǔ)，從這些缺陷分析圖表中可以清楚的看到缺陷的修復(fù)過程，分析缺陷發(fā)生的根本原因，跟蹤管理缺陷的效率。軟件缺陷跟蹤管理系統(tǒng)可以通過添加、修改、排序、查尋、存儲操作來管理軟件缺陷。缺陷跟蹤管理系統(tǒng)在實(shí)現(xiàn)技術(shù)

15、層面上來看是一個數(shù)據(jù)庫應(yīng)用程序。它包括前臺用戶界面、后臺缺陷數(shù)據(jù)庫以及中間數(shù)據(jù)處理層。目前，不少缺陷跟蹤管理系統(tǒng)是采用B/S結(jié)構(gòu)來實(shí)現(xiàn)的，相應(yīng)地，采用的編程語言是ASP或JSP。軟件缺陷管理實(shí)際是軟件測試流程管理的一個子過程,其應(yīng)用模型一般主要由四個部分組成：缺陷收集、缺陷跟蹤、缺陷度量、項(xiàng)目評估。如圖1所示：缺陷收集缺陷度量缺陷跟蹤項(xiàng)目評估圖1 軟件缺陷管理應(yīng)用模型軟件缺陷收集部分是整個應(yīng)用模型的基礎(chǔ)；軟件缺陷跟蹤部分是規(guī)范解決項(xiàng)目中的缺陷的一個必要手段，也是軟件缺陷管理中的一個重要組成部分；軟件缺陷度量方法的選擇是缺陷度量階段的核心問題，它能最大限度的評估軟件的項(xiàng)目；項(xiàng)目評估作為軟件缺陷度

16、量方法的應(yīng)用結(jié)果與這些方法的選擇相關(guān)。軟件缺陷管理系統(tǒng)的實(shí)現(xiàn)過程主要分為兩步，第一步是從軟件缺陷管理的理論到應(yīng)用模型；第二步使用軟件方法實(shí)現(xiàn)該模型。軟件缺陷信息的收集主要依據(jù)缺陷的屬性、缺陷的生命周期以及項(xiàng)目開發(fā)實(shí)踐中所需要的內(nèi)容來設(shè)計(jì)和實(shí)現(xiàn)的；軟件缺陷跟蹤部分是整個系統(tǒng)解決方案中一個重點(diǎn)，主要依據(jù)缺陷跟蹤流程中的角色與缺陷狀態(tài)關(guān)系，并以工作流技術(shù)來靈活配置角色的權(quán)限和缺陷狀態(tài)的變遷過程；軟件缺陷度量是整個系統(tǒng)解決方案的另中一個重點(diǎn)，也是當(dāng)前進(jìn)行缺陷管理過程中容易忽略的一個階段，其重點(diǎn)要解決的就是缺陷度量方法的選取，方法選取是否恰當(dāng)，直接影響到下一階段的項(xiàng)目評估；項(xiàng)目評估部分主要依據(jù)前一階段的

17、缺陷度量的結(jié)果對項(xiàng)目的質(zhì)量、進(jìn)度、效率進(jìn)行評估。目前，不少軟件公司研制出了相應(yīng)的缺陷管理軟件，用得比較多的包括Rational公司的C1earQuest軟件和Mozilla公司的Bugzilla軟件，國內(nèi)的微創(chuàng)公司也推出一套缺陷管理系統(tǒng)BMS。這些產(chǎn)品的推出說明缺陷管理越來越受到軟件企業(yè)的重視，但商業(yè)軟件往往價(jià)格昂貴，代價(jià)高也不一定能起到很好的作用，例如ClearQuest的一個License報(bào)價(jià)在5萬人民幣，如果再要使用與ClearQuest相配套的ClearCase，則一個License要5000美金。價(jià)格是一個問題，維護(hù)代價(jià)也很高。另外，Rational系列產(chǎn)品有些地方不夠人性化，比如要

18、查找一個己經(jīng)提交的缺陷不是很方便，也無法避免重復(fù)缺陷的提交，這樣就給缺陷審核人員帶來了很多不必的麻煩4。即使購買了Rational系列產(chǎn)品的公司往往由于過程管理沒有跟上，使得這些過程支持軟件發(fā)揮不了它們強(qiáng)大的作用?？梢?，工具只是手段，過程本身的改進(jìn)才是重點(diǎn)5。而微創(chuàng)公司的BMS系統(tǒng)中的缺陷狀態(tài)設(shè)置僅為3種：已激活、已解決、已關(guān)閉，這對于缺陷狀態(tài)的描述和缺陷處于不同狀態(tài)的統(tǒng)計(jì)略顯不足，因?yàn)閲庠S多關(guān)于缺陷管理的參考文獻(xiàn)將缺陷狀態(tài)定義為5-7種6。另外，BMS系統(tǒng)將所有成員分成兩種角色：一般用戶（包括個人用戶、項(xiàng)目經(jīng)理）、企業(yè)經(jīng)理，該系統(tǒng)的角色設(shè)置較少，且角色不能定制。而一些免費(fèi)的開源軟件功能又不

19、夠強(qiáng)大，比如Bugzilla軟件的統(tǒng)計(jì)、查詢和分析功能較少，人性化設(shè)計(jì)較差，用戶定制界面較少。由于過程管理軟件往往與軟件組織結(jié)構(gòu)設(shè)置和實(shí)際的開發(fā)過程緊密關(guān)聯(lián)，若軟件無法進(jìn)行恰當(dāng)?shù)亩ㄖ?，必然限制該軟件在軟件組織內(nèi)的推廣使用。因此，根據(jù)特定的需求采取自主研發(fā)軟件缺陷管理系統(tǒng)的方式也逐漸受到青睞。4、總結(jié)軟件缺陷管理作為軟件工程學(xué)科的一個分支，關(guān)于它的理論研究起步較晚，發(fā)展遠(yuǎn)未成熟。同時(shí)，國內(nèi)從事軟件缺陷管理研究和工作的組織和企業(yè)較少。目前國內(nèi)大量的出版物中，關(guān)于軟件缺陷管理方面的資料較少。根據(jù)查閱文獻(xiàn)所掌握的資料，目前軟件缺陷管理的相關(guān)論文總量不多，尤其是國內(nèi)在這方面的研究成果更少。參考文獻(xiàn)1 H

20、ildreth, Sue. Up from a Low-Quality Quagmire . Computerworld.2005, Vol. 39(30):23-252 朱少明.全程軟件測試.北京:電子工業(yè)出版社,20073 朱少明.軟件測試方法和技術(shù).北京:清華大學(xué)出版社,20054 Edward Kit.軟件測試過程改進(jìn).北京:機(jī)械工業(yè)出版社,20045 SPIN一CS，主流測試工具介紹，軟件學(xué)報(bào)，2003.16 徐曉春,李高健.軟件配置管理.北京:清華大學(xué)出版社,20027 Chillarege R,Bhandari I,Chaar J et al.Defect Classificat

21、ion-A Concept for Inprocess Measurements.IEEE Transactions on Software Engineering,1992,18(11):943-9568 王軍,申期.科技統(tǒng)計(jì).北京:中國統(tǒng)計(jì)出版社,20009 謝敏、戴金龍.軟件測試系列報(bào)道之二追蹤每一個軟件缺陷.計(jì)算機(jī)世界.2005年04月25日（第C16版）10 Weinberg,G. M. 質(zhì)量軟件管理系統(tǒng)思維.北京：清華大學(xué)出版社，2004 11 G.Gordon Schulmeyer, James I.McManus. 軟件質(zhì)量保證. 第3版. 北京:機(jī)械工業(yè)出版社,200312

22、陳雷. 軟件測試實(shí)踐之缺陷跟蹤管理.程序員. 2004，1213 Grady Booch, James Rumbaugh, Ivar Jacobson. UML參考手冊. 北京：機(jī)械工業(yè)出版社，200114 Kelly, Michael. Bonding Over BUGS.Computer world. 2005, 39(10):49-5015 Cohen, Alan. Software is too buggy and unreliable. PC Magazine. 2005, 24(14) :86-8716 Stephen H.Ka. 軟件質(zhì)量工程度量與模型. 第2版. 北京:電子工業(yè)

23、出版社,200417 Houman Younessi. 面向?qū)ο蟮能浖毕莨芾? 北京:機(jī)械工業(yè)出版社,200418 Cern Kaner, James Bach, Bret Pettichord.軟件測試經(jīng)驗(yàn)與教訓(xùn).北京:機(jī)械工業(yè)出版社,200419 賽奎春. ASP信息系統(tǒng)開發(fā)實(shí)例精選. 北京:機(jī)械工業(yè)出版社,200620 G.Y. Hong, T.N. Goh.Six Sigma in software quality.The TQM Magazine. 2003,15(6):10-1421 Vanessa Pratt, Jay Warner. Defect inspection in

24、transparent materials.Sensor Review. Volume: 20 Issue 4, 2000 Technical paper22 Rupa Mahanti, Jiju Antony. Confluence of six sigma, simulation and software development. Managerial Auditing Journal. Vol. 20 Issue 7. 2005 Technical paper23 Qinbao Song , Martin Shepperd , Michelle Cartwright , Carolyn

25、Mair. Software Defect Association Mining and Defect Correction Effort Prediction. IEEE Transactions on Software Engineering. 2006.2 Vol. 32 Issue 224 Barry Boehm, Victor R. Basili. Software Defect Reduction Top 10 List. Computer.2001,34(1)第一章 緒 論1.1 軟件缺陷管理系統(tǒng)的開發(fā)背景和意義自從軟件危機(jī)爆發(fā)以來，軟件缺陷的危害幾乎涉及到每一個使用計(jì)算機(jī)的單位

26、與個人，大約40%到50%的用戶程序都有不容忽視的缺陷1。因此，人們越來越重視軟件質(zhì)量問題，試圖用這樣那樣的方法來提高軟件質(zhì)量，現(xiàn)今的軟件項(xiàng)目是把40%到50%的工作量花在了修改上。但多年以來，開發(fā)高質(zhì)量軟件均非易事，原因在于“與生俱來”的軟件缺陷是軟件質(zhì)量的對立面，缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的。軟件測試是檢查軟件發(fā)現(xiàn)缺陷的過程，統(tǒng)計(jì)表明，在典型的軟件開發(fā)項(xiàng)目中，軟件測試工作量往往占總工作量的40%以上，而根據(jù)對國際著名IT企業(yè)的統(tǒng)計(jì)，測試費(fèi)用占軟件開發(fā)的總成本的50%以上2。軟件測試是軟件工程中相當(dāng)重要的一部分，這是軟件行業(yè)二十幾年的不斷失敗中總結(jié)出的經(jīng)驗(yàn)。在國外軟件產(chǎn)業(yè)

27、發(fā)達(dá)國家，軟件測試占有絕對重要的地位。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大區(qū)別，優(yōu)秀測試人員的待遇甚至比程序員還耍高。在微軟內(nèi)部，軟件測試人員與軟件開發(fā)人員的比率一般為1比 1.52.5，微軟軟件開發(fā)的實(shí)踐過程己經(jīng)證明了這種人員結(jié)構(gòu)的合理性與正確性。從國內(nèi)最近幾年軟件測試人員的短缺情況來看，軟件測試行業(yè)正越來越得到重視。以往重開發(fā)輕測試的狀況也得到改善，開發(fā)人員和測試人員也不再像以前那樣互相抵觸，現(xiàn)在，開發(fā)人員期望測試人員發(fā)現(xiàn)更多的缺陷，在整個軟件生命周期中能夠愉快的合作。越來越多的軟件公司和管理技術(shù)人員在工作中將更多的時(shí)間和資源投向了測試方面。很多優(yōu)秀企

28、業(yè)中開發(fā)與測試的人員比例達(dá)到了3比1或2比1，許多頂尖的技術(shù)人員在從事質(zhì)量控制和軟件測試工作。然而，軟件測試的目標(biāo)是找到至今還未發(fā)現(xiàn)的缺陷，而不是確保沒有缺陷3。因此，不管測試工作量有多大，缺陷可能仍然存在，為了保證軟件正常運(yùn)行，必須對軟件中存在的缺陷進(jìn)行有效的管理，從而提高軟件質(zhì)量。軟件缺陷管理作為軟件質(zhì)量管理的重要組成部分，正在成為軟件開發(fā)管理過程的又一亮點(diǎn)，從國內(nèi)外越來越多的公司進(jìn)行相關(guān)管理工具的開發(fā)，到人們對缺陷管理工具的需求逐漸增多且越來越明確，同時(shí)希望獲得物美價(jià)廉切合實(shí)際的可用版本，軟件缺陷管理系統(tǒng)的重要性和所受關(guān)注程度不言而喻。1.2 軟件缺陷管理系統(tǒng)的研究內(nèi)容不論是大型還是中小

29、型軟件測試，其缺陷數(shù)目都是眾多的，如何保證這些缺陷被準(zhǔn)確、及時(shí)發(fā)現(xiàn)和處理，保證軟件測試和開發(fā)的和諧進(jìn)展，使軟件項(xiàng)目在計(jì)劃的時(shí)間內(nèi)，發(fā)布高質(zhì)量的產(chǎn)品，成為項(xiàng)目管理人員、開發(fā)人員和測試人員要認(rèn)真對待的任務(wù)之一4。缺陷管理可視為軟件工程的真正本質(zhì)，缺陷管理的最終目的是提高產(chǎn)品質(zhì)量5。軟件測試的實(shí)踐表明，缺陷管理可以行之有效的保證每一條缺陷被完整記錄、及時(shí)處理、驗(yàn)證和關(guān)閉。它作為軟件測試的一個重要環(huán)節(jié)，包括缺陷報(bào)告，缺陷生命周期，缺陷跟蹤，趨勢分析，分布分析，質(zhì)量評估，缺陷預(yù)防等方面。我們根據(jù)測試需求、測試計(jì)劃，對測試過程中每個狀態(tài)進(jìn)行記錄、跟蹤和管理，并提供相關(guān)的分析和統(tǒng)計(jì)功能，生成和打印各種分析統(tǒng)

30、計(jì)報(bào)表。通過對詳細(xì)記錄的分析，形成較為完整的軟件測試管理文檔，保障軟件在開發(fā)過程中，避免同樣的錯誤再次發(fā)生，從而提高軟件開發(fā)質(zhì)量6。在軟件系統(tǒng)的開發(fā)過程中，為系統(tǒng)建模好比為一個建筑描繪一張藍(lán)圖同樣重要。UML（Unified Modeling Language，統(tǒng)一建模語言）是一種用于面向?qū)ο蠛突跇?gòu)件的、系統(tǒng)建模的、定義明確的、被廣泛接受的可視化建模語言?，F(xiàn)在已經(jīng)成為了軟件分析與設(shè)計(jì)建模的標(biāo)準(zhǔn)，應(yīng)用越來越廣泛7 8。盡管它常常與建模OO軟件系統(tǒng)相關(guān)聯(lián)，但由于其內(nèi)建了大量擴(kuò)展機(jī)制，還可以應(yīng)用于更多的領(lǐng)域中，如商業(yè)建模、需求管理、分析和設(shè)計(jì)、編程和測試等。UML的發(fā)展方向是簡化和鞏固大量已經(jīng)存在

31、的面向?qū)ο蟮慕７椒?，UML定義了九種圖，這些圖被用來建立系統(tǒng)的靜態(tài)（結(jié)構(gòu)）和動態(tài)（行為）模型。結(jié)構(gòu)圖包括類圖（Class Diagram）、對象圖（Object Diagram）、構(gòu)件圖（Component Diagram）和配置圖（Deployment），用于描述建立系統(tǒng)模型時(shí)在問題域中遇到的主要事物。行為圖包括用例圖（UseCase Diagram）、狀態(tài)圖（Statechart Diagram）、活動圖（Activity Diagram）、順序圖（Sequence Diagram）和合作圖（Collaboration Diagram），用于描述建立系統(tǒng)的動態(tài)模型?；诖耍鞠到y(tǒng)的研究內(nèi)

32、容：通過對軟件缺陷的概念、屬性、特征的認(rèn)識，明確了軟件缺陷管理系統(tǒng)的目標(biāo)，分析了缺陷管理的工作流程、系統(tǒng)角色的權(quán)限，設(shè)計(jì)并實(shí)現(xiàn)了一個可對提交的缺陷進(jìn)行跟蹤、管理、統(tǒng)計(jì)和分析的軟件缺陷管理系統(tǒng)；利用軟件缺陷管理系統(tǒng)產(chǎn)生的各種缺陷數(shù)據(jù)分析報(bào)告，發(fā)現(xiàn)軟件開發(fā)過程中的問題，并為過程改進(jìn)和項(xiàng)目管理提供依據(jù)。1.3 本文主要工作在此次的畢業(yè)設(shè)計(jì)中，本人深入了解缺陷信息所應(yīng)包含的內(nèi)容，利用UML統(tǒng)一建模語言詳細(xì)分析了基于四種角色權(quán)限的系統(tǒng)流程，并以此來設(shè)計(jì)數(shù)據(jù)庫、選擇并布局頁面內(nèi)容，完成系統(tǒng)目標(biāo)：實(shí)現(xiàn)缺陷收集、缺陷跟蹤。本文共分為五章。第一章：介紹課題研究背景，陳述了課題研究內(nèi)容，并說明了作者在本課題的研究

33、開發(fā)中所完成的工作。第二章：介紹開發(fā)所依據(jù)的理論根據(jù)、方法和技術(shù)，包括軟件缺陷管理的目標(biāo)，軟件缺陷管理的要素，軟件缺陷管理的流程。第三章：在系統(tǒng)需求分析的基礎(chǔ)上，詳細(xì)闡述了系統(tǒng)總體設(shè)計(jì)、功能設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)等等。第四章：按角色對系統(tǒng)平臺框架、服務(wù)及接口的實(shí)現(xiàn)進(jìn)行詳細(xì)的闡述。第五章：對所作的工作進(jìn)行了簡要的總結(jié)。最后包括致謝和參考文獻(xiàn)。1.4 小結(jié)本章主要介紹了開發(fā)軟件缺陷管理系統(tǒng)的目的和意義，對國內(nèi)外的研究現(xiàn)狀進(jìn)行了分析，并說明了具體的研究內(nèi)容與方法。第二章 軟件缺陷管理綜述2.1 軟件缺陷管理的目標(biāo)缺陷(defect)是指程序中或文檔中存在各種不希望出現(xiàn)的問題。如語法錯誤、拼寫錯誤、標(biāo)點(diǎn)錯誤

34、，或者是一個不正確的、冗余的程序語句或有缺陷的程序段等，缺陷可能出現(xiàn)在程序中、設(shè)計(jì)中，甚至出現(xiàn)在需求規(guī)格說明或其他文檔中。事實(shí)上，缺陷是任何可以影響到程序完整而有效地滿足用戶要求的東西。缺陷不僅影響用戶使用，而且是超支和延期的主要原因，對系統(tǒng)造成或大或小的影響。但缺陷是客觀存在，可以被標(biāo)志、描述和統(tǒng)計(jì)9。軟件缺陷管理就是在開發(fā)中對發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個被發(fā)現(xiàn)的缺陷被關(guān)閉。從某種意義上說，軟件項(xiàng)目管理過程可以看作是軟件產(chǎn)品的缺陷管理過程，軟件過程的目的是避免將缺陷引入軟件產(chǎn)品或?qū)⒁旬a(chǎn)生的缺陷識別出來，并將其排除。軟件缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的

35、缺陷，而對軟件缺陷進(jìn)行跟蹤管理的目的是確保每個被發(fā)現(xiàn)的缺陷都能夠及時(shí)得到處理。軟件測試過程簡單說就是圍繞缺陷進(jìn)行的，對缺陷的跟蹤管理一般而言需要達(dá)到以下目標(biāo)10：確保每個被發(fā)現(xiàn)的缺陷都能夠被解決。這里解決的意思不一定是被修正，也可能是其他處理方式（例如，在下一個版本中修正或是不修正）?？傊瑢γ總€被發(fā)現(xiàn)的缺陷的處理方式必須能夠在開發(fā)組織中達(dá)成一致。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識別測試過程的階段。決定測試過程是否結(jié)束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式。收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過程財(cái)富。上述的第一條是最受到重視的一點(diǎn)，在談到缺陷跟

36、蹤管理時(shí)，一般人都會馬上想到這一條，然而對第二和第三條目標(biāo)卻很容易忽視。其實(shí)，在一個運(yùn)行良好的組織中，缺陷數(shù)據(jù)的收集和分析是很重要的，從缺陷數(shù)據(jù)中可以得到很多與軟件質(zhì)量相關(guān)的數(shù)據(jù)。2.2 軟件缺陷管理的要素軟件缺陷管理一般包括兩個方面：1、缺陷信息的收集與跟蹤，2、缺陷信息的統(tǒng)計(jì)與分析。2.2.1 缺陷收集與跟蹤完整的軟件缺陷信息是輔助缺陷修復(fù)、缺陷信息處理、分析和利用的前提和基礎(chǔ)，也是對缺陷進(jìn)行跟蹤必不可少的步驟。因?yàn)椋ǔＲ粋€項(xiàng)目的缺陷整體跟蹤，就是缺陷的實(shí)時(shí)狀態(tài)報(bào)告。也就是說，缺陷的跟蹤是了解缺陷所在其生命周期的狀態(tài)。通過了解缺陷的實(shí)時(shí)狀態(tài)，對測試過程、項(xiàng)目進(jìn)展的控制和管理都有很大幫助，

37、可以督促開發(fā)人員盡快修正缺陷，調(diào)整測試或開發(fā)計(jì)劃。一般情況下，缺陷信息應(yīng)該包含以下內(nèi)容11 12 13：缺陷標(biāo)識：為了便于對缺陷的管理，每個缺陷賦予一個唯一性的編號，編號規(guī)則可根據(jù)需要和管理要求制定。缺陷所在的產(chǎn)品或項(xiàng)目：如果一個測試團(tuán)隊(duì)同時(shí)負(fù)責(zé)多個產(chǎn)品或項(xiàng)目的測試，并且使用同一個缺陷數(shù)據(jù)庫來存放缺陷記錄，那么就應(yīng)當(dāng)注明這個缺陷出現(xiàn)在哪一個產(chǎn)品或項(xiàng)目中。發(fā)現(xiàn)缺陷的版本：即使正在測試的是某個軟件的第一個發(fā)布版本，也應(yīng)當(dāng)注明它的版本。功能或模塊：如果希望隨時(shí)都能查詢到某個功能或者模塊一共發(fā)現(xiàn)了多少缺陷，哪些已經(jīng)被解決并確認(rèn)通過，或者希望使用功能或模塊作為條件進(jìn)行更加復(fù)雜的分析，那么應(yīng)該填寫這一項(xiàng)。

38、缺陷的類型：根據(jù)缺陷的自然屬性劃分的種類，如表2-1所示：表2-1 軟件缺陷類型列表缺陷類型描 述功能影響了各種系統(tǒng)功能、邏輯的缺陷用戶界面影響了用戶界面、人際交互特性，包括屏幕格式、用戶輸入靈活性、結(jié)果輸出格式等方面的缺陷文檔影響發(fā)布和維護(hù)，包括注釋、用戶手冊、設(shè)計(jì)文檔軟件包由于軟件配置庫、變更管理或版本控制引起的錯誤性能不滿足系統(tǒng)可測量的屬性值，如執(zhí)行時(shí)間、事務(wù)處理速率等系統(tǒng)/模塊接口與其他組件、模塊或設(shè)備驅(qū)動程序、調(diào)用參數(shù)、控制塊或參數(shù)列表等不匹配、沖突嚴(yán)重程度：缺陷的嚴(yán)重程度用來描述出現(xiàn)的缺陷對系統(tǒng)的影響，通常不同的系統(tǒng)或團(tuán)隊(duì)對于嚴(yán)重程度的定義是不同的。如表2-2所示：表2-2 軟件缺

39、陷嚴(yán)重程度列表缺陷嚴(yán)重程度描 述致命(Fatal)將導(dǎo)致產(chǎn)品失去價(jià)值，例如在財(cái)務(wù)軟件中對于數(shù)據(jù)計(jì)算中準(zhǔn)確性問題嚴(yán)重(Critical)將嚴(yán)重影響用戶的工作，例如缺陷導(dǎo)致業(yè)務(wù)流程中斷，用戶的工作無法繼續(xù)進(jìn)行下去一般(General)導(dǎo)致用戶感覺使用不方便，影響用戶滿意度，例如一些不影響系統(tǒng)主要業(yè)務(wù)流程進(jìn)行的缺陷、提示錯誤信息等建議(Suggest)對于系統(tǒng)中設(shè)計(jì)思路或具體實(shí)現(xiàn)的不同看法，如果采納，有可能會提升用戶的滿意度或產(chǎn)品的價(jià)值，但是現(xiàn)有做法也不影響用戶的日常工作優(yōu)先級：缺陷的優(yōu)先級用來描述某個缺陷應(yīng)當(dāng)被賦予的關(guān)注程度。如表2-3所示：表2-3 軟件缺陷優(yōu)先級列表缺陷優(yōu)先級描 述立即解決(E

40、mergency)缺陷導(dǎo)致系統(tǒng)幾乎不能使用或測試不能繼續(xù)，需要立即修復(fù)高優(yōu)先級(High)缺陷嚴(yán)重，影響測試，需要有限考慮正常排隊(duì)(Normal)缺陷需要正常排隊(duì)等待修復(fù)低優(yōu)先級(Low)缺陷可以在開發(fā)人員有時(shí)間的時(shí)候被修復(fù)對于缺陷優(yōu)先級的確定并不是一件容易的事情，缺陷的嚴(yán)重程度是一個參考值，但同時(shí)還要綜合考慮項(xiàng)目當(dāng)前的完成進(jìn)度、解決缺陷的難度、解決缺陷的成本等多方面的因素。所以，通常這一項(xiàng)是由項(xiàng)目經(jīng)理來負(fù)責(zé)填寫的。缺陷的狀態(tài)：每條缺陷記錄都應(yīng)當(dāng)有一個狀態(tài)，用來表明這條缺陷記錄當(dāng)前的處理情況：是否已經(jīng)指定了一個負(fù)責(zé)人？是否已經(jīng)解決？是否已經(jīng)通過了測試人員的回歸測試確認(rèn)？如表2-4所示：表2-4

41、 軟件缺陷狀態(tài)列表缺陷狀態(tài)描 述提交(Submit)問題還沒有解決，確認(rèn)“提交的缺陷”，等待處理打開(Open)通過審核，確認(rèn)為一個缺陷已處理(Fixed)已被開發(fā)人員檢查、修復(fù)過的缺陷，認(rèn)為已解決但還未通過審核結(jié)束(Close)確認(rèn)缺陷不存在之后的狀態(tài)發(fā)生沖突(Conflict)開發(fā)人員不認(rèn)為是一個缺陷，與測試人員發(fā)生沖突的狀態(tài)重新打開(Reopen)經(jīng)審核驗(yàn)證后，仍存在的缺陷，等待開發(fā)人員修復(fù)缺陷起源：缺陷引起的故障或事件第一次被檢測到的階段，如表2-5所示：表2-5 軟件缺陷起源列表缺陷起源描 述需求在需求階段發(fā)現(xiàn)的缺陷構(gòu)架在系統(tǒng)構(gòu)架設(shè)計(jì)階段發(fā)現(xiàn)的缺陷設(shè)計(jì)在程序設(shè)計(jì)階段發(fā)現(xiàn)的缺陷編碼在編

42、碼階段發(fā)現(xiàn)的缺陷測試在測試階段發(fā)現(xiàn)的缺陷用戶在用戶使用階段發(fā)現(xiàn)的缺陷缺陷的影響：如果不修復(fù)此缺陷會給軟件帶來哪方面的影響，如：標(biāo)準(zhǔn)、安全性、可靠性、易用性等。缺陷的提交者和提交日期：缺陷的提交者并不僅僅是測試人員，在實(shí)際工作中，所有參與項(xiàng)目或者會受到項(xiàng)目影響的人都可以提交自己發(fā)現(xiàn)的缺陷。例如行業(yè)專家、實(shí)施人員、客戶服務(wù)人員，甚至開發(fā)人員、需求人員都可以提交自己發(fā)現(xiàn)的缺陷。被指定的缺陷負(fù)責(zé)人：每一條缺陷記錄都應(yīng)當(dāng)指定一個負(fù)責(zé)人，并由其來負(fù)責(zé)解決這個缺陷。缺陷負(fù)責(zé)人需要根據(jù)缺陷的來源和具體的缺陷信息來選擇。附件：一張清晰的屏幕截圖可以幫助缺陷提交者更好的表達(dá)出自己的意思，也可以幫助開發(fā)人員找到一些

43、沒有被包含進(jìn)缺陷記錄的文字內(nèi)容中的（可能是測試人員漏掉的）信息。另外，在測試過程中參考或引用了外部文件，那么還應(yīng)當(dāng)注明訪問這些外部文件的有效路徑。2.2.2 缺陷統(tǒng)計(jì)與分析隨著缺陷數(shù)據(jù)庫中所收集的缺陷信息不斷增多，軟件組織的成員可以基于數(shù)據(jù)庫中的缺陷信息進(jìn)行缺陷數(shù)據(jù)分析，確定測試是否達(dá)到結(jié)束的標(biāo)準(zhǔn)，也就是判定測試是否已達(dá)到用戶可接受的狀態(tài)。通過分析缺陷數(shù)據(jù)的趨勢，評估軟件質(zhì)量和測試過程的效率。在評估缺陷時(shí)應(yīng)遵照缺陷分析策略中指定的分析標(biāo)準(zhǔn)，最常用的缺陷分析方法有四種：缺陷分布報(bào)告：允許將缺陷計(jì)數(shù)作為一個或多個缺陷參數(shù)的函數(shù)來表示，生成缺陷數(shù)量與缺陷屬性的函數(shù)。如測試需求和缺陷狀態(tài)、嚴(yán)重性的分布

44、情況等。缺陷趨勢報(bào)告：按各種狀態(tài)將缺陷計(jì)數(shù)作為時(shí)間的函數(shù)顯示。趨勢報(bào)告可以是累計(jì)的，也可以是非累計(jì)的，可以看出缺陷增長和減少的趨勢。缺陷年齡報(bào)告：是一種特殊類型的缺陷分部報(bào)告，顯示缺陷處于“打開”狀態(tài)的時(shí)間，展示一個缺陷處于某種狀態(tài)的時(shí)間長短，從而了解處理這些缺陷的進(jìn)度情況。測試結(jié)果進(jìn)度報(bào)告：展示測試過程在被測應(yīng)用的幾個版本中的執(zhí)行結(jié)果以及測試周期，顯示對應(yīng)用程序進(jìn)行若干次迭代和測試生命周期后的測試過程執(zhí)行結(jié)果。下面是幾個對缺陷信息分析和利用的例子14：1新發(fā)現(xiàn)缺陷的分布曲線。根據(jù)缺陷提交日期對發(fā)現(xiàn)的缺陷進(jìn)行分析，可以看出一個階段內(nèi)新發(fā)現(xiàn)缺陷的分布趨勢。如果曲線在最近一段時(shí)間內(nèi)呈持續(xù)的平穩(wěn)下降

45、趨勢，那么說明軟件正在逐漸趨于穩(wěn)定；而如果在項(xiàng)目期限將至，這條曲線還呈現(xiàn)出很大幅度的波動并維持在一個較高的水平上，那么就要考慮一下是否推遲產(chǎn)品的發(fā)布，多花些時(shí)間來尋找原因。如圖2-1所示：圖2-1 缺陷的分布曲線2可以通過使用缺陷來源和功能模塊兩個字段，對發(fā)現(xiàn)的缺陷進(jìn)行匯總，來分析在不同的開發(fā)階段，每個功能或模塊交付的工件的質(zhì)量情況，例如相應(yīng)功能模塊發(fā)現(xiàn)的缺陷數(shù)量是否同該功能模塊的業(yè)務(wù)復(fù)雜度成正比？相應(yīng)工作階段中發(fā)現(xiàn)的缺陷數(shù)量是否同該工作階段的工作量成正比？同時(shí)，這個表可以作為各模塊具體負(fù)責(zé)人工作質(zhì)量的評估依據(jù)，也可以作為確定下一步過程改進(jìn)重點(diǎn)的參考。如表2-6所示：表2-6 對發(fā)現(xiàn)的缺陷進(jìn)行

46、匯總模塊1模塊2模塊3模塊4模塊5模塊6合計(jì)需求階段50113010設(shè)計(jì)階段051520022實(shí)現(xiàn)階段213010157588售后階段1022005合計(jì)（單位：個）273528201080當(dāng)然，還可以根據(jù)在實(shí)際工作中產(chǎn)生的管理需求，利用缺陷提交人、缺陷負(fù)責(zé)人、缺陷狀態(tài)、嚴(yán)重程度、優(yōu)先級、解決方案等屬性互相組合出表現(xiàn)形式更多樣、內(nèi)容更復(fù)雜的報(bào)表。例如，可以根據(jù)缺陷負(fù)責(zé)人來對不同狀態(tài)的缺陷進(jìn)行匯總，以便觀察當(dāng)前每個缺陷負(fù)責(zé)人對自己負(fù)責(zé)的缺陷的修復(fù)進(jìn)度。3將那些目前尚未解決的缺陷的提交日期同當(dāng)前日期進(jìn)行比較，對于缺少正當(dāng)理由而長期未得到解決的缺陷，應(yīng)當(dāng)限期給出解決方案。同樣，也可以查詢出超過預(yù)計(jì)延遲

47、期限但仍未解決的“已延期”缺陷，要求缺陷負(fù)責(zé)人盡快給出解決方案。這兩項(xiàng)數(shù)據(jù)可以作為評價(jià)當(dāng)前工作進(jìn)度的參考信息。4將某個時(shí)間段內(nèi)（或其他范圍）的缺陷按照解決方案進(jìn)行匯總，如果發(fā)現(xiàn)“與其他缺陷重復(fù)”的比例較高，則應(yīng)該在接下來的工作中注意代碼重用的安全性，并檢查是否存在“版本退化”的情況。如果“屬于設(shè)計(jì)特性”的缺陷比例較高，應(yīng)當(dāng)要注意需求文檔或設(shè)計(jì)文檔中是否存在描述不夠清楚或者定義不夠準(zhǔn)確的地方，以及有沒有存在需求或設(shè)計(jì)文檔發(fā)生變更卻沒有通知所有涉眾更新的情況；或者，是否需要考慮對相應(yīng)的缺陷提交者增加關(guān)于系統(tǒng)業(yè)務(wù)的內(nèi)部培訓(xùn)。如果項(xiàng)目的時(shí)間和其他資源都比較寬裕，可以考慮同項(xiàng)目負(fù)責(zé)人進(jìn)行溝通，將一部分“

48、可以不修復(fù)”的缺陷重新提上工作日程，盡量將“可以不修復(fù)”的缺陷比例保持在一個較低的水平。通過缺陷的分析，能獲得軟件自身的大量信息，還能得到軟件過程中需要改進(jìn)之處的信息，指導(dǎo)軟件組織改進(jìn)產(chǎn)品質(zhì)量、過程質(zhì)量等方面，從而幫助軟件組織獲得成功。可以根據(jù)缺陷狀態(tài)來判斷測試進(jìn)展情況，開發(fā)人員的編程質(zhì)量，修正缺陷的進(jìn)度。通過缺陷的分析，還可以完成產(chǎn)品質(zhì)量的評估，確定測試是否達(dá)到結(jié)束的標(biāo)準(zhǔn)。通過缺陷的分析，還可以發(fā)現(xiàn)開發(fā)過程中存在的問題。無論對測試人員，還是對開發(fā)人員或是管理人員，缺陷的分析統(tǒng)計(jì)都是一項(xiàng)重要的工作。2.3 軟件缺陷管理的流程2.3.1 軟件缺陷生命周期通常，測試人員需要關(guān)注軟件缺陷在生命周期中

49、的狀態(tài)變化，來跟蹤軟件質(zhì)量和項(xiàng)目進(jìn)度。在軟件開發(fā)的實(shí)際過程中，軟件缺陷生命周期并不是一個簡單的線性過程：“發(fā)現(xiàn)報(bào)告修復(fù)關(guān)閉”，而是要考慮各種情況，包括：l 缺陷描述是否清晰？l 缺陷能否再現(xiàn)？l 缺陷不是一提交就要修復(fù)，需要審核是否是一個缺陷。l 開發(fā)人員發(fā)現(xiàn)不是一個缺陷拒絕修復(fù)時(shí)，需要管理人員裁決。所以，一般情況下，軟件缺陷生命周期如圖2-2所示： 圖2-2 軟件缺陷生命周期示意圖描述如下：測試人員通過運(yùn)行測試程序，發(fā)現(xiàn)并報(bào)告缺陷，經(jīng)審核后，狀態(tài)為“打開”。開發(fā)人員發(fā)現(xiàn)缺陷信息描述不清楚，則還需補(bǔ)充信息；當(dāng)缺陷不能再現(xiàn)，則需要和測試人員進(jìn)一步的溝通。然后開發(fā)人員修正缺陷，并將缺陷狀態(tài)設(shè)為“已

50、修復(fù)”，再次經(jīng)測試人員回歸測試，項(xiàng)目管理人員審核，“關(guān)閉”缺陷。若檢查發(fā)現(xiàn)不需要修復(fù)，則“延期修復(fù)”；若缺陷屬于設(shè)計(jì)問題，則進(jìn)入“修改設(shè)計(jì)”環(huán)節(jié)，也可以在“下一個版本”中進(jìn)行修改。在軟件缺陷生命周期中，缺陷經(jīng)歷了數(shù)次的審閱和狀態(tài)的變化，最終通過關(guān)閉缺陷來結(jié)束生命周期。軟件缺陷一旦被發(fā)現(xiàn)，便會收到嚴(yán)密的跟蹤，直至被關(guān)閉，以保證在較短的時(shí)間內(nèi)高效率處理所有缺陷，縮短軟件測試的過程，減少開發(fā)和維護(hù)成本。2.3.2 軟件缺陷管理流程中的角色在軟件缺陷管理中所涉及的角色主要有以下幾種：1、測試人員：進(jìn)行測試的人員，提交缺陷，并關(guān)注缺陷如何解決，他們對所有“已修復(fù)”的缺陷進(jìn)行重新測試。2、測試組長：缺陷的

51、管理者，領(lǐng)導(dǎo)著項(xiàng)目的測試工作，他對測試和缺陷報(bào)告的質(zhì)量負(fù)有責(zé)任，由他來審核所有被“提交”的缺陷以及進(jìn)行過回歸測試的缺陷，并“關(guān)閉”缺陷。3、項(xiàng)目經(jīng)理：對整個項(xiàng)目負(fù)責(zé)，對產(chǎn)品質(zhì)量負(fù)責(zé)的人員，他決定哪些缺陷應(yīng)被改正，優(yōu)先等級如何劃分，以及哪些缺陷問題不做任何處理等。4、開發(fā)人員：執(zhí)行開發(fā)任務(wù)的人員，完成缺陷的修改。5、評審委員會：對缺陷進(jìn)行最終確認(rèn)，在項(xiàng)目成員對缺陷的意見不統(tǒng)一時(shí)，行使仲裁權(quán)力。2.4 小結(jié)本章先介紹了軟件缺陷的基本概念，并由此引出對軟件缺陷管理目標(biāo)的討論，分析了軟件缺陷管理的兩個要素：軟件收集與跟蹤、軟件統(tǒng)計(jì)與分析，研究了軟件缺陷的特征及缺陷分析方法，解釋了軟件缺陷管理的流程，包

52、括：軟件缺陷生命周期與管理流程中的角色的介紹。第三章 軟件缺陷管理系統(tǒng)的開發(fā)與設(shè)計(jì)3.1 系統(tǒng)開發(fā)環(huán)境及工具信息服務(wù)器：Internet Information Service 5.1版本。開發(fā)語言：HTML 4.0；JavaScript；VBScript；ASP。開發(fā)工具：Macromedia Dreamweaver 8。數(shù)據(jù)庫：SQL Server 2000。3.2 可行性分析本系統(tǒng)的開發(fā)建立在穩(wěn)定的操作系統(tǒng)之上，ASP頁面是在原來的HTML頁面中加入了一些腳本程序，所以容易滿足用戶對系統(tǒng)界面友好性、合理性的需求。后臺采用Microsoft SQL Server 2000數(shù)據(jù)庫，它是當(dāng)今市

53、面上三大主流數(shù)據(jù)庫之一，具有強(qiáng)大的存儲功能和查詢功能。因此，前臺和后臺的良好結(jié)合，開發(fā)本系統(tǒng)無論是在技術(shù)上還是在經(jīng)濟(jì)上都是十分可行的。3.3 系統(tǒng)的需求分析下面采用面向?qū)ο蟮姆治龇椒▽Ρ鞠到y(tǒng)進(jìn)行需求分析。UML中的順序圖是用來描述對象之間的交互關(guān)系的。眾所周知，對象之間的交互是按照特定的順序發(fā)生的，這些按特定順序發(fā)生的交互序列從開始到結(jié)束需要一定的時(shí)間。當(dāng)建立一個系統(tǒng)時(shí)，必須指定這個序列，這也就是順序圖需要完成的工作。一個缺陷的生命周期是如下順序，“提交”“打開”“發(fā)生沖突”“重新打開”“被修復(fù)”“回歸測試”“驗(yàn)證”“結(jié)束”，如圖3-1所示：圖3-1 缺陷事件跟蹤圖這里，我們簡化了軟件缺陷管理

54、的流程，將角色設(shè)置為測試人員、測試經(jīng)理、開發(fā)人員、項(xiàng)目經(jīng)理四種。由測試人員“提交”缺陷，經(jīng)過測試經(jīng)理審核確認(rèn)為一個缺陷時(shí)，“打開”缺陷，通知開發(fā)人員修復(fù)，開發(fā)人員檢查后不認(rèn)為是一個缺陷，也就是“發(fā)生沖突”，此時(shí)項(xiàng)目經(jīng)理查看該缺陷信息，裁決仍屬于缺陷，需要被修復(fù)，于是“重新打開”缺陷，然后由開發(fā)人員修復(fù)該缺陷，測試人員再進(jìn)行回歸測試，測試經(jīng)理審核驗(yàn)證后確認(rèn)修復(fù)完畢，“關(guān)閉”缺陷。在UML中，活動圖常常被用來簡化描述一個過程或者操作的工作步驟。它是狀態(tài)圖的一種擴(kuò)展?；顒訄D描述了一個動態(tài)的過程，這樣就不易找出過程中各個活動由哪個對象負(fù)責(zé)。為了彌補(bǔ)這個缺點(diǎn)，活動圖中引入了泳道這個概念。泳道是一張圖被分

55、割成多個平行的段后每一個段的名稱，每個泳道的頂部可以顯示出角色的名稱，每個角色負(fù)責(zé)的活動放在各個角色的泳道中。一個泳道到另一個泳道之間可以發(fā)生轉(zhuǎn)移。下面給出四種角色權(quán)限的操作流程的活動圖：1、測試人員：查看缺陷；提交缺陷。如圖3-2所示。2、測試經(jīng)理：修改缺陷狀態(tài)。當(dāng)缺陷狀態(tài)為“提交”時(shí)，判斷是否為一個缺陷，若是，則置缺陷狀態(tài)為“打開”；若否，則將缺陷狀態(tài)置為“結(jié)束”。當(dāng)缺陷狀態(tài)為“已處理”時(shí)，確認(rèn)是否為一個缺陷，若仍是，則置缺陷狀態(tài)為“重新打開”；若否，則置缺陷狀態(tài)為“結(jié)束”。如圖3-3所示。3、開發(fā)人員：查看缺陷，判斷是否需要處理缺陷，若需要，則處理缺陷，并置缺陷狀態(tài)為“已處理”；若不需要，則置缺陷狀態(tài)為“發(fā)生沖突”。如圖3-4所示。4、項(xiàng)目經(jīng)理：解