《軟件缺陷管理制度(共10頁).docx》由會員分享，可在線閱讀，更多相關(guān)《軟件缺陷管理制度(共10頁).docx（10頁珍藏版）》請在匯文網(wǎng)上搜索。

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件缺陷管理制度軟件項目測試組文檔編號： 編寫人：編寫日期：2018年3月20日審核人：審核日期：審批人：審批日期：專心-專注-專業(yè)修訂歷史記錄日期版本說明作者目 錄第1章 總則為了加強部門管理工作，建立規(guī)范的缺陷管理制度，提高工作水平，根據(jù)公司和部門的有關(guān)規(guī)定，制定缺陷管理制度。本缺陷管理制度適用于工程技術(shù)部。各測試，研發(fā)人員應(yīng)當依據(jù)本制度的規(guī)定，規(guī)范工作，保證軟件質(zhì)量。軟件缺陷又被叫做Bug。所謂軟件缺陷，即為軟件中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一

2、個標準的定義：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護過程中存在的錯誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。軟件缺陷的管理分為四個階段。包括：缺陷提交、明確指明缺陷類型 、缺陷修復、缺陷回歸驗證。第2章 職責項目人員應(yīng)對各階段測試發(fā)現(xiàn)的缺陷進行跟蹤管理，以保證各級缺陷的修復率達到一定標準。包含內(nèi)容如下：2.1測試人員在提供的缺陷模板中新建或重新打開缺陷。2.2測試人員提交的缺陷將反饋給項目負責人，由項目負責人安排開發(fā)人員修復缺陷。2.3開發(fā)人員修復缺陷后，記錄處理時間及處理結(jié)果，并將文檔及時反饋給測試人員驗證。2.4測試人員驗證缺陷后，記錄驗證時間及驗證結(jié)果

3、，并提交給項目負責人。第3章 缺陷類型缺陷類型是指根據(jù)缺陷的自然屬性劃分的缺陷種類。共分為九類，包括：文檔缺陷、設(shè)計缺陷、配置缺陷、界面交互缺陷、數(shù)據(jù)校驗缺陷、查詢統(tǒng)計缺陷、功能缺陷、性能缺陷、安全性缺陷。3.1 文檔缺陷文檔缺陷是指軟件相關(guān)文檔不滿足其完整性、正確性、一致性、易理解性、易瀏覽性的要求。滿足以下一或多種情況：（1）影響發(fā)布和維護，其中包括注釋。（2）文檔中術(shù)語不一致。（3）文檔中詞語、語句表達不清晰，產(chǎn)生歧義。（4）文檔內(nèi)容缺失，結(jié)構(gòu)不完整。（5）文檔編制過程中產(chǎn)生的錯誤。（6）文檔中發(fā)現(xiàn)的其他錯誤。3.2 設(shè)計缺陷設(shè)計缺陷是指軟件在最初設(shè)計時由于未考慮全面，而使軟件在使用中存

4、在的一些潛在的缺陷。滿足以下一或多種情況：（1）需求分析階段沒有考慮和挖掘到的隱式需求，導致的需求缺失。（2）操作便捷性設(shè)計不符合大眾操作習慣。（3）控件功能設(shè)計不符合大眾使用習慣。（4）錯誤提示內(nèi)容不符合大眾閱讀習慣。（5）其他設(shè)計不合理引發(fā)的缺陷。3.3 配置缺陷配置缺陷是指由于配置庫、變更管理或版本控制引起的錯誤。滿足以下一或多種情況：（1）獨立安裝部署不成功。（2）配置文件或初始化數(shù)據(jù)錯誤。（3）不同運行環(huán)境產(chǎn)生的錯誤。3.4 界面交互缺陷界面交互缺陷是指接口通信和人機交互時產(chǎn)生的缺陷。滿足以下一或多種情況：（1）組件、模塊之間數(shù)據(jù)通信錯誤。（2）程序接口錯誤。（3）硬件接口通信錯誤。

5、（4）界面不存在，界面不滿足易用性要求，界面難以被用戶理解，界面不協(xié)調(diào)不美觀，提示信息沒有使用用業(yè)務(wù)詞匯或者容易被用戶理解的詞匯而是使用計算機專業(yè)術(shù)語。（5）界面風格不相對一致，不符合操作習慣。（6）提示、警告、錯誤說明等友好信息表達模糊、失當。（7）沒有區(qū)別不同操作（增加、刪除、修改、查詢）對應(yīng)界面的性質(zhì)。（8）沒有提供輔助輸入手段。3.5 數(shù)據(jù)校驗缺陷數(shù)據(jù)校驗缺陷是指提示的錯誤信息，不適當?shù)臄?shù)據(jù)驗證等缺陷。滿足以下一或多種情況：（1）數(shù)據(jù)計算錯誤。（2）數(shù)據(jù)約束錯誤。（3）不同操作之間數(shù)據(jù)邏輯校驗錯誤。（4）數(shù)據(jù)庫發(fā)生死鎖。（5）數(shù)據(jù)庫的表、缺省值未加完整性等約束條件。（6）數(shù)據(jù)庫連接錯誤

6、。（7）數(shù)據(jù)庫中得表有過多空字段。3.6 查詢統(tǒng)計缺陷查詢統(tǒng)計缺陷是指條件設(shè)置不準確引起的查詢統(tǒng)計結(jié)果不正確。滿足以下一或多種情況：（1）查詢條件設(shè)置不準確。（2）查詢結(jié)果列表異常。（3）同一查詢條件得到的結(jié)果不一致。3.7 功能缺陷功能缺陷是指影響軟件要求或基本功能實現(xiàn)的缺陷。滿足以下一或多種情況：（1）功能無法實現(xiàn)。（2）功能實現(xiàn)錯誤。（3）業(yè)務(wù)流程錯誤。（4）功能操作與數(shù)據(jù)庫存儲不一致。（5）功能與輔助幫助不吻合。3.8 性能缺陷性能缺陷是指產(chǎn)品性能不能滿足需求規(guī)格說明書中對性能需求的要求。滿足以下一或多種情況：（1）業(yè)務(wù)處理效率低。（2）查詢統(tǒng)計效率低。（3）響應(yīng)速度不能滿足需求規(guī)格說

7、明書中的要求。3.9 安全性缺陷安全性缺陷是指產(chǎn)品不能滿足需求規(guī)格說明書中對安全性需求的要求。滿足以下一或多種情況：（1）用戶登錄用戶名/口令校驗不正確。（2）口令沒有掩碼顯示。（3）用戶權(quán)限分配錯誤。（4）用戶功能超權(quán)限。第4章 缺陷管理流程4.1 新增（提交）缺陷提交階段需要提交缺陷報告，測試人員必須保證登記的缺陷信息可以被處置負責人員理解，因此缺陷報告必須詳細描述缺陷內(nèi)容。詳細內(nèi)容參見缺陷記錄。4.2 定位缺陷分析定位階段需要根據(jù)缺陷報告的內(nèi)容對缺陷進行分析和定位。缺陷分析和定位是相關(guān)人員根據(jù)缺陷報告中對缺陷的詳細描述查找重現(xiàn)缺陷，確定缺陷產(chǎn)生的原因，明確缺陷所處的位置，以便修改缺陷。4

8、.4 解決缺陷修復階段需要對已經(jīng)定位的缺陷進行修改。缺陷修復是開發(fā)人員對已經(jīng)分析定位的缺陷進行修改并更改缺陷狀態(tài)，修改后的軟件需要實現(xiàn)預期的結(jié)果（缺陷報告中的預期結(jié)果）。4.5 否決如果開發(fā)人員發(fā)現(xiàn)該缺陷不可再現(xiàn)、重復、不是問題等情況，可以把缺陷狀態(tài)設(shè)置成“否決”。4.6 推遲處理如果按照開發(fā)計劃，缺陷發(fā)生的功能不屬于當前開發(fā)階段必須的完成的，可將缺陷狀態(tài)設(shè)置為“推遲處理”。4.7 回歸驗證缺陷回歸驗證階段需要對已經(jīng)修改的缺陷進行驗證和回歸測試。缺陷回歸驗證是測試人人員對已經(jīng)修改的缺陷進行回歸測試，根據(jù)缺陷報告中的操作步驟對缺陷重新進行測試，并對缺陷修改過程中可能影響到的組件、模塊或功能進行重

9、新測試，驗證修改后的缺陷可以實現(xiàn)預期結(jié)果并對其他組件、模塊或功能無影響。同時，根據(jù)驗證結(jié)果修改相應(yīng)的缺陷狀態(tài)，提交新產(chǎn)生的缺陷。4.8 再打開驗證測試不通過的缺陷，應(yīng)當重新打開，狀態(tài)變?yōu)椤爸匦麓蜷_”。關(guān)閉了的缺陷再次出現(xiàn)時(通常因為解決缺陷的方法導致相同位置出現(xiàn)不同形式的缺陷時)，測試人員重新打開缺陷，開發(fā)人員需要繼續(xù)解決。項目負責人應(yīng)當關(guān)注“重新打開”的缺陷。4.9 關(guān)閉測試人員確認缺陷已經(jīng)解決后，關(guān)閉缺陷。對于否決的缺陷，測試人員需要和項目負責人討論，項目負責人同意的可以關(guān)閉，項目負責人不同意的需要“重新打開”。第5章 缺陷記錄5.1 編號缺陷的唯一標識，可以方便對特定缺陷記錄的引用。5.

10、2 項目5.3 發(fā)布版本即缺陷是在什么發(fā)布版本中發(fā)現(xiàn)。5.4 功能模塊5.5 缺陷描述對該缺陷進行簡短的描述，盡量使負責人能夠理解。5.6 重現(xiàn)步驟描述該缺陷出現(xiàn)的詳細步驟，盡量做到步驟清楚、有實例、可再現(xiàn)。5.7 嚴重程度缺陷嚴重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。分為五類，包括：致命、嚴重、一般、輕微、提示。（1）致命：不能執(zhí)行正常工作功能或重要功能。（2）嚴重：嚴重影響系統(tǒng)要求或基本功能的實現(xiàn)導致系統(tǒng)出錯或關(guān)閉進程，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬于更正辦法）（3）一般：嚴重影響系統(tǒng)要求或基本功能的實現(xiàn)導致系統(tǒng)提示錯誤，但存在合理的更正辦法。（重新安裝或重新啟動該

11、軟件不屬于更正辦法）（4）輕微：使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。（5）提示：其他錯誤。5.8 優(yōu)先級缺陷優(yōu)先級指缺陷必須被修復的緊急程度。分為四類，包括：緊急、嚴重、一般、輕微。（1）緊急：缺陷不被修改將無法繼續(xù)測試。（2）嚴重：缺陷必須被立即解決。（3）一般：缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。（4）建議：缺陷可以在方便時被糾正。5.9 狀態(tài)缺陷狀態(tài)指缺陷在跟蹤修復過程中的進展狀態(tài)。分為五類，包括：新建、打開、重現(xiàn)打開、否決、解決、延遲、關(guān)閉。（1）新建：已提交的缺陷。（2）打開：確認“提交的缺陷”，等待處理。（3）重新打開：驗證后發(fā)現(xiàn)未修復的缺陷。（4）

12、否決：否決“提交的缺陷”，不需要修復或不是缺陷。（5）解決：缺陷被修復。（6）延遲：缺陷暫緩修復。（7）關(guān)閉：確認被修復的缺陷，將其關(guān)閉。5.10 負責人負責處置解決缺陷的負責人，對于功能缺陷，負責人應(yīng)當具體開發(fā)人員；對于文檔缺陷，負責人應(yīng)當是具體文檔的作者。缺陷登記者不明確責任人時，可以指定項目負責人為責任人，由他重新分配負責人。5.11 處理意見處置意見是缺陷負責人對缺陷處置結(jié)果的簡短描述。如“已修正”、“重復提交”、“不是問題”等。5.12 處理記錄（解決的辦法）處置記錄通常是解決方法，其中包括不限于簡要闡述缺陷產(chǎn)生原因、解決方法，是否會引起其他問題等。第6章 附錄測試團隊中的任何人都有權(quán)利和義務(wù)提出缺陷,并負責跟蹤和關(guān)閉。如本人無法跟蹤和關(guān)閉，請委托上一級領(lǐng)導進行跟蹤并關(guān)閉缺陷。缺陷的嚴重程度、優(yōu)先級和狀態(tài)均嚴格按照本制度執(zhí)行。本制度于審核通過起施行。