新版缺陷管理專題知識(shí)宣講

本課教學(xué)目標(biāo)了解缺陷的嚴(yán)重級(jí)和優(yōu)先級(jí)分類正確理解缺陷跟蹤管理流程了解缺陷管理流程的要點(diǎn)正確理解缺陷數(shù)據(jù)分析的重要性1新版缺陷管理專題知識(shí)宣講2/16/2025課程內(nèi)容6.1軟件缺陷概念回顧6.2缺陷的嚴(yán)重性和優(yōu)先級(jí)6.3缺陷跟蹤管理6.4缺陷書寫規(guī)范6.5缺陷數(shù)據(jù)分析2新版缺陷管理專題知識(shí)宣講2/16/20256.1軟件缺陷概念回顧軟件缺陷的定義：（1）軟件未達(dá)到產(chǎn)品說明書中已經(jīng)標(biāo)明的功能；（2）軟件出現(xiàn)了產(chǎn)品說明書中指明不會(huì)出現(xiàn)的錯(cuò)誤；（3）軟件未達(dá)到產(chǎn)品說明書中雖未指出但應(yīng)當(dāng)達(dá)到的目標(biāo)；

（4）軟件功能超出了產(chǎn)品說明書中指明的范圍；（5）軟件測試人員認(rèn)為軟件難以理解、不易使用，或者最終用戶認(rèn)為該軟件使用效果不良。3新版缺陷管理專題知識(shí)宣講2/16/2025軟件缺陷概念回顧（續(xù)）軟件缺陷的特征：

“看不到”

——軟件的特殊性決定了缺陷不易看到“看到但是抓不到”

——發(fā)現(xiàn)了缺陷，但不易找到問題發(fā)生的原因所在4新版缺陷管理專題知識(shí)宣講2/16/2025軟件缺陷概念回顧（續(xù)）其他10%軟件產(chǎn)品說明書（需求）56%編寫代碼7%設(shè)計(jì)27%圖軟件缺陷產(chǎn)生的原因分布缺陷分布情況：5新版缺陷管理專題知識(shí)宣講2/16/2025

6.2軟件缺陷嚴(yán)重性和優(yōu)先級(jí)重要軟件缺陷會(huì)導(dǎo)致重大經(jīng)濟(jì)損失與災(zāi)難測試員應(yīng)對(duì)軟件缺陷分類，以簡明扼要的方式指出其影響，以及修改次序劃分軟件缺陷嚴(yán)重級(jí)和優(yōu)先級(jí)的通用原則表示軟件缺陷所造成的危害的惡劣程度優(yōu)先級(jí)表示修復(fù)缺陷的重要程度與次序6新版缺陷管理專題知識(shí)宣講2/16/2025

軟件缺陷嚴(yán)重性和優(yōu)先級(jí)（續(xù)）嚴(yán)重級(jí)嚴(yán)重：系統(tǒng)崩潰、數(shù)據(jù)丟失、數(shù)據(jù)損壞較嚴(yán)重：操作性錯(cuò)誤、錯(cuò)誤結(jié)果、遺漏功能一般：小問題、錯(cuò)別字、UI布局、罕見故障建議：不影響使用的瑕疵或更好的實(shí)現(xiàn)7新版缺陷管理專題知識(shí)宣講2/16/2025

軟件缺陷嚴(yán)重性和優(yōu)先級(jí)（續(xù)）優(yōu)先級(jí)最高優(yōu)先級(jí)：立即修復(fù)，停止進(jìn)一步測試次高優(yōu)先級(jí)：在產(chǎn)品發(fā)布之前必須修復(fù)中等優(yōu)先級(jí)：如果時(shí)間允許應(yīng)該修復(fù)最低等優(yōu)先級(jí)：可能會(huì)修復(fù)，不修復(fù)也能發(fā)布一般嚴(yán)重性和優(yōu)先級(jí)的劃分用數(shù)字１～４表示，有的小數(shù)字表示的級(jí)別最高，而有的用大數(shù)字表示級(jí)別高。另外嚴(yán)重級(jí)和優(yōu)先級(jí)的劃分并不唯一，可適當(dāng)修改8新版缺陷管理專題知識(shí)宣講2/16/2025缺陷等級(jí)劃分（SZSTC）等級(jí)描述說明5-緊急發(fā)現(xiàn)可重復(fù)出現(xiàn)的致命問題——導(dǎo)致系統(tǒng)崩潰；——導(dǎo)致程序模塊丟失；——主業(yè)務(wù)流程出現(xiàn)斷點(diǎn)；——內(nèi)存泄漏；——導(dǎo)致死機(jī)4-非常高發(fā)現(xiàn)可重復(fù)出現(xiàn)的嚴(yán)重問題——被測功能不能正確實(shí)現(xiàn)；——軟件錯(cuò)誤導(dǎo)致數(shù)據(jù)丟失；——被測數(shù)據(jù)處理錯(cuò)誤；——用戶需求未實(shí)現(xiàn)。3-高一般性的錯(cuò)誤或功能實(shí)現(xiàn)有不完美處——操作界面錯(cuò)誤；——打印內(nèi)容、格式錯(cuò)誤；——簡單的輸入限制未放在前臺(tái)進(jìn)行控制；——?jiǎng)h除操作未給出提示。2-中細(xì)小的錯(cuò)誤——界面不規(guī)范；——輔助說明描述不清楚；——輸入輸出不規(guī)范；——長操作未給用戶提示；——提示窗口文字未采用行業(yè)術(shù)語。1-低建議類錯(cuò)誤需求說明書、用戶手冊(cè)中未說明，但影響用戶對(duì)軟件使用的方便性等9新版缺陷管理專題知識(shí)宣講2/16/2025問題與討論請(qǐng)將自己的缺陷定義等級(jí)劃分10新版缺陷管理專題知識(shí)宣講2/16/2025

6.３軟件缺陷跟蹤管理6.3.1缺陷跟蹤管理目標(biāo)6.3.2缺陷跟蹤管理6.3.3軟件缺陷的狀態(tài)6.3.4缺陷管理流程6.3.5缺陷流程管理原則11新版缺陷管理專題知識(shí)宣講2/16/2025

6.3.1缺陷跟蹤管理目標(biāo)確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被解決

（修正或其他處理方式）收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識(shí)別測試過程的階段

收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過程財(cái)富12新版缺陷管理專題知識(shí)宣講2/16/2025

6.3.2缺陷跟蹤管理為了正確跟蹤每個(gè)軟件缺陷的處理過程，通常將軟件測試發(fā)現(xiàn)的每個(gè)錯(cuò)誤作為一條條記錄輸入指定的錯(cuò)誤跟蹤管理系統(tǒng)目前的缺陷跟蹤管理軟件包括：ClearQuest(IBM)TestDirector(MercuryInterative)Bugzilla(很重要自己學(xué)習(xí)一下)13新版缺陷管理專題知識(shí)宣講2/16/2025缺陷跟蹤管理（續(xù)）作為一個(gè)缺陷跟蹤管理系統(tǒng)，需要正確的記錄錯(cuò)誤信息和錯(cuò)誤處理信息的全部內(nèi)容Bug記錄信息測試軟件名稱測試版本號(hào)測試人名稱測試用例標(biāo)題測試軟件和硬件配置環(huán)境發(fā)現(xiàn)軟件錯(cuò)誤的類型錯(cuò)誤嚴(yán)重等級(jí)詳細(xì)步驟必要的附圖發(fā)生錯(cuò)誤的模塊…Bug處理信息

處理者姓名處理時(shí)間處理步驟缺陷記錄的當(dāng)前狀態(tài)14新版缺陷管理專題知識(shí)宣講2/16/2025軟件缺陷的主要狀態(tài)包括以下的內(nèi)容新建(New)： 測試中新報(bào)告的軟件缺陷；打開(Open)： 被確認(rèn)并分配給相關(guān)開發(fā)人員處理；修正(Fixed)： 開發(fā)人員已完成修正，等待測試人員驗(yàn)證；拒絕(Declined)： 拒絕修改缺陷；延期(Deferred)： 不在當(dāng)前版本修復(fù)的錯(cuò)誤，下一版修復(fù)關(guān)閉(Closed)： 錯(cuò)誤已被修復(fù)。

6.3.3軟件缺陷狀態(tài)15新版缺陷管理專題知識(shí)宣講2/16/2025測試人員提交新發(fā)現(xiàn)的缺陷入庫，缺陷狀態(tài)為“New”高級(jí)測試人員驗(yàn)證錯(cuò)誤如果確認(rèn)是錯(cuò)誤，則分配給相應(yīng)的開發(fā)人員，設(shè)置狀態(tài)為“Open”如果不是錯(cuò)誤，則拒絕，設(shè)置為“Declined”狀態(tài)開發(fā)人員查詢狀態(tài)為“Open”的缺陷，對(duì)其進(jìn)行處理如果不是錯(cuò)誤，則狀態(tài)置為“Declined”如果是錯(cuò)誤，則修復(fù)并置狀態(tài)為“Fix”如果不能解決，要留下文字說明并保持缺陷狀態(tài)仍為“Open”對(duì)于不能解決或者延期解決的缺陷，不能由開發(fā)人員自己決定，一般要通過某種會(huì)議（評(píng)審會(huì)）才能認(rèn)可測試人員查詢狀態(tài)為“Fix”的缺陷，驗(yàn)證缺陷是否已解決，做如下處理如果問題解決了，置缺陷的狀態(tài)為“Closed”如果問題沒有結(jié)果，則置狀態(tài)為“Reopen”

6.3.4缺陷管理流程16新版缺陷管理專題知識(shí)宣講2/16/2025問題與討論請(qǐng)以缺陷管理流程圖的形式描述自己平時(shí)工作中的缺陷管理流程（包括涉及到的人物角色，缺陷狀態(tài)和工作方式）OpenResolvedVerifiedClosedClose（缺陷評(píng)審委員會(huì)）Reopen（測試人員）Resolve（程序員）Verify（測試工程師）Close（測試工程師）Reopen（測試人員）17新版缺陷管理專題知識(shí)宣講2/16/2025缺陷流程管理應(yīng)遵循以下原則為了保證錯(cuò)誤的正確性，需要有豐富測試經(jīng)驗(yàn)的測試人員驗(yàn)證發(fā)現(xiàn)的錯(cuò)誤是否是真正的錯(cuò)誤，書寫的測試步驟是否準(zhǔn)確，可以重復(fù)。每次對(duì)錯(cuò)誤的處理都要保留處理信息，包括處理姓名，時(shí)間，處理方法，處理意見，Bug狀態(tài)。拒絕或延期錯(cuò)誤不能由程序員單方面決定，應(yīng)該由項(xiàng)目經(jīng)理，測試經(jīng)理和設(shè)計(jì)經(jīng)理共同決定。錯(cuò)誤修復(fù)后必須由報(bào)告錯(cuò)誤的測試人員驗(yàn)證后，確認(rèn)已經(jīng)修復(fù)，才能關(guān)閉錯(cuò)誤。加強(qiáng)測試人員與程序員的交流，對(duì)于某些不能重復(fù)的錯(cuò)誤，可以請(qǐng)測試人員補(bǔ)充詳細(xì)的測試步驟和方法，以及必要的測試用例。

缺陷管理流程要點(diǎn)18新版缺陷管理專題知識(shí)宣講2/16/20256.4缺陷書寫規(guī)范（一）標(biāo)題：應(yīng)保持簡短、準(zhǔn)確，提供缺陷的本質(zhì)信息盡量按缺陷發(fā)生的原因與結(jié)果的方式書寫；避免使用模糊不清的詞語，例如：“功能中斷，功能不正確，行為不起作用”等。應(yīng)該使用具體文字說明缺陷的癥狀；為了便于他人理解，避免使用術(shù)語、俚語或過分具體的測試細(xì)節(jié)。復(fù)現(xiàn)步驟：應(yīng)包含如何使別人能夠很容易的復(fù)現(xiàn)該缺陷的完整步驟。為了達(dá)到這個(gè)要求，復(fù)現(xiàn)步驟的信息必須是完整的、準(zhǔn)確的、簡明的、可復(fù)現(xiàn)的。常見問題：包含了過多的多余步驟，且句子結(jié)構(gòu)混亂，可讀性差，難以理解；包含的信息過少，丟失了操作的必要步驟；沒有對(duì)軟件缺陷發(fā)生的條件和影響區(qū)域進(jìn)行隔離。19新版缺陷管理專題知識(shí)宣講2/16/2025復(fù)現(xiàn)步驟的正確書寫方式：提供測試的環(huán)境信息；簡單地一步步引導(dǎo)復(fù)現(xiàn)該缺陷，一個(gè)步驟包含的操作不要多；每個(gè)步驟前使用數(shù)字對(duì)步驟編號(hào)；盡量使用短語或短句，避免復(fù)雜句型句式；復(fù)現(xiàn)的步驟要完整、準(zhǔn)確、簡短；將常見步驟合并為較少步驟；按實(shí)際需要決定是否包含步驟執(zhí)行后的結(jié)果。實(shí)際結(jié)果：是執(zhí)行復(fù)現(xiàn)步驟后軟件的現(xiàn)象和產(chǎn)生的行為。實(shí)際結(jié)果的描述應(yīng)向標(biāo)題信息那樣，要列出具體的缺陷癥狀，而不是簡單地指出“不正確”或“不起作用”。6.4缺陷書寫規(guī)范（二）20新版缺陷管理專題知識(shí)宣講2/16/2025期望結(jié)果：描述應(yīng)與實(shí)際結(jié)果的描述方式相同。通常需要列出期望的結(jié)果是什么。附件：對(duì)缺陷描述的補(bǔ)充說明，可以是以下一些類型：缺陷癥狀的截圖；測試使用的數(shù)據(jù)文件；缺陷交流的記錄，例如相關(guān)郵件等；解決缺陷的補(bǔ)丁程序其它：選擇合適的缺陷嚴(yán)重性屬性；按相應(yīng)的規(guī)定，填寫相應(yīng)的字段信息6.4缺陷書寫規(guī)范（三）21新版缺陷管理專題知識(shí)宣講2/16/2025避免常見的錯(cuò)誤：避免使用我、你等人稱代詞，可以直接使用動(dòng)詞或必要時(shí)使用“用戶”代替避免使用情緒化的語言和強(qiáng)調(diào)符號(hào)；避免使用諸如“似乎”、“看上去可能”等含義模糊的詞匯，而需要報(bào)告確定的缺陷結(jié)果；避免使用自認(rèn)為比較幽默的語句，只需客觀地描述缺陷的信息；避免提交不確定的測試問題，自己至少需要重現(xiàn)一次再提交。6.4缺陷書寫規(guī)范（四）上海人：哪能查詢到的結(jié)果和查詢條件不搭噶的。北京人：哥們好不容易輸入一堆個(gè)人詳細(xì)信息后，點(diǎn)擊保存后全瞎了。22新版缺陷管理專題知識(shí)宣講2/16/2025問題與討論請(qǐng)指出下面這個(gè)缺陷的不足之處23新版缺陷管理專題知識(shí)宣講2/16/2025問題與討論請(qǐng)修改自己的缺陷描述24新版缺陷管理專題知識(shí)宣講2/16/20256.5缺陷數(shù)據(jù)分析6.5.1缺陷數(shù)據(jù)分析關(guān)注的問題6.5.2缺陷數(shù)據(jù)分析的重要性6.5.3缺陷數(shù)據(jù)分析的數(shù)據(jù)指標(biāo)25新版缺陷管理專題知識(shí)宣講2/16/20256.5.1缺陷數(shù)據(jù)分析關(guān)注的問題正在測試的軟件哪個(gè)模塊的問題最多？測試人員中誰報(bào)告的軟件缺陷最多？各類缺陷所占的數(shù)量百分比分別是多少？開發(fā)人員能及時(shí)修復(fù)軟件缺陷嗎？開發(fā)人員一次正確修復(fù)缺陷的百分比是多少？正在開發(fā)的軟件能否在計(jì)劃的時(shí)間內(nèi)正常發(fā)布？。。。26新版缺陷管理專題知識(shí)宣講2/16/20256.5.2缺陷數(shù)據(jù)分析的重要性統(tǒng)計(jì)未修復(fù)的缺陷數(shù)目（特別是嚴(yán)重性高的缺陷），預(yù)計(jì)軟件是否可以如期發(fā)布。分析缺陷的類型分布，發(fā)現(xiàn)存在較多缺陷的程序模塊，找出原因，進(jìn)行軟件開發(fā)過程改進(jìn)。根據(jù)測試人員報(bào)告缺陷的數(shù)量和準(zhǔn)確性，評(píng)估測試有效性和測試技能。根據(jù)報(bào)告的缺陷修復(fù)是否及時(shí)，改進(jìn)軟件開發(fā)與測試的關(guān)系，使測試與開發(fā)更有機(jī)的配合。27新版缺陷管理專題知識(shí)宣講2/16/20256.5.3缺陷數(shù)據(jù)分析的數(shù)據(jù)指標(biāo)每天/周報(bào)告的新缺陷數(shù)目；每天/周修復(fù)的缺陷數(shù)；累計(jì)報(bào)告的缺陷數(shù)目；累計(jì)修復(fù)的缺陷數(shù)；不同嚴(yán)重性類型的缺陷數(shù)；程序模塊與發(fā)現(xiàn)的缺陷的對(duì)應(yīng)關(guān)系；。。。28新版缺陷管理專題知識(shí)宣講2/16/20256.5.4不同軟件組織的缺陷管理過程個(gè)體行為處于CMM第一級(jí)（或稱為初始級(jí)）的軟件組織，對(duì)軟件缺陷的管理無章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相應(yīng)的軟件。通常，沒有人會(huì)去記錄自己發(fā)現(xiàn)的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測試中才有可能知道那些所謂已被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。所以這樣的軟件組織的項(xiàng)目交貨期（ReleaseDate）表現(xiàn)出強(qiáng)烈的不可預(yù)測性。并且，為了獲得一個(gè)高質(zhì)量的軟件產(chǎn)品（如果能夠的話），通常要在測試上花費(fèi)大量的人力。29新版缺陷管理專題知識(shí)宣講2/16/20256.5.4不同軟件組織的缺陷管理過程(續(xù))項(xiàng)目行為在CMM第二級(jí)（或稱為可重復(fù)級(jí)）的軟件組織中，軟件項(xiàng)目會(huì)從自身的需要出發(fā)，制定本項(xiàng)目的缺陷管理過程。一個(gè)完備軟件缺陷管理過程通常會(huì)包括如下幾個(gè)方面：

（1）提交缺陷

（2）分析和定位缺陷

（3）提請(qǐng)修改相應(yīng)的軟件

（4）修改相應(yīng)的軟件

（5）驗(yàn)證修改項(xiàng)目組會(huì)完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺陷的修改過程，并驗(yàn)證修改缺陷的結(jié)果。30新版缺陷管理專題知識(shí)宣講2/16/20256.5.4不同軟件組織的缺陷管理過程(續(xù))組織行為

CMM第三級(jí)（或稱為已定義級(jí)）的軟件組織會(huì)匯集組織內(nèi)部以前項(xiàng)目的經(jīng)驗(yàn)教訓(xùn)，制定組織級(jí)的缺陷管理過程。并且，要求項(xiàng)目根據(jù)組織級(jí)的缺陷管理過程定制本項(xiàng)目的缺陷管理過程。從而，整個(gè)軟件組織中的項(xiàng)目都遵循類似的過程來管理缺陷。好的缺陷管理實(shí)踐成為所有項(xiàng)目的實(shí)踐，而教訓(xùn)也為所有項(xiàng)目所了解。更重要的是，隨著組織的不斷發(fā)展完善，組織的過程會(huì)得到持續(xù)性的改進(jìn)，所有項(xiàng)目的過程也都會(huì)相應(yīng)的改進(jìn)。31新版缺陷管理專題知識(shí)宣講2/16/20256.5.4不同軟件組織的缺陷管理過程(續(xù))量化管理

CMM第四級(jí)（或稱為已管理級(jí)）的軟件組織會(huì)根據(jù)已收集的缺陷數(shù)據(jù)，采用SPC的方法建立軟件過程能力基線（ProcessCapabilityBaseline）。對(duì)于缺陷管理，可以缺陷密度為例，過程能力基線通常包括期望（Mean），