【文章內(nèi)容簡(jiǎn)介】 件測(cè)試的實(shí)踐表明，缺陷管理可以行之有效的保證每一條缺陷被完整記錄、及時(shí)處理、驗(yàn)證和關(guān)閉。 它作為 軟件測(cè)試的一個(gè)重要環(huán)節(jié)， 包括缺陷報(bào)告，缺陷生命周期，缺陷跟蹤，趨勢(shì)分析，分布分析，質(zhì)量評(píng)估，缺陷預(yù)防等 方面。 我們根據(jù)測(cè)試需求 、 測(cè)試計(jì)劃 ，對(duì)測(cè)試過(guò)程中每個(gè)狀態(tài)進(jìn)行記錄、跟蹤和管理 ， 并提供相關(guān)的分析 和統(tǒng)計(jì)功能 ， 生成和打印各種分析統(tǒng)計(jì)報(bào)表。通過(guò)對(duì)詳細(xì)記錄的分析 ， 形成較為完整的軟件測(cè)試管理文檔 ，保障軟件在開發(fā)過(guò)程中 ， 避免同樣的錯(cuò)誤再次發(fā)生 ， 從而提高軟件開發(fā)質(zhì)量 [6]。 在軟件系統(tǒng)的開發(fā)過(guò)程中 ， 為系統(tǒng)建模好比為一個(gè)建筑描繪一張藍(lán)圖同 樣重要。UML（ Unified Modeling Language， 統(tǒng)一建模語(yǔ)言） 是一種用于面向?qū)ο蠛突跇?gòu)件的、系統(tǒng)建模的、定義明確的、被廣泛接受的可視化建模語(yǔ)言。 現(xiàn)在已經(jīng)成為了軟件分析與設(shè)計(jì)建模的標(biāo)準(zhǔn) ，應(yīng)用越來(lái)越廣泛 [7] [8]。 盡管 它常常與建模 OO 軟件系統(tǒng)相關(guān)聯(lián)，但由于其 內(nèi)建了大量擴(kuò)展機(jī)制，還可以應(yīng)用于更多的領(lǐng)域中， 如商業(yè)建模、需求管理、分析和設(shè)計(jì)、編程和測(cè)試等。 UML 的發(fā)展方向是簡(jiǎn)化和鞏固大量已經(jīng)存在的面向?qū)ο蟮慕７椒?， UML 定義了九種圖 ， 這些圖被用來(lái)建立系統(tǒng)的靜態(tài) （ 結(jié)構(gòu) ） 和動(dòng)態(tài) （ 行為 ） 模型。結(jié)構(gòu)圖包括類圖 （ Class Diagram） 、對(duì)象圖 （ Object Diagram） 、構(gòu)件圖 （ Component Diagram） 和配置圖 （ Deployment）， 用于描述建立系統(tǒng)模型時(shí)在問(wèn)題域中遇到的主要事物。行為圖包括用例圖 （ UseCase Diagram） 、狀態(tài)圖 （ Statechart Diagram） 、活動(dòng)圖 （ Activity Diagram） 、順序圖 （ Sequence Diagram） 和合作圖 （ Collaboration Diagram）， 用于描述建立系統(tǒng)的動(dòng)態(tài)模型。 基于此，本系統(tǒng)的 研究?jī)?nèi)容 ： 通過(guò)對(duì)軟件缺陷的概念、屬性、特征的認(rèn)識(shí)，明確了軟件缺陷管理系統(tǒng)的目標(biāo)，分析了缺陷管理的工作流程、系統(tǒng)角色的權(quán)限，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)可對(duì)提交的缺陷進(jìn)行跟蹤、管理、統(tǒng)計(jì)和分析的軟件缺陷管理系統(tǒng) ； 利用軟件缺陷管理系統(tǒng)產(chǎn)生的各種缺陷數(shù)據(jù)分析報(bào)告，發(fā)現(xiàn)軟件開發(fā)過(guò)程中的問(wèn)題，并為過(guò)程改進(jìn)和項(xiàng)目管理 提供依據(jù)。 10 本文主要 工作 在此次的畢業(yè)設(shè)計(jì)中， 本人深入了解缺陷信息所應(yīng)包含的內(nèi)容， 利用 UML 統(tǒng)一建模語(yǔ)言 詳細(xì)分析了基于四種角色權(quán)限的系統(tǒng)流程， 并以此來(lái)設(shè)計(jì)數(shù)據(jù)庫(kù) 、 選擇并布局頁(yè)面內(nèi)容 ， 完成系統(tǒng)目標(biāo)：實(shí)現(xiàn)缺陷收集、缺陷跟蹤。 本文共分為五章。 第一章： 介紹 課題研究背景， 陳述了課題 研究?jī)?nèi)容 ，并說(shuō)明了作者在本課題的研究開發(fā)中所完成的工作。 第二章：介紹開發(fā)所依據(jù)的理論根據(jù)、方法和技術(shù)，包括 軟件缺陷管理的目標(biāo)， 軟件缺陷管理的要素， 軟件缺陷管理的流程 。 第三章：在 系統(tǒng) 需求分析的基礎(chǔ)上，詳細(xì)闡述了 系統(tǒng)總體設(shè) 計(jì)、功能設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì) 等等。 第四章： 按角色 對(duì)系統(tǒng)平臺(tái)框架、服務(wù)及接口的實(shí)現(xiàn)進(jìn)行詳細(xì)的闡述。 第五章：對(duì)所作的工作進(jìn)行了簡(jiǎn)要的總結(jié) 。 最后包括致謝和參考文獻(xiàn)。 小結(jié) 本章主要 介紹 了 開發(fā) 軟件 缺陷管理系統(tǒng) 的目的和意義，對(duì)國(guó)內(nèi)外的 研究現(xiàn)狀進(jìn)行 了分析，并說(shuō)明了具體的研究?jī)?nèi)容與方法。 11 第二章 軟件缺陷管理 綜述 軟件缺陷管理的 目標(biāo) 缺陷 (defect)是指程序中或文檔中存在各種不希望出現(xiàn)的問(wèn)題。如語(yǔ)法錯(cuò) 誤、拼寫錯(cuò)誤、標(biāo)點(diǎn)錯(cuò)誤，或者是 一個(gè)不正確的、冗余的程序語(yǔ)句或有缺陷的程序段等，缺陷可能出現(xiàn)在程序 中、設(shè)計(jì)中，甚至出現(xiàn)在需求規(guī)格說(shuō)明或其他文檔中。事實(shí)上，缺陷是任何可以影響到程序完整而有效地滿足用戶要求的東西。缺陷不僅影響用戶使用，而且是超支和延期的主要原因，對(duì)系統(tǒng)造成或大或小的影響。但缺陷是客觀存在，可以被標(biāo)志、描述和統(tǒng)計(jì) [9]。 軟件 缺陷管理就是在開發(fā)中對(duì)發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個(gè)被發(fā)現(xiàn)的缺陷被關(guān)閉。從某種意義上說(shuō)，軟件項(xiàng)目管理過(guò)程可以看作是軟件產(chǎn)品的缺陷管理過(guò)程，軟件過(guò)程的目的是避免將缺陷引入軟件產(chǎn)品或?qū)⒁旬a(chǎn)生的缺陷識(shí)別出來(lái)，并將其排除。軟件缺陷跟蹤管理是測(cè)試工作的一個(gè)重要部分，測(cè)試的目的是為了 盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，而對(duì)軟件缺陷進(jìn)行跟蹤管理的目的是確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠及時(shí)得到處理。軟件測(cè)試過(guò)程簡(jiǎn)單說(shuō)就是圍繞缺陷進(jìn)行的，對(duì)缺陷的跟蹤管理一般而言需要達(dá)到以下目標(biāo) [10]： ㈠確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被解決。這里解決的意思不一定是被修正，也可能是其他處理方式（例如，在下一個(gè)版本中修正或是不修正）?？傊?，對(duì)每個(gè)被發(fā)現(xiàn)的缺陷的處理方式必須能夠在開發(fā)組織中達(dá)成一致。 ㈡收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢(shì)曲線識(shí)別測(cè)試過(guò)程的階段。決定測(cè)試過(guò)程是否結(jié)束有很多種方式，通過(guò)缺陷趨勢(shì)曲線來(lái)確定測(cè)試過(guò)程是否結(jié)束是常用并 且較為有效的一種方式。 ㈢收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過(guò)程財(cái)富。 上述的第一條是最受到重視的一點(diǎn)，在談到缺陷跟蹤管理時(shí)，一般人都會(huì)馬上想到這一條，然而對(duì)第二和第三條目標(biāo)卻很容易忽視。其實(shí)，在一個(gè)運(yùn)行良好的組織中，缺陷數(shù)據(jù)的收集和分析是很重要的，從缺陷數(shù)據(jù)中可以得到很多與軟件質(zhì)量相關(guān)的數(shù)據(jù)。 軟件缺陷管理的 要素 軟件缺陷 管理一般 包括兩個(gè)方面： 缺陷信息的收集與跟蹤 ， 缺陷信息的統(tǒng)計(jì)與分析 。 缺陷收集與跟蹤 完整的軟件缺陷信息是輔助缺陷修復(fù)、缺陷信息處理、分析和利用的前提 和基礎(chǔ) ，也是對(duì)缺陷進(jìn)行跟蹤必不可少的步驟。因?yàn)?，通常一個(gè)項(xiàng)目的缺陷整體跟蹤，就是缺陷 12 的實(shí)時(shí)狀態(tài)報(bào)告。 也就是說(shuō)，缺陷的跟蹤是了解缺陷所在其生命周期的狀態(tài)。 通過(guò)了解缺陷的實(shí)時(shí)狀態(tài)，對(duì)測(cè)試過(guò)程、項(xiàng)目進(jìn)展的控制和管理都有很大幫助，可以督促開發(fā)人員盡快修正缺陷， 調(diào)整測(cè)試或開發(fā)計(jì)劃。 一般情況下，缺陷信息應(yīng)該包含以下內(nèi)容 [11] [12] [13]： ⑴缺陷標(biāo)識(shí) ：為了便于對(duì)缺陷的管理，每個(gè)缺陷賦予一個(gè)唯一性的編號(hào)，編號(hào)規(guī)則可根據(jù)需要和管理要求制定。 ⑵缺陷所在的產(chǎn)品或項(xiàng)目：如果一個(gè)測(cè)試團(tuán)隊(duì)同時(shí)負(fù)責(zé)多個(gè)產(chǎn)品或項(xiàng)目的測(cè)試， 并且使用同一個(gè)缺陷數(shù)據(jù)庫(kù)來(lái)存放缺陷記錄，那么就應(yīng)當(dāng)注明這個(gè)缺陷出現(xiàn)在哪一個(gè)產(chǎn)品或項(xiàng)目中。 ⑶發(fā)現(xiàn)缺陷的版本：即使正在測(cè)試的是某個(gè)軟件的第一個(gè)發(fā)布版本，也應(yīng)當(dāng)注明它的版本。 ⑷功能或模塊：如果希望隨時(shí)都能查詢到某個(gè)功能或者模塊一共發(fā)現(xiàn)了多少缺陷，哪些已經(jīng)被解決并確認(rèn)通過(guò)，或者希望使用功能或模塊作為條件進(jìn)行更加復(fù)雜的分析，那么應(yīng)該填寫這一項(xiàng)。 ⑸缺陷的類型：根據(jù)缺陷的自然屬性劃分的種類 ，如 表 21 所示： 表 21 軟件缺陷類型列表 缺陷類型 描 述 功能 影響了各種系統(tǒng)功能、邏輯的缺陷 用戶界面 影響 了用戶界面、人際交互特性，包括屏幕格式、用戶輸入靈活性、結(jié)果輸出格式等方面的缺陷 文檔 影響發(fā)布和維護(hù)，包括注釋、用戶手冊(cè)、設(shè)計(jì)文檔 軟件包 由于軟件配置庫(kù)、變更管理或版本控制引起的錯(cuò)誤 性能 不滿足系統(tǒng)可測(cè)量的屬性值，如執(zhí)行時(shí)間、事務(wù)處理速率等 系統(tǒng) /模塊接口 與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表等不 匹配、沖突 ⑹嚴(yán)重程度：缺陷的嚴(yán)重程度用來(lái)描述出現(xiàn)的缺陷對(duì)系統(tǒng)的影響，通常不同的系統(tǒng)或團(tuán)隊(duì)對(duì)于嚴(yán)重程度的定義是不同的。 如表 22 所示 ： 表 22 軟件缺陷嚴(yán)重程度列表 缺陷嚴(yán)重 程度 描 述 致命 (Fatal) 將導(dǎo)致產(chǎn)品失去價(jià)值，例如在財(cái)務(wù)軟件中對(duì)于數(shù)據(jù)計(jì)算中準(zhǔn)確性問(wèn)題 嚴(yán)重 (Critical) 將嚴(yán)重影響用戶的工作，例如缺陷導(dǎo)致業(yè)務(wù)流程中斷，用戶的工作無(wú)法 繼續(xù)進(jìn)行下去 一般 (General) 導(dǎo)致用戶感覺(jué)使用不方便，影響用戶滿意度，例如一些不影響系統(tǒng)主要 業(yè)務(wù)流程進(jìn)行的缺陷、提示錯(cuò)誤信息等 建議 (Suggest) 對(duì)于系統(tǒng)中設(shè)計(jì)思路或具體實(shí)現(xiàn)的不同看法，如果采納，有可能會(huì)提升 用戶的滿意度或產(chǎn)品的價(jià)值，但是現(xiàn)有做法也不影響用戶的日常工作 13 ⑺優(yōu)先級(jí)：缺陷的優(yōu)先級(jí)用來(lái)描 述某個(gè)缺陷應(yīng)當(dāng)被賦予的關(guān)注程度。 如表 23 所示： 表 23 軟件缺陷優(yōu)先級(jí)列表 缺陷優(yōu)先級(jí) 描 述 立即解決 (Emergency) 缺陷導(dǎo)致系統(tǒng)幾乎不能使用或測(cè)試不能繼續(xù)，需要立即修復(fù) 高優(yōu)先級(jí) (High) 缺陷嚴(yán)重，影響測(cè)試，需要有限考慮 正常排隊(duì) (Normal) 缺陷需要正常排隊(duì)等待修復(fù) 低優(yōu)先級(jí) (Low) 缺陷可以在開發(fā)人員有時(shí)間的時(shí)候被修復(fù) 對(duì)于缺陷優(yōu)先級(jí)的確定并不是一件容易的事情，缺陷的嚴(yán)重程度是一個(gè)參考值，但同時(shí)還要綜合考慮項(xiàng)目當(dāng)前的完成進(jìn)度、解決缺陷的難度、解決缺陷的成本等多方 面的因素。所以，通常這一項(xiàng)是由項(xiàng)目經(jīng)理來(lái)負(fù)責(zé)填寫的。 ⑻缺陷的狀態(tài)：每條缺陷記錄都應(yīng)當(dāng)有一個(gè)狀態(tài)，用來(lái)表明這條缺陷記錄當(dāng)前的處理情況：是否已經(jīng)指定了一個(gè)負(fù)責(zé)人？是否已經(jīng)解決？是否已經(jīng)通過(guò)了測(cè)試人員的回歸測(cè)試確認(rèn)？ 如表 24 所示： 表 24 軟件缺陷狀態(tài)列表 缺陷狀態(tài) 描 述 提交 (Submit) 問(wèn)題還沒(méi)有解決，確認(rèn)“提交的缺陷”，等待處理 打開 (Open) 通過(guò)審核，確認(rèn)為一個(gè)缺陷 已處理 (Fixed) 已被開發(fā)人員檢查、修復(fù)過(guò)的缺陷，認(rèn)為已解決但還未通過(guò)審核 結(jié)束 (Close) 確認(rèn)缺陷不 存在之后的狀態(tài) 發(fā)生沖突 (Conflict) 開發(fā)人員不認(rèn)為是一個(gè)缺陷，與測(cè)試人員發(fā)生沖突的狀態(tài) 重新打開 (Reopen) 經(jīng)審核驗(yàn)證后，仍存在的缺陷，等待開發(fā)人員修復(fù) ⑼ 缺陷起源：缺陷引起的故障或事件第一次被檢測(cè)到的階段，如表 25 所示： 表 25 軟件缺陷起源列表 缺陷起源 描 述 需求 在需求階段發(fā)現(xiàn)的缺陷 構(gòu)架 在系統(tǒng)構(gòu)架設(shè)計(jì)階段發(fā)現(xiàn)的缺陷 設(shè)計(jì) 在程序設(shè)計(jì)階段發(fā)現(xiàn)的缺陷 編碼 在編碼階段發(fā)現(xiàn)的缺陷 測(cè)試 在測(cè)試階段發(fā)現(xiàn)的缺陷 用戶 在用戶使用階段發(fā)現(xiàn)的缺陷 ⑽ 缺陷的影響： 如果不修復(fù)此缺陷會(huì)給軟件帶來(lái)哪方面的影響，如：標(biāo)準(zhǔn)、安全性、可靠性、易用性等。 ⑾缺陷的提交者和提交日期：缺陷的提交者并不僅僅是測(cè)試人員，在實(shí)際工作中，所有參與項(xiàng)目或者會(huì)受到項(xiàng)目影響的人都可以提交自己發(fā)現(xiàn)的缺陷。例如行業(yè)專家、實(shí)施人員、客戶服務(wù)人員，甚至開發(fā)人員、需求人員都可以提交自己發(fā)現(xiàn)的缺陷。 ⑿ 被指定的缺陷負(fù)責(zé)人：每一條缺陷記錄都應(yīng)當(dāng)指定一個(gè)負(fù)責(zé)人，并由其來(lái)負(fù)責(zé)解 14 決這個(gè)缺陷。缺陷負(fù)責(zé)人需要根據(jù)缺陷的來(lái)源和具體的缺陷信息來(lái)選擇。 ⒀ 附件：一張清晰的屏幕截圖可以幫助缺陷提交者更好的表達(dá)出自己的意思，也可以 幫助開發(fā)人員找到一些沒(méi)有被包含進(jìn)缺陷記錄的文字內(nèi)容中的（可能是測(cè)試人員漏掉的）信息。 另外，在測(cè)試過(guò)程中參考或引用了外部文件，那么還應(yīng)當(dāng)注明訪問(wèn)這些外部文件的有效路徑。 缺陷統(tǒng)計(jì)與分析 隨著缺陷數(shù)據(jù)庫(kù)中所收集的缺陷信息不斷增多， 軟件組織的成員 可以基于數(shù)據(jù)庫(kù)中的缺陷信息進(jìn)行缺陷數(shù)據(jù)分析，確定測(cè)試是否達(dá)到結(jié)束的標(biāo)準(zhǔn)，也就是判定測(cè)試是否已達(dá) 到 用戶可接受的狀態(tài)。通過(guò)分析缺陷數(shù)據(jù)的趨勢(shì)，評(píng)估軟件質(zhì)量和 測(cè)試過(guò)程的效率。在評(píng)估缺陷時(shí)應(yīng)遵照缺陷分析策略中指定的分析標(biāo)準(zhǔn)， 最常用的缺陷分析方法有四種： ⑴ 缺陷分 布 報(bào) 告：允許將缺陷計(jì)數(shù)作為一個(gè)或多個(gè)缺陷參數(shù)的函數(shù)來(lái)表示， 生成缺陷數(shù)量與缺陷屬性的函數(shù)。如測(cè)試需求和缺陷狀態(tài)、嚴(yán)重性的分布情況等。 ⑵缺陷趨勢(shì)報(bào)告：按各種狀態(tài)將缺陷計(jì)數(shù)作為時(shí)間的函數(shù)顯示。趨勢(shì)報(bào)告可以是累計(jì)的，也可以是非累計(jì)的，可以看出缺陷增長(zhǎng)和減少的趨勢(shì)。 ⑶缺陷年齡報(bào)告：是一種特殊類型的缺陷分部報(bào)告，顯示缺陷處于“打開”狀態(tài)的時(shí)間，展示一個(gè)缺陷處于某種狀態(tài)的時(shí)間長(zhǎng)短，從而了解處理這些缺陷的進(jìn)度情況。 ⑷測(cè)試結(jié)果進(jìn)度報(bào)告：展示測(cè)試過(guò)程在被測(cè)應(yīng)用的幾個(gè)版本中的執(zhí)行結(jié)果以及測(cè)試周期，顯示對(duì)應(yīng)用程序進(jìn)行若干次迭代和 測(cè)試生命周期后的測(cè)試過(guò)程執(zhí)行結(jié)果。 下面是幾個(gè) 對(duì)缺陷信息分析和利用的例子 [14]： 1．新發(fā)現(xiàn)缺陷的分布曲線。根據(jù)缺陷提交日期對(duì)發(fā)現(xiàn)的缺陷進(jìn)行分析，可以看出一個(gè)階段內(nèi)新發(fā)現(xiàn)缺陷的分布趨勢(shì)。如果曲線在最近一段時(shí)間內(nèi)呈持續(xù)的平穩(wěn)下降趨勢(shì)，那么說(shuō)明軟件正在逐漸趨于穩(wěn)定；而如果在項(xiàng)目期限將至，這條曲線還呈現(xiàn)出很大幅度的波動(dòng)并維持在一個(gè)較高的水平上，那么就要考慮一下是否推遲產(chǎn)品的發(fā)布，多花些時(shí)間來(lái)尋找原因。 如圖 21 所示： 15 圖 21 缺陷的分布曲線 2．可以通過(guò)使用缺陷來(lái)源和功能模塊兩個(gè)字段，對(duì)發(fā)現(xiàn)的缺陷進(jìn)行匯總 ，來(lái)分析在不同的開發(fā)階段，每個(gè)功能或模塊交付的工件的質(zhì)量情況，例如相應(yīng)功能模塊發(fā)現(xiàn)的缺陷數(shù)量是否同該功能模塊的業(yè)務(wù)復(fù)雜度成正比？相應(yīng)工作階段中發(fā)現(xiàn)的缺陷數(shù)量是否同該工作階段的工作量成正比？同時(shí)，這個(gè)表可以作為各模塊具體負(fù)責(zé)人工作質(zhì)量的評(píng)估依據(jù)，也可以作為確定下一步過(guò)程改進(jìn)重點(diǎn)的參考。如表 26 所示 ： 表 26 對(duì)發(fā)現(xiàn)的缺陷進(jìn)行匯總 模塊 1 模塊 2 模塊 3 模塊 4 模塊 5 模塊 6 合計(jì) 需求階段 5 0 1 1 3 0 10 設(shè)計(jì)階段 0 5 15 2 0 0 22 實(shí)現(xiàn)階段 21 30 10 15 7 5 88 售后階段 1 0