confidential 缺陷管理流程
version 1.0
文件模板變更記錄
檔案狀態：
[ ]草稿
[√]正式發布當前版本：v1.0
作者：羅偉
審核人：朱守民
發布日期：2009-9-10
修訂號修改內容描述修改人修改日期備註123
目錄1. 引言 (1)
1.1. 文件目的 (1)
1.2. 適用範圍 (1)
1.3. 讀者物件 (1)
1.4. 術語與縮略語 (1)
2. 缺陷跟蹤流程 (1)
2.1. 缺陷狀態 (1)
2.2. 缺陷生命週期 (3)
2.2.1. 缺陷流程圖 (3)
2.2.2. 流程圖說明 (3)
3. 角色與職責 (4)
3.1. 測試組長/經理 (4)
3.1.1. 職責 (4)
3.1.2. mqc許可權 (4)
3.2. 測試人員 (4)
3.2.1. 職責 (4)
3.2.2. mqc許可權 (4)
3.3. 開發組長/經理 (5)
3.3.1. 職責 (5)
3.3.2. mqc許可權 (5)
3.4. 開發人員 (5)
3.4.1. 職責 (5)
3.4.2. mqc許可權 (5)
3.5. 專案經理 (5)
3.5.1. 職責 (5)
3.5.2. mqc許可權 (6)
3.6. 需求方專家 (6)
3.6.1. 職責 (6)
3.6.2. mqc許可權 (6)
3.7. 配置管理員 (6)
3.7.1. 職責 (6)
3.7.2. mqc許可權 (6)
3.8. qa (7)
3.8.1. 職責 (7)
3.8.2. mqc許可權 (7)
3.9. 瀏覽者 (7)
3.9.1. 職責 (7)
3.9.2. mqc許可權 (7)
4. 缺陷提交規範 (7)
4.1. 缺陷提交原則 (7)
4.2. 缺陷填寫要求 (8)
5. 附錄 (9)
5.1. 缺陷屬性定義 (9)
1.引言
1.1.文件目的
本文件對測試工作中角色、測試流程、缺陷管理規範、缺陷跟蹤規範進行了定義，並明確了測試工作中每個角色的職責，保證測試流程的正確執行，保證測試工具被正確地使用。
1.2.適用範圍
本文件適用於本公司各研發類與實施類專案的功能測試和系統測試階段的測試活動，從開發人員提交第一次測試開始，到專案結束期間的測試工作。
1.3.讀者物件
本流程讀者物件為公司專案組所有成員。
本流程是保證缺陷跟蹤流程順利執行的前提，所有專案組成員需要按流程規範履行職責。對缺陷管理流程有特殊要求的專案組，可告知專案組pqa人員做適當的調整。
1.4.術語與縮略語
mqc：mercury quality center，hp公司的綜合測試管理工具，用於組織和管理應用程式測試流程的所有階段，包括指定測試需求、計畫測試、執行測試和跟蹤缺陷。
2.缺陷跟蹤流程
2.1.缺陷狀態
缺陷通過乙個跟蹤修復過程的進展情況。包括：新建（new）、開啟（open）、重新開啟（reopen）、已修復（fixed）、關閉（closed）、拒絕（rejected）、掛起/凍結（suspend）和無效（no bug）。
新建（new）為測試人員新問題提交所標誌的狀態。
開啟（open）為任務分配人（專案經理授權）對該問題準備進行修改並對該
問題分配修改人員所標誌的狀態，表示缺陷解決中的狀態，由
任務分配人改變。
第1頁/共9頁
重新開啟（reopen）為測試人員對修改問題進行驗證後沒有通過所標誌的狀態；或
者已經修改正確的問題，又出現新的錯誤，由測試人員改變。
已修復（fixed）為開發人員修改問題後所標誌的狀態。
關閉（closed）為測試人員對修改問題進行驗證後通過所標誌的狀態，由測試
人員改變。
拒絕（rejected）開發人員認為不是缺陷、描述不清、重複、不能復現、不採納
所提意見建議、或雖然是個錯誤但還沒到非改不可的地步故可
忽略不計、或者測試人員提錯，從而拒絕的問題。由缺陷分配
人或者開發人員來設定。
無效（no bug）測試人員確認拒絕的缺陷，如缺陷拒絕的合理，置狀態為無效。
掛起/凍結（suspend） 1.開發人員和測試人員對問題有不同意見需要討論時，可將
缺陷暫時設為該狀態，由提交此缺陷的測試人員負責後續
跟蹤處理；
2.對於有些缺陷，開發組也承認的確是個問題，但本階段不
進行修改，而是只保留做將來參考之用或其它用途，則開
發組長/經理對其作掛起處理，對本階段而言是缺陷最終狀
態之一。
2.2.缺陷生命週期
2.2.1.缺陷流程圖
2.2.2.流程圖說明
正常缺陷生命週期流程：新建—開啟—已修復—關閉。
由測試人員發現缺陷，並加入缺陷列表，缺陷狀態為「新建」。
開發經理（或授權人）分析缺陷，確認則設定狀態為「開啟」，並分配給相應開發人員。如果不是缺陷或不能重現，專案經理（授權人）和開發人員都有許可權將缺陷狀態置為「拒絕」，並在qc的comment說明原因。
測試組驗證「拒絕」狀態的缺陷，並和專案組進行討論直至達成一致，如果確認拒絕的問題合理置狀態為「無效」，如果不合理則由專案經理（授權人）置狀態為「開啟」並
分配，對於不能解決和延期解決的缺陷，置狀態為「掛起（凍結）」，均需要在qc的comment說明原因。
開發人員修復缺陷後，把缺陷由「開啟」置為「已修復」，需要在qc中的comment註明修改方式及版本號。
測試人員對缺陷進行回歸測試，如果修改正確，把缺陷狀態由「已修復」置為「關閉」，如果缺陷還是存在，則置為「重新開啟」，重新提交開發人員。
3.角色與職責
3.1.測試組長/經理
3.1.1.職責
負責專案測試管理工具mqc的搭建，包括建立使用者、分配許可權、使用講解和工具維護。負責設定角色、角色許可權、檢查監督錯誤跟蹤流程。
審核測試人員提交的缺陷，對長期處於中間狀態的缺陷查詢原因，使其繼續流轉下去。定期對缺陷庫進行分析，描繪出曲線圖等，報告現狀、**趨勢。在測試總結報告中給出意見。
許可權可新增、修改、刪除缺陷。
缺陷狀態可執行：任何狀態->任何狀態。
3.2.測試人員
3.2.1.職責
發現問題時按缺陷提交規範要求提交新的缺陷。
跟蹤自己提交的問題，對狀態為已修復的問題進行確認回歸測試。
對狀態為拒絕的問題，及時檢查拒絕原因，如果不同意拒絕，則主動與開發人員溝通，確定缺陷的狀態。
對狀態為掛起的問題，主動檢視原因後與開發人員討論後進行後續處理。
許可權可新增，修改缺陷，不能刪除缺陷
缺陷狀態可執行：已修復->關閉、重新開啟；拒絕->無效、掛起、重新開啟；
掛起->開啟、關閉。
3.3.開發組長/經理
3.3.1.職責
每天對新建的問題進行分配（也可授權技術負責人進行），並根據缺陷原因，標註處理意見，給定緊急程度。
對於諮詢類、理解錯誤類等不是缺陷的問題，置狀態為「拒絕」，並在注釋中簽名並填寫原因；對於確實是缺陷的問題，置狀態為「開啟」並分配給相應開發人員。
對開發人員拒絕的問題，進行分析，及時確定問題狀態。
每天對新增的掛起類問題進行處理，標註處理意見，更新其狀態。
許可權可新增，修改缺陷，不能刪除缺陷
缺陷狀態可執行：新建->開啟，拒絕，掛起；開啟->已修復、拒絕、掛起；
重新開啟->已修復；掛起->開啟。
3.4.開發人員
3.4.1.職責
負責對分配給自己的缺陷在qc中跟蹤修復。
負責對缺陷進行設計開發和內部測試
許可權可新增，修改缺陷，不能刪除缺陷
缺陷狀態可執行：開啟->已修復；開啟->拒絕；重新開啟->已修復。
3.5.專案經理
3.5.1.職責
負責對缺陷庫中所有的問題進行跟蹤處理。
每天對新增的掛起類問題進行處理，標註處理意見，更新其狀態。
定期對缺陷庫分析，找出常出錯的模組，進行**審查。
許可權可新增，修改缺陷，不能刪除缺陷
缺陷狀態可執行：任何狀態->任何狀態
3.6.需求方專家
3.6.1.職責
對存在業務不理解與需求不明確的問題給出修改建議。
對開發方與客戶方存在分歧的問題給出修改建議。
許可權可新增，修改缺陷，不能刪除缺陷
缺陷狀態可執行：已修復->關閉、重新開啟；拒絕->無效、掛起、重新開啟；
掛起->開啟、關閉。
3.7.配置管理員
3.7.1.職責
負責從開發人員處獲取最新程式**，發布測試環境並確定版本，以及該版本更新的內容。
乙個版本經測試人員測試完畢後，配置管理員從mqc中獲取該版本出現的缺陷，與下一次的版本更新內容做對比，進行版本管理和版本控制。
對在多個版本反覆出現的問題進行跟蹤。
許可權可新增、修改缺陷
缺陷狀態可執行：已修復->關閉、重新開啟；拒絕->無效、掛起、重新開啟；
掛起->開啟、關閉。
3.8.1.職責
質量管理人員負責對整個缺陷流程的跟蹤。
負責指導流程相關方正確使用需求跟蹤工具mqc。
負責提供《缺陷狀態報告》。
許可權可新增、修改、刪除缺陷。
缺陷狀態可執行：任何狀態->任何狀態。
3.9.瀏覽者
3.9.1.職責
對有檢視要求的人員賦予該職責
許可權不可新增、修改、刪除缺陷。
缺陷狀態可執行：無
4.缺陷提交規範
4.1.缺陷提交原則
缺陷描述的要求為分類準確、敘述簡潔、步驟清楚、有例項、易再現、複雜問題有據可查（截圖或其它形式的附件）。測試組長/經理把關，以開發人員的角度來審查缺陷描述，檢查是否描述清楚了缺陷，具體要求為：
問題描述一般格式：問題描述時，建議分幾步描述：模組或功能點=>測試步驟=>期望結果=>實際結果=>其它資訊，可依實際情況調整；
簡潔：每個步驟的描述應盡可能簡潔明瞭。只解釋事實、演示和描述軟體缺陷必要的細
節，不要寫無關資訊；
再現：問題必須在自己機器上能復現方可入庫（個別嚴重問題復現不了也可入庫，但需標明）；
複雜的問題應附截圖補充說明或直接通知指定的修改人
報告中不允許使用抽象詞句：比如「有錯誤」、「是不是？」「請開發人員確認」等等之類；
有關作業系統特徵問題：應在不同作業系統上進行操作，看是否能重現，並在缺陷報告中標識；
4.2.缺陷填寫要求
（1）問題摘要：必填，要求簡單扼要的描述缺陷出現的以及缺陷的特徵。
（2）已分配給：必填，新提交的問題分配給相應的開發人員。
（3）檢測人：問題提交者，預設為自己。
（4）檢測版本：必填，問題最開始發現的軟體版本號，對應開發的版本號。
（5）測試日期：問題最開始提交的時間，預設為當天。
（6）緊急程度：由開發組長填寫，問題要求解決的優先順序，越高表示開發盡快修復問題。
（7）嚴重程度：必填，問題本身的嚴重級別，越高表示越嚴重（嚴重級別請以專案劃分的嚴重級別規則進行劃分）。
（8）問題狀態：問題的狀態，新提交時預設為「新建」。
（9）主題：必填，問題屬於哪個模組，關聯測試計畫根目錄。
（10）問題描述：必填，詳細描述問題，描述中必須包括預期結果和實際結果，盡量附圖，如有建議，寫出修改建議。
（11）問題類別：必填，問題實際發生的原因。
（12）問題處理意見：專案人員對缺陷給出處理的建議，均可讀寫。
（13）專案經理處理意見：專案經理對缺陷給出處理的建議，只有專案經理可寫。
（14）需求方處理意見：需求方專家對缺陷給出處理的建議，只有需求方專家可寫。
缺陷描述規範
摘要簡練描述什麼模組出現什麼型別的錯誤
描述以什麼使用者登入系統執行什麼操作
產生什麼錯誤結果
預期結果
截圖提供錯誤頁面的截圖，附在缺陷中
comment交流缺陷修改情況
5.附錄
5.1.缺陷屬性定義
零缺陷管理
零缺陷管理簡稱zd。亦稱 缺點預防 零缺陷管理的思想主張企業發揮人的主觀能動性來進行經營管理，生產者 工作者要努力使自己的產品 業務沒有缺點，並向著高質量標準的目標而奮鬥。目錄簡介 產生 基本內涵和基本原則 1.概括 2.具體要求 菲利浦 克勞斯比與 零缺陷 樹立零缺陷管理的理念 實施步驟 成功案例...
零缺陷管理
零缺陷概念的產生 被譽為 全球質量管理大師 零缺陷之父 和 偉大的管理思想家 的菲利浦 克勞士比 philip b.crosby 在20世紀60年代初提出 零缺陷 思想，並在美國推行零缺陷運動。後來，零缺陷的思想傳至日本，在日本製造業中得到了全面推廣，使日本製造業的產品質量得到迅速提高，並且領先於世...
裝置缺陷設施缺陷管理制度
1 目的 本裝置缺陷管理制度實施細則目的是為了提高裝置健康水平，力求實現機組安全 經濟 穩定執行，及時消除裝置及系統存在的缺陷，規範缺陷管理流程，真實反應裝置健康狀態，依據裝置缺陷管理制度之規定，結合公司實際情況，特制定本細則。2 引用標準及關聯子系統 2.1 風險管理子系統 2.2 執行管理子系統...