測試缺陷管理規(guī)范#嚴(yán)選優(yōu)質(zhì)

1、測試缺陷管理規(guī)范1. 目的1.1. 缺陷是產(chǎn)品與規(guī)定要求不相符的部分，會存在于軟件產(chǎn)品的整個生命周期中，本文規(guī)范軟件測試過程中的出現(xiàn)的缺陷，通過測試活動及早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，并確保缺陷被有效標(biāo)識、跟蹤、和修改，保證軟件系統(tǒng)能夠達到要求的質(zhì)量。2. 適用范圍2.1. 適用于軟件的整個生命周期。2.2. 不限于測試過程發(fā)現(xiàn)的缺陷。評審，用戶使用等過程中發(fā)現(xiàn)的缺陷都是應(yīng)當(dāng)按照本流程進行登記跟蹤管理。3. 術(shù)語和定義3.1. 軟件缺陷：軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。3.2. 嚴(yán)重程度：缺陷嚴(yán)重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。3.3. 優(yōu)先級：

2、缺陷必須被修復(fù)的緊急程度。4. 職責(zé)4.1. 技術(shù)部4.1.1. 測試工程師：主要是指發(fā)現(xiàn)缺陷和報告缺陷的測試人員。在一般流程中，需要對這個缺陷后續(xù)相關(guān)的狀態(tài)負責(zé)：包括相關(guān)人員對這個缺陷相關(guān)信息的詢問回答，以及驗證測試。4.1.2. 開發(fā)工程師：主要是指對這個缺陷進行研究和修改的開發(fā)人員。同時，需要對修改后的缺陷在提交測試人員正式測試驗證之前需要進行驗證測試。 4.1.3. 其他參與人員：項目負責(zé)人、用戶組等，他們對缺陷進行優(yōu)先級劃分，負責(zé)人進行確認并調(diào)節(jié)爭議。4.1.4. 配置管理員：負責(zé)缺陷庫的創(chuàng)建和權(quán)限管理，并監(jiān)督指導(dǎo)缺陷庫的定制。5. 缺陷流程5.1. 登記5.1.1. 缺陷發(fā)現(xiàn)后，由

3、測試人員或者其他發(fā)現(xiàn)缺陷的人員登記到缺陷庫。5.1.2. 缺陷登記后，提交前可以反復(fù)編輯，補充缺陷記錄的信息。5.1.3. 登記缺陷描述的要求為分類準(zhǔn)確、敘述簡潔、步驟清楚、有實例、可再現(xiàn)、復(fù)雜問題有據(jù)可查（截圖或上傳附件的形式）具體要求為：單一：盡量一個報告只針對一個軟件缺陷。簡潔： 每個步驟的描述應(yīng)簡潔明了。再現(xiàn)：描述重現(xiàn)的步驟和條件，比如具體輸入?yún)?shù)值，以便進行回歸驗證。應(yīng)提供截圖。期望結(jié)果。實際結(jié)果。其它信息，可依實際情況增加。5.2. 提交5.2.1. 測試人員確認缺陷已經(jīng)表述清楚，可以提交缺陷。5.2.2. 提交后的缺陷狀態(tài)時“已提交”。5.2.3. 缺陷提交前必須分配一個具體的開

4、發(fā)人員負責(zé)，如果測試人員不確定誰負責(zé)，可以把缺陷分配給開發(fā)負責(zé)人，由開發(fā)負責(zé)人重新分配責(zé)任人。5.3. 處置5.3.1. 開發(fā)人員確認缺陷是自己負責(zé)后，開始著手處理，并修改缺陷的狀態(tài)為“打開”，表示缺陷正在處理中。5.3.2. 開發(fā)人員對缺陷處置完成后，需做處置記錄：原因：說明缺陷產(chǎn)生的原因，比如：設(shè)計考慮不周，邊界處理不嚴(yán)密，邏輯判斷不合理。要求描述具體簡潔，以便總結(jié)經(jīng)驗。解決方法：修改稿涉及的文件、源代碼、配置、腳本等。概括：缺陷是否可能存在于其他位置，或引起其他問題。5.3.3. 已打開的缺陷也可以修改負責(zé)人。5.4. 解決5.4.1. 問題解決后，填寫解決處理記錄，寫明造成缺陷的原因和

5、解決方案，改變?nèi)毕轄顟B(tài)為“已解決”。5.4.2. 如果開發(fā)人員發(fā)現(xiàn)如下情況，可以把缺陷駁回給測試人員：缺陷不可再現(xiàn)與先前登記的缺陷重復(fù)不是缺陷，是測試人員理解錯誤缺陷輕微，且修改困難、或修改易導(dǎo)致更大的潛在問題如果按照開發(fā)計劃，缺陷發(fā)生的功能不屬于當(dāng)前開發(fā)階段必須完成的（需與項目負責(zé)人確認）。5.5. 驗證5.5.1. 測試人員對“已解決”狀態(tài)的缺陷進行重新測試，測試步驟應(yīng)當(dāng)按照等級的可重現(xiàn)步驟進行。5.6. 關(guān)閉5.6.1. 測試人員確認缺陷已經(jīng)解決后，關(guān)閉缺陷。5.6.2. 對于被開發(fā)人員駁回的缺陷，測試人員需和項目負責(zé)人討論，項目負責(zé)人同意的可以關(guān)閉，否則需駁回給開發(fā)人員；5.7. 駁回

6、開發(fā)人員重新修改5.7.1. 驗證測試不通過的缺陷，應(yīng)當(dāng)駁回給開發(fā)人員，狀態(tài)為“重新打開”。5.7.2. 關(guān)閉了的缺陷再次出現(xiàn)時（通常因為解決缺陷的方法導(dǎo)致相同位置出現(xiàn)不同形式的缺陷時），測試人員重新打開缺陷，開發(fā)人員需要繼續(xù)解決。6. 附件6.1. 缺陷嚴(yán)重程度嚴(yán)重程度標(biāo)示含義1致命導(dǎo)致軟件無法使用問題，例如整個程序崩潰，導(dǎo)致無法使用，測試阻塞。1.問題會自發(fā)的影響整個系統(tǒng)。2.用戶使用正常的操作步驟，就會影響整個系統(tǒng)提供的服務(wù)。3.具有操作先后順序的功能，已開始的步驟出現(xiàn)故障，導(dǎo)致后續(xù)步驟無法使用。2嚴(yán)重某個功能未實現(xiàn)或?qū)е乱粋€特性或?qū)е乱粋€特性不能運行并且沒有替代方案3一般錯誤導(dǎo)致了一個

7、特性不能運行但可有一個替代方案。功能特征設(shè)計不符合系統(tǒng)的需求，不影響系統(tǒng)的業(yè)務(wù)，并且有相應(yīng)的補救方法。4輕微錯誤是表面化或微小的（提示信息不太準(zhǔn)確友好、不準(zhǔn)確、誤導(dǎo)、錯別字、界面布局或罕見故障等），對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用。5建議建設(shè)性的意見或建議。需求文檔沒有規(guī)定的特性，如果實現(xiàn)會對系統(tǒng)功能或易用性有所提高。6.2. 缺陷優(yōu)先級優(yōu)先級含義1 緊急如果故障妨礙開發(fā)人員的進一步開發(fā)活動，應(yīng)立即修復(fù)。如果阻塞測試，應(yīng)立即修復(fù)。2 必須的必須修改，版本發(fā)布前必須修正3 應(yīng)該的必須修改，不一定馬上修改，但需確定在某個特定版本發(fā)布前必須修正4 可選的如果時間允許應(yīng)該修改5 不需要允許不修改6.3. 缺陷狀態(tài)缺陷狀態(tài)描述初始狀態(tài)測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或項目經(jīng)理分配修改負責(zé)人駁回要求缺陷