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

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

創(chuàng)新互聯(lián)專注于洮南網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供洮南營(yíng)銷型網(wǎng)站建設(shè)，洮南網(wǎng)站制作、洮南網(wǎng)頁(yè)設(shè)計(jì)、洮南網(wǎng)站官網(wǎng)定制、微信小程序服務(wù)，打造洮南網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供洮南網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

一 Bugzilla的狀態(tài)

狀態(tài)                                              說明

unconfirmed	未確定（針對(duì)反饋Bug/需求）
confirming	確認(rèn)中（針對(duì)反饋需求）
new	新建
assigned	已分配
resolved	已解決
verified	已驗(yàn)證
closed	已關(guān)閉
reopened	重新打開

二 Bugzilla的解決途徑

解決途徑                                         說明

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

三 Bugzilla的提交形式

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

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

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

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

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

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

                                 【時(shí)限要求】一周

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

五 Bug嚴(yán)重級(jí)別規(guī)范

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

六 反饋的缺陷處理說明

6.1 反饋的缺陷處理說明

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

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

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

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

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

七 反饋的需求處理說明

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(確認(rèn)中)狀態(tài)的反饋需求，必須先將狀態(tài)變更為unconfirmed

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

八 過程bug的處理說明

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

九 Deadline填寫說明

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

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

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

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

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

10.1 目的

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

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

10.2 范圍

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

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

10.3 使用說明

10.3.1 引入階段的定義

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

10,3,2 填寫說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十三 bug驗(yàn)證規(guī)范

十四 bugzilla管理規(guī)范

十五 主要字段說明

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

網(wǎng)頁(yè)標(biāo)題：Bugzilla系統(tǒng)使用規(guī)范有哪些
網(wǎng)頁(yè)地址：http://bm7419.com/article48/pcshep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、用戶體驗(yàn)、外貿(mào)網(wǎng)站建設(shè)、企業(yè)建站、云服務(wù)器、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)