軟件測試缺陷管理規(guī)范

目錄TOC\o"1-2"\h\u152291背景 299381.1推行目的 26121.2適用范圍 2129091.3術語定義 2183732缺陷分類標準 236742.1缺陷類型 25002.2缺陷嚴重程度 3326512.3缺陷優(yōu)先級 3128692.4缺陷狀態(tài) 3147262.5缺陷來源 480982.6缺陷復現(xiàn)率 4110473缺陷提交規(guī)范 4314263.1缺陷所屬 4292813.2缺陷標題 5249283.3缺陷內容 5141363.4缺陷指派 581623.5缺陷類型 6284823.6缺陷嚴重程度和優(yōu)先級 6197713.7缺陷來源 6221274缺陷管理規(guī)范 6315284.1缺陷所屬管理 638254.2缺陷時效化 6176414.3未關閉缺陷的處理 7106134.4非系統(tǒng)測試缺陷的處理 7背景推行目的缺陷是產品與規(guī)定要求不相符的部分，會存在于軟件產品的整個生命周期中，本文規(guī)范軟件測試過程中的出現(xiàn)的缺陷，通過測試活動及早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，并確保缺陷被有效標識、跟蹤、和修改，保證軟件系統(tǒng)能夠達到要求的質量。適用范圍本文檔適用于公司項目研發(fā)以及項目運行過程中的缺陷管理。術語定義名詞描述軟件缺陷軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。嚴重程度指缺陷引起的故障對軟件產品的影響程度。優(yōu)先級修復缺陷的緊急程度。缺陷分類標準缺陷類型缺陷類型說明功能問題影響了重要的特性、用戶界面、產品接口、硬件結構接口和全局數(shù)據(jù)結構。并且設計文檔需要正式的變更。如指針循環(huán)，遞歸，功能等缺陷。接口問題與其他組件、模塊或設備驅動程序、調動參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。用戶界面問題人機交互特性：屏幕格式，確認用戶輸入，功能有特性，頁面排版等方面的缺陷。性能問題不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事物處理速率等缺陷。配置問題由于配置庫、變更管理或版本控制引起的錯誤。安全問題所存在安全方面的問題兼容問題軟件之間不能正確的交互和共享信息。設計缺陷軟件需求設計考慮不全。其他以上問題所不包含的問題缺陷嚴重程度嚴重級別對應缺陷嚴重等級說明致命P0阻礙測試的bug和生產環(huán)境中影響主業(yè)務的問題。系統(tǒng)任何一個主要功能完全喪失，用戶數(shù)據(jù)受到破壞，系統(tǒng)崩潰、懸掛、死機等問題。嚴重P1功能未能實現(xiàn)的bug和生產環(huán)境中影響使用的問題。產生錯誤的結果，導致系統(tǒng)不穩(wěn)定運行時好時壞等。一般P2功能雖實現(xiàn)、但存在一些瑕疵。次要功能沒有實現(xiàn)，但不影響用戶正常使用。輕微P3用戶操作起來不方便或者麻煩，但是不影響功能的運行和結果。有需要優(yōu)化改進的地方。缺陷優(yōu)先級缺陷優(yōu)先級對應缺陷嚴重等級（大概率）說明非常緊急P0產品研發(fā)環(huán)節(jié)時效性要求：上午提交的bug，當天解決；下午提交的bug，最晚第二天下班前解決生產環(huán)境時效性要求：當天解決

緊急P1產品研發(fā)環(huán)節(jié)時效性要求：解決周期≤5天生產環(huán)境時效性要求：解決周期≤3天高優(yōu)先級P2產品研發(fā)環(huán)節(jié)時效性要求：解決周期≤15天如遇版本計劃發(fā)版節(jié)點，需在正式定版前解決一般優(yōu)先級P3產品研發(fā)環(huán)節(jié)時效性要求：解決周期≤20天如遇版本計劃發(fā)版節(jié)點，需在正式定版前解決缺陷狀態(tài)缺陷狀態(tài)說明激活測試人員提交新的缺陷到庫。確認/修復中開發(fā)人員或者是其他人員已經收到缺陷，并在修復的過程中。拒絕拒絕“提交的缺陷”：不需要修復或不是缺陷或缺陷已經被其他的軟件測試人員發(fā)現(xiàn)。已解決已被開發(fā)人員檢查、修復過的缺陷，通過單元測試，認為已解決但還沒有被測試人員驗證。重新打開經過測試人員驗證，缺陷還存在，故激活缺陷為重新打開，開發(fā)人員需要再次修復。設計如此經開發(fā)人員、產品經理評估，缺陷的內容為設計如此，無需修復。重復缺陷經開發(fā)人員評估，此缺陷以存在于缺陷庫中。無法重現(xiàn)按照缺陷內容中的操作步驟，無法重新缺陷。延期處理經過開發(fā)人員和項目經理評估，此缺陷當前暫不修復，延期修復。關閉開發(fā)已解決，經過測試人員回歸驗證順利解決，由測試人員關閉缺陷。缺陷來源缺陷來源說明系統(tǒng)測試由測試人員進行的集成測試、系統(tǒng)測試、回歸測試產生的缺陷。UI還原度測試由UI設計師進行的UI還原度測試發(fā)現(xiàn)的缺陷?？蛻趄炇諟y試由客戶驗收時發(fā)現(xiàn)的缺陷。線上運行軟件已運行狀態(tài)，再由用戶、客戶、體驗人員發(fā)現(xiàn)的缺陷。缺陷復現(xiàn)率缺陷復現(xiàn)率說明必現(xiàn)100%復現(xiàn)大概率按照測試用例，通常情況下會產生這個軟件缺陷，其產生的頻率大概是80%—90%小概率按照測試用例，有時候產生這個軟件缺陷，其產生的頻率大概是30%—50%極小概率按照測試用例，很少產生這個軟件缺陷，其產生的頻率大概是1%—5%缺陷提交規(guī)范缺陷所屬在提交缺陷時，需要嚴格按照缺陷所屬的產品、項目、版本、模塊進行填寫，不能不進行填寫，此舉是為了在后續(xù)進行總結時進行缺陷分析。缺陷標題注意：在提交一條缺陷前，應檢查缺陷庫是否已經存在此缺陷，避免重復提交。缺陷標題應該盡量簡潔明了，以最少的文字描述出缺陷結果，標題應該避免長篇大論、文字過多，具體復現(xiàn)步驟和補充說明可以放在缺陷內容描述中。必要時缺陷標題中可以加入約定好的標簽信息，如模塊、類別等。以下為缺陷標題舉例：缺陷內容缺陷內容主要包括操作步驟、實際結果、預期結果。操作步驟：按照分步的方式描述復現(xiàn)缺陷的操作以及數(shù)據(jù)、環(huán)境等信息。實際結果：描述按照操作步驟得出的缺陷實際結果，必要時可以截圖、錄屏。預期結果：描述根據(jù)需求應該表現(xiàn)的預期結果。以下為缺陷內容舉例：缺陷指派缺陷應按照約定正確指派給對應的負責人，可以是前端負責人、后端負責人、項目經理等，不能無指派人。缺陷類型提交缺陷時，需要根據(jù)實際情況選擇缺陷所屬類型，類型說見“2.1缺陷類型”缺陷嚴重程度和優(yōu)先級提交缺陷時，需要根據(jù)實際情況選擇缺陷的嚴重程度和優(yōu)先級，嚴重程度劃分標準見“2.2缺陷嚴重程度”，缺陷優(yōu)先級見“2.3缺陷優(yōu)先級”。以“禪道”舉例：缺陷來源提交缺陷時，需要根據(jù)實際情況選擇缺陷來源，來源說明見“2.5缺陷來源”：缺陷管理規(guī)范缺陷所屬管理在提交缺陷前，測試負責人應預先創(chuàng)建好提交缺陷時所需要的字段內容，包括項目、版本、模塊等，并要求缺陷提交人在提交缺陷時嚴格按照實時進行內容選擇或填寫，做好缺陷的分類化。缺陷時效化缺陷提交后，測試人員、項目經理、開發(fā)負責人需要注意缺陷的截止日期，督促修復人員需要在截止日期前進行缺陷的修復。未關閉缺陷的處理對于設計如此、延期處理、無法重現(xiàn)等非關閉狀態(tài)缺陷，需要由測試人員找產品經理和項目經理進行確認，得到確認不修復的結果后，再到缺陷備注中添加說明做好記錄，以免在后續(xù)忘記處理結果。對于確認后還是得出需要修復的缺陷，應及時重新打開，指派給對應的負責人進行修復處理。非系統(tǒng)測試缺陷的處理對于非系統(tǒng)測試缺陷（