一 Bugzilla的狀態

狀態 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?說明

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

二 Bugzilla的解決途徑

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

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

三 Bugzilla的提交形式

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

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

四 Bug優先級定義

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

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

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

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

注：缺陷的優先級可以隨著時間推移根據實際情況作調整

五 Bug嚴重級別規范

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

六 反饋的缺陷處理說明

6.1 反饋的缺陷處理說明

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

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

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

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

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

七 反饋的需求處理說明

7.1 反饋的需求處理說明

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

2 處于new狀態的反饋需求，必須先將狀態變為assigned（已分配），不能將狀態直接變為resolved（解決途徑為invaild duplicate的除外）。再變更到assigned之前，必須填寫完‘最后期限’（deadline）字段

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

7.2 反饋的需求狀態機

八 過程bug的處理說明

8.1 過程bug的狀態機

九 Deadline填寫說明

1 對于可行的，計劃在后續予以實現的產品反饋需求，產品經理和測試經理一同評估需求實現周期，提出需求實現計劃，計入需求處理系統，并通知系統工程師，產品市場經理

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

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

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

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

10.1 目的

問題回溯——產品發布后的缺陷分析，用于產品系統質量改進

流程相關問題發掘和流程改進

10.2 范圍

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

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

10.3 使用說明

10.3.1 引入階段的定義

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

10,3,2 填寫說明

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

當開發人員不能定位時，須告知產品經理，由產品經理進行定位

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

????

ü?定位為“設計”階段的反饋bug需架構師或產品經理確認；

ü?定位為“產品需求”階段的反饋bug需SE或產品經理確認；

ü?定位為“市場需求”階段的反饋bug需產品市場經理確認；

ü?定位為“版本管理”的反饋bug需項目級配置管理員或產品經理確認；

ü?定位為“歷史遺留”的反饋bug需產品經理確認等。

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

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

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

十一 測試bug提交內容規范

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

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

十二 開發bug回復內容規范

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

十三 bug驗證規范

十四 bugzilla管理規范

十五 主要字段說明

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

總結

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

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