10/12/2023軟件缺陷管理Version1.02010年5月10/12/2023課程介紹10/12/20232課程介紹課程目標(biāo)預(yù)備知識日程表詞匯表10/12/20233課程目標(biāo)通過學(xué)習(xí)本章節(jié)。你可以：了解缺陷的屬性掌握缺陷的報告方式了解缺陷跟蹤管理過程掌握缺陷數(shù)據(jù)的使用10/12/20234熟悉軟件測試流程熟悉軟件測試基本方法預(yù)備知識10/12/20235日程表共計：2課時詳細(xì)安排<0:05>課程介紹<0:15>缺陷管理概述<0:35>缺陷管理流程<0:10>缺陷管理工具介紹<0:05>問題&反饋Total:<1:10>hours10/12/20236軟件缺陷管理10/12/20237主題軟件缺陷概述如何報告缺陷如何跟蹤缺陷缺陷度量缺陷管理工具10/12/20238軟件缺陷概述軟件缺陷的定義軟件缺陷的屬性軟件缺陷的分類標(biāo)準(zhǔn)10/12/20239缺陷的定義軟件缺陷（Defect），常常又被叫做Bug。所謂軟件缺陷，即為計算機(jī)軟件或程序中存在的某種破壞正常運(yùn)行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。10/12/202310缺陷的屬性（主要）屬性名稱描述缺陷標(biāo)識(Identifier)缺陷標(biāo)識是標(biāo)記某個缺陷的一組符號。每個缺陷必須有一個唯一的標(biāo)識缺陷類型

(Type)缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。缺陷嚴(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ā)生錯誤的根本因素。10/12/202311缺陷的屬性（其他）屬性名稱描述缺陷摘要

(Summary)用一句話概要地描述缺陷的現(xiàn)象缺陷描述(Description)詳細(xì)的描述缺陷重現(xiàn)的環(huán)境、前置條件、步驟、期望結(jié)果、實(shí)際結(jié)果等。指定的負(fù)責(zé)人

(owner/assignee)通常是負(fù)責(zé)修復(fù)該缺陷的開發(fā)人員，在有的系統(tǒng)中也支持開發(fā)人員修復(fù)好缺陷修改其在缺陷跟蹤系統(tǒng)中的狀態(tài)后把它指定（assign）給相關(guān)的測試人員。foundin缺陷被發(fā)現(xiàn)的版本fixedin缺陷被修復(fù)的時候由開發(fā)人員填寫。解決辦法（resolution）由開發(fā)人員修復(fù)缺陷的時候填寫。verifiedin反映缺陷的修復(fù)在哪個版本被驗(yàn)證了附件（attachment

）附加的屏幕截圖、服務(wù)器或客戶端日志等相關(guān)文件，便于開發(fā)人員定位缺陷的原因。10/12/202312缺陷類型編號缺陷類型描述10F-Function影響了重要的特性、用戶界面、產(chǎn)品接口、硬件接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計文檔需要正式的變更。如邏輯，指針，循環(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-UserInterface人機(jī)交互特性：屏幕格式，確認(rèn)用戶輸入，功能有效性，頁面排版等方面的缺陷90P-Performance不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事務(wù)處理速率等。100N-Norms不符合各種標(biāo)準(zhǔn)的要求，如編碼標(biāo)準(zhǔn)、設(shè)計符號等。缺陷的分類-缺陷類型(Type)10/12/202313缺陷的分類-嚴(yán)重程度(Severity)#缺陷嚴(yán)重等級描述1Critical不能執(zhí)行正常工作功能或重要功能?；蛘呶＜叭松戆踩?Major嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬于更正辦法）3Minor嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)，但存在合理的更正辦法。（重新安裝或重新啟動該軟件不屬于更正辦法）4Cosmetic使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。5Other其它錯誤10/12/202314缺陷的分類-優(yōu)先級(Priority)#解決優(yōu)先級描述1Low低（不影響系統(tǒng)的功能實(shí)現(xiàn)，如提示信息錯誤，錯別字等）2Medium中（某些非總要的功能未能實(shí)現(xiàn)，但不影響其他功能）3High高（不符合系統(tǒng)的設(shè)計或某一主要功能無法實(shí)現(xiàn)）4VeryHigh很高（缺陷造成數(shù)據(jù)丟失或死機(jī)）5Urgent緊急（缺陷必選立即被解決，否則無法測試下去）10/12/202315缺陷的分類-狀態(tài)(Status)缺陷狀態(tài)描述New新建缺陷Open被確認(rèn)并分配相關(guān)開發(fā)人員處理Fixed開發(fā)人員已確認(rèn)修改，等待測試人員處理Rejected拒絕修改缺陷Deferred被確認(rèn)，但延期修改缺陷Closed缺陷已被修復(fù)10/12/202316缺陷起源描述Requirement在需求階段發(fā)現(xiàn)的缺陷Architecture在構(gòu)架階段發(fā)現(xiàn)的缺陷Design在設(shè)計階段發(fā)現(xiàn)的缺陷Code在編碼階段發(fā)現(xiàn)的缺陷Test在測試階段發(fā)現(xiàn)的缺陷缺陷的分類-缺陷起源(Origin)10/12/202317缺陷來源描述Requirement由于需求的問題引起的缺陷Architecture由于構(gòu)架的問題引起的缺陷Design由于設(shè)計的問題引起的缺陷Code由于編碼的問題引起的缺陷Test由于測試的問題引起的缺陷Integration由于集成的問題引起的缺陷缺陷的分類-缺陷來源(Source)10/12/202318缺陷原因描述目標(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ī)不純等。缺陷的分類-缺陷根源(RootCause)10/12/202319如何報告缺陷10/12/202320主題如何面對軟件缺陷如何有效描述缺陷10/12/202321如何面對缺陷確保發(fā)現(xiàn)的軟件缺陷全部被關(guān)閉，但不一定被修復(fù)。沒有足夠的時間。不算真正的軟件缺陷。修復(fù)的風(fēng)險太大。不值得修復(fù)。軟件缺陷報告不夠有效。導(dǎo)致對缺陷的判斷失誤。10/12/202322如何面對缺陷報告軟件缺陷的原則一盡快報告軟件缺陷嚴(yán)重軟件缺陷小軟件缺陷項(xiàng)目啟動項(xiàng)目結(jié)束可能修復(fù)的缺陷10/12/202323如何面對缺陷報告軟件缺陷的原則二有效描述軟件缺陷短小：只解釋事實(shí)和演示、描述軟件缺陷必經(jīng)的細(xì)節(jié)。單一：每一個報告只針對一個軟件缺陷。明顯和通用：使用者容易看懂的、展示通用性的、簡單易行的步驟描述軟件缺陷。再現(xiàn)軟件缺陷：按照描述，可以讓軟件缺陷再次出現(xiàn)。在報告軟件缺陷時不做任何評價：針對事實(shí)，不能對程序員作任何評價。補(bǔ)充的完善軟件缺陷報告：對發(fā)現(xiàn)的缺陷不要跟丟了。10/12/202324如何面對缺陷報告軟件缺陷的原則二-示例缺陷描述1：“無論何時登錄對話框中輸入一串隨機(jī)字符，軟件就開始亂“缺陷描述2：“聯(lián)機(jī)幫助文件中有5個單詞拼寫錯誤：…..”缺陷描述3：“你控制打印機(jī)的代碼很糟糕，根本無法工作。我相信你在送來測試之前一點(diǎn)也沒有檢查“10/12/202325如何有效描述缺陷缺陷描述的三個部分概要再現(xiàn)步驟隔離10/12/202326如何有效描述缺陷-概要使用一兩句話來描述錯誤，留下深刻印象。告訴經(jīng)理、開發(fā)人員以及其他讀者為什么應(yīng)該關(guān)心該問題。1、“屏幕分辨率有問題”；2、”設(shè)定屏幕分辨率為800*1024時，屏幕不刷新”；10/12/202327如何有效描述缺陷-再現(xiàn)步驟對于如何再現(xiàn)缺陷提供了準(zhǔn)確的描述要求簡明但完全；不含糊且精確。多次重復(fù)。再現(xiàn)步驟：1、啟動編輯器，然后創(chuàng)建新文件2、輸入四行文本，重復(fù)輸入“thequickforjumpsoverthelazybrowndog”3、選中四行文本，然后選擇下拉菜單，并選擇Arial。4、所有文件讀被轉(zhuǎn)換為控制字符、數(shù)字和其他明顯的隨機(jī)二進(jìn)制數(shù)據(jù)。5、重復(fù)三次，結(jié)果都一樣。10/12/202328如何有效描述缺陷-隔離是指測試員用來確認(rèn)錯誤是一個真正的問題，并識別哪些影響錯誤表現(xiàn)的因素而收集的結(jié)果和信息。描述了錯誤的界限隔離：新建1.1.018；同樣的測試用例在從1.1.007到1.1.017上都通過。對Wingdings和Symbol字體重復(fù)相同的步驟。粗略估計是格式問題，保存文件，關(guān)閉編輯器并重新打開文件，但是數(shù)據(jù)仍然被破壞。在改變字體前保存文件防止錯誤。對現(xiàn)存文件，錯誤不再發(fā)生。只在Win98下發(fā)生，而不出現(xiàn)在Solaris，Mac或其他Windows系統(tǒng)10/12/202329如何有效描述缺陷-一個完整的實(shí)例概要：

Arial、Wingdings、Symbol字體會破壞新文件。再現(xiàn)步驟：

1、啟動編輯器，然后創(chuàng)建新文件

2、輸入四行文本，重復(fù)輸入“thequickforjumpsoverthelazybrowndog”3、選中四行文本，然后選擇下拉菜單，并選擇Arial。

4、所有文件讀被轉(zhuǎn)換為控制字符、數(shù)字和其他明顯的隨機(jī)二進(jìn)制數(shù)據(jù)。

5、重復(fù)三次，結(jié)果都一樣。隔離：新建1.1.018；同樣的測試用例在從1.1.007到1.1.017上都通過。對Wingdings和Symbol字體重復(fù)相同的步驟。粗略估計是格式問題，保存文件，關(guān)閉編輯器并重新打開文件，但是數(shù)據(jù)仍然被破壞。在改變字體前保存文件防止錯誤。對現(xiàn)存文件，錯誤不再發(fā)生。只在Win98下發(fā)生，而不出現(xiàn)在Solaris，Mac或其他Windows系統(tǒng)10/12/202330如何有效描述缺陷-十步驟過程結(jié)構(gòu):測試過程的Structure。再現(xiàn):三次再現(xiàn)缺陷。隔離:確定影響再現(xiàn)的變量。推廣:確定系統(tǒng)其他部分是否可能出現(xiàn)這種錯誤。比較:評審運(yùn)行相似測試的結(jié)果?？偨Y(jié):簡短描述客戶或用戶的質(zhì)量體驗(yàn)和觀察到的特征。壓縮:精簡不必要的信息，特別是冗余的測試步驟。去除歧義:使用清晰的語言。中立:公正地表達(dá)自己的意思，避免夸張、幽默、諷刺。評審:同行評審。10/12/202331如何跟蹤缺陷10/12/202332主題使用狀態(tài)來管理缺陷生命周期強(qiáng)調(diào)所有權(quán)和責(zé)任關(guān)鍵轉(zhuǎn)移10/12/202333使用狀態(tài)來管理缺陷生命周期不是每個組織都采用相同的缺陷生命周期。所定義的缺陷的狀態(tài)可能會不完全相同。定義的缺陷狀態(tài)缺陷狀態(tài)描述New新建缺陷Open被確認(rèn)并分配相關(guān)開發(fā)人員處理Fixed開發(fā)人員已確認(rèn)修改，等待測試人員處理Rejected拒絕修改缺陷Deferred被確認(rèn)，但延期修改缺陷Closed缺陷已被修復(fù)10/12/202334使用狀態(tài)來管理缺陷生命周期根據(jù)上面的狀態(tài)確定缺陷生命周期或工作流NewRejectedClosedFixedOpenedDeferred10/12/202335缺陷管理流程10/12/202336使用狀態(tài)來管理缺陷生命周期問題？狀態(tài)夠嗎？缺陷生命周期合理嗎？10/12/202337強(qiáng)調(diào)所有權(quán)和責(zé)任誰負(fù)責(zé)設(shè)置和改變?nèi)毕莸臓顟B(tài)？使用分配和估計修復(fù)日期跟蹤缺陷修復(fù)。跟蹤測試人員所有權(quán)，盡快完成回歸測試。10/12/202338關(guān)鍵轉(zhuǎn)移幾個問題？什么是再現(xiàn)錯誤現(xiàn)象要求的準(zhǔn)確性和最少步驟？這些步驟成功再現(xiàn)錯誤的幾率有多少？故障說明是測試錯誤還是系統(tǒng)錯誤？影響錯誤現(xiàn)象的外部因素是什么？問題的根本原因是什么？如何能修復(fù)問題，而不引入新問題？變化都正確地調(diào)試了嗎？問題修復(fù)了嗎？10/12/202339關(guān)鍵轉(zhuǎn)移測試人員開發(fā)人員測試小組開發(fā)小組缺陷報告缺陷修復(fù)1、我能再現(xiàn)故障嗎？2、測試錯誤還是系統(tǒng)錯誤？3、哪些因素影響了故障？4、根本原因是什么？5、如何不引入新問題的情況下修復(fù)缺陷？6、修復(fù)是否正確調(diào)試了？7、問題修復(fù)了嗎？現(xiàn)在系統(tǒng)能通過以前的測試嗎？系統(tǒng)的其余部分仍然正常工作嗎？錯誤報告和測試發(fā)布過程中的交互和勞動分工明確10/12/202340缺陷度量10/12/202341主題測試有效性度量缺陷度量缺陷數(shù)量產(chǎn)品缺陷缺陷消除率(DRE)缺陷齡期(潛伏期)（DefectAge）缺陷損耗缺陷密度10/12/202342測試有效性度量測試有效性度量分類客戶滿意度度量調(diào)查服務(wù)臺接到的電話缺陷度量測試中發(fā)現(xiàn)的缺陷客戶發(fā)現(xiàn)缺陷嚴(yán)重程度、潛伏期、密度、分布覆蓋度量代碼設(shè)計需求10/12/202343缺陷度量-缺陷數(shù)量用缺陷數(shù)量作為測試有效性度量的兩個問題所有的Bug并不都是均等的。有必要對bug進(jìn)行“加權(quán)”或采用影響等級分類。最初存在的數(shù)量對發(fā)現(xiàn)的bug數(shù)量由著重要的應(yīng)影響采用類似項(xiàng)目的比較來度量發(fā)現(xiàn)的缺陷數(shù)量時間項(xiàng)目A項(xiàng)目B10/12/202344缺陷度量-缺陷數(shù)量采用預(yù)測方式來度量預(yù)測總量預(yù)測量(P)與實(shí)際量(A)PAPAPAPAPA1月2月3月4月5月需求評審202014設(shè)計評審35501515代碼審查1206060單元測試80系統(tǒng)測試40驗(yàn)收測試10產(chǎn)品使用6個月后15總計32025141515606010/12/202345缺陷度量-產(chǎn)品缺陷在產(chǎn)品中或客戶發(fā)現(xiàn)的缺陷數(shù)量。測試員沒有發(fā)現(xiàn)的或者是在發(fā)布之前未修復(fù)的。10/12/202346缺陷度量-缺陷消除率(DRE)在我們可能發(fā)現(xiàn)的bug集合中，我們到底發(fā)現(xiàn)了多少bug?定義：DRE=未發(fā)現(xiàn)的Bug數(shù)量=客戶發(fā)現(xiàn)的bug數(shù)量測試期間發(fā)現(xiàn)的bug數(shù)量測試期間發(fā)現(xiàn)的Bug數(shù)量+未發(fā)現(xiàn)的bug數(shù)量10/12/202347缺陷度量-缺陷消除率(DRE)使用該度量，必須清楚以下幾點(diǎn)必須考慮Bug的嚴(yán)重程度和分布狀況。我們怎么才知道客戶到什么時候會發(fā)現(xiàn)所有的bug?這種度量是“馬后炮”性質(zhì)的度量。對當(dāng)前項(xiàng)目的測試有效性度量無意義，但有利于組織的測試有效性的長期趨勢度量。我們什么時候開始計算Bug?有些Bug在測試中發(fā)現(xiàn)不了！受測試環(huán)境的影響，發(fā)現(xiàn)不了的bug是否需要考慮度量。10/12/202348缺陷度量-缺陷消除率(DRE)提出需求設(shè)計代碼/單元測試集成測試系統(tǒng)測試驗(yàn)收測試產(chǎn)品200造成的Bug數(shù)量30306012013013011050100發(fā)現(xiàn)的bug數(shù)量80401002050DRE=(80+40+100+20+50+30)/(80+40+100+20+50+30+30)=91%系統(tǒng)測試的DRE=系統(tǒng)測試發(fā)現(xiàn)的bug數(shù)量/（系統(tǒng)測試發(fā)現(xiàn)的bug數(shù)量+驗(yàn)收測試和產(chǎn)品中發(fā)現(xiàn)的bug數(shù)量）=50/（50+30+30）=45%10/12/202349缺陷度量-缺陷潛伏期我們發(fā)現(xiàn)bug的時間越晚，這個bug所帶來的損害就越大，修復(fù)這個bug所耗費(fèi)的成本就越多。缺陷潛伏期尺度缺陷造成階段發(fā)現(xiàn)階段需求概要設(shè)計詳細(xì)設(shè)計編碼單元測試集成測試系統(tǒng)測試驗(yàn)收測試試點(diǎn)產(chǎn)品產(chǎn)品需求0123456789概要設(shè)計012345678詳細(xì)設(shè)計01234567編碼0123456總計10/12/202350缺陷度量-缺陷潛伏期項(xiàng)目缺陷的造成與發(fā)現(xiàn)示例造成階段發(fā)現(xiàn)階段需求概要設(shè)計詳細(xì)設(shè)計編碼單元測試集成測試系統(tǒng)測試驗(yàn)收測試試點(diǎn)產(chǎn)品產(chǎn)品總量需求084100562127概要設(shè)計09301312120詳細(xì)設(shè)計01534001831編碼0621662320109總計081319652114983018710/12/202351缺陷度量-缺陷損