Bugzilla系統使用規范有哪些

Bugzilla系統使用規范有哪些，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

一 Bugzilla的狀態

狀態                                              說明

二 Bugzilla的解決途徑

解決途徑                                         說明

三 Bugzilla的提交形式

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

四 Bug優先級定義

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

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

                                 【時限要求】一周

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

五 Bug嚴重級別規范

六 反饋的缺陷處理說明

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管理規范

十五 主要字段說明

關于Bugzilla系統使用規范有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。