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

1、軟件缺陷管理制度軟件項目測試組文檔編號： 編寫人：編寫日期：2018年3月20日審核人：審核日期：審批人：審批日期：修訂歷史記錄日期版本說明作者目 錄軟件缺陷管理制度1修訂歷史記錄1目 錄1第1章 總則1第2章 職責1第3章 缺陷類型13.1 文檔缺陷13.2 設計缺陷23.3 配置缺陷23.4 界面交互缺陷23.5 數(shù)據(jù)校驗缺陷33.6 查詢統(tǒng)計缺陷33.7 功能缺陷33.8 性能缺陷33.9 安全性缺陷4第4章 缺陷管理流程44.1 新增（提交）44.2 定位44.4 解決44.5 否決44.6 推遲處理44.7 回歸驗證54.8 再打開54.9 關(guān)閉5第5章 缺陷記錄55.1 編號55.

2、2 項目55.3 發(fā)布版本55.4 功能模塊55.5 缺陷描述55.6 重現(xiàn)步驟55.7 嚴重程度65.8 優(yōu)先級65.9 狀態(tài)65.10 負責人65.11 處理意見75.12 處理記錄（解決的辦法）7第6章 附錄7第1章 總則為了加強部門管理工作，建立規(guī)范的缺陷管理制度，提高工作水平，根據(jù)公司和部門的有關(guān)規(guī)定，制定缺陷管理制度。本缺陷管理制度適用于工程技術(shù)部。各測試，研發(fā)人員應當依據(jù)本制度的規(guī)定，規(guī)范工作，保證軟件質(zhì)量。軟件缺陷又被叫做Bug。所謂軟件缺陷，即為軟件中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE7

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

4、，記錄驗證時間及驗證結(jié)果，并提交給項目負責人。第3章 缺陷類型缺陷類型是指根據(jù)缺陷的自然屬性劃分的缺陷種類。共分為九類，包括：文檔缺陷、設計缺陷、配置缺陷、界面交互缺陷、數(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 設計缺陷設計缺陷是指軟件在最初設計時由于未考慮

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

6、（3）硬件接口通信錯誤。（4）界面不存在，界面不滿足易用性要求，界面難以被用戶理解，界面不協(xié)調(diào)不美觀，提示信息沒有使用用業(yè)務詞匯或者容易被用戶理解的詞匯而是使用計算機專業(yè)術(shù)語。（5）界面風格不相對一致，不符合操作習慣。（6）提示、警告、錯誤說明等友好信息表達模糊、失當。（7）沒有區(qū)別不同操作（增加、刪除、修改、查詢）對應界面的性質(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ù)庫的表、缺省值未加完整性等約束條

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

8、應速度不能滿足需求規(guī)格說明書中的要求。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)生的原因，明確缺陷所處

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

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

11、特定缺陷記錄的引用。5.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)提示錯誤，但存在合理的更正辦法

12、。（重新安裝或重新啟動該軟件不屬于更正辦法）（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）重新打開：驗證后

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