軟件缺點管理制度軟件項目測試組文檔編號：編寫人：編寫日期：3月20日審核人：審核日期：審批人：審批日期：修訂歷史統(tǒng)計日期版本闡明作者目錄軟件缺點管理制度 1修訂歷史統(tǒng)計 1目錄 1第1章總則 1第2章職責 1第3章缺點類型 13.1文檔缺點 13.2設(shè)計缺點 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章缺點統(tǒng)計 55.1編號 55.2項目 55.3公布版本 55.4功效模塊 55.5缺點描述 55.6重現(xiàn)環(huán)節(jié) 55.7嚴重程度 65.8優(yōu)先級 65.9狀態(tài) 65.10負責人 65.11解決意見 75.12解決統(tǒng)計（解決的方法） 7第6章附錄 7第1章總則為了加強部門管理工作，建立規(guī)范的缺點管理制度，提高工作水平，根據(jù)公司和部門的有關(guān)規(guī)定，制訂缺點管理制度。本缺點管理制度合用于工程技術(shù)部。各測試，研發(fā)人員應(yīng)當根據(jù)本制度的規(guī)定，規(guī)范工作，確保軟件質(zhì)量。軟件缺點又被叫做Bug。所謂軟件缺點，即為軟件中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功效缺點。缺點的存在會造成軟件產(chǎn)品在某種程度上不能滿足顧客的需要。IEEE729-1983對缺點有一種原則的定義：從產(chǎn)品內(nèi)部看，缺點是軟件產(chǎn)品開發(fā)或維護過程中存在的錯誤、毛病等多個問題；從產(chǎn)品外部看，缺點是系統(tǒng)所需要實現(xiàn)的某種功效的失效或違反。軟件缺點的管理分為四個階段。涉及：缺點提交、明確指明缺點類型、缺點修復(fù)、缺點回歸驗證。第2章職責項目人員應(yīng)對各階段測試發(fā)現(xiàn)的缺點進行跟蹤管理，以確保各級缺點的修復(fù)率達成一定原則。包含內(nèi)容以下：2.1測試人員在提供的缺點模板中新建或重新打開缺點。2.2測試人員提交的缺點將反饋給項目負責人，由項目負責人安排開發(fā)人員修復(fù)缺點。2.3開發(fā)人員修復(fù)缺點后，統(tǒng)計解決時間及解決成果，并將文檔及時反饋給測試人員驗證。2.4測試人員驗證缺點后，統(tǒng)計驗證時間及驗證成果，并提交給項目負責人。第3章缺點類型缺點類型是指根據(jù)缺點的自然屬性劃分的缺點種類。共分為九類，涉及：文檔缺點、設(shè)計缺點、配備缺點、界面交互缺點、數(shù)據(jù)校驗缺點、查詢統(tǒng)計缺點、功效缺點、性能缺點、安全性缺點。3.1文檔缺點文檔缺點是指軟件有關(guān)文檔不滿足其完整性、對的性、一致性、易理解性、易瀏覽性的規(guī)定。滿足下列一或多個狀況：（1）影響公布和維護，其中涉及注釋。（2）文檔中術(shù)語不一致。（3）文檔中詞語、語句體現(xiàn)不清晰，產(chǎn)生歧義。（4）文檔內(nèi)容缺失，構(gòu)造不完整。（5）文檔編制過程中產(chǎn)生的錯誤。（6）文檔中發(fā)現(xiàn)的其它錯誤。3.2設(shè)計缺點設(shè)計缺點是指軟件在最初設(shè)計時由于未考慮全方面，而使軟件在使用中存在的某些潛在的缺點。滿足下列一或多個狀況：（1）需求分析階段沒有考慮和挖掘到的隱式需求，造成的需求缺失。（2）操作便捷性設(shè)計不符合大眾操作習慣。（3）控件功效設(shè)計不符合大眾使用習慣。（4）錯誤提示內(nèi)容不符合大眾閱讀習慣。（5）其它設(shè)計不合理引發(fā)的缺點。3.3配備缺點配備缺點是指由于配備庫、變更管理或版本控制引發(fā)的錯誤。滿足下列一或多個狀況：（1）獨立安裝布署不成功。（2）配備文獻或初始化數(shù)據(jù)錯誤。（3）不同運行環(huán)境產(chǎn)生的錯誤。3.4界面交互缺點界面交互缺點是指接口通信和人機交互時產(chǎn)生的缺點。滿足下列一或多個狀況：（1）組件、模塊之間數(shù)據(jù)通信錯誤。（2）程序接口錯誤。（3）硬件接口通信錯誤。（4）界面不存在，界面不滿足易用性規(guī)定，界面難以被顧客理解，界面不協(xié)調(diào)不美觀，提示信息沒有使用用業(yè)務(wù)詞匯或者容易被顧客理解的詞匯而是使用計算機專業(yè)術(shù)語。（5）界面風格不相對一致，不符合操作習慣。（6）提示、警告、錯誤闡明等和諧信息體現(xiàn)含糊、失當。（7）沒有區(qū)別不同操作（增加、刪除、修改、查詢）對應(yīng)界面的性質(zhì)。（8）沒有提供輔助輸入手段。3.5數(shù)據(jù)校驗缺點數(shù)據(jù)校驗缺點是指提示的錯誤信息，不適宜的數(shù)據(jù)驗證等缺點。滿足下列一或多個狀況：（1）數(shù)據(jù)計算錯誤。（2）數(shù)據(jù)約束錯誤。（3）不同操作之間數(shù)據(jù)邏輯校驗錯誤。（4）數(shù)據(jù)庫發(fā)生死鎖。（5）數(shù)據(jù)庫的表、缺省值未加完整性等約束條件。（6）數(shù)據(jù)庫連接錯誤。（7）數(shù)據(jù)庫中得表有過多空字段。3.6查詢統(tǒng)計缺點查詢統(tǒng)計缺點是指條件設(shè)立不精確引發(fā)的查詢統(tǒng)計成果不對的。滿足下列一或多個狀況：（1）查詢條件設(shè)立不精確。（2）查詢成果列表異常。（3）同一查詢條件得到的成果不一致。3.7功效缺點功效缺點是指影響軟件規(guī)定或基本功效實現(xiàn)的缺點。滿足下列一或多個狀況： （1）功效無法實現(xiàn)。（2）功效實現(xiàn)錯誤。（3）業(yè)務(wù)流程錯誤。（4）功效操作與數(shù)據(jù)庫存儲不一致。（5）功效與輔助協(xié)助不吻合。3.8性能缺點性能缺點是指產(chǎn)品性能不能滿足需求規(guī)格闡明書中對性能需求的規(guī)定。滿足下列一或多個狀況：（1）業(yè)務(wù)解決效率低。（2）查詢統(tǒng)計效率低。（3）響應(yīng)速度不能滿足需求規(guī)格闡明書中的規(guī)定。3.9安全性缺點安全性缺點是指產(chǎn)品不能滿足需求規(guī)格闡明書中對安全性需求的規(guī)定。滿足下列一或多個狀況：（1）顧客登錄顧客名/口令校驗不對的。（2）口令沒有掩碼顯示。（3）顧客權(quán)限分派錯誤。（4）顧客功效超權(quán)限。第4章缺點管理流程4.1新增（提交）缺點提交階段需要提交缺點報告，測試人員必須確保登記的缺點信息能夠被處置負責人員理解，因此缺點報告必須具體描述缺點內(nèi)容。具體內(nèi)容參見缺點統(tǒng)計。4.2定位缺點分析定位階段需要根據(jù)缺點報告的內(nèi)容對缺點進行分析和定位。缺點分析和定位是有關(guān)人員根據(jù)缺點報告中對缺點的具體描述查找重現(xiàn)缺點，擬定缺點產(chǎn)生的因素，明確缺點所處的位置，方便修改缺點。4.4解決缺點修復(fù)階段需要對已經(jīng)定位的缺點進行修改。缺點修復(fù)是開發(fā)人員對已經(jīng)分析定位的缺點進行修改并更改缺點狀態(tài)，修改后的軟件需要實現(xiàn)預(yù)期的成果（缺點報告中的預(yù)期成果）。4.5否決如果開發(fā)人員發(fā)現(xiàn)該缺點不可再現(xiàn)、重復(fù)、不是問題等狀況，能夠把缺點狀態(tài)設(shè)立成“否決”。4.6推遲解決如果按照開發(fā)計劃，缺點發(fā)生的功效不屬于現(xiàn)在開發(fā)階段必須的完畢的，可將缺點狀態(tài)設(shè)立為“推遲解決”。4.7回歸驗證缺點回歸驗證階段需要對已經(jīng)修改的缺點進行驗證和回歸測試。缺點回歸驗證是測試人人員對已經(jīng)修改的缺點進行回歸測試，根據(jù)缺點報告中的操作環(huán)節(jié)對缺點重新進行測試，并對缺點修改正程中可能影響到的組件、模塊或功效進行重新測試，驗證修改后的缺點能夠?qū)崿F(xiàn)預(yù)期成果并對其它組件、模塊或功效無影響。同時，根據(jù)驗證成果修改對應(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章缺點統(tǒng)計5.1編號缺點的唯一標記，能夠方便對特定缺點統(tǒng)計的引用。5.2項目5.3公布版本即缺點是在什么公布版本中發(fā)現(xiàn)。5.4功效模塊5.5缺點描述對該缺點進行簡短的描述，盡量使負責人能夠理解。5.6重現(xiàn)環(huán)節(jié)描述該缺點出現(xiàn)的具體環(huán)節(jié)，盡量做到環(huán)節(jié)清晰、有實例、可再現(xiàn)。5.7嚴重程度缺點嚴重程度是指因缺點引發(fā)的故障對軟件產(chǎn)品的影響程度。分為五類，涉及：致命、嚴重、普通、輕微、提示。（1）致命：不能執(zhí)行正常工作功效或重要功效。（2）嚴重：嚴重影響系統(tǒng)規(guī)定或基本功效的實現(xiàn)造成系統(tǒng)出錯或關(guān)閉進程，且沒有方法改正。（重新安裝或重新啟動該軟件不屬于改正方法）（3）普通：嚴重影響系統(tǒng)規(guī)定或基本功效的實現(xiàn)造成系統(tǒng)提示錯誤，但存在合理的改正方法。（重新安裝或重新啟動該軟件不屬于改正方法）（4）輕微：使操作者不方便或碰到麻煩，但它不影響執(zhí)行工作功效或重要功效。（5）提示：其它錯誤。5.8優(yōu)先級缺點優(yōu)先級指缺點必須被修復(fù)的緊急程度。分為四類，涉及：緊急、嚴重、普通、輕微。（1）緊急：缺點不被修改將無法繼續(xù)測試。（2）嚴重：缺點必須被立刻解決。（3）普通：缺點需要正常排隊等待修復(fù)或列入軟件公布清單。（4）建議：缺點能夠在方便時被糾正。5.9狀態(tài)缺點狀態(tài)指缺點在跟蹤修復(fù)過程中的進展狀態(tài)。分為五類，涉及：新建、打開、重現(xiàn)打開、否決、解決、延遲、關(guān)閉。（1）新建：已提交的缺點。（2）打開：確認“提交的缺點”，等待解決。（3）重新打開：驗證后發(fā)現(xiàn)未修復(fù)的缺點。（4）否決：否決“提交的缺點”，不需要修復(fù)或不是缺點。（5）解決：缺點被修復(fù)。（6）延遲：缺點暫緩修復(fù)。（7）關(guān)閉：確認被修復(fù)的缺點，將其關(guān)閉。5.10負責人負責處置解決缺點的負責人，對于功效缺點，負責人應(yīng)當具體開發(fā)人員；對于文檔缺點，負責人應(yīng)當是具體文檔的作者。缺點登記者不明確負責人時，能夠指定項目負責人為負責人，由他重新分派負責人。5.11解決意見處置