缺陷劃分規(guī)劃

1、缺陷劃分規(guī)劃為了在各項目中后期能對各項目質量做比較全面合理的評估， 本次缺 陷管理過程中定義了比較充分的質量評估考察點， 將缺陷進行了多角 度劃分，下面將各劃分方法一一列出。1.1缺陷（defect ）與錯誤的嚴重級別（severity ）定義問題性質QC中級別概要描述詳細描述致命性問題5-Urge nt（緊急）引起系統(tǒng)數(shù)據(jù)錯誤、操作不能繼續(xù)進行、死機、系統(tǒng)崩潰等問題；系統(tǒng)崩潰造成系統(tǒng)宕機應用系統(tǒng)停止工作導致程序異常退出的錯誤4-VeryHigh （非常高）應用程序不能正常運行窗口打開異常死循環(huán)數(shù)據(jù)被破壞資源泄露嚴重性明顯功能性問題3-High（高）功能不能正常完成或完成有誤的問題主要功能未正

2、常實現(xiàn)功能執(zhí)行錯誤彈出系統(tǒng)異常告警性問題2-Medium（中）功能完成正常，但由于 非正常操作而引起系統(tǒng) 提示警告，屬于系統(tǒng)健 壯性問題；系統(tǒng)容錯處理異常輸入框沒有按照約定進行數(shù)據(jù)約束窗口沒有按照既定規(guī)定處理沒有合理彈出應用異常處理（正常提 示）建議性問題1-Low （低）不影響目前系統(tǒng)的使用，但可進行進一步完 善和優(yōu)化，是測試人員 提出的優(yōu)化建議；界面文字拼音錯誤；不影響目前系統(tǒng)的使用，但可進行進步完善和優(yōu)化，是測試人員提出的優(yōu)化建議；1.2缺陷（defect ）的狀態(tài)（status ）定義優(yōu)先級別描述New（新建）測試中新報告的軟件缺陷Open （打開）被確認并分配給相關開發(fā)人員處理Fix

3、ed （已修復）開發(fā)人員已完成修正，等待測試人員驗證Reopen （重新打開）對開發(fā)人員已修復的缺陷，經(jīng)回歸測試后發(fā)現(xiàn)問題仍然存在Rejected （已否決）拒絕修改此缺陷，但要說明拒絕理由Postponed （延遲修改）不在當前版本修復的錯誤，下一版修復Closed （已關閉）缺陷已被成功修復1.3缺陷（defect ）的優(yōu)先級（priority ）定義優(yōu)先級別描述5-Urgent （緊急）高優(yōu)先級，馬上響應，對于緊急需要處理的問題。般要求2小時內必須要求開發(fā)組做出響 應。4-Very High （非常高）高優(yōu)先級，優(yōu)先級比5級低，但是也是高優(yōu)先級，需要開發(fā)組盡快給予響應，一般要求當天 內必

4、須要求開發(fā)組做出響應。3-High （高）高優(yōu)先級，優(yōu)先級比4級低，但是也是高優(yōu)先 級，需要開發(fā)組盡快給予響應，一般要求幾天 內開發(fā)組必須做出響應。2-Medium（中）低優(yōu)先級，響應時間要求更為寬松，需要開發(fā) 組在限定的時間內予以響應，比如幾個星期。1-Low （低）低優(yōu)先級，優(yōu)先級比2級更低 些，需要開發(fā) 組在限定的時間內予以響應，甚至可以不用修 改，只要寫清原因：如時間緊暫時不改、可以 忽略等。1.4缺陷（defect ）類型定義缺陷類型描述1-代碼錯誤因開發(fā)人員代碼實現(xiàn)錯誤引起的缺陷（如：查詢結果不對）2-界面優(yōu)化操作界面中圖標、按鈕、文字、鏈接等大小位置不規(guī)范，需要優(yōu)化界面3-界面設

5、計功能能正確實現(xiàn)，但是操作方式不優(yōu)，用戶時候用起來很費勁，如冋 類的幾個功能分到幾個操作界面中，使用戶使用起來不好操作又不好 理解4-系統(tǒng)設計表明此缺陷是因系統(tǒng)設計引起，如模塊功能劃分，開發(fā)架構選型5-數(shù)據(jù)庫設計表明此缺陷是因數(shù)據(jù)庫設計引起6-數(shù)據(jù)庫與程序不一 致表明此缺陷是因數(shù)據(jù)與程序實現(xiàn)不 致引起7-設計變更表明此缺陷是因設計已變更而不考慮編碼引起8-數(shù)據(jù)錯誤表明此缺陷是因數(shù)據(jù)庫數(shù)據(jù)有誤引起的9-需求不合理表明此缺陷是因用戶所提需求不合理或前后矛盾引起10-需求變更表明此缺陷是因用戶需求變更而不滿足現(xiàn)實需求引起的2.缺陷提交規(guī)范2.1缺陷提交原則清晰、可重現(xiàn)、不重復2.2缺陷填寫要求缺陷填

6、寫要求：（門概述（summary :必填，要求簡單扼要的描述缺陷的出現(xiàn)位置以及缺陷的特征；女口：用戶管理-用戶維護信息：Tab鍵跳格功能問題: 矚慫潤厲釤瘞睞櫪廡賴。（2）分派到（Assigned to ）:必填，新提交的問題同意分配給子系 統(tǒng)的開發(fā)組長；（3）檢查者（Detected by ）:必填，問題提交者，默認自己；（4）測試版本（Detected in Version ）:必填，問題最開始發(fā)現(xiàn)的軟件版本號；（5）測試日期（Detected on Date）:必填，問題最開始提交的日期， 默認為當天；（6）優(yōu)先級（Priority ）:必填，問題要求解決的優(yōu)先級，越高表示 要求開發(fā)盡快

7、修復問題；（7）嚴重級別（severity ）:必填，問題本身的嚴重級別，越高表示問題越嚴重（嚴重級別請以及項目問題的級別劃分規(guī)則進行劃分）；聞創(chuàng)溝燴鐺險愛氌譴凈。（8）狀態(tài)（status ）:必填，問題的狀態(tài)，新提交時默認為“ NeW;（9）模塊名（subject ）：必填，問題屬于哪個模塊（細分到第一級 功能點）；（10）子系統(tǒng)（subsystem）:必填，問題屬于哪個子系統(tǒng)；（11）項目名稱（project name :所測試的軟件項目或軟件產(chǎn)品名；（12） 缺陷類型：根據(jù)測試人員自己的經(jīng)驗確定一個缺陷類型，標明 該缺陷是哪一類型。（13）測試類型：該缺陷是在進行什么類型的測試過程等中發(fā)

8、現(xiàn)的。（14）測試所處的階段：表示該缺陷測試在軟件生命的哪個時期發(fā)現(xiàn) 的。（佝詳細描述（Description ）:必填，詳細描述問題：什么系統(tǒng)什么模塊什么操作時輸入什么數(shù)據(jù)時出現(xiàn)什么樣的問題，什么情況下就不會出現(xiàn)問題，以及有無附件圖片，如果有建議，則寫出修改建議；一 般地可按如下方式進行書寫缺陷：殘騖樓諍錈瀨濟溆塹籟。*操作步驟：第一步：進入 XX模塊做XX操作；預期結果：系統(tǒng)出現(xiàn)XX的頁面*實現(xiàn)結果：在界面上錄入信息時，按 TAB鍵應該有序的一個一個跳 到下一個輸入編輯框，可是光標并沒有按順序跳；釅錒極額閉鎮(zhèn)檜豬訣錐。*修改建議：調整界面上TAB鍵自動跳格功能（16）注釋（R&D Comments）開發(fā)與測試就問題的處理等交互作用的 BBS填寫時要求先點擊“ Comment按鈕簽名，然后填寫想要說明的 內容，然后寫清楚本次說明的內容是在哪個版本上測試的。如下面的例子： 彈貿攝爾霽斃攬磚鹵廡。例：王傳寶vwangcb:2009-6-2:順序后已經(jīng)調整好，請測試人員進行 回歸測試。2.3缺陷提交注意點（1）BUG苗述一定要簡潔清楚；（2）盡量把錯誤用附件圖抓下來；（3）提交BUG寸，操作以及數(shù)據(jù)都要描述清楚；（4）對于有些于測試機器環(huán)境有關的問題，可以