OI-IT-20-缺陷管理規(guī)范

1/1OI-IT-20_缺陷管理規(guī)范缺陷管理規(guī)范2012年12月27日起發(fā)布實施文檔修訂歷史修訂版本修訂日期作者審核人批準人說明目的本文檔用于規(guī)范信息系統(tǒng)部缺陷管理的過程以及與缺陷相關的一些屬性。

適用范圍本文檔適用于研發(fā)測試過程中所有缺陷的處理。

定義/專用術語Administrators:系統(tǒng)管理員Developer:開人員Users：

AllMembersBug：

缺陷職責配置組：

定期對Jira系統(tǒng)及數(shù)據庫進行維護，數(shù)據備份。

(建議每天備份時間為24：

00)測試組：

依照需求規(guī)格及測試用例進行測試。

提交Bug，IssueType必須選為BUG類型，對Bug進行狀態(tài)跟蹤，對已交付Bug進行驗證；項目組定期組織會議跟蹤Bug處理進度，定期提交Bug匯總報告。

開發(fā)組：

及時接收處理Bug，修復Bug所涉及相關問題，如因其他原因不能及時修復，應及時將原因通知項目經理，由項目組協(xié)調決定是否修復，并在Bugcomment中注明緣由。

項目組應定期組織會議，對未修復Bug進行協(xié)商，或調整優(yōu)先級。

工作程序缺陷理論5.1.1缺陷生命周期從提交到關閉狀態(tài)，所有bugs都要經歷一個特定的生命周期，信息系統(tǒng)部缺陷生命周期是在Jira中定義的，它一共有5個狀態(tài)，具體如下：

Created-一個新的缺陷被提交后的狀態(tài)；Open-bug停留未開始修復狀態(tài)Reopenedbug沒修復完全或者再次出現(xiàn)InProgressbug修復中Resolved-當bug被處理完后，DEV就可以選擇相應的處理結果（Fixed,WontFix,Incomplete,,Dplicated,CannotReporduce）；Closed-缺陷被驗證通過，提交者改成Closed狀態(tài)；5.1.2缺陷庫權限控制缺陷管理按照三個角色來定義權限，它們分別是：

Developers,Users,Administrator。

各角色具體最終權限的控制需要根據缺陷管理工具和各項目實際情況而定。

特別注明：

缺陷只能由提交者才能關閉。

5.1.3缺陷屬性下面描述了Jira的缺陷相關屬性，同時各個項目可以根據自己的不同特點添加相關屬性，標準信息如下（紅色標記為必填字段）：

IDBug的唯一識別碼,系統(tǒng)自動生成State參考Jira缺陷生命周期流程圖，此狀態(tài)由系統(tǒng)自動轉換SummaryBug概要描述PriorityBug優(yōu)先級SeverityBug嚴重級別Component組件模塊名稱AffectsVersio/sbug發(fā)現(xiàn)版本FixVersion/sBug修復版本AssigneeBug修復人員ReporterBug提交人員Environment測試環(huán)境描述DescriptionBug詳細信息Blocked是否阻塞測試AttachmentBug附加描述信息5.1.4缺陷級別(Severity)缺陷的嚴重級別是由提交者根據它的表現(xiàn)情況而決定的，包括但是不限于以下所述問題:重級別狀態(tài)描述舉例Blocks（致命）致命錯誤：

a、導致運行中斷(應用程序崩潰),預期的功能沒有得到實現(xiàn),測試工作無法繼續(xù)進行等。

b、由于程序引起的非法死機，退出，數(shù)據丟失，主要功能完全喪失等錯誤。

從用戶角度：

由于產品功能或者性能造成80%以上用戶無法使用的問題：

a)操作某一功能時，導致程序異常退出，或其余功能無法使用，或造成經常性死機和重啟b)內存泄漏c)用戶數(shù)據丟失或破壞d)系統(tǒng)崩潰/死機/凍結e)模塊無法啟動或異常退出f)嚴重的數(shù)值計算錯誤g)功能設計與需求嚴重不符h)導致其它功能無法測試的錯誤Cirtical（嚴重）嚴重錯誤：

a、較大的功能缺陷如該功能沒有實現(xiàn)或實現(xiàn)有錯誤，b、嚴重影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正沖突。

C、主要功能喪失，導致嚴重的問題，或致命的錯誤聲明。

從用戶角度：

用戶可以使用，但性能非常不穩(wěn)定，經常出現(xiàn)服務中斷a)實現(xiàn)的功能與相關需求嚴重不符，b)功能未實現(xiàn)c)功能錯誤d)系統(tǒng)刷新錯誤e)輕微的數(shù)值計算錯誤f)系統(tǒng)所提供的功能或服務受到明顯的影響Major（一般性錯誤）普通錯誤：

次要功能喪失，不太嚴重，可通過變通手段解決。

從用戶角度：

用戶可以使用，偶爾出現(xiàn)服務中斷（軟件功能和需求規(guī)格級別基本相符）。

a)邊界值的處理無效，重要界面的顯示問題，會對用戶產生一定影響的文字錯誤b)操作界面錯誤（包括數(shù)據窗口內列名定義、含義是否一致）c)邊界條件顯示錯誤d)提示信息錯誤（包括未給出信息、信息提示錯誤等）e)長時間操作無進度提示f)系統(tǒng)未優(yōu)化（性能問題）g)光標跳轉設置不好，鼠標（光標）定位錯誤a)字符串顯示不統(tǒng)一，b)拼寫、對齊類的錯誤、UI圖標、文字性錯誤；c)界面顯示不美觀但對用戶不產生影響的問題；d)不經常出現(xiàn)而且用戶可恢復的非嚴重問題，e)輔助說明描述不清楚f)操作時未給用戶提示g)可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志h)個別不影響產品理解的錯別字i)文字排列不整齊等一些小問題Minor（較小錯誤）較小的功能缺陷：

微小的問題，如果不進行修改，不影響主要功能，產品及屬性仍可使用，如有字符大小不統(tǒng)一。

從用戶角度：

用戶可以使用，但交互性不好，對于用戶可能造成難于操作、學習和理解。

Trivial（建議性）建議性意見：

從使用者角度，提出的建議性意見。

從用戶角度：

個別功能使用不夠方便，但是不影響用戶使用的問題a)用戶界面不太友好；b)使用不習慣；c)好的操作建議等；5.1.5缺陷優(yōu)先級(Priority)缺陷的優(yōu)先級是由測試Teamlead或者PM根據缺陷嚴重程度以及版本發(fā)布策略來定義。

P1立即解決P2高度關注P3正常排隊P4低優(yōu)先級優(yōu)先級(Priority)應變措施(Resolution)預計完成時間預設值(EstimatedFinishDate)P1-立即解決立即修改完成(Fiximmediately)即日完成P2-高度關注下一個版本結束前必須修改完成(Fixbeforenextstage)三個工作日內P3-正常排隊產品推出前必須修改完成(Fixbeforerelease)七個工作內P4-低優(yōu)先級如果時間允許才進行修改(Fixifavailable)十五個工作天內5.1.6缺陷描述規(guī)范這里我們主要關注缺陷報告的如下兩個方面。

摘要（Summary）努力做到將問題抽象化，爭取用最少的語言清晰的描述存在的問題，通過一句話描述清楚該缺陷的主要信息。

描述（Description）有效的缺陷報告描述一般具備以下特征：

可重現(xiàn)按照描述中給出的步驟可以再現(xiàn)缺陷隔離僅描述重現(xiàn)Bug所需的必要步驟，沒有冗余步驟簡潔簡要而清楚地說明問題，只解釋事實和描述軟件缺陷必需的細節(jié)單一每個報告只針對一個缺陷完整信息完整，包含預期結果，實際結果，必要的補充說明（如截屏圖）等中立只要求說出事實。

不帶傾向性、個人觀點和煽動性發(fā)現(xiàn)及提交Bug當發(fā)現(xiàn)一個Bug時，報告人員應第一時間確定Bug所屬產品模塊并按缺陷規(guī)范要求提交Bug記錄到缺陷管理庫，系統(tǒng)將自動發(fā)送郵件到預先定義產品負責人郵箱。

審核接收外部入口提交Bug到缺陷庫后，應先由測試人員進行審核接收，確認是否為真實Bug，并按缺陷管理規(guī)范完善所需信息后分配Bug到所屬產品模塊負責人。

分配處理研發(fā)人員收到Bug記錄郵件通知后，應及時判定Bug是否為歸屬自己。

如果是自己負責項目Bug，應先更改Bug狀態(tài)更改為INprogress。

如果不是，需要重新分配Bug給項目經理，由項目經理確定最終