基于缺陷模式的軟件測試(第12章)課件

1、1第12章基于缺陷模式的軟件測試 2內(nèi)容提要12.1概述12.1.1 相關(guān)定義12.1.2 軟件缺陷的產(chǎn)生原因12.1.3 減少缺陷的關(guān)鍵因素12.1.4 軟件缺陷的特征12.2軟件缺陷屬性12.2.1 缺陷類型12.2.2 缺陷嚴(yán)重程度12.2.3 同行評審錯誤嚴(yán)重程度12.2.4 缺陷優(yōu)先級12.2.5 缺陷狀態(tài)12.2.6 缺陷起源12.2.7 缺陷來源12.2.8 缺陷根源3內(nèi)容提要12.3軟件缺陷的嚴(yán)重性和優(yōu)先級12.3.1 缺陷的嚴(yán)重性和優(yōu)先級的關(guān)系12.3.2 處理缺陷的嚴(yán)重性和優(yōu)先級的常見錯誤12.3.3 缺陷的嚴(yán)重性和優(yōu)先級的表示和確定12.4 軟件缺陷管理和CMM的關(guān)系12

2、.4.1 初始級的缺陷管理12.4.2 可重復(fù)級的缺陷管理12.4.3 已定義級的缺陷管理12.4.4 定量管理級的缺陷管理12.4.5 持續(xù)優(yōu)化級的缺陷管理4內(nèi)容提要12.5 報告軟件缺陷12.5.1 報告軟件缺陷的基本原則12.5.2 IEEE軟件缺陷報告模板12.6軟件缺陷管理12.6.1 缺陷管理目標(biāo)12.6.2 人員職責(zé)12.6.3 缺陷生命周期12.6.4 缺陷管理系統(tǒng)12.7軟件缺陷分析12.7.1 缺陷分析方法12.7.2 缺陷分析指標(biāo)12.8小結(jié)512.1概述軟件業(yè)的發(fā)展推動了社會經(jīng)濟(jì)的快速發(fā)展，但是軟件質(zhì)量卻變得越來越難以控制。從某種程度上說，軟件產(chǎn)品的競爭力已經(jīng)不完全取決

3、于技術(shù)的先進(jìn)，更重要的是取決于軟件質(zhì)量的穩(wěn)定。然而對于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此付出的代價和成本是巨大的。研究表明，大約有60%的錯誤是在設(shè)計階段之前注入的，并且修正一個軟件錯誤所需要的費(fèi)用將隨著軟件生存期的進(jìn)展而上升。錯誤發(fā)現(xiàn)得越晚，修復(fù)它的費(fèi)用就越高，而且呈指數(shù)上升的趨勢。在軟件的編碼測試階段遺漏編碼缺陷，如果到系統(tǒng)測試時才發(fā)現(xiàn)，那么這時糾正缺陷所花費(fèi)的成本是在編碼階段糾錯花費(fèi)的成本的7倍以上，而且測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目（即檢錯率）很可能成正比。712.1.1 相關(guān)定義軟件錯誤：軟件錯誤是指在軟件生存期內(nèi)的不希望或不可接受的人為錯誤，其結(jié)果是導(dǎo)

4、致軟件缺陷的產(chǎn)生?？梢?，軟件錯誤是一種人為過程，相對于軟件本身，是一種外部行為。軟件缺陷：軟件缺陷是存在于軟件（文檔，數(shù)據(jù)或程序）之中的那些不希望或不可接受的偏差。其結(jié)果是軟件運(yùn)行于某一特定條件時出現(xiàn)軟件故障，這時稱軟件缺陷被激活。軟件故障：軟件故障是指軟件運(yùn)行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。比如：軟件處于執(zhí)行一個多余循還過程時，我們說軟件出現(xiàn)故障。若此時沒有適當(dāng)?shù)拇胧ㄈ蒎e）加以處理，便產(chǎn)生軟件失效。軟件故障是一種動態(tài)行為。軟件失效：軟件失效是指軟件運(yùn)行時產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。 軟件失效機(jī)理8軟件缺陷管理：在軟件開發(fā)過程中對所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個被發(fā)現(xiàn)

5、的軟件缺陷被關(guān)閉。邏輯上僅有2種方法應(yīng)用于開發(fā)低缺陷的軟件缺陷預(yù)防缺陷排除1012.1.3 減少缺陷的關(guān)鍵因素軟件在版本發(fā)布后發(fā)現(xiàn)和解決一個軟件存在的問題所需的費(fèi)用，通常要比在需求和設(shè)計階段發(fā)現(xiàn)、解決問題高出約100倍；當(dāng)前的軟件項(xiàng)目約40%到50%的費(fèi)用花費(fèi)在可以避免的重復(fù)工作上；大約80%的可避免的重復(fù)工作產(chǎn)生于20%的缺陷；大約的80%缺陷產(chǎn)生于20%的模塊，約一半的模塊缺陷是很少的；大約的90%軟件故障來來自于的10%缺陷；有效的審核可以找出約60%的缺陷；有的目的性審核能夠比無方向的審核多捕獲約35%的缺陷；人員的專業(yè)性訓(xùn)練可減少高達(dá)約75%的缺陷出現(xiàn)率；同等情況下，開發(fā)高可信賴的軟

6、件產(chǎn)品與開發(fā)低可信賴的軟件產(chǎn)品相比，成本要高出近50%。然而，如果考慮到軟件項(xiàng)目的運(yùn)行和維護(hù)成本的話，這種投資是完全值得的；大約40%到50%的用戶程序都包含有非常細(xì)小的缺陷。1112.1.4 軟件缺陷的特征1、缺陷的發(fā)生都是有原因的2、缺陷的重現(xiàn)性3、缺陷的累積性、放大性（見下頁圖所示）4、缺陷的修復(fù)可能又引進(jìn)新的缺陷12典型瀑布模型的軟件缺陷的累積和放大效應(yīng)14缺陷標(biāo)識（Identifier）：缺陷標(biāo)識是標(biāo)記某個缺陷的一組符號。每個缺陷必須有一個唯一的標(biāo)識；缺陷類型 （Type）：缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、

7、系統(tǒng)/模塊接口缺陷等；缺陷嚴(yán)重程度 （Severity）：缺陷嚴(yán)重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度；缺陷優(yōu)先級（Priority）：缺陷的優(yōu)先級指缺陷必須被修復(fù)的緊急程度；缺陷狀態(tài)（Status）：缺陷狀態(tài)指缺陷通過一個跟蹤修復(fù)過程的進(jìn)展情況；缺陷起源（Origin）：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段；缺陷來源（Source）：缺陷來源指引起缺陷的起因；缺陷根源（Root Cause）：缺陷根源指發(fā)生錯誤的根本因素。1512.2.1 缺陷類型缺陷類型編號缺陷類型描述10F- Function影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計

8、文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。20A- Assignment需要修改少量代碼，如初始化或控制塊。如聲明、重復(fù)命名，范圍、限定等缺陷。30I- Interface與其他組件、模塊或設(shè)備驅(qū)動程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。40C- Checking提示的錯誤信息，不適當(dāng)?shù)臄?shù)據(jù)驗(yàn)證等缺陷。50B Build/package/merge由于配置庫、變更管理或版本控制引起的錯誤。60D- Documentation影響發(fā)布和維護(hù)，包括注釋。70G- Algorithm算法錯誤。80U-User Interface人機(jī)交互特性：屏幕格式，確認(rèn)用戶輸入，功能有效性

9、，頁面排版等方面的缺陷。90P-Performance不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事務(wù)處理速率等。100N-Norms不符合各種標(biāo)準(zhǔn)的要求，如編碼標(biāo)準(zhǔn)、設(shè)計符號等。1712.2.3 同行評審錯誤嚴(yán)重程度#缺陷嚴(yán)重等級描述1Major主要的，較大的缺陷2Minor次要的，小的缺陷1812.2.4 缺陷優(yōu)先級#缺陷優(yōu)先級描述1Resolve Immediately缺陷必須被立即解決。2Normal Queue缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單。3Not Urgent缺陷可以在方便時被糾正。1912.2.5 缺陷狀態(tài)缺陷狀態(tài)描述Submitted已提交的缺陷Open確認(rèn)“提交的缺

10、陷”，等待處理Rejected拒絕“提交的缺陷”，不需要修復(fù)或不是缺陷Resolved缺陷被修復(fù)Closed確認(rèn)被修復(fù)的缺陷，將其關(guān)閉2012.2.6 缺陷起源缺陷起源描述Requirement在需求階段發(fā)現(xiàn)的缺陷 Architecture在構(gòu)架階段發(fā)現(xiàn)的缺陷 Design在設(shè)計階段發(fā)現(xiàn)的缺陷 Code在編碼階段發(fā)現(xiàn)的缺陷 Test在測試階段發(fā)現(xiàn)的缺陷 2112.2.7 缺陷來源缺陷來源描述Requirement由于需求的問題引起的缺陷 Architecture由于構(gòu)架的問題引起的缺陷 Design由于設(shè)計的問題引起的缺陷 Code由于編碼的問題引起的缺陷 Test由于測試的問題引起的缺陷 I

11、ntegration由于集成的問題引起的缺陷 2212.2.8 缺陷根源缺陷原因描述目標(biāo)如：錯誤的范圍，誤解了目標(biāo)，超越能力的目標(biāo)等；過程，工具和方法如：無效的需求收集過程，過時的風(fēng)險管理過程，不適用的項(xiàng)目管理方法，沒有估算規(guī)程，無效的變更控制過程等。人如：項(xiàng)目團(tuán)隊(duì)職責(zé)交叉，缺乏培訓(xùn)。沒有經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)，缺乏士氣和動機(jī)不純等。缺乏組織和通訊如：缺乏用戶參與，職責(zé)不明確，管理失敗等。2412.3.1 缺陷的嚴(yán)重性和優(yōu)先級的關(guān)系嚴(yán)重性（Severity）顧名思義就是軟件缺陷對軟件質(zhì)量的破壞程度，反應(yīng)其對產(chǎn)品和用戶的影響，即此軟件缺陷的存在將對軟件的功能和性能產(chǎn)生怎樣的影響。在軟件測試中，軟件缺陷的

12、嚴(yán)重性的判斷應(yīng)該從軟件最終用戶的觀點(diǎn)做出判斷，即判斷缺陷的嚴(yán)重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣后果的嚴(yán)重性。優(yōu)先級表示修復(fù)缺陷的重要程度和應(yīng)該何時修復(fù)，是表示處理和修正軟件缺陷的先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。確定軟件缺陷優(yōu)先級，更多的是站在軟件開發(fā)工程師的角度考慮問題，因?yàn)槿毕莸男拚樞蚴莻€復(fù)雜的過程，有些不是純粹的技術(shù)問題，而且開發(fā)人員更熟悉軟件代碼，能夠比測試工程師更清楚修正缺陷的難度和風(fēng)險。2512.3.2 處理缺陷的嚴(yán)重性和優(yōu)先級的常見錯誤正確處理缺陷的嚴(yán)重性和優(yōu)先級不是件非常容易的事情，對于經(jīng)驗(yàn)不很豐富的開發(fā)人員經(jīng)常會發(fā)生如下的情形：將比較

13、輕微的缺陷報告成較高級別的缺陷和高優(yōu)先級，夸大缺陷的嚴(yán)重程度，經(jīng)常給人“狼來了”的錯覺，將影響軟件質(zhì)量的正確評估，也耗費(fèi)開發(fā)人員辨別和處理缺陷的時間。將很嚴(yán)重的缺陷報告成輕微缺陷和低優(yōu)先級，這樣可能掩蓋了很多嚴(yán)重的缺陷。如果在項(xiàng)目發(fā)布前，發(fā)現(xiàn)還有很多由于不正確分配優(yōu)先級造成的嚴(yán)重缺陷，將需要投入很多人力和時間進(jìn)行修正，影響軟件的正常發(fā)布?；蛘哌@些嚴(yán)重的缺陷成了“漏網(wǎng)之魚”，隨軟件一起發(fā)布出去，影響軟件的質(zhì)量和用戶的使用信心。2712.4 軟件缺陷管理和CMM的關(guān)系CMM 是指“軟件能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮

14、寫為SW-CMM，簡稱CMM。它是對于軟件組織在定義、實(shí)施、度量、控制和改善其軟件過程的實(shí)踐中各個發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護(hù)，進(jìn)行過程監(jiān)控和研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠更好地實(shí)現(xiàn)商業(yè)目標(biāo)。2812.4.1 初始級的缺陷管理處于CMM一級（或稱為初始級）的軟件組織，對軟件缺陷的管理無章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相應(yīng)的軟件。通常，沒有人會去記錄自己發(fā)現(xiàn)的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測試中才有可能知道那些所謂己被糾正了的缺陷是否真的被糾正了，更重要的是

15、糾正過程是否引入了新的缺陷。所以這樣的軟件組織的項(xiàng)目交貨期表現(xiàn)出強(qiáng)烈的不可預(yù)測性。并且，為了獲得一個高質(zhì)量的軟件產(chǎn)品（如果能夠的話），通常要在測試上花費(fèi)大量的人力。2912.4.2 可重復(fù)級的缺陷管理在 CMM 二級（或稱為可重復(fù)級）的軟件組織中，軟件項(xiàng)目會從自身的需要出發(fā)，制定本項(xiàng)目的缺陷管理過程。一個完備軟件缺陷管理過程通常會包括如下幾個方面：提交缺陷；分析和定位缺陷；提請修改相應(yīng)的軟件；修改相應(yīng)的軟件；驗(yàn)證修改。項(xiàng)目組會完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺陷的修改過程，并驗(yàn)證修改缺陷的結(jié)果。3012.4.3 已定義級的缺陷管理CMM 三級（或稱為己定義級）的軟件組織會匯集組織內(nèi)部以前項(xiàng)目的

16、經(jīng)驗(yàn)教訓(xùn)，制定組織級的缺陷管理過程。并且，要求項(xiàng)目根據(jù)組織級的缺陷管理過程定制本項(xiàng)目的缺陷管理過程。從而，整個軟件組織中的項(xiàng)目都遵循類似的過程來管理缺陷。好的缺陷管理實(shí)踐成為所有項(xiàng)目的實(shí)踐，而教訓(xùn)也為所有項(xiàng)目所了解。更重要的是，隨著組織的不斷發(fā)展完善，組織的過程會得到持續(xù)性的改進(jìn)，所有項(xiàng)目的過程也都會相應(yīng)的改進(jìn)。3112.4.4 定量管理級的缺陷管理沒實(shí)現(xiàn)缺陷預(yù)防的缺陷密度CMM4（已管理級）：建立軟件過程能力基線3212.4.5 持續(xù)優(yōu)化級的缺陷管理實(shí)現(xiàn)了缺陷預(yù)防的缺陷密度CMM5（持續(xù)優(yōu)化級）：強(qiáng)調(diào)對組織的過程進(jìn)行持續(xù)性改進(jìn)3312.5 報告軟件缺陷12.5.1 報告軟件缺陷的基本原則準(zhǔn)確

17、報告軟件缺陷是非常重要的，因?yàn)椋呵逦鷾?zhǔn)確的軟件缺陷描述可以減少軟件缺陷從開發(fā)人員返回的數(shù)量；提高軟件缺陷修復(fù)的速度，使每一個小組能夠有效的工作；提高測試人員的信任度，可以得到開發(fā)人員對清晰的軟件缺陷描述有效的響應(yīng)；加強(qiáng)開發(fā)人員，測試人員和管理人員的協(xié)同工作，讓他們可以更好的工作；34軟件缺陷的有效描述規(guī)則軟件缺陷的有效描述規(guī)則，主要包括：單一準(zhǔn)確。每個報告只針對一個軟件缺陷。在一個報告中報告多個軟件缺陷的弊端是常常會導(dǎo)致缺陷部分被注意和修復(fù)，不能得到徹底的修正?？梢栽佻F(xiàn)。提供缺陷的精確操作步驟，使開發(fā)人員容易看懂，可以自己再現(xiàn)這個缺陷，通常情況下，開發(fā)人員只有再現(xiàn)了缺陷，才能正確地修復(fù)缺陷。完

18、整統(tǒng)一。提供完整、前后統(tǒng)一的軟件缺陷的步驟和信息，例如：圖片信息，Log文件等。短小簡練。通過使用關(guān)鍵詞，可以使軟件缺陷的標(biāo)題的描述短小簡練，又能準(zhǔn)確解釋產(chǎn)生缺陷的現(xiàn)象。如“主頁的導(dǎo)航欄在低分辨率下顯示不整齊”中“主頁”、“導(dǎo)航欄”、“分辨率”等是關(guān)鍵詞。特定條件。許多軟件功能在通常情況下沒有問題，而是在某種特定條件下會存在缺陷，所以軟件缺陷描述不要忽視這些看似細(xì)節(jié)的但又必要的特定條件（如特定的操作系統(tǒng)、瀏覽器或某種設(shè)置等），能夠提供幫助開發(fā)人員找到原因的線索。如“搜索功能在沒有找到結(jié)果返回時跳轉(zhuǎn)頁面不對”。補(bǔ)充完善。從發(fā)現(xiàn)bug那一刻起，測試人員的責(zé)任就是保證它被正確的報告，并且得到應(yīng)有的重

19、視，繼續(xù)監(jiān)視其修復(fù)的全過程。不做評價。在軟件缺陷描述不要帶有個人觀點(diǎn)，對開發(fā)人員進(jìn)行評價。軟件缺陷報告是針對產(chǎn)品、針對問題本身，將事實(shí)或現(xiàn)象客觀地描述出來就可以，不需要任何評價或議論。3512.5.2 IEEE軟件缺陷報告模板3612.6軟件缺陷管理12.6.1 缺陷管理目標(biāo)由于不同的軟件開發(fā)組織在軟件開發(fā)過程、質(zhì)量保證體系的不同，缺陷管理的方式和處理流程也不盡相同。但其目的都是對各階段測試發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，以保證各級缺陷的修復(fù)率達(dá)到標(biāo)準(zhǔn)。一般而言缺陷管理應(yīng)當(dāng)具有以下目標(biāo)：及時了解并跟蹤每個被發(fā)現(xiàn)的缺陷；確保每個被發(fā)現(xiàn)的缺陷都能夠被處理。這里處理的意思不一定是被修正，也可能是其他處理方式

20、（例如，在下一個版本中修正）。對于每個被發(fā)現(xiàn)的缺陷的處理方式應(yīng)當(dāng)在開發(fā)組織內(nèi)中達(dá)成一致。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線來識別測試過程是否結(jié)束。決定測試過程是否結(jié)束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式。收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過程財富。3712.6.2 人員職責(zé)參與缺陷管理過程人員角色包括項(xiàng)目經(jīng)理、項(xiàng)目測試負(fù)責(zé)人、測試人員、項(xiàng)目相關(guān)開發(fā)人員、質(zhì)量保證人員，其職責(zé)描述如下：項(xiàng)目經(jīng)理（PM）：負(fù)責(zé)指派缺陷給相關(guān)責(zé)任人。項(xiàng)目測試負(fù)責(zé)人（TM）:決定缺陷管理方式和工具，擬定決策評審計劃；管理所有缺陷關(guān)閉情況；審核測試人員提交的缺陷；對測試人

21、員的工作質(zhì)量進(jìn)行跟蹤與評價。測試人員（TE）負(fù)責(zé)報告系統(tǒng)缺陷記錄，且協(xié)助項(xiàng)目人員進(jìn)行缺陷定位；負(fù)責(zé)驗(yàn)證缺陷修復(fù)情況，且填寫缺陷記錄中相應(yīng)信息；負(fù)責(zé)執(zhí)行系統(tǒng)回歸測試；提交缺陷報告；負(fù)責(zé)被測軟件進(jìn)行質(zhì)量數(shù)據(jù)和分析。項(xiàng)目相關(guān)開發(fā)人員（DE）修改測試發(fā)現(xiàn)的缺陷，并提交成果物做再測試；負(fù)責(zé)接收各自的缺陷記錄，并且修改；負(fù)責(zé)提供缺陷記錄跟蹤中其它相應(yīng)信息。質(zhì)量保證人員（SQA）監(jiān)控項(xiàng)目組缺陷管理規(guī)程執(zhí)行情況。3812.6.3 缺陷生命周期軟件缺陷的狀態(tài)在其生命周期中變化如下：缺陷從隱藏在產(chǎn)品中被發(fā)現(xiàn)，這時缺陷狀態(tài)為“創(chuàng)建”。得到缺陷修復(fù)請求以后，開發(fā)經(jīng)理將缺陷修復(fù)任務(wù)分配給相應(yīng)的開發(fā)人員進(jìn)行修復(fù)，這時缺陷

22、的狀態(tài)變?yōu)椤耙逊峙洹?。開發(fā)人員得到缺陷修復(fù)任務(wù)以后，根據(jù)缺陷的描述重現(xiàn)缺陷的癥狀、修復(fù)缺陷，然后提交測試人員驗(yàn)證修改，這時缺席的狀態(tài)變?yōu)椤耙研迯?fù)”。測試人員驗(yàn)證修改的有效性，若缺陷的修正得到最終確認(rèn)，其狀態(tài)變?yōu)椤耙汛_認(rèn)”。最終缺陷提交者或者測試人員，關(guān)閉這個缺陷，結(jié)束其生命周期。這時缺陷狀態(tài)變?yōu)椤耙殃P(guān)閉”?；镜能浖毕萆芷?9實(shí)踐中的軟件缺陷生命周期 實(shí)踐中的軟件缺陷生命周期4012.6.4 缺陷管理系統(tǒng)缺陷管理系統(tǒng)是用來管理軟件缺陷整個生命的工作流系統(tǒng)，跟蹤缺陷從發(fā)生到被修正并發(fā)布的整個過程。它能夠加強(qiáng)缺陷修正的過程控制，是缺陷管理的實(shí)現(xiàn)工具。缺陷跟蹤系統(tǒng)能否成功的實(shí)施取決于相應(yīng)的缺陷

23、跟蹤流程的設(shè)計和軟件設(shè)計。其作用主要表現(xiàn)在：提高軟件缺陷報告的質(zhì)量。軟件缺陷報告的一致性和正確性是衡量軟件測試過程專業(yè)化程度的重要指標(biāo)之一。通過正確和完整填寫軟件缺陷管理系統(tǒng)提供的各項(xiàng)內(nèi)容，可以保證不同測試工程師的缺陷報告格式統(tǒng)一。實(shí)時管理和控制缺陷狀態(tài)。軟件缺陷查詢、篩選、排序、添加、修改保存、權(quán)限控制是缺陷管理系統(tǒng)的基本功能和主要優(yōu)勢。通過方便的數(shù)據(jù)庫查詢和分類篩選，便于迅速定位缺陷和統(tǒng)計缺陷的類型。通過權(quán)限設(shè)置，保證只有適當(dāng)權(quán)限的人才能修改或刪除軟件缺陷，確保了數(shù)據(jù)安全性。量化修復(fù)工作量。通過缺陷管理系統(tǒng)建立對缺陷數(shù)據(jù)的分析功能可以幫助軟件組織對員工績效、項(xiàng)目進(jìn)展情況等等進(jìn)行評估，幫助企業(yè)改進(jìn)軟件過程提高員工工作效率。確保每一個缺陷能被處理，避免缺陷被遺忘或信息丟失等情況的發(fā)生。提供解決問題的知識，開發(fā)人員利用缺陷跟蹤系統(tǒng)，對已解決的問題所采用方法進(jìn)行學(xué)習(xí)，提高軟件缺陷修復(fù)效率。BugzillaClearQuest41缺陷管理系統(tǒng)比較 工具名稱BugzillaClearQuest流程定制支持支持查詢功能支持支持郵件通知支持支持系統(tǒng)架構(gòu)B/SC/S，B/S支持平臺Linux，F(xiàn)reeBSD，WindowsUnix，Windows數(shù)據(jù)庫SQL ServerOacle，SQL Server復(fù)雜度簡單復(fù)雜產(chǎn)品價格