【文章內(nèi)容簡介】 件測試的實(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)計(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)建模的、定義明確的、被廣泛接受的可視化建模語言。 現(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)存在的面向?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)模型時在問題域中遇到的主要事物。行為圖包括用例圖 （ UseCase Diagram） 、狀態(tài)圖 （ Statechart Diagram） 、活動圖 （ Activity Diagram） 、順序圖 （ Sequence Diagram） 和合作圖 （ Collaboration Diagram）， 用于描述建立系統(tǒng)的動態(tài)模型。 基于此，本系統(tǒng)的 研究內(nèi)容 ： 通過對軟件缺陷的概念、屬性、特征的認(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ù)。 10 本文主要 工作 在此次的畢業(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)容 ，并說明了作者在本課題的研究開發(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)。 小結(jié) 本章主要 介紹 了 開發(fā) 軟件 缺陷管理系統(tǒng) 的目的和意義，對國內(nèi)外的 研究現(xiàn)狀進(jìn)行 了分析，并說明了具體的研究內(nèi)容與方法。 11 第二章 軟件缺陷管理 綜述 軟件缺陷管理的 目標(biāo) 缺陷 (defect)是指程序中或文檔中存在各種不希望出現(xiàn)的問題。如語法錯 誤、拼寫錯誤、標(biāo)點(diǎn)錯誤，或者是 一個不正確的、冗余的程序語句或有缺陷的程序段等，缺陷可能出現(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)中的缺陷，而對軟件缺陷進(jìn)行跟蹤管理的目的是確保每個被發(fā)現(xiàn)的缺陷都能夠及時得到處理。軟件測試過程簡單說就是圍繞缺陷進(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)，在談到缺陷跟蹤管理時，一般人都會馬上想到這一條，然而對第二和第三條目標(biāo)卻很容易忽視。其實(shí)，在一個運(yùn)行良好的組織中，缺陷數(shù)據(jù)的收集和分析是很重要的，從缺陷數(shù)據(jù)中可以得到很多與軟件質(zhì)量相關(guān)的數(shù)據(jù)。 軟件缺陷管理的 要素 軟件缺陷 管理一般 包括兩個方面： 缺陷信息的收集與跟蹤 ， 缺陷信息的統(tǒng)計(jì)與分析 。 缺陷收集與跟蹤 完整的軟件缺陷信息是輔助缺陷修復(fù)、缺陷信息處理、分析和利用的前提 和基礎(chǔ) ，也是對缺陷進(jìn)行跟蹤必不可少的步驟。因?yàn)?，通常一個項(xiàng)目的缺陷整體跟蹤，就是缺陷 12 的實(shí)時狀態(tài)報(bào)告。 也就是說，缺陷的跟蹤是了解缺陷所在其生命周期的狀態(tài)。 通過了解缺陷的實(shí)時狀態(tài)，對測試過程、項(xiàng)目進(jìn)展的控制和管理都有很大幫助，可以督促開發(fā)人員盡快修正缺陷， 調(diào)整測試或開發(fā)計(jì)劃。 一般情況下，缺陷信息應(yīng)該包含以下內(nèi)容 [11] [12] [13]： ⑴缺陷標(biāo)識 ：為了便于對缺陷的管理，每個缺陷賦予一個唯一性的編號，編號規(guī)則可根據(jù)需要和管理要求制定。 ⑵缺陷所在的產(chǎn)品或項(xiàng)目：如果一個測試團(tuán)隊(duì)同時負(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)注明它的版本。 ⑷功能或模塊：如果希望隨時都能查詢到某個功能或者模塊一共發(fā)現(xiàn)了多少缺陷，哪些已經(jīng)被解決并確認(rèn)通過，或者希望使用功能或模塊作為條件進(jìn)行更加復(fù)雜的分析，那么應(yīng)該填寫這一項(xiàng)。 ⑸缺陷的類型：根據(jù)缺陷的自然屬性劃分的種類 ，如 表 21 所示： 表 21 軟件缺陷類型列表 缺陷類型 描 述 功能 影響了各種系統(tǒng)功能、邏輯的缺陷 用戶界面 影響 了用戶界面、人際交互特性，包括屏幕格式、用戶輸入靈活性、結(jié)果輸出格式等方面的缺陷 文檔 影響發(fā)布和維護(hù)，包括注釋、用戶手冊、設(shè)計(jì)文檔 軟件包 由于軟件配置庫、變更管理或版本控制引起的錯誤 性能 不滿足系統(tǒng)可測量的屬性值，如執(zhí)行時間、事務(wù)處理速率等 系統(tǒng) /模塊接口 與其他組件、模塊或設(shè)備驅(qū)動程序、調(diào)用參數(shù)、控制塊或參數(shù)列表等不 匹配、沖突 ⑹嚴(yán)重程度：缺陷的嚴(yán)重程度用來描述出現(xiàn)的缺陷對系統(tǒng)的影響，通常不同的系統(tǒng)或團(tuán)隊(duì)對于嚴(yán)重程度的定義是不同的。 如表 22 所示 ： 表 22 軟件缺陷嚴(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)有做法也不影響用戶的日常工作 13 ⑺優(yōu)先級：缺陷的優(yōu)先級用來描 述某個缺陷應(yīng)當(dāng)被賦予的關(guān)注程度。 如表 23 所示： 表 23 軟件缺陷優(yōu)先級列表 缺陷優(yōu)先級 描 述 立即解決 (Emergency) 缺陷導(dǎo)致系統(tǒng)幾乎不能使用或測試不能繼續(xù)，需要立即修復(fù) 高優(yōu)先級 (High) 缺陷嚴(yán)重，影響測試，需要有限考慮 正常排隊(duì) (Normal) 缺陷需要正常排隊(duì)等待修復(fù) 低優(yōu)先級 (Low) 缺陷可以在開發(fā)人員有時間的時候被修復(fù) 對于缺陷優(yōu)先級的確定并不是一件容易的事情，缺陷的嚴(yán)重程度是一個參考值，但同時還要綜合考慮項(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)？ 如表 24 所示： 表 24 軟件缺陷狀態(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ù) ⑼ 缺陷起源：缺陷引起的故障或事件第一次被檢測到的階段，如表 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)的缺陷 測試 在測試階段發(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é)解 14 決這個缺陷。缺陷負(fù)責(zé)人需要根據(jù)缺陷的來源和具體的缺陷信息來選擇。 ⒀ 附件：一張清晰的屏幕截圖可以幫助缺陷提交者更好的表達(dá)出自己的意思，也可以 幫助開發(fā)人員找到一些沒有被包含進(jìn)缺陷記錄的文字內(nèi)容中的（可能是測試人員漏掉的）信息。 另外，在測試過程中參考或引用了外部文件，那么還應(yīng)當(dāng)注明訪問這些外部文件的有效路徑。 缺陷統(tǒng)計(jì)與分析 隨著缺陷數(shù)據(jù)庫中所收集的缺陷信息不斷增多， 軟件組織的成員 可以基于數(shù)據(jù)庫中的缺陷信息進(jìn)行缺陷數(shù)據(jù)分析，確定測試是否達(dá)到結(jié)束的標(biāo)準(zhǔn)，也就是判定測試是否已達(dá) 到 用戶可接受的狀態(tài)。通過分析缺陷數(shù)據(jù)的趨勢，評估軟件質(zhì)量和 測試過程的效率。在評估缺陷時應(yīng)遵照缺陷分析策略中指定的分析標(biāo)準(zhǔn)， 最常用的缺陷分析方法有四種： ⑴ 缺陷分 布 報(bào) 告：允許將缺陷計(jì)數(shù)作為一個或多個缺陷參數(shù)的函數(shù)來表示， 生成缺陷數(shù)量與缺陷屬性的函數(shù)。如測試需求和缺陷狀態(tài)、嚴(yán)重性的分布情況等。 ⑵缺陷趨勢報(bào)告：按各種狀態(tài)將缺陷計(jì)數(shù)作為時間的函數(shù)顯示。趨勢報(bào)告可以是累計(jì)的，也可以是非累計(jì)的，可以看出缺陷增長和減少的趨勢。 ⑶缺陷年齡報(bào)告：是一種特殊類型的缺陷分部報(bào)告，顯示缺陷處于“打開”狀態(tài)的時間，展示一個缺陷處于某種狀態(tài)的時間長短，從而了解處理這些缺陷的進(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)缺陷的分布趨勢。如果曲線在最近一段時間內(nèi)呈持續(xù)的平穩(wěn)下降趨勢，那么說明軟件正在逐漸趨于穩(wěn)定；而如果在項(xiàng)目期限將至，這條曲線還呈現(xiàn)出很大幅度的波動并維持在一個較高的水平上，那么就要考慮一下是否推遲產(chǎn)品的發(fā)布，多花些時間來尋找原因。 如圖 21 所示： 15 圖 21 缺陷的分布曲線 2．可以通過使用缺陷來源和功能模塊兩個字段，對發(fā)現(xiàn)的缺陷進(jìn)行匯總 ，來分析在不同的開發(fā)階段，每個功能或模塊交付的工件的質(zhì)量情況，例如相應(yīng)功能模塊發(fā)現(xiàn)的缺陷數(shù)量是否同該功能模塊的業(yè)務(wù)復(fù)雜度成正比？相應(yīng)工作階段中發(fā)現(xiàn)的缺陷數(shù)量是否同該工作階段的工作量成正比？同時，這個表可以作為各模塊具體負(fù)責(zé)人工作質(zhì)量的評估依據(jù)，也可以作為確定下一步過程改進(jìn)重點(diǎn)的參考。如表 26 所示 ： 表 26 對發(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