軟件缺陷管理流程

1、軟件缺陷管理辦法1. 目的本文檔定義了軟件缺陷管理流程和相關規(guī)則，確保軟件缺陷管理的系統(tǒng)性和 規(guī)范性，以保證項目研發(fā)質量。2. 適用范圍適用于部門項目研發(fā)過程的缺陷管理，對各階段的缺陷管理過程進行指導和 規(guī)范。3. 定義3.1術語缺陷（Defect）:存在于軟件之中偏差，可被激活，以靜態(tài)形式存在于軟件 內部。Bug :缺陷一種表現(xiàn)形態(tài)，系統(tǒng)或程序存在的任何一種破壞正常運轉能力的 問題。3.2缺陷定義（1）軟件未達到需求規(guī)格說明書的功能；（2）軟件出現(xiàn)了需求規(guī)格說明書指明不會出現(xiàn)的錯誤；（3）軟件功能超出需求規(guī)格說明書的范圍；（4）軟件未達到需求規(guī)格說明書未指出但應達到的目標；（5）測試工程師認

2、為軟件難以理解、不易使用、運行速度慢，或者最終用戶認 為不好。4. 缺陷生命周期4.1缺陷生命周期圖麗L 關閉 4通4卄：態(tài) rJ*T扎 lij4.2缺陷狀態(tài)說明缺陷狀態(tài)狀態(tài)說明激活狀態(tài)缺陷的初始狀態(tài)，或者重新被激活的狀態(tài)。激活狀態(tài)的缺陷可以通過編輯來修改缺陷內容，并指派給合適的工程師處理。解決狀態(tài)缺陷被解決之后的狀態(tài)。激活狀態(tài)的缺陷經過成功修復以后，由開發(fā)工程師操作為解決狀態(tài)，系統(tǒng)將自動指派回創(chuàng)建者。關閉狀態(tài)解決狀態(tài)的缺陷在驗證通過后關閉，缺陷狀態(tài)變?yōu)殛P閉，生命周期結束。 如果驗證未修復或者新版本又發(fā)生，則重新激活，缺陷狀態(tài)重新變?yōu)榧せ睢?. 缺陷處理過程5.1正常處理過程（1）創(chuàng)建問題在測

3、試管理系統(tǒng)中，所有用戶都可以創(chuàng)建新問題，包括需求問題和軟件缺陷 等。創(chuàng)建問題時，需要描述清楚，并選擇正確的選項，詳細請參考5.4和 5.5。（2）指派問題創(chuàng)建問題時，創(chuàng)建者通常要指派給該項目開發(fā)負責人，再由其指派任務，或 直接指派給相應模塊的開發(fā)工程師。如果指派人是錯誤的，或者需要他人確認或幫助，則可以重新指派給合適的 工程師，寫上相關備注。（3）確認問題通常開發(fā)工程師收到新問題后，需要分析和確認此問題是否為Bug。如果是Bug，則選擇“確認狀態(tài)”；如果認為非 Bug，則注明原因并指派回創(chuàng)建者。當創(chuàng)建者收到確認指派時，需要進行及時確認。如果同意為非bug,則及時關閉它；如果不同意，則需要注明理

4、由并指派回相關工程師。如果問題確認指派次數大于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在對應版本上面進行驗證。如果驗證通過， 則可關閉Bug;如果驗證不通過，則激

5、活此Bug，系統(tǒng)將自動指派回給解決者。驗證通過準則：相同的操作步驟，進行一定次數的驗證測試都沒有發(fā)生。驗證不通過準則： 相同的操作步驟， 全部或部分實際結果還會發(fā)生， 驗證不 通過則激活 Bug。(6) 關閉問題通過驗證的Bug，驗證者需要注明驗證結果并進行關閉操作，系統(tǒng)將指派給 Closed。如果關閉狀態(tài)的Bug在之后版本又會發(fā)生，則激活此Bug,系統(tǒng)將自動指派回 給解決者。5.2 特別處理過程(1) 客戶問題客戶反饋的問題可以由客戶直接反饋或項目經理、 市場部等了解到的客戶問 題，經確認后的Bug提交到測試管理系統(tǒng)，按照以上處理流程進行處理，由創(chuàng)建 者或測試組進行跟蹤驗證關閉。創(chuàng)建客戶問題

6、時，創(chuàng)建者需要在Bug標題開頭標記為客戶問題，測試組負 責檢查和更正。(2) 爭議處理當開發(fā)和測試工程師對某問題有爭議并且多次溝通無果時(暫定為 6次)， 可以注明雙方的理由，并指派給項目經理進行處理。項目經理可以召開評審會議， 或者直接與雙方溝通了解， 并根據項目情況給 出專業(yè)意見和最終決定。開發(fā)和測試工程師根據項目經理的最終決定執(zhí)行。(3) 延期解決當開發(fā)工程師對確認Bug進行解決時，發(fā)現(xiàn)或評估其解決時間緊或風險比較 大等，可以說明原因或理由并指派給項目經理來確認。項目經理可以召開評審會議， 或者直接溝通了解， 并根據項目情況給出最終 決定。如果不同意，項目經理將此 Bug指派回開發(fā)工程師

7、，開發(fā)工程師繼續(xù)分析 和解決。如果同意，項目經理需要在 Bug標題開頭標記為延期解決和在處理狀 態(tài)選擇“延期解決”，然后注明解決時間計劃并指派回開發(fā)工程師，開發(fā)工程師 根據解決時間計劃來規(guī)劃和解決此 Bug。5.3 缺陷管理工具軟件測試過程中所有缺陷要提交到公司測試管理系統(tǒng)進行跟蹤管理。(1) 管理工具的作用a. 確保每個被發(fā)現(xiàn)的缺陷都能夠被跟蹤與處理。b. 收集缺陷數據并根據缺陷趨勢曲線識別或報告測試狀態(tài)。c. 收集缺陷數據并在其上進行數據分析，作為測試評估的依據。(2) 缺陷驅動原則缺陷管理系統(tǒng)主要通過指派狀態(tài)來驅動相關開發(fā)工程師、 測試工程師和項目 經理盡快地處理問題， 以提高研發(fā)效率，

8、 所以會特別關注缺陷指派給誰和停留時間，并反饋在定期報告所以，缺陷驅動原則：盡量不要讓缺陷掛在你身上54缺陷屬性定義缺陷相關屬性缺陷屬性說明缺陷ID缺陷ID是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的ID。缺陷類型缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。嚴重程度缺陷嚴重程度是指因缺陷引起的失效對軟件產品的影響程度。發(fā)生概率缺陷發(fā)生概率指缺陷按照測試操作步驟發(fā)生的概率情況。解決方案缺陷解決方案是指缺陷被解決掉的處理方案。缺陷描述缺陷描述是對缺陷的報告，包括標題、操作步驟和結果等。(2)缺陷類型說明類型名稱說明設計缺陷由于軟件設計或代碼實現(xiàn)所產生的功能或流程的問題。界面問題系統(tǒng)頁面的展示

9、的冋題。數據問題系統(tǒng)數據的來源，處理及處理結果的問題。需求冋題軟件需求測試發(fā)現(xiàn)的問題，也包括之后需求變更的問題。安裝部署軟件安裝部署過程的錯誤。性能問題軟件性能相關的缺陷。文檔問題用戶使用手冊，軟件幫助文檔等出現(xiàn)的問題常識問題系統(tǒng)用戶的正常使用習慣相關問題。安全問題系統(tǒng)漏洞安全問題。優(yōu)化建議針對操作過程邏輯或界面顯示的優(yōu)化性建議。其他除前面分類的其他問題(3)嚴重程度定義嚴重程度定義和說明致命阻礙開發(fā)或測試工作繼續(xù)進行的系統(tǒng)性故障， 例如：實現(xiàn)的功能與產品定義或軟件需求規(guī)格嚴重不符。 系統(tǒng)無法執(zhí)行、崩潰、凍結，死循環(huán)等。程序引起的死機，非法退出。主要功能模塊嚴重錯誤。數據庫鏈接錯誤，嚴重數據計

10、算錯誤通訊錯誤等。嚴重系統(tǒng)出現(xiàn)的嚴重錯誤，但不影響當前測試工作的錯誤。例如：模塊功能錯誤，模塊功能未實現(xiàn)，亂碼等； 功能錯誤，如鏈接模塊有誤，基本按鍵使用有誤等。數據錯誤，如用戶數據丟失、破壞、計算、保存有誤等。一般不影響用戶使用的非嚴重問題次要功能未實現(xiàn)或與需求不符。操作界面錯誤，如界面圖表或字符的一般性錯誤，但不影響操作。 提示信息錯誤，輔助說明不清楚。數據錯誤，數據邊界、格式約束未實現(xiàn)或需求不一致建議測試過程中發(fā)現(xiàn)不利用戶操作的優(yōu)化建議。 界面字符或提示與的顯示不恰當。 頁面或操作習慣的優(yōu)化性建議。 功能操作更好的實現(xiàn)方式。注：嚴重等級由創(chuàng)建者在創(chuàng)建缺陷時根據此定義來選擇，之后都不能隨意

11、更改 (5)優(yōu)先級的定義優(yōu)先級定義和說明立刻阻礙測試工作無法進行，需要開發(fā)工程師馬上解決問題。 所有的致命問題都需要立刻解決；時間急迫時影響版本上線的問題等；緊急不影響測試工作的嚴重問題，下個測試版本發(fā)版前必須解決。 所有嚴重冋題；常用模塊功能、業(yè)務邏輯或數據錯誤；明顯的性能問題；盡快一般性功能錯誤，版本發(fā)布前應該解決的冋題。大多數一般冋題；頁面顯示，頁面的字符，界面圖標、文字顯示、鏈接有誤，不影響使用。如 錯別字，圖標顯示異常等；一般不影響版本上線的問題，部分問題允許不修改。 非常用界面或字符的顯示錯誤或不恰當； 用戶使用習慣，語言表達等優(yōu)化建議；注：立刻、緊急、盡快的問題都要求在系統(tǒng)上線前

12、解決(6) 發(fā)生概率定義發(fā)生概率定義說明驗證問題最小次數必現(xiàn)100%。測試5次，出現(xiàn)5次。5次經常100%&=30%測試5次，出現(xiàn)34次；或測試10次，出現(xiàn)3次及以上；或測試15次，出現(xiàn)5次及以上。10次偶爾30%&=10% 測試10次，出現(xiàn)2次；或測試15次，出現(xiàn)24次。20次隨機10%。測試15次，出現(xiàn)1次。30次(7) 處理狀態(tài)說明處理狀態(tài)相關規(guī)則確認中當問題確認過程時，可以選擇這狀態(tài)來說明。解決中開發(fā)工程師設置此狀態(tài)。當Bug正在分析或解決時，可選這狀態(tài)來說明。復現(xiàn)中當正在復現(xiàn)問題，或者正在跟蹤測試問題，可以選擇這狀態(tài)來說明。驗證中當驗證隨機問題等需要長時間，可以選擇這狀態(tài)來說明。延期

13、解決項目經理才能設置此狀態(tài)，參考5.2(8) 解決方案定義與規(guī)則解決方案方案說明相關規(guī)則已經解決缺陷被修復或更正，并通過其驗 證測試。開發(fā)工程師權限，解決時需要填寫“解決版 本”和注明Bug原因等。重復缺陷相冋的缺陷別人已經提交，或者 開發(fā)認為原因是相同的開發(fā)工程師權限，解決時需要填寫正確的重 復缺陷ID。無效缺陷設計如此，不是問題，優(yōu)化建議 不采納，沒法解決的第三方問題。開發(fā)工程師需要與創(chuàng)建者溝通說明，直到創(chuàng) 建者冋意，開發(fā)工程師才能選擇此方案。無法復現(xiàn)開發(fā)和測試工程師沒法復現(xiàn)又不 能解決的問題，并且跟蹤測試二 個以上版本也不能復現(xiàn)。開發(fā)和測試工程師經過努力也不能復現(xiàn)，并 由測試工程師跟蹤測

14、試二個以上版本，開發(fā) 工程師才能選擇此方案。延期解決開發(fā)工程師Bug進行解決時，發(fā) 現(xiàn)或評估其解決時間緊或風險比 較大等，向項目經理說明原因。項目經理的權限，項目經理綜合通過考慮解 決冋題的時間、風險、市場需求等多方面要 素決定是否選擇此方案注：無法復現(xiàn)問題將作為風險評估點5.5缺陷描述規(guī)范(1)缺陷標題缺陷標題是對所提交缺陷的概述，需要簡短而準確的描述出缺陷概要信息， 并使用一些精煉的關鍵詞，主要內容包括：位置 +對象+動作+現(xiàn)象。a. 環(huán)境關鍵詞：包括數據環(huán)境，時間環(huán)境，地點環(huán)境條件環(huán)境，描述缺陷發(fā)生時所處的背景環(huán)境，或正在執(zhí)行的操作或所處的界面環(huán)境，如“在” 頁面，“當時”，“在過程中”

15、等；b. 動作關鍵詞：弓I發(fā)缺陷所執(zhí)行的操作，如“點鍵”“選選項”等；c. 對象的關鍵詞：描述缺陷出現(xiàn)的對象，“頁面”，“顯示框” ，“圖 表”等；d. 現(xiàn)象的關鍵詞： 描述缺陷出現(xiàn)的現(xiàn)象， 如“顯示為負數” ，“卡死”等。 根據上述關鍵詞的組合來描寫缺陷標題。（2）重現(xiàn)步驟 在描述缺陷重現(xiàn)步驟的過程中，通常需要通過描述前提條件，測試步驟，實 際結果，期望結果這四個方面清楚詳細的描述缺陷。a. 前提條件 外部環(huán)境，這里包括網絡環(huán)境，硬件環(huán)境和軟件環(huán)境的狀態(tài)。默認情況下， 無需特殊說明，前提條件均為“系統(tǒng)正常運行”，其含義為網絡正常，電腦硬件 環(huán)境能支撐軟件運行， 系統(tǒng)軟件配置情況正常。 需要注

16、意， 軟件環(huán)境有可能弓發(fā) 缺陷的功能模塊所處的狀態(tài)， 以及重現(xiàn)該缺陷需要的模塊相關狀態(tài)或者特殊設置 情況應該前在前提條件中做說明。數據環(huán)境，對缺陷產生的所在案件或引發(fā) bug現(xiàn)象的數據輸入和數據設計等 應該在前提條件中做相應說明?？傊?，這里對缺陷現(xiàn)象重現(xiàn)緊密相關的預先設置， 或與缺陷模塊相關聯(lián)的預 先設置都應該在前提條件中說明。b. 測試步驟這里需要詳細描述出重現(xiàn)缺陷的操作步驟， 以便于重現(xiàn)缺陷， 修復和驗證缺 陷。在描寫測試步驟時應該注意以下幾點：精簡：只描述缺陷必須的細節(jié)； 單一：每個缺陷單只報告一個缺陷； 步驟清晰：詳細的、有序的描述出每一個步驟，包括輸入的數據情況，執(zhí)行 的操作以及執(zhí)行

17、操作的界面。操作量化：對操作次數的描述需要量化，如“連續(xù) 3次點確認鍵”等，盡量 避免出現(xiàn)“多次”等模糊的詞。c. 實際結果實際結果是指按照測試步驟操作后實際反映的情況， 這里指的是缺陷的表現(xiàn) 現(xiàn)象。這里應該詳細描述出錯誤的現(xiàn)象，包括頁面錯誤，連接錯誤，字符錯誤， 業(yè)務流程錯誤，數據錯誤等。d. 期望結果期望結果是指按照測試步驟操作， 正常情況下正確執(zhí)行測試步驟后應該滿足 設計要求的結果。對于不確定的期望結果就需要用到如建議，提示等關鍵字。 （ 3） 附件為了方便開發(fā)工程師分析和解決， 創(chuàng)建缺陷時需要添加必要的附件， 包括缺 陷現(xiàn)象圖、測試的數據文檔，測試時用到的其他特殊文件，測試腳本，操作步驟 的錄像等。所以，測試人員在測試的過程中，要求每個缺陷有現(xiàn)象截圖，以便協(xié)助開發(fā) 人員快速定位問題。僅供個人用于學習、研究；不得用于商業(yè)用途For personal use only in study and research; not for commercial use.Nur f u r d