1、缺陷管理指導書 卓望數碼技術(深圳有限公司 版權所有 內部資料 注意保密 修訂記錄: 目 錄1 目的與范圍 . 42 定義與縮略語 . 42.1 定義 . 4 2.2 縮略語 . 43 控制機制 . 54 缺陷級別 . 55 缺陷狀態 . 65.1 狀態定義 . 6 5.2 狀態遷移 . 66 相關工具 /表格 /記錄 . . 11附錄:引用 . 12 1 目的與范圍本文描述 Test Director 和 ClearQuest 中缺陷管理的相關內容(下面簡稱缺陷管理辦法 , 為參與缺陷管理活動的人員提供信息和指導,以保證開發的產品滿足功能、質量等方面的配 置屬性。文件提供缺陷管理的一般性指導

2、,不同產品可以進行裁剪和修訂,制訂符合具體產 品的缺陷管理規范,產品的缺陷管理規范必須經質量管理部審核批準后才能實施。本文描述的缺陷管理規范適用于卓望公司的所有產品的軟件測試工作。主要的使用人員 為系統測試部和產品線。2 定義與縮略語2.1 定義缺陷 :存在于一個已交付產品中的異常現象或缺陷。這樣的例子包括在生命周期的早期 階段發現的疏忽和有缺陷的地方,以及在一個足以成熟的用于測試或操作的軟件中包含的錯 誤的癥狀。缺陷可以是任何你想跟蹤并解決的問題。2.2 縮略語 3 控制機制測試 TWG 、系統測試部負責維護本指導書, SEPG 組長審核、質量部主管 VP 簽發本 指導書。4 缺陷級別 5

3、缺陷狀態5.1 狀態定義NEW :新增的缺陷OPEN :開發人員處理中的缺陷FXIED :開發人員已修復的缺陷VERIFIED :測試人員已驗證的缺陷SUSPENDED :開發人員掛起暫不解決的缺陷REOPEN :測試人員重新打開的缺陷REJECTED :開發人員拒絕的缺陷CLOSED :關閉的缺陷5.2 狀態遷移 動作 1:缺陷提交(Submit Defeat輸入:發現缺陷輸出:缺陷已創建,缺陷狀態變成 NEW 。角色和活動:STE-測試人員提出缺陷并說明其類型及評估。必須給出缺陷的嚴重級及優先 級以及基本的描述。 具體可以參考缺陷中的缺陷提交表單 (見附件 。 如 果測試人員可以將此缺陷定

4、位到某開發人員,則此開發就已經獲得授權 進行修改了;如果不能,則需要提交給項目經理或開發組長,項目經理 或開發組長對問題做進一步的分析,然后授權某開發人員修改。動作 2:缺陷打開(Open Defeat輸入:已創建的缺陷請求。輸出:項目經理或開發組長對這個缺陷進行初步的接納和確認,狀態由 NEW 變成 OPEN 。角色和活動:PM/TL-D-項目經理或開發組長對這個變更進行初步的接納和確認,表示其已 經進入處理階段。動作 3:缺陷拒絕(Reject Defeat輸入:已提交缺陷請求輸出:項目經理或開發組長拒絕此缺陷,狀態由 OPEN 變成 REJECTED 。角色和活動:PM/TL-D-項目經

5、理或開發組長對已提交的缺陷進行評估后 , 認為有理由拒絕 , 并且將理由寫在表單上, 由測試人員確認, 如果存在爭議, 由產品經理、 項目經理、測試主管,直至 CCB 對此進行進一步評估。動作 4:已拒絕的缺陷重新打開(Reopen Defeat輸入:項目經理或開發組長已拒絕的缺陷請求輸入準則:評估后確認需要修復的已拒絕的缺陷請求輸出:測試人員重新打開已拒絕的缺陷,變更狀態由 REJECTED 變成 REOPEN 。 角色和活動:STE-對已拒絕的缺陷進行評估后 , 認為有必要修復此缺陷 , 測試人員將評估結 果寫在表單上并將缺陷打開,開發人員重新處理此缺陷。動作 5:缺陷掛起(Suspend

6、 Defeat輸入:已提交的缺陷請求輸出:項目經理或開發組長暫時掛起此缺陷,缺陷狀態由 OPEN/REOPEN/NEW變 成 SUSPENDED 。角色和活動:PM/TL-D-項目經理或開發組長評估已提交的缺陷,如果認為此缺陷由于某些 原因目前還不能完成, 可以注明掛起原因, 并將此缺陷的狀態變為掛起。 在今后的缺陷回顧報告 見附件 和缺陷回顧會議 見附件 上要重點進行 討論,來決定此掛起的缺陷將在什么時候解決。動作 6:缺陷重啟動(Reopen Defeat輸入:項目經理或開發組長已掛起的缺陷請求輸出:項目經理或開發組長重新啟動已掛起缺陷, 狀態由 SUSPENDED 變成 OPEN 。 角

7、色和活動:PM/TL-D-項目經理或開發組長評估曾經掛起的缺陷,如果認為此缺陷有條件 或必需重新給予考慮可以將此缺陷重新啟動。動作 7:缺陷任務執行(Fix Defeat輸入:項目經理或開發組長已分配的缺陷修復任務輸出:開發人員完成任務,缺陷狀態由 OPEN/REOPEN變成 FIXED 。角色和活動:SDE-開發人員根據項目經理或開發組長分配 /授權的任務以及相應的資源環 境,進行變更的完成,并提交該完成的任務,等待驗證。對動作 7的說明:如果經 CCB 確認此缺陷設計到對需求,高層設計,底層設計修改 的話,那么后續流程請按照變更控制管理規范 。動作 8:缺陷任務驗證通過(Verify De

8、feat輸入:被提交了的已完成的缺陷修復任務。輸出:驗證變更任務成功,缺陷狀態由 FIXED 變成 VERIFIED 。角色和活動:STE-測試人員對提交的已完成的缺陷任務進行充分的驗證,如果此提交的版 本成功完成了缺陷修改請求里的要求,則視為驗證通過。動作 9:缺陷修復任務驗證拒絕(Reopen Defeat輸入:被提交了的已完成的缺陷修復任務。輸出:驗證缺陷修復失敗,缺陷狀態由 FIXED 變成 REOPEN 。角色和活動:STE-測試人員對提交的已完成的缺陷修復任務進行充分的驗證,如果此提交 的版本沒有成功完成缺陷修復請求里的要求,則視為驗證失敗,并拒絕 之。動作 10:驗證通過的缺陷修

9、改請求關閉(Close Defeat輸入:已經成功被驗證的缺陷修復任務。輸出:將已成功被驗證的缺陷修復任務關閉,缺陷狀態由 VERIFIED 變成 CLOSE 。 角色和活動:TL-T-測試主管對已成功被驗證的缺陷修復請求進行審查,如果沒有其他問題 就可以將此缺陷修復請求予以關閉。6 缺陷類型 缺陷管理指導書 5、 因單元測試案例中因單元對外接口的案例的缺失或不清晰或錯 誤引起的缺陷。 7 缺陷根源 缺陷根源 產品需求 軟件需求 架構設計 高層設計 底層設計 編碼 版本發布測試案例 系統測試案例 集成測試案例 單元測試案例 用戶文檔 其他 根源描述 指因產品需求規格說明書的內容缺失、 不清晰或

10、錯誤在本交付物或后 續交付物中引起的缺陷； 指因軟件需求規格說明書的內容缺失、 不清晰或錯誤在本交付物或后 續交付物中引起的缺陷； 指因架構設計說明書的內容缺失、 不清晰或錯誤在本交付物或后續交 付物中引起的缺陷； 指因高層設計說明書的內容缺失、 不清晰或錯誤在本交付物或后續交 付物中引起的缺陷； 指因底層設計說明書的內容缺失、 不清晰或錯誤在本交付物或后續交 付物中引起的缺陷； 指因編碼的缺失或錯誤在本交付物或其他交付物中引起的缺陷； 指因版本發布測試案例的缺失、 不清晰或錯誤在本交付物中引起的缺 陷； 指因系統測試案例的缺失、不清晰或錯誤在本交付物中引起的缺陷； 指因集成測試案例的缺失、不清晰或錯誤在本交付物中引起的缺陷； 指因單元測試案例的缺失、不清晰或錯誤在本交付物中引起的缺陷； 指因用戶文檔的內容缺失、不清晰或錯誤在本交付物中引起的缺陷； 非上述根源引起的缺陷 缺陷類型與缺陷根源的對應關系見附錄一。 8 缺陷模式 模式 缺失 不清晰 錯誤 模式描述 指因文檔的內容描述或代碼實現的缺失引起的缺陷 指因文檔的內容描述不清晰引起的缺先 指因文檔的內容描述或代碼實現的錯誤引起的缺陷 9 相關工具/表格/記錄 無。 第 11 頁 附錄：引用 9.1 附錄一：缺陷類型及缺陷根源的對應關系。 注：打指在此類型缺陷由對應的根源產生，缺陷根源與缺陷類型交叉處無者即該類缺陷不可