目錄
一：在了解Bugzilla的使用前，先了解一些基本知識(shí)：
1.什么是Bugzilla
2.bug的來源
3.bug的生命周期
4.處理bug的所有角色：
5.一個(gè)bug的生命周期：
6.bugzilla使用時(shí)的基本流程圖：
二：了解基本知識(shí)后，開始進(jìn)入bugzilla的基本使用：
1.登錄用戶?
2.創(chuàng)建用戶
3.編寫bug
填寫bug的注意點(diǎn)：
BUG嚴(yán)重級(jí)別解釋規(guī)范
BUG優(yōu)先級(jí)別解釋規(guī)范
三：測(cè)試demo，對(duì)測(cè)試流程進(jìn)行一個(gè)使用舉例：
四：角色的權(quán)限設(shè)置：
一：在了解Bugzilla的使用前，先了解一些基本知識(shí)：
1.什么是Bugzilla
在一個(gè)產(chǎn)品研發(fā)或者軟件開發(fā)的結(jié)束后，對(duì)一個(gè)產(chǎn)品進(jìn)行測(cè)試后，會(huì)發(fā)現(xiàn)很多的bug，以前的bug的保留都是以手記，口傳，或者文檔記錄。但是時(shí)常會(huì)出現(xiàn)bug的消失，bug的追溯和bug的追蹤出現(xiàn)問題，所以為了更好的管理bug，記錄bug和追蹤bug，就出現(xiàn)了bugzilla這個(gè)bug管理系統(tǒng)。
簡單介紹以下Bugziila，它就是一個(gè)Bug的管理系統(tǒng)，Bug的追蹤系統(tǒng)，用來幫助你管理軟件開發(fā)，建立完善的BUG跟蹤體系。
2.bug的來源
在使用bugzilla前，我們需要弄懂，bug的來源，bug的生命周期以及在處理bug過程中的所有角色分為哪些。
bug的來源就是產(chǎn)品，和產(chǎn)品的組件。
3.bug的生命周期
bug的生命周期總的來說無非就是屬于兩個(gè)狀態(tài)，一個(gè)是屬于開啟狀態(tài)，一個(gè)是屬于關(guān)閉狀態(tài)的。
開啟狀態(tài)的bug分為三種：
1.unconfirmed:
2.confirmed：
3.in progress
關(guān)閉狀態(tài)的bug分為兩種：
1.resolved
2.verified
而resolved和verified下又分為7種處理意見：
fixed，invalid，wontfix，duplicate，worksforme，reopened，closed
1、Bug狀態(tài)分類（status）?
未確認(rèn)(unconfirmed)
已確認(rèn)(confirmed）
在處理中(inprogress)
待返測(cè)的(Resolved) ?
待歸檔的(Verified) ?
2、Bug處理意見（Resolution） ?
已修改的（Fixed） ?
不是問題（INVALID） ?
無法修改（Wontfix）
重復(fù)（Duplicate） ?
無法重現(xiàn)（Worksforme） ?
已關(guān)閉的(close) ?
問題未解決的(Reopened) ?
4.處理bug的所有角色：
1.reporter: filed the bug//報(bào)告者，一般為測(cè)試工程師進(jìn)行產(chǎn)品的測(cè)試，負(fù)責(zé)填寫bug，可對(duì)bug狀態(tài)進(jìn)行更改。
2.Assignee:in charge of resolving the bug//受理人:負(fù)責(zé)處理bug，可對(duì)bug的狀態(tài)進(jìn)行更改一般為產(chǎn)品的某個(gè)部分的工程師，比如軟件工程師，硬件工程師。
3.QA contact:confirmed the bugs if it is unconfirm and verifying the fix one the bug has been resovled//判斷是否bug是否已經(jīng)解決
4.CC對(duì)象：抄寫人：這個(gè)角色對(duì)bug不進(jìn)行更改，但是每次bug的狀態(tài)的更改都會(huì)以郵箱方式通知他。一般是領(lǐng)導(dǎo)或者整個(gè)項(xiàng)目的負(fù)責(zé)人，但是不負(fù)責(zé)解決bug?？梢允侨我庠赽ugzilla中使用的用戶。
5.每一次bug的狀態(tài)更改，reporter和CC對(duì)象都會(huì)收到郵件消息。
5.一個(gè)bug的生命周期：
6.bugzilla使用時(shí)的基本流程圖：
二：了解基本知識(shí)后，開始進(jìn)入bugzilla的基本使用：
1.登錄用戶?
在輸入郵箱和密碼欄中輸入郵箱和密碼即可登錄
2.創(chuàng)建用戶
創(chuàng)建用戶，點(diǎn)擊Open a New Account 進(jìn)行新用戶的創(chuàng)建，輸入郵箱后，你的郵箱會(huì)收到一封創(chuàng)建用戶的郵箱，點(diǎn)擊地址會(huì)進(jìn)入bugzilla進(jìn)行編輯密碼和賬戶信息
3.編寫bug
填寫bug的注意點(diǎn)：
1.最開始的status沒有經(jīng)過Assignee的確認(rèn)一般填寫是uncomfirm
2.一般默認(rèn)的assingee是這個(gè)產(chǎn)品的component的負(fù)責(zé)人
3.CC對(duì)象是抄寫人，這個(gè)角色對(duì)bug不進(jìn)行更改，但是每次bug的狀態(tài)的更改都會(huì)以郵箱方式通知他。一般是領(lǐng)導(dǎo)或者整個(gè)項(xiàng)目的負(fù)責(zé)人，但是不負(fù)責(zé)解決bug。
2.如何填寫Severtity和Priority:
Severity（嚴(yán)重性）與Priority（優(yōu)先級(jí)）之間的區(qū)別：
軟件里的Bug所產(chǎn)生的效果不會(huì)自動(dòng)的與修復(fù)它的優(yōu)先級(jí)相關(guān)聯(lián)。一個(gè)嚴(yán)重的Bug可能是那種對(duì)1%的用戶來說也是不太會(huì)發(fā)生的使軟件崩潰的bug。那它的優(yōu)先級(jí)也比那些誤操作導(dǎo)致的需要對(duì)每個(gè)用戶每次需要重新鍵入一部分輸入的Bug的優(yōu)先級(jí)要低。
因此：需要分別跟蹤Bug優(yōu)先級(jí)和嚴(yán)重性，然后進(jìn)行適當(dāng)?shù)男迯?fù)。Bug的重要性是由項(xiàng)目來決定的，不同于客戶對(duì)Bug的感知。某些情況下，分別跟蹤急迫的或是按照客戶觀點(diǎn)定義的Bug也是很有意義的。
優(yōu)先級(jí)與項(xiàng)目日程相關(guān)，嚴(yán)重性與標(biāo)準(zhǔn)相關(guān)。優(yōu)先級(jí)表示需要優(yōu)先考慮和注意的對(duì)象；由重要性順序構(gòu)建成優(yōu)先級(jí)；嚴(yán)重性暗示需要嚴(yán)格遵照標(biāo)準(zhǔn)或者是高層原則，比如，一個(gè)嚴(yán)重的代碼行為。優(yōu)先級(jí)和嚴(yán)重性這2個(gè)詞出現(xiàn)在Bug跟蹤里。某種商業(yè)化的，問題跟蹤及管理的軟件工具是可行的。這些工具，隨著測(cè)試工程師們逐條的輸入，給予團(tuán)隊(duì)完整的信息，以致開發(fā)人員能明白Bug，明白Bug的嚴(yán)重性，重現(xiàn)它，并修復(fù)它。修復(fù)建立在優(yōu)先級(jí)和嚴(yán)重性的基礎(chǔ)上。嚴(yán)重性的問題按照客戶的風(fēng)險(xiǎn)評(píng)估來定義，并記錄于被選擇的跟蹤工具中。多Bug的軟件會(huì)“嚴(yán)重”影響項(xiàng)目進(jìn)度，依次也能導(dǎo)致對(duì)“優(yōu)先級(jí)”重新評(píng)估和商榷。
Severity: 一個(gè)bug對(duì)功能的影響程度
Priority: 一個(gè)bug對(duì)業(yè)務(wù)的影響程度
BUG嚴(yán)重級(jí)別解釋規(guī)范
目的：測(cè)試工程師在提交Bug時(shí)，為選擇Bug的嚴(yán)重級(jí)別的依據(jù)。
測(cè)試工程師在提交Bug時(shí)，需要選擇該Bug的嚴(yán)重程度，不同的選項(xiàng)代表不同的嚴(yán)重程度，解釋如下：
Blocker
該Bug不僅造成本產(chǎn)品/項(xiàng)目異常，并且導(dǎo)致其他服務(wù)器、數(shù)據(jù)庫、中間件、程序、操作系統(tǒng)等不能提供正常服務(wù)（包括客戶端）。 ? ? ? ? ? ?
Critical
該Bug影響兩個(gè)或兩個(gè)模塊以上的功能無法應(yīng)用或者用例無法執(zhí)行（不包括顯示文字以及裝飾內(nèi)容。例如：一級(jí)菜單按鈕文字，版權(quán)消息內(nèi)容等）；
Major
需求規(guī)格說明書中已描述，但是功能未實(shí)現(xiàn)，或?qū)崿F(xiàn)功能與產(chǎn)品需求規(guī)格書不符。
Minor
所實(shí)現(xiàn)功能，在需求規(guī)格說明書中沒有定義，所實(shí)現(xiàn)功能如果存在缺陷將提出Bug，如果實(shí)現(xiàn)功能比較完美，不再提Bug。
Trivial
裝飾性問題，主要是界面方面問題，如錯(cuò)別字、畫面誤顯示、頁面顯示變形或誤動(dòng)作，提示信息有誤。
Enhancement
產(chǎn)品易用性、美觀性問題，屬于用戶體驗(yàn)，進(jìn)行合理化建議。
注：1：報(bào)Major 與Minor類Bug的前提為，是否為功能性問題；（提示消息是否準(zhǔn)確、有效不在此范圍內(nèi)）
2：提示信息類Bug報(bào)在Trivial中。注：如果需求文檔中，對(duì)該提示信息有明確的樣本，但程序?qū)崿F(xiàn)與樣本有差異，此類bug也屬于Trivial類bug。
BUG優(yōu)先級(jí)別解釋規(guī)范
目的：測(cè)試工程師在提交Bug時(shí)，為選擇Bug的優(yōu)先級(jí)的依據(jù)。
?測(cè)試工程師在提交Bug時(shí)，需要選擇該Bug的優(yōu)先級(jí)，不同的選項(xiàng)代表不同的優(yōu)先程度，解釋如下：
Highest為 最優(yōu)先修改的Bug。
注：此優(yōu)先級(jí)別的Bug，如果不進(jìn)行修改會(huì)影響到系統(tǒng)主要功能的測(cè)試，優(yōu)先級(jí)別最高。
?High為較 為優(yōu)先修改的Bug。
注：此優(yōu)先級(jí)別的Bug，如果不進(jìn)行修改，會(huì)影響到相關(guān)此組件其他功能的測(cè)試，優(yōu)先級(jí)別較高。
Normal為 一般優(yōu)先修改的Bug。
注：此優(yōu)先級(jí)別的Bug，如果不進(jìn)行修改，說明該功能沒有實(shí)現(xiàn)或?qū)崿F(xiàn)有錯(cuò)誤，優(yōu)先級(jí)別一般。
Low為 次優(yōu)先修改的Bug。
注：此優(yōu)先級(jí)別的Bug，如果不進(jìn)行修改，不影響主要功能，屬于頁面美觀和易用性的問題。
Lowest為 最不優(yōu)先修改的Bug。
注：此優(yōu)先級(jí)別的Bug，不影響主要功能，只是頁面上的文字錯(cuò)誤或者需要改進(jìn)的建議5
三：測(cè)試demo，對(duì)測(cè)試流程進(jìn)行一個(gè)使用舉例：
完成bug的編寫后界面如下：
完成一個(gè)bug的編輯后，Assignee對(duì)象會(huì)收到一封郵箱
完成一個(gè)bug的編寫后，CC對(duì)象會(huì)收到一個(gè)郵件，內(nèi)容如下
在Assignee對(duì)象的Bugzilla賬號(hào)中的My Bugs 中的顯示是
Assignee查看bug后改bug狀態(tài)為IN_PROGRESS后reporter會(huì)收到一封郵箱
在對(duì)bug修改完后，進(jìn)行bug解決后的描述和狀態(tài)和處理意見的編輯
在Assignee對(duì)bug進(jìn)行fixed后，reported會(huì)收到一封郵箱通知，收到通知后在search中尋找對(duì)應(yīng)bug，再次對(duì)bug進(jìn)行測(cè)試，如果測(cè)試發(fā)現(xiàn)bug已經(jīng)解決則更改狀態(tài)為verified，處理意見為closed。
?
到此一個(gè)bug的生命結(jié)束。
四：角色的權(quán)限設(shè)置：
每一個(gè)用戶的權(quán)限是可以被管理員進(jìn)行授予,下圖是所有可以被授予的權(quán)限。
管理員沒有授予用戶權(quán)限時(shí)的Administrator界面如下：
?管理員在User中指定用戶后進(jìn)行設(shè)置權(quán)限如下：
管理員授予用戶指定的權(quán)限后的Administrator界面如下：文章來源：http://www.zghlxwxcb.cn/news/detail-789162.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-789162.html
到了這里，關(guān)于Bugzilla的快速入門指南(全網(wǎng)最詳細(xì))的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
