《測(cè)試管理》PPT課件.ppt

1、第16章 測(cè)試管理,羅 東 俊 ZSUJONE126.COM,1,主要內(nèi)容,16.1測(cè)試管理基礎(chǔ) 16.2測(cè)試執(zhí)行周期的開始和結(jié)束 16.3隔離測(cè)試環(huán)境和開發(fā)環(huán)境 16.4測(cè)試用例的有效管理 16.5缺陷追蹤管理 16.6測(cè)試的評(píng)測(cè),2,16.1測(cè)試管理基礎(chǔ),16.1.1 軟件測(cè)試管理的內(nèi)容 16.1.2 軟件測(cè)試管理工具,3,16.1.1 軟件測(cè)試管理的內(nèi)容,軟件測(cè)試管理的目的是確保軟件測(cè)試技術(shù)在項(xiàng)目的生命周期內(nèi)得到順利實(shí)施，并產(chǎn)生預(yù)期的效果。 按照管理的對(duì)象不同，軟件測(cè)試管理大致可分為： 軟件測(cè)試團(tuán)隊(duì)組織管理 軟件測(cè)試計(jì)劃管理 軟件缺陷(錯(cuò)誤)跟蹤管理 軟件測(cè)試件管理,4,軟件測(cè)試團(tuán)隊(duì)組織

2、管理,就是指測(cè)試團(tuán)隊(duì)?wèi)?yīng)該如何組建。 通常，一個(gè)好的測(cè)試團(tuán)隊(duì)首先要有好的帶頭人，這個(gè)帶頭人必須具有極為豐富的開發(fā)經(jīng)驗(yàn)，對(duì)開發(fā)過程中常見的缺陷或錯(cuò)誤了然于胸，此外，他還應(yīng)具有親和力和人格魅力。 其次，測(cè)試團(tuán)隊(duì)還應(yīng)有具備一技之長的成員，例如對(duì)某些自動(dòng)化測(cè)試工具運(yùn)用嫻熟或能輕而易舉地編寫自動(dòng)化測(cè)試腳本。 另外，測(cè)試團(tuán)隊(duì)還應(yīng)有兼職成員，例如驗(yàn)收測(cè)試實(shí)施過程中，同行評(píng)審是最常使用的一種形式，這些同行專家就屬于兼職測(cè)試團(tuán)隊(duì)成員的范疇。 測(cè)試團(tuán)隊(duì)里往往包括幾個(gè)開發(fā)經(jīng)驗(yàn)欠缺的新成員，這部分人員可以安排去從事交付驗(yàn)收或黑盒測(cè)試之類的工作。,5,軟件測(cè)試計(jì)劃管理,就是指安排好測(cè)試流程 。 這部分內(nèi)容具體涵蓋軟件測(cè)試

3、策劃、軟件測(cè)試技術(shù)剪裁、測(cè)試進(jìn)度管理、成本管理等幾個(gè)部分。 測(cè)試策劃工作主要是指具體測(cè)試活動(dòng)實(shí)施之前做好策劃工作，如起草測(cè)試大綱以及測(cè)試計(jì)劃； 軟件測(cè)試技術(shù)剪裁工作主要是指測(cè)試團(tuán)隊(duì)?wèi)?yīng)根據(jù)軟件項(xiàng)目的具體實(shí)際，剪裁出所要實(shí)施的測(cè)試技術(shù)； 測(cè)試進(jìn)度管理工作主要是排出各項(xiàng)測(cè)試的時(shí)間進(jìn)度及人員安排，如有變動(dòng)時(shí)應(yīng)如何做相應(yīng)調(diào)整； 測(cè)試成本管理工作主要指管理測(cè)試活動(dòng)中會(huì)涉及到的資源需求。,6,軟件缺陷(錯(cuò)誤)跟蹤管理,就是確保發(fā)現(xiàn)的缺陷(錯(cuò)誤)已經(jīng)被開發(fā)團(tuán)隊(duì)糾正或處理過并且沒有引入新的缺陷(錯(cuò)誤)。 具體來講，當(dāng)測(cè)試團(tuán)隊(duì)通過各種途徑發(fā)現(xiàn)了文檔或代碼中的缺陷或錯(cuò)誤以后，并不是交一份測(cè)試報(bào)告就草草了事，而是在遞

4、交報(bào)告以后繼續(xù)督促開發(fā)團(tuán)隊(duì)及時(shí)關(guān)閉已知缺陷或錯(cuò)誤。當(dāng)然，如有必要應(yīng)對(duì)這些缺陷、錯(cuò)誤做嚴(yán)重程度排序，以便開發(fā)團(tuán)隊(duì)能視輕重緩急安排處理順序。當(dāng)開發(fā)團(tuán)隊(duì)關(guān)閉了測(cè)試報(bào)告中的缺陷(錯(cuò)誤)以后，測(cè)試團(tuán)隊(duì)還需驗(yàn)證開發(fā)團(tuán)隊(duì)在關(guān)閉過程中有沒有引入新的錯(cuò)誤。通常，這個(gè)過程稱為回歸測(cè)試。回歸測(cè)試如發(fā)現(xiàn)問題，繼續(xù)報(bào)告開發(fā)團(tuán)隊(duì)，按上述流程循環(huán)，直至回歸測(cè)試最終通過。,7,軟件測(cè)試件管理,是指努力建設(shè)好測(cè)試團(tuán)隊(duì)的軟件測(cè)試件庫并對(duì)測(cè)試團(tuán)隊(duì)成員進(jìn)行技能培訓(xùn)以幫助他們能使用好這個(gè)軟件測(cè)試件庫。 測(cè)試件(Testware)是指測(cè)試工作形成的產(chǎn)品，包括測(cè)試團(tuán)隊(duì)在長期實(shí)踐過程中逐步積累起來的經(jīng)驗(yàn)教訓(xùn)、測(cè)試技巧、測(cè)試工具、規(guī)格文檔以及

5、一些經(jīng)過少量修改就能推廣至通用的測(cè)試腳本程序。,8,16.1.2 軟件測(cè)試管理工具,采用高水平的軟件測(cè)試管理工具則能保證以一個(gè)較小規(guī)模的測(cè)試隊(duì)伍完成復(fù)雜的大量的測(cè)試工作，以此來做到對(duì)成本和時(shí)間效率的有效管理。 除此之外，通過該軟件，用戶也可以及時(shí)地掌握軟件的測(cè)試和完成情況，并對(duì)整個(gè)過程進(jìn)行監(jiān)督和管理，這對(duì)用戶控制成本和做相應(yīng)的安排也是有好處的。 目前，市場(chǎng)上主流的企業(yè)級(jí)測(cè)試管理工具主要有Mercury TestDirector和IBM RationalTest Manager,9,TestDirector的主要功能,用戶權(quán)限管理 TestDirector設(shè)置有六個(gè)用戶組，分別為TDAdmin、

6、QATester、ProjectManager、Developer、Viewer、Customer 集中式項(xiàng)目信息管理 后臺(tái)采用集中式的數(shù)據(jù)庫(Oracle、SQLServer、Access等) 分布式訪問 定義測(cè)試工作流程 需求管理、規(guī)劃測(cè)試、安排測(cè)試進(jìn)度并運(yùn)行測(cè)試、缺陷管理、圖示和報(bào)告,10,開源軟件測(cè)試管理工具,第一個(gè)工具為TestLink(http：/ 第二個(gè)工具為Bugzilla Test Runner(http：/,11,16.2測(cè)試執(zhí)行周期的開始和結(jié)束,測(cè)試人員應(yīng)該為測(cè)試執(zhí)行周期的開始和結(jié)束定義入口標(biāo)準(zhǔn)和出口標(biāo)準(zhǔn)。 入口標(biāo)準(zhǔn)描述了測(cè)試小組何時(shí)可以開始測(cè)試一個(gè)特定的版本； 出口標(biāo)準(zhǔn)

7、描述了軟件完成充分測(cè)試的時(shí)間。 由于測(cè)試資源是有限的，測(cè)試預(yù)算和測(cè)試人員的數(shù)目有限，測(cè)試時(shí)間有限，軟件發(fā)布時(shí)間緊張，因此測(cè)試工作的范圍一定要有限制。,12,系統(tǒng)測(cè)試執(zhí)行入口標(biāo)準(zhǔn),所有的單元測(cè)試和集成測(cè)試已經(jīng)成功完成。 軟件的生成(編譯)過程沒有任何錯(cuò)誤。 軟件版本通過了煙霧測(cè)試(最基本的測(cè)試，關(guān)鍵功能的測(cè)試)。 配套文檔已經(jīng)完成，文檔的內(nèi)容涉及軟件版本的新功能和修改的內(nèi)容。 缺陷已經(jīng)修正并且準(zhǔn)備重新測(cè)試。 源代碼已經(jīng)存儲(chǔ)在版本控制系統(tǒng)中,13,測(cè)試出口標(biāo)準(zhǔn),已經(jīng)執(zhí)行了用來確定系統(tǒng)滿足指定的功能性和非功能性需求的測(cè)試過程。 在測(cè)試結(jié)果中記錄的所有1級(jí)、2級(jí)和3級(jí)的軟件問題都已經(jīng)解決。 在測(cè)試結(jié)果

8、中記錄的所有1級(jí)、2級(jí)的軟件問題都已經(jīng)解決。 在測(cè)試結(jié)果中記錄的所有1級(jí)、2級(jí)的軟件問題都已經(jīng)解決，同時(shí)90的3級(jí)問題已經(jīng)解決。 軟件發(fā)布時(shí)可能存在已知的低優(yōu)先級(jí)的缺陷(當(dāng)然有若干未知缺陷)。 一些度量也可以作為出口標(biāo)準(zhǔn)的一部分 缺陷修改的質(zhì)量 、缺陷趨勢(shì)分析,14,16.3隔離測(cè)試環(huán)境和開發(fā)環(huán)境,當(dāng)測(cè)試組執(zhí)行測(cè)試、實(shí)施測(cè)試策略時(shí)，測(cè)試環(huán)境必須和開發(fā)環(huán)境分離開。 如果沒有獨(dú)立的測(cè)試環(huán)境，那么測(cè)試工作就會(huì)遇到下面的一些問題： 環(huán)境的變化 版本管理 操作環(huán)境的變化,15,16.4測(cè)試用例的有效管理,16,測(cè)試用例分析例子,17,16.5缺陷追蹤管理,16.5.1軟件缺陷的生命周期和處理流程 16.

9、5.2軟件缺陷的嚴(yán)重性和優(yōu)先級(jí) 16.5.3軟件缺陷的報(bào)告、分離和再現(xiàn) 16.5.4軟件缺陷的度量 16.5.5缺陷管理系統(tǒng),18,16.5.1軟件缺陷的生命周期和處理流程,簡(jiǎn)單的軟件缺陷生命周期,19,復(fù)雜的軟件缺陷生命周期例子,20,通用的軟件缺陷生命周期,21,缺陷狀態(tài),22,軟件缺陷分類,23,普通的缺陷處理流程,缺陷報(bào)告最初生成的狀態(tài)為“新”； 賦予各個(gè)小組打開不同問題的能力（錯(cuò)誤請(qǐng)求、變更請(qǐng)求、增強(qiáng)請(qǐng)求） 選擇缺陷優(yōu)先級(jí) 評(píng)估缺陷，為缺陷分配狀態(tài) 若狀態(tài)為“打開”，則把缺陷分配給負(fù)責(zé)的人，變?yōu)椤伴_發(fā)”狀態(tài) 開始改正缺陷了，變?yōu)椤罢陂_發(fā)”狀態(tài) 缺陷改正完了，改為“修改完畢”狀態(tài)；或

10、者“工作正?！?、“缺陷不能重現(xiàn)” 若創(chuàng)建了新版本，所有改正的缺陷改為“返測(cè)”狀態(tài) 測(cè)試工程師返測(cè)這些改動(dòng)，設(shè)置狀態(tài)為“關(guān)閉-改正”、“返測(cè)失敗”,24,普通的缺陷處理流程,25,16.5.2軟件缺陷的嚴(yán)重性和優(yōu)先級(jí),嚴(yán)重性(Severity)顧名思義就是軟件缺陷對(duì)軟件質(zhì)量的破壞程度，即此軟件缺陷的存在將對(duì)軟件的功能和性能產(chǎn)生怎樣的影響。 優(yōu)先級(jí)(Priority)是表示處理和修正軟件缺陷的先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。 處理嚴(yán)重性和優(yōu)先級(jí)，既是一種經(jīng)驗(yàn)技術(shù)，也是保證軟件質(zhì)量的重要環(huán)節(jié),26,嚴(yán)重性 vs. 優(yōu)先級(jí),一般來說，嚴(yán)重性程度高的軟件缺陷具有較高的優(yōu)先級(jí)

11、。嚴(yán)重性高說明缺陷對(duì)軟件造成的質(zhì)量危害性大，需要優(yōu)先處理，而嚴(yán)重性低的缺陷可能只是軟件不太盡善盡美，可以稍后處理。 但是，嚴(yán)重性和優(yōu)先級(jí)并不總是一一對(duì)應(yīng)。因?yàn)樾拚浖毕莶皇且患兗夹g(shù)問題，有時(shí)需要綜合考慮市場(chǎng)發(fā)布和質(zhì)量風(fēng)險(xiǎn)等問題。,27,例如,如果某個(gè)嚴(yán)重的軟件缺陷只在非常極端的條件下產(chǎn)生，則沒有必要馬上解決。 另外，如果修正一個(gè)軟件缺陷，需要重新修改軟件的整體架構(gòu)，可能會(huì)產(chǎn)生更多潛在的缺陷，而且軟件由于市場(chǎng)的壓力必須盡快發(fā)布，此時(shí)即使缺陷的嚴(yán)重性很高，是否需要修正，需要全盤考慮。 另一方面，如果軟件缺陷的嚴(yán)重性很低，例如，界面單詞拼寫錯(cuò)誤，但是如果是軟件名稱或公司名稱的拼寫錯(cuò)誤，則必須盡快

12、修正，因?yàn)檫@關(guān)系到軟件和公司的市場(chǎng)形象。,28,嚴(yán)重性的常用劃分方法,29,優(yōu)先級(jí)的常用劃分方法,30,例如,極少發(fā)生的數(shù)據(jù)毀壞缺陷應(yīng)該劃分為嚴(yán)重性1，優(yōu)先級(jí)3； 導(dǎo)致用戶電話求助的安裝指示錯(cuò)別字應(yīng)該劃分為嚴(yán)重性3，優(yōu)先級(jí)2； 只要一啟動(dòng)就崩潰的測(cè)試軟件版本屬于嚴(yán)重性1，優(yōu)先級(jí)1； 如果認(rèn)為某按鈕向頁面下方再移動(dòng)一點(diǎn)，則屬于嚴(yán)重性4，優(yōu)先級(jí)4。 軟件缺陷的優(yōu)先級(jí)在項(xiàng)目期間也可能會(huì)發(fā)生變化。 原本標(biāo)記為優(yōu)先級(jí)2的軟件缺陷隨著時(shí)間即將用盡，以及軟件發(fā)布日期臨近，可能變?yōu)閮?yōu)先級(jí)4。,31,16.5.3軟件缺陷的報(bào)告、分離和再現(xiàn),報(bào)告軟件缺陷要以明顯、通用和再現(xiàn)的形式進(jìn)行描述。 有效的軟件缺陷描述要求

13、 ： 簡(jiǎn)單與短?。褐唤忉屖聦?shí)和演示、描述軟件缺陷必需的細(xì)節(jié)。 單一：每一個(gè)報(bào)告只針對(duì)一個(gè)軟件缺陷 明顯和通用：用使用者容易看懂的、展示通用性的簡(jiǎn)單易行步驟描述的軟件缺陷 再現(xiàn)：軟件缺陷報(bào)告必須報(bào)告記錄按照預(yù)定步驟可以使軟件達(dá)到缺陷再次出現(xiàn)的相同狀況 使用IT業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法 補(bǔ)充完善軟件缺陷報(bào)告,32,缺陷報(bào)告基本組成,優(yōu)秀的錯(cuò)誤描述主要由三個(gè)基本部分組成：摘要、重建步驟和隔離。 “摘要”又叫主題或標(biāo)題，是關(guān)于錯(cuò)誤的一兩句話的描述，強(qiáng)調(diào)它對(duì)顧客或系統(tǒng)用戶的影響。 “重建步驟”提供了如何重復(fù)這個(gè)失敗的精確描述。 “隔離”是指測(cè)試人員收集的結(jié)果和信息，以確認(rèn)錯(cuò)誤確實(shí)是一個(gè)問題，并標(biāo)識(shí)那

14、些影響到錯(cuò)誤表現(xiàn)的要素。,33,一份優(yōu)秀的缺陷報(bào)告,34,16.5.4軟件缺陷的度量,對(duì)缺陷數(shù)據(jù)進(jìn)行分析和度量，使我們?cè)诟恼毕莸耐瑫r(shí)，將缺陷管理過程推向更高的階段量化管理階段 軟件開發(fā)只有引入了度量機(jī)制和定量化的管理，才能稱為真正意義上的“工程”，這一準(zhǔn)則清楚地體現(xiàn)在CMM中： CMM 4級(jí)（已管理級(jí)）引入了“定量軟件過程” CMM 5級(jí)（優(yōu)化級(jí)）則完全建立在定量管理的基礎(chǔ)之上，并明確提出了“缺陷預(yù)防”。,35,軟件缺陷度量的過程,軟件缺陷度量的過程可以分為四大部分： 計(jì)劃度量 執(zhí)行度量 分析度量結(jié)果 評(píng)價(jià)度量,36,計(jì)劃度量,嚴(yán)格地指定要度量什么，如何對(duì)數(shù)據(jù)進(jìn)行合并產(chǎn)生滿足信息需要的結(jié)果。

15、 如： 在回歸測(cè)試中，從以前運(yùn)轉(zhuǎn)正常的功能中發(fā)現(xiàn)缺陷的比例（修正工作破壞以前運(yùn)轉(zhuǎn)正常功能的頻率） 缺陷修正失敗的頻率 新缺陷的發(fā)現(xiàn)率走勢(shì),37,獲取度量數(shù)據(jù),缺陷文檔中可能包括的屬性有：缺陷ID、缺陷狀態(tài)、測(cè)試人員ID、提交時(shí)間、缺陷所屬項(xiàng)目ID、缺陷所屬模塊ID、開發(fā)人員ID、缺陷類型、嚴(yán)重級(jí)別、優(yōu)先級(jí)、修改人ID、解決方案、修改時(shí)間、修改次數(shù)、確認(rèn)結(jié)果等。,38,幾個(gè)核心度量,缺陷持續(xù)時(shí)間 缺陷糾正到返測(cè)的時(shí)間 缺陷趨勢(shì)分析 缺陷修改的質(zhì)量 缺陷密度 測(cè)試人員工作效率,39,缺陷持續(xù)時(shí)間,缺陷持續(xù)時(shí)間是指從發(fā)現(xiàn)缺陷到改正缺陷的時(shí)間跨度，同時(shí)必須考慮缺陷修正工作的復(fù)雜度。 該度量用于驗(yàn)證缺陷

16、是否被及時(shí)地解決，利用缺陷持續(xù)時(shí)間的數(shù)據(jù)，測(cè)試組可以分析開發(fā)組對(duì)改錯(cuò)工作的反應(yīng)是否影響了測(cè)試工作的進(jìn)度 一個(gè)缺陷的持續(xù)時(shí)間越長，糾正缺陷的難度可能就越大，因?yàn)榭赡茉阱e(cuò)誤代碼的基礎(chǔ)上又加入了新的代碼,40,缺陷糾正到返測(cè)的時(shí)間,缺陷糾正到返測(cè)時(shí)間是指缺陷被修正并且在新版本中發(fā)布的時(shí)間到缺陷被返測(cè)的時(shí)間跨度。 該度量提供了一種衡量測(cè)試組的返測(cè)缺陷速度的方法。,41,缺陷趨勢(shì)分析,缺陷趨勢(shì)分析是指在測(cè)試生命周期內(nèi)，隨著測(cè)試工作的進(jìn)行，發(fā)現(xiàn)缺陷的數(shù)量的變化趨勢(shì)。 缺陷趨勢(shì)分析有助于確定所發(fā)現(xiàn)的缺陷的變化趨勢(shì)，對(duì)于軟件產(chǎn)品發(fā)布而言，缺陷趨勢(shì)分析圖是輔助決策的重要依據(jù)。,42,缺陷發(fā)生率,43,缺陷趨勢(shì)圖

17、,44,缺陷修改的質(zhì)量,缺陷修改的質(zhì)量是指修改后剩余的缺陷數(shù)量，即重現(xiàn)率。 該度量測(cè)量的是缺陷修正工作給以前工作正常的功能帶來的新缺陷，或者破壞以前工作正常的功能的百分比。 例如，修復(fù)了100個(gè)缺陷，后來發(fā)現(xiàn)其中20個(gè)修復(fù)引入了新的缺陷，則缺陷糾正率為D=(100 - 20)/100100=80。,45,缺陷密度,缺陷密度(Defect Density)是指一段時(shí)間里發(fā)現(xiàn)的缺陷數(shù)與軟件大小的比例。 軟件的大小可以采用功能點(diǎn)度量，也可以用源代碼行數(shù)衡量。用數(shù)學(xué)公式表示為：DD=defects/KLOC或DD=defects/KFP KLOC表示每千行源代碼，KFP表示每千個(gè)功能點(diǎn)。 產(chǎn)品的缺陷密

18、度直接影響著客戶的滿意程度。,46,各模塊中每千行代碼的缺陷密度,47,缺陷密度度量的缺點(diǎn),缺陷密度這種度量方法是極不完善的，度量本身是不充分的。 這里邊存在的主要問題是：所有的缺陷并不都是均等構(gòu)造的。 各個(gè)軟件缺陷的惡劣程度，及其對(duì)產(chǎn)品和用戶的影響的嚴(yán)重程度，以及修復(fù)缺陷的重要程度有很大差別， 因此，有必要對(duì)缺陷進(jìn)行“分級(jí)、加權(quán)”處理，給出軟件缺陷在各嚴(yán)重性級(jí)別或優(yōu)先級(jí)上的分布作為補(bǔ)充度量，,48,缺陷在各優(yōu)先級(jí)上的分布,49,缺陷嚴(yán)重程度分布,50,缺陷產(chǎn)生原因分布圖,它是缺陷分析中最為重要的一張圖表，因?yàn)樗梢灾苯臃从吵龈鬈浖こ袒顒?dòng)的質(zhì)量，為軟件過程的改進(jìn)提供直接的參考數(shù)據(jù)。 一般來說

19、，缺陷產(chǎn)生的根本原因劃分的越細(xì)致，分析的結(jié)果就越精確。 例如，當(dāng)發(fā)現(xiàn)需求中出現(xiàn)的缺陷比較多的時(shí)候，在未來的項(xiàng)目中我們可以通過需求評(píng)審、需求變更控制來減少該種缺陷的數(shù)量，以達(dá)到軟件質(zhì)量保證的目的。 同樣如果我們發(fā)現(xiàn)軟件設(shè)計(jì)過程中產(chǎn)生的問題比較多，那么就可以通過加強(qiáng)軟件設(shè)計(jì)階段中的審查活動(dòng)來保證設(shè)計(jì)的質(zhì)量。,51,幾個(gè)綜合指標(biāo),測(cè)試人員工作效率 缺陷探測(cè)效率 發(fā)布前的缺陷消除率,52,測(cè)試人員工作效率,測(cè)試人員工作效率：是指測(cè)試人員在一定時(shí)期內(nèi)測(cè)試出不同類型缺陷的能力，它等于測(cè)試人員測(cè)試出的不同缺陷類型數(shù)量與對(duì)應(yīng)權(quán)值的乘積之和，再除以本次測(cè)試的周期，從而衡量測(cè)試人員的熟練程度。,53,缺陷探測(cè)效率

20、,缺陷探測(cè)效率(Defect Detection Efficien，DDE)：是指軟件生命周期的各個(gè)階段由測(cè)試人員發(fā)現(xiàn)缺陷的效率。它可以這樣計(jì)算：在各個(gè)生命周期階段發(fā)現(xiàn)某個(gè)階段產(chǎn)生的缺陷數(shù)與在該階段中產(chǎn)生的缺陷總個(gè)數(shù)的比例。 如果DDE為100，則表明該階段發(fā)現(xiàn)了所有在這個(gè)階段中產(chǎn)生的缺陷，沒有缺陷傳播到下一個(gè)階段。 如果DDE為30，則表明該階段發(fā)現(xiàn)了30在這個(gè)階段中產(chǎn)生的缺陷，將有70在這個(gè)階段中產(chǎn)生的缺陷傳播到下一個(gè)階段。 DDE說明了過程的效率。,54,發(fā)布前的缺陷消除率,發(fā)布前的缺陷消除率(Pre Delivery Defect Removal Efficiency)：是指軟件發(fā)布前

21、的各個(gè)階段發(fā)現(xiàn)的缺陷總數(shù)占軟件缺陷總數(shù)的比例。 如，發(fā)布前發(fā)現(xiàn)了300個(gè)缺陷，發(fā)布后使用半年又發(fā)現(xiàn)了100個(gè)缺陷，則發(fā)布前的缺陷消除率PDRE=300/(300+100)100=75。,55,16.5.5缺陷管理系統(tǒng),國內(nèi)外已出現(xiàn)了一批質(zhì)量較好的缺陷管理工具，其中比較有代表性的有： 開源軟件Bugzilla、jira Compuware公司的TrackRecord 、 Rational公司的ClearQuest、 北京航空航天大學(xué)的QAMonitor、 上海微創(chuàng)軟件有限公司的BMS等。 這些工具各有特色，在功能的全面性上也各不相同，但都是基于“找出缺陷、修改缺陷、進(jìn)行回歸測(cè)試”這種面向流程處理的傳統(tǒng)模式，實(shí)現(xiàn)了缺陷管理的基本流程，并在此基礎(chǔ)上提供了一些查詢和統(tǒng)計(jì)功能； 其共同的缺點(diǎn)是沒有充分利用軟件開發(fā)過程中產(chǎn)生的缺陷數(shù)據(jù)，不能以一種主動(dòng)的、精確量化的方式對(duì)軟件缺陷進(jìn)行預(yù)防并提供軟件項(xiàng)目管理者所需的有關(guān)產(chǎn)品和過程的度量信息。,56,16.6測(cè)試的評(píng)測(cè),16.6.1覆蓋評(píng)測(cè) 16.6.2質(zhì)量評(píng)測(cè),5