一 Bugzilla的狀態(tài)

狀態(tài) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?說明

unconfirmed	未確定（針對反饋Bug/需求）
confirming	確認中（針對反饋需求）
new	新建
assigned	已分配
resolved	已解決
verified	已驗證
closed	已關閉
reopened	重新打開

二 Bugzilla的解決途徑

解決途徑 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 說明

fixed	已修復
waitpacket	等待打包（已經(jīng)廢棄，待刪除 ）
invaild	無效
wontfix	決定不改
later	后續(xù)版本
duplicate	重復
worksforme	無法重試
walkaround	以規(guī)避
remind	提醒
moved	已移出

三 Bugzilla的提交形式

提交形式	說明
file	文件
built	升級包
code	代碼

注：提交形式只在狀態(tài)為resolved，解決途徑為fixed時才可使用

四 Bug優(yōu)先級定義

優(yōu)先級	缺陷反饋BUG	內部BUG
高	1 因我公司設備導致客戶網(wǎng)絡或業(yè)務系統(tǒng)中斷或癱瘓；【時限要求】：24小時 2 設備出現(xiàn)嚴重問題或者不可用，并導致客戶網(wǎng)絡或業(yè)務系統(tǒng)無法正常工作【時限要求】：48小時	1 阻礙測試繼續(xù)運行 2 項目測試進度計劃受到極大影響 3 影響結項通過的 4 影響當前測試升級包發(fā)布的 5 已知問題在對外發(fā)布版本也存在，并且有導致客戶網(wǎng)絡或業(yè)務系統(tǒng)中斷或癱瘓風險的 【時限要求】：48小時
中	在線串聯(lián)設備出現(xiàn)嚴重問題，但客戶網(wǎng)絡或業(yè)務沒有受到影響 【時限要求】：72小時	從當前時間點上看問題緊急程度不高，時限要求： 1 必須在結項版本解決 2 必須在當前測試升級包發(fā)布版本解決 3 在測試和開發(fā)雙方商議的deadline期限內解決

低 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 設備出現(xiàn)問題，但仍可正常運行 ? ?問題在時限上沒有特別要求 ?

?????????????????????????????????不影響客戶正常使用 ? ? ? ? ? ? ?開發(fā)有時間則納入計劃解決

?????????????????????????????????【時限要求】一周

注：缺陷的優(yōu)先級可以隨著時間推移根據(jù)實際情況作調整

五 Bug嚴重級別規(guī)范

嚴重程度等級	定義標準	示例 ? Bug相關產(chǎn)品
critical	1 導致客戶網(wǎng)絡或業(yè)務系統(tǒng)中斷或癱瘓 2 系統(tǒng)崩潰/掛起 數(shù)據(jù)丟失或內存嚴重泄漏等導致系統(tǒng)不可用? 3 系統(tǒng)存在易于***且危害高的安全漏洞	【公共平臺】Bug 24149：設備外網(wǎng)口疑似LAND***后NAT池資源耗盡導致TCP通訊異常 【eps】bug 10581 發(fā)現(xiàn)內存，句柄泄漏現(xiàn)象
major	1 功能嚴重不可用，或影響系統(tǒng)自身業(yè)務流程完成 2 系統(tǒng)存在易于***或危害高的安全漏洞	【公共平臺】Bug 25432 URL過濾功能失效 【EPS】Bug 13915 代理端口開機5分鐘左右以后，自保護功能失效
nornal	1、功能部分不可用，影響一般：不影響客戶業(yè)務系統(tǒng)正常運轉，同時也不影響系統(tǒng)自身業(yè)務流程完成； 2、系統(tǒng)存在一般性的安全漏洞	IPS] Bug 23624：29001號規(guī)則誤阻斷風行在線視頻 [公共平臺] Bug 25657:清除報表后，頁面出現(xiàn)http404提示
trivial	UI顯示、文本、文字等錯誤，且不影響功能
enhancement	建議性質的意見

六 反饋的缺陷處理說明

6.1 反饋的缺陷處理說明

1)?有關于反饋Bug所涉及的績效統(tǒng)計，參見《績效辭典》。

2)?處于resolved（已解決）狀態(tài)的Bug，必須先將狀態(tài)變更到verified（已驗證）后，才能將狀態(tài)再變更為closed（已關閉）。變更到verified狀態(tài)之前，必須填寫“缺陷引入階段”字段（解決途徑是：invaild（無效）、duplicate（重復）、worksforme（無法重現(xiàn)）的除外）；

3)?客戶現(xiàn)場存在問題，而內部無法重現(xiàn)的反饋Bug，如果能判斷較大的可能是由產(chǎn)品缺陷引起的問題，測試經(jīng)理和產(chǎn)品經(jīng)理溝通確認后，可以先將Bug狀態(tài)設置為NEW。后續(xù)如果最終確認不是產(chǎn)品缺陷的，將Bug的解決途徑設置成INVAILD(無效)；如果最終確認是產(chǎn)品缺陷的，按照缺陷的情況進行處理。（注：與此相關的績效“產(chǎn)品維護階段反饋缺陷的平均解決周期”的統(tǒng)計方法是從第一個unconfirmed(未確定 針對反饋bug/需求)到VERIFIED，不包括無效Bug。）

4)?客戶現(xiàn)場重現(xiàn)周期長或重現(xiàn)困難，而內部無法重現(xiàn)的反饋Bug，在能保證其他客戶處不重復出現(xiàn)，且相關方面可接受規(guī)避方案的情況下，可以先規(guī)避解決，將解決途徑設置成WALKAROUND，狀態(tài)為RESOLVED，技術支持經(jīng)理在此之后，等待一個月客戶現(xiàn)場不再繼續(xù)出現(xiàn)問題，也沒有再收到同樣的缺陷反饋，可將該反饋Bug關閉。如果在等待過程中，再出現(xiàn)問題或收到相同缺陷反饋，將該反饋Bug重新打開REOPENED。在該反饋Bug關閉之后再出現(xiàn)同樣問題的話，建立新的反饋Bug進行跟蹤，不再重新打開已關閉的反饋Bug。

5)?反饋缺陷的問題確認及復現(xiàn)，由產(chǎn)品質量部負責（特殊或緊急情況開發(fā)人員可以進行緊急處理）。UNCONFIRMED狀態(tài)變更為NEW狀態(tài)的操作，一般由測試經(jīng)理或測試人員在問題確認后完成。

七 反饋的需求處理說明

7.1 反饋的需求處理說明

1處于unconfirmed(未確定)狀態(tài)的反饋需求，必須先將狀態(tài)更改為new，不能將狀態(tài)直接更變?yōu)閞esolved(解決途徑為invaild無效 duplicate重復的除外?

2 處于new狀態(tài)的反饋需求，必須先將狀態(tài)變?yōu)閍ssigned（已分配），不能將狀態(tài)直接變?yōu)閞esolved（解決途徑為invaild duplicate的除外）。再變更到assigned之前，必須填寫完‘最后期限’（deadline）字段

3 處于confirming(確認中)狀態(tài)的反饋需求，必須先將狀態(tài)變更為unconfirmed

7.2 反饋的需求狀態(tài)機

八 過程bug的處理說明

8.1 過程bug的狀態(tài)機

九 Deadline填寫說明

1 對于可行的，計劃在后續(xù)予以實現(xiàn)的產(chǎn)品反饋需求，產(chǎn)品經(jīng)理和測試經(jīng)理一同評估需求實現(xiàn)周期，提出需求實現(xiàn)計劃，計入需求處理系統(tǒng)，并通知系統(tǒng)工程師，產(chǎn)品市場經(jīng)理

需求實現(xiàn)計劃至少包含城垛計劃完成的時間點（deadline，指到已驗證verified狀態(tài)的時間點）工作量預計（以 人*小時 為單位），可以包括計劃實現(xiàn)的版本號，實現(xiàn)方式等；要求產(chǎn)品經(jīng)理接到需求處理通知后在2個工作日內完成該任務，同時在bugzilla中將需求記錄狀態(tài)設置為已分配assigned

2 對應確認需要進行修復的產(chǎn)品反饋缺陷，產(chǎn)品經(jīng)理和測試經(jīng)理一同評估缺陷修復及完成驗證周期。完成討論之后，產(chǎn)品經(jīng)理給出修復處理方案，包括承諾計劃完成的時間點（deadline，指到已驗證verified狀態(tài)的時間點），記錄到bugzilla系統(tǒng)中，分配責任人，并將缺陷記錄狀態(tài)設置為已分配（assigned）

3如果系統(tǒng)工程師，產(chǎn)品市場經(jīng)理或產(chǎn)品支持經(jīng)理等認為時間承諾等無法滿足市場要求的，可以考慮召集評審會議重新審核，或升級事件到更高一層的領導協(xié)調

十 bug引入階段字段的使用說明

10.1 目的

問題回溯——產(chǎn)品發(fā)布后的缺陷分析，用于產(chǎn)品系統(tǒng)質量改進

流程相關問題發(fā)掘和流程改進

10.2 范圍

在buggilla中新增一個字段，用來定位和回溯發(fā)布后反饋bug在生命周期中的引入階段

用于buggilla中反饋的bug，內部測試暫不執(zhí)行

10.3 使用說明

10.3.1 引入階段的定義

對于引入階段，初步定義為6項：“市場需求”階段，“測頻需求”階段，“設計”階段，“編碼”階段，“版本管理”和“歷史遺留”，在查詢bug 更新bug時可以看到，如下圖所示：

10,3,2 填寫說明

此階段定位由開發(fā)人員填寫，當反饋bug的責任人指向某開發(fā)人員時，開發(fā)人員響應，處理此bug期間，同時定位bug的引入階段，如上圖所示，在“缺陷引入階段”右側的下拉框中選定引入階段即可

當開發(fā)人員不能定位時，須告知產(chǎn)品經(jīng)理，由產(chǎn)品經(jīng)理進行定位

為保證問題定位的準確性，以降低后續(xù)系統(tǒng)改進趨勢分析的偏差，對問題定位需由相關人員進行確認，確保問題定位在組內達成一致，不存在分歧，確任人員如下：

????

ü?定位為“設計”階段的反饋bug需架構師或產(chǎn)品經(jīng)理確認；

ü?定位為“產(chǎn)品需求”階段的反饋bug需SE或產(chǎn)品經(jīng)理確認；

ü?定位為“市場需求”階段的反饋bug需產(chǎn)品市場經(jīng)理確認；

ü?定位為“版本管理”的反饋bug需項目級配置管理員或產(chǎn)品經(jīng)理確認；

ü?定位為“歷史遺留”的反饋bug需產(chǎn)品經(jīng)理確認等。

通常建議在反饋bug關閉時，bug引入階段的定位也需要確定完畢，例外為定位出現(xiàn)分歧的情況，允許直到達成一致時填寫完畢；

??因流程改進和系統(tǒng)改進需要，開發(fā)中心項目管理組會定期抽取相關數(shù)據(jù)，周期為2周（每月中旬）或4周（每月最后一周）左右，請各產(chǎn)品組盡量在相關周期內提交完畢。

??此字段填寫于2009年5月開始試行。

十一 測試bug提交內容規(guī)范

測試人員在提交BUG時，應該按照以下的格式要求，提交BUG相關的信息。

????ENV等處的內容，各個產(chǎn)品可以根據(jù)產(chǎn)品自身的特點，增加或裁減相關內容項，例如，RCM組的可能還需要包括插件數(shù)、漏洞數(shù)、被掃描系統(tǒng)的版本等信息。

十二 開發(fā)bug回復內容規(guī)范

開發(fā)人員在完成BUG定位、BUG修復工作之后，更新BUG狀態(tài)的同時，應該按照以下的格式要求，對BUG進行回復。盡量將以下內容填寫清楚，對的確不涉及的內容，可以省略。

十三 bug驗證規(guī)范

十四 bugzilla管理規(guī)范

十五 主要字段說明

轉載于:https://blog.51cto.com/12730159/1946835

總結

以上是生活随笔為你收集整理的Bugzilla系统使用规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。