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

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

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

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

AllMembersBug：

缺陷職責(zé)配置組：

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

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

00)測試組：

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

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

開發(fā)組：

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

項(xiàng)目組應(yīng)定期組織會議，對未修復(fù)Bug進(jìn)行協(xié)商，或調(diào)整優(yōu)先級。

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

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

Developers,Users,Administrator。

各角色具體最終權(quán)限的控制需要根據(jù)缺陷管理工具和各項(xiàng)目實(shí)際情況而定。

特別注明：

缺陷只能由提交者才能關(guān)閉。

5.1.3缺陷屬性下面描述了Jira的缺陷相關(guān)屬性，同時各個項(xiàng)目可以根據(jù)自己的不同特點(diǎn)添加相關(guān)屬性，標(biāo)準(zhǔn)信息如下（紅色標(biāo)記為必填字段）：

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

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

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

從用戶角度：

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

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

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

C、主要功能喪失，導(dǎo)致嚴(yán)重的問題，或致命的錯誤聲明。

從用戶角度：

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

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

從用戶角度：

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

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

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

從用戶角度：

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

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

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

從用戶角度：

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

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

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

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

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

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

審核接收外部入口提交Bug到缺陷庫后，應(yīng)先由測試人員進(jìn)行審核接收，確認(rèn)是否為真實(shí)Bug，并按缺陷管理規(guī)范完善所需信息后分配Bug到所屬產(chǎn)品模塊負(fù)責(zé)人。

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

如果是自己負(fù)責(zé)項(xiàng)目Bug，應(yīng)先更改Bug狀態(tài)更改為INprogress。

如果不是，需要重新分配Bug給項(xiàng)目經(jīng)理，由項(xiàng)目經(jīng)理確定最終