缺陷管理指引講解

缺陷管理指南北京博微廣華科技有限公司（版權(quán)所有，翻版必究）

變更記錄版本修改條款修改內(nèi)容修改人/日期批準人/日期1.0.0正式版郝海鳳20141128第1頁共18頁目錄TOC\o"1-5"\h\z\o"CurrentDocument"目的 3\o"CurrentDocument"適用范圍 3\o"CurrentDocument"缺陷定義 3缺陷產(chǎn)生的原因 3缺陷的定義 4\o"CurrentDocument"缺陷報告 4\o"CurrentDocument"缺陷類型 5\o"CurrentDocument"缺陷的嚴重程度 7\o"CurrentDocument"缺陷的優(yōu)先級 10\o"CurrentDocument"缺陷描述 11缺陷跟蹤 12缺陷的生命周期 12\o"CurrentDocument"缺陷狀態(tài)的跟蹤 14\o"CurrentDocument"缺陷結(jié)果分析 15第2頁共18頁1.目的本文對規(guī)范缺陷上報、缺陷的處理流程及缺陷分析進行詳細說明 ，以提高測試效率，確保軟件測試目的的實現(xiàn)。.適用范圍1）軟件項目集成測試階段（即軟件開發(fā)階段的測試）、系統(tǒng)測試階段和系統(tǒng)維護階段。2）能驗證階段。3）客戶反饋的問題。.缺陷定義缺陷產(chǎn)生的原因1）軟件項目自身問題引起的軟件需求定義不夠清晰，導(dǎo)致設(shè)計目標偏離客戶的需求。軟件系統(tǒng)結(jié)構(gòu)非常復(fù)雜而又無法構(gòu)造成一個有序的層次結(jié)構(gòu)或者組件結(jié)構(gòu)，從而導(dǎo)致很多意想不到的問題。新技術(shù)的應(yīng)用導(dǎo)致涉及技術(shù)和兼容性的問題事先沒有考慮周到。2）軟件項目管理的問題項目計劃不夠完善，對質(zhì)量、資源、任務(wù)、成本的平衡性把握不好，容易壓縮需求分析、評審、測試的時間從而遺留較多缺陷。項目流程不夠完善，存在較多的隨機性和缺乏嚴謹?shù)膬?nèi)審和評審機制。溝通不夠流暢，導(dǎo)致不同階段、不同團隊的開發(fā)人員對問題的理解不一致。第3頁共18頁

缺陷的定義從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品在需求定義，開發(fā)設(shè)計過程中所存在的錯誤。從外部看，缺陷就是軟件項目在某種程度上不能滿足用戶的需要。.缺陷報告為了準確、清楚地描述缺陷，現(xiàn)定義軟件缺陷的屬性，如下表所示:類別屬性名稱是否必填含義并簡要說明可跟蹤信息缺陷ID自動生成缺陷的唯一標識，用于識別、跟蹤、查詢、排序、存儲管理等。一般使用數(shù)字序號表示基本描述信息摘要必填對缺陷的概括性描述，方便列表、瀏覽、管理等詳細描述必填包括測試前提、操作步驟、預(yù)期結(jié)果和實際結(jié)果等測試環(huán)境必填缺陷發(fā)現(xiàn)時所處的測試環(huán)境，包括操作系統(tǒng)和IE所屬模塊必填缺陷所屬模塊，以及模塊下的組件，方便缺陷統(tǒng)計分析檢測版本必填缺陷發(fā)現(xiàn)于產(chǎn)品的哪個版本狀態(tài)自動默認缺陷默認為“新建”狀態(tài)，根據(jù)缺陷的修改情況，更改為相應(yīng)的狀態(tài)測試階段必填測試所處的階段，包括功能驗證、集成測試、第4頁共18頁

系統(tǒng)測試、系統(tǒng)維護修正所需信息嚴重程度必填指的是缺陷對軟件質(zhì)量的破壞程度，一般分為“嚴重”，“一般”，“輕微”三種程度優(yōu)先級必填指解決軟件缺陷的先后順序，即哪些缺陷需要優(yōu)先解決，哪些缺陷可以稍后解決。一般分為“緊急”，“高”，“中”，“低”四種級別缺陷類型必填屬于哪方面的缺陷。如功能、需求、數(shù)據(jù)內(nèi)容錯誤、用戶界面、建議性、刷新問題、性能、安裝兼容性、穩(wěn)定性問題、安全性問題可重現(xiàn)頻率必填缺陷產(chǎn)生的頻率。包括每次、較局、較低創(chuàng)建者自動默認新建缺陷的人員，根據(jù)缺陷管理系統(tǒng)的登錄用戶名自動默認檢測者必填檢測確認缺陷的人員。檢測者默認為創(chuàng)建者，如需重新打開缺陷，則將檢測者修改為當前人員分配給可選指派給缺陷下一操作的人員檢測時間自動默認默認為提交缺陷時的當前系統(tǒng)時間關(guān)閉于版本可選確認缺陷已經(jīng)被成功解決時的版本信息缺陷類型描述功能功能實現(xiàn)錯誤或者未實現(xiàn)，功能控制錯誤第5頁共18頁

需求需求規(guī)格說明書中存在的問題1）需求設(shè)計有誤2）軟件中使用的模板，資源，編碼（項目劃分編碼，WBS編碼）錯誤3）需求設(shè)計不完備4）軟件默認值設(shè)置錯誤5）小數(shù)位數(shù)控制數(shù)據(jù)內(nèi)容錯誤軟件中動態(tài)讀取的值錯誤，如數(shù)據(jù)計算錯誤，數(shù)據(jù)誤差，變量調(diào)用錯誤，報表數(shù)據(jù)錯誤建議性提出關(guān)于軟件功能實現(xiàn)不合理，提高軟件易用性的建議性意見刷新問題數(shù)據(jù)刷新，內(nèi)容刷新，界面刷新等問題用戶界面軟件界面布局/、合理軟件中靜態(tài)讀取的值錯誤，如界面錯別字界面信息顯示不全安裝兼容性1）安裝過程中出現(xiàn)的問題，如：安裝向?qū)栴}，安裝義件問題2）卸載過程中出現(xiàn)的問題，如：卸載后用戶工程被刪除3）成功安裝后與軟件環(huán)境或硬件環(huán)境不兼容引起的問題，如：需求中明確要求兼谷win/系統(tǒng)，但是軟件不能在win7下安裝成功；在特定的配飾下軟件崩潰。第6頁共18頁穩(wěn)定性問題軟件長時間使用過程中，軟件異常退出內(nèi)存、GDI存在泄漏等安全性問題軟件鎖權(quán)限控制問題，如：資源控制，節(jié)點數(shù)量控制用戶權(quán)限控制問題數(shù)據(jù)安全問題，如用戶密碼顯示為明文；性能不滿足系統(tǒng)提出的性能指標，如：右鍵功能響應(yīng)時間超出需求制止的指標；生成報表時間超出需求制止的指標“缺陷類型等級”的概念，當一個缺陷同時符合幾個缺陷類型的特征時， 其缺陷類型以“缺陷類型等級”較高的類型為準。建議缺陷類型等級如下（' >'左側(cè)表示等級高）：安全性問題>穩(wěn)定性問題>性能>需求>數(shù)據(jù)內(nèi)容錯誤>安裝兼容性>刷新問題>用戶界面>建議性>功能缺陷的嚴重程度Bug的嚴重級別指的是軟件缺陷對軟件質(zhì)量的破壞程度嚴重：軟件缺陷對軟件質(zhì)量的破壞程度嚴重。主要包括以下幾種情況：體功能正常操作實現(xiàn)錯誤或者未實現(xiàn)。主體功能即系統(tǒng)的本質(zhì)特征，是必不可少的。即主界面各模塊內(nèi)包含的功能。2）需求設(shè)計錯誤或不完備：需求規(guī)格說明書中設(shè)計或者考慮不全面導(dǎo)致的錯誤，如：業(yè)務(wù)流程不正確，需求邏輯錯誤等。3）數(shù)據(jù)錯誤：主要為數(shù)據(jù)讀取錯誤，數(shù)據(jù)計算錯誤，如：變量數(shù)據(jù)，報表第7頁共18頁數(shù)據(jù)調(diào)用錯誤或計算錯誤。錄入的資源數(shù)據(jù)錯誤（原價，單價，單重等） 。4）權(quán)限及安全問題。用戶密碼是否泄漏，權(quán)限控制是否得當。一般：軟件缺陷對軟件質(zhì)量的破壞程度一般主要包括以下幾種情況：1）輔助功能正常操作實現(xiàn)錯誤或者未實現(xiàn)。輔助功能即完善或輔助主體功能實現(xiàn)的一些功能點。即菜單欄，工具欄的功能。2）數(shù)據(jù)內(nèi)容刷新：對軟件進行修改后無法及時更新，通過切換界面或執(zhí)行某些軟件操作后，軟件刷新到正確狀態(tài)。a.數(shù)據(jù)刷新：當存在數(shù)據(jù)聯(lián)動時，修改其中一個數(shù)據(jù)，與之聯(lián)動的其他數(shù)據(jù)未及時發(fā)生更新。b.內(nèi)容刷新：多個界面都調(diào)用同一字段值，修改其中一個，其他界面未及時發(fā)生變動。如：在工程管理中對工程進行重命名，結(jié)果項目屬性，報表中調(diào)用的仍然為舊值。3）數(shù)據(jù)誤差：軟件計算結(jié)果與實際計算結(jié)果存在誤差。如：不同界面同一變量的數(shù)據(jù)精度控制不一致，如：“材料費”在不同界面調(diào)用，控制的小數(shù)位數(shù)不一致，a界面為0.1234,b界面為0.123,最后導(dǎo)致同一變量含義在不同報表體現(xiàn)的值不一致；數(shù)據(jù)四舍五入不正確。如：0.045枳.04。4）內(nèi)容錯誤：主要為字段內(nèi)容讀取錯誤，如：工程名稱，電壓等級等字段內(nèi)容讀取錯誤。軟件中使用的模板，資源內(nèi)容（代碼，名稱，單位等），編碼（項目劃分編碼，WBS編碼）錯誤。5）輸入控制錯誤。需求中明確某個字段不能輸入。包括輸入字符類型的控第8頁共18頁制，輸入字節(jié)數(shù)的控制，如：“比例”字段可以輸入中文；小數(shù)位數(shù)可輸入無限位。6）性能指標無法達到。性能達不到需求制定的指標，如：打開有500條工程量的工程，花費30分鐘，需求定義為10分鐘。7）軟件安裝卸載問題。覆蓋安裝后無法進入程序或進入程序后報錯； 安裝的控件版本錯誤；卸載過程中出現(xiàn)的問題，如：卸載后用戶工程被刪除。8）軟件兼容性問題。軟件在不同系統(tǒng)下安裝使用出錯；與其他軟件存在兼容性錯誤等。9）穩(wěn)定性問題。軟件長時間使用過程中，軟件異常報錯或者內(nèi)存、 GDI存在泄漏等。如：對軟件不進行任何操作，內(nèi)存或GDI數(shù)量一直增長。10）功能異常操作，超出需求定義的范圍，如添加10級項目劃分，軟件異常退出；手工斷電，軟件崩潰。輕微：軟件缺陷對軟件質(zhì)量的破壞程度輕微主要包括以下幾種情況：1）信息提示框問題。指提示框內(nèi)的信息不正確，如：輸入空字符提示“數(shù)據(jù)錄入不合法”，應(yīng)提示為“***不能為空”。2）界面顯示問題。包括按鈕未對齊，圖片無法加載，內(nèi)容顯示不全或者有錯別字，界面刷新問題等。在特定的系統(tǒng)下，無法顯示完全。3）建議性問題，功能不合理，功能操作易用性的建議。如：顯示的內(nèi)容建議進行排序；功能的快捷鍵實現(xiàn)。4）軟件默認值設(shè)置錯誤。如：工程稅金默認值錯誤，實際結(jié)果為 5,預(yù)期結(jié)果應(yīng)為3.41第9頁共18頁注：無法重現(xiàn)的缺陷，在原定等級的基礎(chǔ)上下降一級缺陷的優(yōu)先級缺陷的優(yōu)先級一一解決軟件缺陷的先后順序，即哪些缺陷需要優(yōu)先解決，哪些缺陷可以稍后解決。確定軟件缺陷優(yōu)先級，更多的是站在客戶使用的角度考慮問題，同時需要考慮問題修改的成本與時間。主要包括以下情況：緊急一一缺陷導(dǎo)致系統(tǒng)幾乎不能使用或者測試無法繼續(xù)， 需要立即修復(fù)。如:點擊新建工程軟件報錯高一一軟件功能沒有實現(xiàn)或者沒有正確實現(xiàn)，對軟件的使用效果影響比較大。必須修改，需確定在集成測試階段內(nèi)某個特定里程碑結(jié)束前修正。如：工程新建成功后，無法讀取新建工程向?qū)е休斎氲膮?shù)；中一一軟件功能實現(xiàn)不合理，對軟件的使用效果影響一般。必須修改，不一定馬上修改，系統(tǒng)測試階段之前必須修正。如：新建工程向?qū)е?，輸入?yún)?shù)執(zhí)行“下一步”，再執(zhí)行“上一步”輸入的參數(shù)未保存缺一一對軟件的使用效果影響非常小，缺陷不解決的情況下不影響軟件正常使用，在時間允許的情況下，考慮盡量解決。如：工程新建成功后，彈出的提示信息框顯示不全優(yōu)先級設(shè)置說明：1）在軟件正常操作的情況下，軟件出現(xiàn)的錯誤，缺陷的優(yōu)先級可以定義為“中”及以上。2）在軟件異常操作的情況下，（如特殊字符的輸入，超長字符的輸入，文件格式或軟件配置的任意更改），軟件出現(xiàn)的錯誤，缺陷的優(yōu)先級可以定義為“中”及以下第10頁共18頁一般來說，嚴重級別高的bug具有較高的優(yōu)先處理級別，但是嚴重級別和優(yōu)先級并不總是一一對應(yīng)。有時候嚴重級別高的 Bug優(yōu)先級不一定高，而一些嚴重級別低的Bug卻需要及時處理，具有較高的優(yōu)先級。例如，軟件崩潰只在某種非常極端的條件下才會產(chǎn)生，那么此缺陷的優(yōu)先級別可以定義為“低” o缺陷描述1）缺陷描述簡要法則檢測人員：WHO——描述缺陷的時候應(yīng)該明確缺陷的檢測者。檢測結(jié)果：WHAT——使用陳述句簡明扼要的描述bug摘要。檢測環(huán)境：WHERE——檢測到缺陷時所處的環(huán)境，包括操作系統(tǒng)以及當前系統(tǒng)中安裝的其他軟件；缺陷所屬的模塊或組件檢測時間：WHEN——檢測到缺陷的時間。缺陷產(chǎn)生原因：WHY——分析缺陷產(chǎn)生的原因，可以補充到注釋中。操作步驟：HOW——描述可重現(xiàn)bug的有效步驟?？梢詧D形表現(xiàn)缺陷的則必須采用附件的形式附上截圖。出錯的工程則有必要附上工程。2）缺陷描述說明單一準確。每個報告只針對一個軟件缺陷。在一個報告中報告多個缺陷的弊端是缺陷常常只是部分被修復(fù)而不能得到徹底解決?？梢栽佻F(xiàn)。提供缺陷產(chǎn)生的準確操作步驟，使開發(fā)人員容易看懂并能自己再現(xiàn)缺陷，開發(fā)人員只有看懂了才可能有效的解決缺陷。完整統(tǒng)一。提供完整、前后統(tǒng)一的軟件缺陷產(chǎn)生的步驟和信息，例如：圖片信息，LOG文件等?？紤]到網(wǎng)絡(luò)數(shù)據(jù)傳輸效率，截圖的文件格式須使用JPG第11頁共18頁格式在截圖中建議使用三號粗線，顏色設(shè)置為紅色將出錯的地方標識出來。短小簡練。通過使用關(guān)鍵詞，可以使軟件缺陷的摘要短小簡練又能準確的描述缺陷產(chǎn)生的現(xiàn)象。如“PDA在上傳下載的時候出現(xiàn)了死機的現(xiàn)象”中的“PDA”，“上傳下載”，“死機”等是關(guān)鍵詞。描述的操作步驟，自己要先分析填寫的操作步驟是否與提交的缺陷有關(guān)聯(lián)，描述并不是越詳細越好，而是要有效的信息。特定條件。許多軟件功能在通常情況下是沒有問題而是在某種特定條件下才會產(chǎn)生缺陷。所以軟件缺陷的描述中不要忽視這些看似細節(jié)但又是必要的特定條件（如特定的操作步驟，特定的設(shè)置等條件），這些條件是幫助開發(fā)人員找到原因的線索。不做評價。在描述軟件的缺陷過程中不要帶有個人的觀點，不要對開發(fā)人員進行評價。軟件的缺陷報告只是針對產(chǎn)品，針對問題本身。在報告缺陷的過程中只需要將事實或者現(xiàn)象客觀描述出來即可，不需要任何評價。缺陷描述格式化。所屬模塊或功能點=>缺陷現(xiàn)象=>測試步驟=>預(yù)期結(jié)果=>實際結(jié)果=>其它信息，可依實際情況調(diào)整。測試步驟超過兩個步驟時用序號分開描述；針對描述內(nèi)容為功能名稱或報表名稱等，建議使用雙引號括起來。.缺陷跟蹤缺陷的生命周期新建：提交缺陷的初始狀態(tài)打開：問題經(jīng)確認后確實存在第12頁共18頁已解決：被相關(guān)人員成功修復(fù)的缺陷無效bug:根據(jù)事實依據(jù)，確認不是缺陷延期：由于時間或者技術(shù)等方面的原因，同時考慮到修改此缺陷而帶來的風(fēng)險，需要延期解決重復(fù)：該缺陷與缺陷管理系統(tǒng)中已有的缺陷含義相同不做處理：由于技術(shù)或者其他原因無法修復(fù)重新打開：已解決的缺陷依然存在或者未得到徹底解決，需要進一步修正關(guān)閉：缺陷確認已經(jīng)被成功修復(fù)，不再存在有爭議：對于缺陷的處理方式，檢測者與確認者存在歧義無法重現(xiàn)：確認缺陷的時候，無法重現(xiàn)缺陷中描述的現(xiàn)象第13頁共18頁缺陷狀態(tài)的跟蹤開發(fā)人員「所有業(yè)務(wù)類型的bug全部由業(yè)務(wù)組長確認分配類型的bug全部由開發(fā)組長確認分配1F業(yè)務(wù)詛長進彳TBU型理藍線一一開發(fā)人員處理紅線一一業(yè)務(wù)人員處理黑線一一開發(fā)人員「所有業(yè)務(wù)類型的bug全部由業(yè)務(wù)組長確認分配類型的bug全部由開發(fā)組長確認分配1F業(yè)務(wù)詛長進彳TBU型理藍線一一開發(fā)人員處理紅線一一業(yè)務(wù)人員處理黑線一一測試人員處理黑粗線一一主要流程檢測者所有非業(yè)R開發(fā)組長進行BU型理測與認意不一檢者確者見統(tǒng)歸試陷底修

一回測缺徹被重新打開■宏強以外是ug開人旃該陷b-測員為須理

檢人認必處“新建”狀態(tài)的bug,根據(jù)其缺陷類型，業(yè)務(wù)類型的bug由業(yè)務(wù)組長進行確認分配，所有非業(yè)務(wù)類型的bug由開發(fā)組長進行確認分配。開發(fā)組長判定為“延期”的bug，檢測者根據(jù)項目實際情況可以“重新打開”開發(fā)組長判定“打開”的bug,同時分配開發(fā)人員進行修正，修正完畢后由開發(fā)人員將其狀態(tài)置為“已解決”。對于置為“無法重現(xiàn)”、“重復(fù)”、“不做處理”、“無效bug”的缺陷，檢測者進行驗證后，如意見一致，則在軟件發(fā)布后將其置為“已關(guān)閉”，否則將其置為“有爭議”。針對“有爭議”的缺陷，測試組長提出處理方案，供項目組內(nèi)參考第14頁共18頁檢測者對開發(fā)人員置為“已解決”的bug進行回歸測試，確認問題解決后，根據(jù)“誰新建/重新打開bug,誰負責(zé)關(guān)閉”的原則，由檢測者將bug置為“關(guān)閉”狀態(tài)；回歸測試中，發(fā)現(xiàn)問題沒有解決或者解決不徹底時，將bug置為“重新打開”狀態(tài)。確認缺陷“已解決”，“關(guān)閉”時應(yīng)該標記解決的版本號。將缺陷設(shè)置為“無效bug”，“延期”，“不做處理”，“重新打開”，“有爭議”，相關(guān)人員必須添加注釋。分別在集成測試階段結(jié)束時和系統(tǒng)測試階段結(jié)束時，對于“有爭議”、“不做處理”、“延期”的BUG,項目組需經(jīng)過討論后得出處理結(jié)果，由項目組長確定最終處理方式。已關(guān)閉的BUG,在后續(xù)版本中如果出現(xiàn)相同或者相似問題，可以“重新打開”，并相應(yīng)的修改bug屬性。.缺陷結(jié)果分析通過缺陷的分析可以反映出項目測試的進展情況、項目流程中的薄弱環(huán)節(jié)，同時還可以對產(chǎn)品質(zhì)量進行評估，確認測試是否達到結(jié)束的標準。所以每個測試階段結(jié)束后都需要在測試報告中針對當前項目的測試情況進行總結(jié)，分析，確定是否可以進入下一個階段。按照“所屬模塊”進行分析根據(jù)“所屬模塊”字段，分析具體模塊的bug情況，找出影響產(chǎn)品質(zhì)量的關(guān)鍵模塊；測試經(jīng)驗表明，“發(fā)