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

軟件缺點管理規(guī)范（ISO9001：）目的本文檔定義了軟件缺點管理流程和有關(guān)規(guī)則，確保軟件缺點管理的系統(tǒng)性和規(guī)范性，以確保項目研發(fā)質(zhì)量。合用范疇合用于部門項目研發(fā)過程的缺點管理，對各階段的缺點管理過程進行指導和規(guī)范。定義3.1術(shù)語缺點（Defect）：存在于軟件之中偏差，可被激活，以靜態(tài)形式存在于軟件內(nèi)部。Bug：缺點一種體現(xiàn)形態(tài)，系統(tǒng)或程序存在的任何一種破壞正常運轉(zhuǎn)能力的問題。3.2缺點定義（1）軟件未達成需求規(guī)格闡明書的功效；（2）軟件出現(xiàn)了需求規(guī)格闡明書指明不會出現(xiàn)的錯誤；（3）軟件功效超出需求規(guī)格闡明書的范疇；（4）軟件未達成需求規(guī)格闡明書未指出但應達成的目的；（5）測試工程師認為軟件難以理解、不易使用、運行速度慢，或者最后顧客認為不好。缺點生命周期4.1缺點生命周期圖4.2缺點狀態(tài)闡明缺點狀態(tài)狀態(tài)闡明激活狀態(tài)缺點的初始狀態(tài)，或者重新被激活的狀態(tài)。激活狀態(tài)的缺點能夠通過編輯來修改缺點內(nèi)容，并指派給適宜的工程師解決。解決狀態(tài)缺點被解決之后的狀態(tài)。激活狀態(tài)的缺點通過成功修復后來，由開發(fā)工程師操作為解決狀態(tài)，系統(tǒng)將自動指派回創(chuàng)立者。關(guān)閉狀態(tài)解決狀態(tài)的缺點在驗證通過后關(guān)閉，缺點狀態(tài)變?yōu)殛P(guān)閉，生命周期結(jié)束。如果驗證未修復或者新版本又發(fā)生，則重新激活，缺點狀態(tài)重新變?yōu)榧せ睢?.缺點解決過程5.1正常解決過程（1）創(chuàng)立問題在測試管理系統(tǒng)中，全部顧客都能夠創(chuàng)立新問題，涉及需求問題和軟件缺點等。創(chuàng)立問題時，需要描述清晰，并選擇對的的選項，具體請參考5.4和5.5。（2）指派問題創(chuàng)立問題時，創(chuàng)立者普通要指派給該項目開發(fā)負責人，再由其指派任務，或直接指派給對應模塊的開發(fā)工程師。如果指派人是錯誤的，或者需要別人確認或協(xié)助，則能夠重新指派給適宜的工程師，寫上有關(guān)備注。（3）確認問題普通開發(fā)工程師收到新問題后，需要分析和確認此問題與否為Bug。如果是Bug，則選擇“確認狀態(tài)”；如果認為非Bug，則注明因素并指派回創(chuàng)立者。當創(chuàng)立者收到確認指派時，需要進行及時確認。如果同意為非bug，則及時關(guān)閉它；如果不同意，則需要注明理由并指派回有關(guān)工程師。如果問題確認指派次數(shù)不不大于6次時，需要進入“爭議解決”流程，具體請參考5.2。（4）解決問題此為開發(fā)工程師的重要職責，涉及Bug的復現(xiàn)、修改和修改驗證。開發(fā)工程師需要及時對確認狀態(tài)Bug進行分析和解決，并自己驗證通過，則操作為解決狀態(tài)，解決方案規(guī)則請參考5.4中解決方案定義部分，在缺點管理系統(tǒng)中解決方案選擇對應的選項，解決后系統(tǒng)將自動指派回給創(chuàng)立者。如果Bug無法解決或修改影響比較大，可申請進入“延期解決”流程，請參考5.2中延期解決部分。（5）驗證問題創(chuàng)立者需要及時對解決狀態(tài)的Bug在對應版本上面進行驗證。如果驗證通過，則可關(guān)閉Bug；如果驗證不通過，則激活此Bug，系統(tǒng)將自動指派回給解決者。驗證通過準則：相似的操作環(huán)節(jié)，進行一定次數(shù)的驗證測試都沒有發(fā)生。驗證不通過準則：相似的操作環(huán)節(jié)，全部或部分實際成果還會發(fā)生，驗證不通過則激活Bug。(6)關(guān)閉問題通過驗證的Bug，驗證者需要注明驗證成果并進行關(guān)閉操作，系統(tǒng)將指派給Closed。如果關(guān)閉狀態(tài)的Bug在之后版本又會發(fā)生，則激活此Bug，系統(tǒng)將自動指派回給解決者。5.2特別解決過程(1)客戶問題客戶反饋的問題能夠由客戶直接反饋或項目經(jīng)理、市場部等理解到的客戶問題，經(jīng)確認后的Bug提交到測試管理系統(tǒng)，按照以上解決流程進行解決，由創(chuàng)立者或測試組進行跟蹤驗證關(guān)閉。創(chuàng)立客戶問題時，創(chuàng)立者需要在Bug標題開頭標記為[客戶問題]，測試組負責檢查和改正。(2)爭議解決當開發(fā)和測試工程師對某問題有爭議并且多次溝通無果時（暫定為6次），能夠注明雙方的理由，并指派給項目經(jīng)理進行解決。項目經(jīng)理能夠召開評審會議，或者直接與雙方溝通理解，并根據(jù)項目狀況給出專業(yè)意見和最后決定。開發(fā)和測試工程師根據(jù)項目經(jīng)理的最后決定執(zhí)行。(3)延期解決當開發(fā)工程師對確認Bug進行解決時，發(fā)現(xiàn)或評定其解決時間緊或風險比較大等，能夠闡明因素或理由并指派給項目經(jīng)理來確認。項目經(jīng)理能夠召開評審會議，或者直接溝通理解，并根據(jù)項目狀況給出最后決定。如果不同意，項目經(jīng)理將此Bug指派回開發(fā)工程師，開發(fā)工程師繼續(xù)分析和解決。如果同意，項目經(jīng)理需要在Bug標題開頭標記為[延期解決]和在解決狀態(tài)選擇“延期解決”，然后注明解決時間計劃并指派回開發(fā)工程師，開發(fā)工程師根據(jù)解決時間計劃來規(guī)劃和解決此Bug。5.3缺點管理工具軟件測試過程中全部缺點要提交到公司測試管理系統(tǒng)進行跟蹤管理。管理工具的作用確保每個被發(fā)現(xiàn)的缺點都能夠被跟蹤與解決。收集缺點數(shù)據(jù)并根據(jù)缺點趨勢曲線識別或報告測試狀態(tài)。收集缺點數(shù)據(jù)并在其上進行數(shù)據(jù)分析，作為測試評定的根據(jù)。（2）缺點驅(qū)動原則缺點管理系統(tǒng)重要通過指派狀態(tài)來驅(qū)動有關(guān)開發(fā)工程師、測試工程師和項目經(jīng)理盡快地解決問題，以提高研發(fā)效率，因此會特別關(guān)注缺點指派給誰和停留時間，并反饋在定時報告。因此，缺點驅(qū)動原則：盡量不要讓缺點掛在你身上。5.4.缺點屬性定義(1)缺點有關(guān)屬性缺點屬性闡明缺點ID缺點ID是標記某個缺點的一組符號。每個缺點必須有一種唯一的ID。缺點類型缺點類型是根據(jù)缺點的自然屬性劃分的缺點種類。嚴重程度缺點嚴重程度是指因缺點引發(fā)的失效對軟件產(chǎn)品的影響程度。發(fā)生概率缺點發(fā)生概率指缺點按照測試操作環(huán)節(jié)發(fā)生的概率狀況。解決方案缺點解決方案是指缺點被解決掉的解決方案。缺點描述缺點描述是對缺點的報告，涉及標題、操作環(huán)節(jié)和成果等。缺點類型闡明類型名稱闡明設(shè)計缺點由于軟件設(shè)計或代碼實現(xiàn)所產(chǎn)生的功效或流程的問題。界面問題系統(tǒng)頁面的展示的問題。數(shù)據(jù)問題系統(tǒng)數(shù)據(jù)的來源，解決及解決成果的問題。需求問題軟件需求測試發(fā)現(xiàn)的問題，也涉及之后需求變更的問題。安裝布署軟件安裝布署過程的錯誤。性能問題軟件性能有關(guān)的缺點。文檔問題顧客使用手冊，軟件協(xié)助文檔等出現(xiàn)的問題常識問題系統(tǒng)顧客的正常使用習慣有關(guān)問題。安全問題系統(tǒng)漏洞安全問題。優(yōu)化建議針對操作過程邏輯或界面顯示的優(yōu)化性建議。其它除前面分類的其它問題(3)嚴重程度定義嚴重程度定義和闡明致命妨礙開發(fā)或測試工作繼續(xù)進行的系統(tǒng)性故障，例如：實現(xiàn)的功效與產(chǎn)品定義或軟件需求規(guī)格嚴重不符。系統(tǒng)無法執(zhí)行、崩潰、凍結(jié)，死循環(huán)等。程序引發(fā)的死機，非法退出。重要功效模塊嚴重錯誤。數(shù)據(jù)庫鏈接錯誤，嚴重數(shù)據(jù)計算錯誤通訊錯誤等。嚴重系統(tǒng)出現(xiàn)的嚴重錯誤，但不影響現(xiàn)在測試工作的錯誤。例如：模塊功效錯誤，模塊功效未實現(xiàn)，亂碼等；功效錯誤，如鏈接模塊有誤，基本按鍵使用有誤等。數(shù)據(jù)錯誤，如顧客數(shù)據(jù)丟失、破壞、計算、保存有誤等。普通不影響顧客使用的非嚴重問題次要功效未實現(xiàn)或與需求不符。操作界面錯誤，如界面圖表或字符的普通性錯誤，但不影響操作。提示信息錯誤，輔助闡明不清晰。數(shù)據(jù)錯誤，數(shù)據(jù)邊界、格式約束未實現(xiàn)或需求不一致建議測試過程中發(fā)現(xiàn)不利顧客操作的優(yōu)化建議。界面字符或提示與的顯示不恰當。頁面或操作習慣的優(yōu)化性建議。功效操作更加好的實現(xiàn)方式。注：嚴重等級由創(chuàng)立者在創(chuàng)立缺點時根據(jù)此定義來選擇，之后都不能隨意更改。(5)優(yōu)先級的定義優(yōu)先級定義和闡明立刻妨礙測試工作無法進行，需要開發(fā)工程師立刻解決問題。全部的致命問題都需要立刻解決；時間急迫時影響版本上線的問題等；緊急不影響測試工作的嚴重問題，下個測試版本發(fā)版前必須解決。全部嚴重問題；慣用模塊功效、業(yè)務邏輯或數(shù)據(jù)錯誤；明顯的性能問題；盡快普通性功效錯誤，版本公布前應當解決的問題。大多數(shù)普通問題；頁面顯示，頁面的字符，界面圖標、文字顯示、鏈接有誤，不影響使用。如錯別字，圖標顯示異常等；普通不影響版本上線的問題，部分問題允許不修改。非慣用界面或字符的顯示錯誤或不恰當；顧客使用習慣，語言體現(xiàn)等優(yōu)化建議；注：立刻、緊急、盡快的問題都規(guī)定在系統(tǒng)上線前解決。(6)發(fā)生概率定義發(fā)生概率定義闡明驗證問題最小次數(shù)必現(xiàn)100%。測試5次，出現(xiàn)5次。5次經(jīng)常100%>&>=30%。測試5次，出現(xiàn)3~4次；或測試10次，出現(xiàn)3次及以上；或測試15次，出現(xiàn)5次及以上。10次偶然30%>&>=10%。測試10次，出現(xiàn)2次；或測試15次，出現(xiàn)2~4次。20次隨機<10%。測試15次，出現(xiàn)1次。30次(7)解決狀態(tài)闡明解決狀態(tài)有關(guān)規(guī)則確認中當問題確認過程時，能夠選擇這狀態(tài)來闡明。解決中開發(fā)工程師設(shè)立此狀態(tài)。當Bug正在分析或解決時，可選這狀態(tài)來闡明。復現(xiàn)中當正在復現(xiàn)問題，或者正在跟蹤測試問題，能夠選擇這狀態(tài)來闡明。驗證中當驗證隨機問題等需要長時間，能夠選擇這狀態(tài)來闡明。延期解決項目經(jīng)理才干設(shè)立此狀態(tài)，參考5.2(8)解決方案定義與規(guī)則解決方案方案闡明有關(guān)規(guī)則已經(jīng)解決缺點被修復或改正，并通過其驗證測試。開發(fā)工程師權(quán)限，解決時需要填寫“解決版本”和注明Bug因素等。重復缺點相似的缺點別人已經(jīng)提交，或者開發(fā)認為因素是相似的開發(fā)工程師權(quán)限，解決時需要填寫對的的重復缺點ID。無效缺點設(shè)計如此，不是問題，優(yōu)化建議不采納，沒法解決的第三方問題。開發(fā)工程師需要與創(chuàng)立者溝通闡明，直到創(chuàng)立者同意，開發(fā)工程師才干選擇此方案。無法復現(xiàn)開發(fā)和測試工程師沒法復現(xiàn)又不能解決的問題，并且跟蹤測試二個以上版本也不能復現(xiàn)。開發(fā)和測試工程師通過努力也不能復現(xiàn)，并由測試工程師跟蹤測試二個以上版本，開發(fā)工程師才干選擇此方案。延期解決開發(fā)工程師Bug進行解決時，發(fā)現(xiàn)或評定其解決時間緊或風險比較大等，向項目經(jīng)理闡明因素。項目經(jīng)理的權(quán)限，項目經(jīng)理綜合通過考慮解決問題的時間、風險、市場需求等多方面要素決定與否選擇此方案注：無法復現(xiàn)問題將作為風險評定點。5.5缺點描述規(guī)范（1）缺點標題缺點標題是對所提交缺點的概述，需要簡短而精確的描述出缺點概要信息，并使用某些精煉的核心詞，重要內(nèi)容涉及：位置+對象+動作+現(xiàn)象。環(huán)境核心詞：涉及數(shù)據(jù)環(huán)境，時間環(huán)境，地點環(huán)境條件環(huán)境，描述缺點發(fā)生時所處的背景環(huán)境，或正在執(zhí)行的操作或所處的界面環(huán)境，如“在…”頁面，“當…時…”，“在…過程中…”等；動作核心詞：引發(fā)缺點所執(zhí)行的操作，如“點…鍵”“選…選項”等；對象的核心詞：描述缺點出現(xiàn)的對象，“頁面”，“顯示框”，“圖表”等；現(xiàn)象的核心詞：描述缺點出現(xiàn)的現(xiàn)象，如“顯示為負數(shù)”，“卡死”等。根據(jù)上述核心詞的組合來描寫缺點標題。（2）重現(xiàn)環(huán)節(jié)在描述缺點重現(xiàn)環(huán)節(jié)的過程中，普通需要通過描述前提條件，測試環(huán)節(jié)，實際成果，盼望成果這四個方面清晰具體的描述缺點。前提條件外部環(huán)境，這里涉及網(wǎng)絡環(huán)境，硬件環(huán)境和軟件環(huán)境的狀態(tài)。默認狀況下，無需特殊闡明，前提條件均為“系統(tǒng)正常運行”，其含義為網(wǎng)絡正常，電腦硬件環(huán)境能支撐軟件運行，系統(tǒng)軟件配備狀況正常。需要注意，軟件環(huán)境有可能引發(fā)缺點的功效模塊所處的狀態(tài)，以及重現(xiàn)該缺點需要的模塊有關(guān)狀態(tài)或者特殊設(shè)立狀況應當前在前提條件中做闡明。數(shù)據(jù)環(huán)境，對缺點產(chǎn)生的所在案件或引發(fā)bug現(xiàn)象的數(shù)據(jù)輸入和數(shù)據(jù)設(shè)計等應當在前提條件中做對應闡明。總之，這里對缺點現(xiàn)象重現(xiàn)緊密有關(guān)的預先設(shè)立，或與缺點模塊有關(guān)聯(lián)的預先設(shè)立都應當在前提條件中闡明。測試環(huán)節(jié)這里需要具體描述出重現(xiàn)缺點的操作環(huán)節(jié)，方便于重現(xiàn)缺點，修復和驗證缺點。在描寫測試環(huán)節(jié)時應當注意下列幾點：精簡：只描述缺點必須的細節(jié)；單一：每個缺點單只報告一種缺點；環(huán)節(jié)清晰：具體的、有序的描述出每一種環(huán)節(jié)，涉及輸入的數(shù)據(jù)狀況，執(zhí)行的操作以及執(zhí)行操作的界面。操作量化：對操作次數(shù)的描述需要量化，如“持續(xù)3次點確認鍵”等，盡量避免出現(xiàn)“多次”等含糊的詞。實際成果實際成果是指按照測試環(huán)節(jié)操作后實際反映的狀