Bugzilla系統(tǒng)使用規(guī)范有哪些

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

一 Bugzilla的狀態(tài)

狀態(tài)                                              說明

二 Bugzilla的解決途徑

解決途徑                                         說明

三 Bugzilla的提交形式

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

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

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

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

                                 【時限要求】一周

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

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

六 反饋的缺陷處理說明

6.1 反饋的缺陷處理說明

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

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

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

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

5) 反饋缺陷的問題確認及復(fù)現(xiàn)，由產(chǎn)品質(zhì)量部負責(zé)（特殊或緊急情況開發(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重復(fù)的除外 

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)的時間點）工作量預(yù)計（以 人*小時 為單位），可以包括計劃實現(xiàn)的版本號，實現(xiàn)方式等；要求產(chǎn)品經(jīng)理接到需求處理通知后在2個工作日內(nèi)完成該任務(wù)，同時在bugzilla中將需求記錄狀態(tài)設(shè)置為已分配assigned

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

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

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

10.1 目的

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

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

10.2 范圍

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

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

10.3 使用說明

10.3.1 引入階段的定義

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

10,3,2 填寫說明

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

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

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

ü 定位為“設(shè)計”階段的反饋bug需架構(gòu)師或產(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關(guān)閉時，bug引入階段的定位也需要確定完畢，例外為定位出現(xiàn)分歧的情況，允許直到達成一致時填寫完畢；

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

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

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

測試人員在提交BUG時，應(yīng)該按照以下的格式要求，提交BUG相關(guān)的信息。

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

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

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

十三 bug驗證規(guī)范

十四 bugzilla管理規(guī)范

十五 主要字段說明

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