Bugzilla培訓手冊

系統管理員手冊

前言.........................................................................1

培訓前的故事.................................................................I

Bugzilla介紹.................................................................2

產生.....................................................................2

目的.....................................................................2

Bugzilla操作說明.............................................................3

1、用戶登錄及設置......................................................3

2、Bug的處理過程.......................................................3

4、BUG處理流程.......................................................5

Bugzilla管理員操作指南......................................................6

要緊工作內容：..........................................................6

基本操作：..............................................................6

管理group..............................................................................................................................6

管理Product與component.................................................................................................6

Bugzilla中的Bug流程........................................................7

前言

不論你有任何借口，只要你寫程序，哪怕只是一個人的小組，假如你沒有一個系統化的

管理軟件BUG的工具，你寫的程序的質量一定高不了。許多程序員覺得自己能夠記得自己的

軟件BUG。沒門！我從來記不住超過2到3個軟件BUG。而且第二天旦上起床后忙著去買這

買那，好不容易記住的軟件BUG早忘掉了。你絕對需要一個系統來管住你的那些BUG。

軟件BUG管理系統功能有多有少。但最少要管理下列幾種信息：

?如何重復軟件BUG的全面步驟

?正常情況（無BUG）應是如何

?現在情況（有BUG）又是如何

?誰來負責修補BUG

?問題是否具有解決

這就是公司搭建Bugzilla的意義所在。

培訓前的故事

本段描述了軟件工程開發中關于管理的重要性，可跳過閱讀。

微軟WindowsWord的第一版的開發項目曾被認為是“死亡之旅”項目。好象永遠也做

不完，永遠超時。所有人瘋狂地工作，可怎么也完成不了任務。整個項目一拖再拖，大家都

覺得壓力大得受不了。最后終于做完了這個鬼項目，微軟把全組送到墨西哥的Cancun去度

假，讓大家坐下來好好想想。

大家意識到由于項目經理過于強求程序員們按時交活，結果大家只能匆匆地趕活，寫出

的程序毛病百出。由于項目經理的開發計劃并沒有考慮解決BUG的時間，大家只能把解決

BUG的任務往后推，結果BUG越積越多。有一個程序員負責寫計算字體高度的程序，為了圖

快，居然寫一行“return12;”了事。他指望以后的質檢人員發現這段程序有毛病后報告他

再改正。項目經理的開發計劃事實上已變成一個列寫程序功能的清單，而上面列的所謂程序

功能遲早都會成為軟件BUGo在項目總結會上，我們稱這種工作方法為“絕對劣質之路”。

記住：在任何時候，都要把解決現有程序里的問題作為首要問題來抓，然后再去寫新程序。

通常說來，你越不及時地解決BUG,解決BUG的代價（時間與金錢）就會越高，隨程序

開發進度而指數增長。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把

它改正。你剛寫好的程序在第一次運行時發現了一個問題，你也很快就能解決它，由于你對

你剛寫的程序還經歷猶新。假如你運行你的程序時發現了一個問題，可這個程序是幾天往常

寫的，你可能就需要折騰一會兒，還好，你還大致記得，因此不可能花太長時間。但假如你

在你幾個月往常寫的程序里發現了問題，就比較難解決了，由于你已經忘了許多細節。這時

候，你還沒準兒正忙著解決別人程序里的BUG吶，由于這家伙到加勒比海阿魯巴島度假去了。

這時候，解決這堆問題的難度不亞于從事尖端科學研究。你定得小心翼翼地，井常系統

化地從事，而且你很難明白多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用

戶手里了，才發現問題，那你就等著套腰包吧。

總結起來，就一條：越早解決問題，越容易解決。

另外還有一個原因，剛寫的程序里發現問題，你能夠比較容易地估算解決它的時間。舉

個例子，假如我問你寫一?段程序去把?個列表排序需要花多長時間，你能夠給我?個比較確

切的估計。假如你的程序，在InternetExplorer5.5安裝以后，工作不正常。我問你要多

長時間把這個問題解決，你估計都估計不出來，由于你根本就不明白是什么原因造成了這個

問題。你可能要花三天時間才能解決，也有可能只花兩分鐘。

這個例子告訴我們，假如你的開發過程中有許多BUG沒有及時解決，那你的開發計劃確

信不可靠。反過來，假如你們已經把己知的BUG全部解決了，要做的事只是寫新的程序，那

你的開發計劃就會比較準確。

把已知的BUG全部解決，這樣做還有一個好處：你能夠對競爭對手快速反擊。有些人把

這叫著“讓開發中的產品隨時處在能夠交給用戶的狀態，假如你的競爭對于推出一個新的

功能想把你的客戶搶走，你能夠馬上在你的產品里加上這個功能，立刻將新產品交付用戶，

由于你沒有一大堆積存下來的問題要解決。

Bugzilla介紹

產生

Bugzilla屬于產品缺陷跟蹤系統一種，創始人是TerryWeissman,開始時使用一種名為

“TCL”的語言創建的，后用Perl語言實現，并作為Opensource公布。

目的

也許你還沒有看到?個錯誤管理系統所具有的價值；也許你正被大量的測試數據所淹沒，而

迫切的需要一個產品缺陷的記錄及跟蹤的好幫手：也許你正在通過如：電子表格、數據庫等各類

方式來不斷的開發與完善一個錯誤跟蹤系統。Mozilla公司向我們提供了一個共享的免費工具

Buzilla.作為一個產品缺陷的記錄及跟蹤工具，它能夠為你建立一個完善的Bug跟蹤體系，包含

報告Bug、查詢Bug記錄并產生報表、處懂得決、管理員系統初始化與設置四部分。并具有如下

特點：

1.基于Web方式，安裝簡單、運行方便快捷、管理安全。

2.有利于缺陷的清晰傳達。本系統使用數據庫進行管理.，提供全面詳盡的報告輸入項，產

生標準化的Bug報告。提供大量的分析選項與強大的查詢匹配能力，能根據各類條件組合進行

Bug統計。當錯誤在它的生命周期中變化時，開發人員、測試人員、及管理人員將及時獲得動態

的變化信息，同意你獲取歷史紀錄，并在檢查錯誤的狀態時參考這一記錄。

3.系統靈活，強大的可配置能力。Buzilla工具能夠對軟件產品設定不一致的模塊，并針

對不一致的模塊設定制定的開發人員與測試人員：這樣能夠實現提交報告時自動發給指定的責任

人；并可設定不一致的小組，權限也可劃分。設定不一致的用戶對Bug記錄的操作權限不一致,

可有效操縱進行管理。同意設定不一致的嚴重程度與優先級能夠在錯誤的生命其中管理錯誤，從

最初的報告到最后的解決，確保了錯誤不可能被忽略，同時能夠使注意力集中在優先級與嚴重程

度高的錯誤上。

4.自動發送Email,通知有關人員。根據設定的不一致責任人，自動發送最新的動態信息，

有效的幫助測試人員與開發人員進行溝通。

下面我們將按照Bugzilla的操作說明、Dugzilla管理員的操作指甫兩部分來說明這個工

具的具體使用。

Bugzilla操作說明

1、用戶登錄及設置

1.1用戶登錄

1.進入主頁面后，點擊【Lo義intoanexistingaccount],再點擊【loginin]進入。

2.進入注冊頁面，輸入用戶名與密碼即可登錄。用戶名為Email地址，初始密碼為用戶

名縮寫。登錄后自動進入查詢頁面。

3.如不記得密碼，輸入用戶名，點擊【submilrequest】，根據收到的郵件進行重新設置。

1.2修改密碼及設置

1.Login登錄后，【Editprefs]->[accoutsettings]進行密碼修改。

2.[Editprefs]->【emailsettings]進行郵件設置。

3.[Editprefs]->[permissions]進行權限查詢

2、Bug的處理過程

2.1報告Bug

2.1.1測試人員報告Bug

1.請先進行查詢，確認要提交的bug報告不可能在原有紀錄中存在，若已經存在，不要提

交，若有什么建議，可在原有紀錄中增加注釋，告知其屬主，讓bug的屬主看到這個而自己去修

改。

2.若Bug不存在，創建一份有效的bug報告后進行提交。

3.操作：點擊New,選擇產品后，填寫下表。

4.填表注意：Assignedto:為空則默認為設定的owner,也可手工制定。CC:可為多人,

需用"，"隔開。Desription中要全面說明下列情況：

1）發現問題的步驟

2）執行上述步驟后出現的情況

3）期望應出現的正確結果

選擇group設置限定此bug對組的權限，若為空，則為公開。

5.操作結果：Bug狀態（status）能夠選擇Initialstate為New或者Unconfirmed.

系統將自動通過Email通知項目組長或者直接通知開發者。

6.幫助：Bugwritingguidelines

2.1.2開發人員報告Bug.

1.具體方法同測試人員報告。

2.區別：Bug初始狀態將自動設為Unconfirmed,待測試人員確定后變為“New”.

2.2Bug的不一致處理情況

2.2.1Bug的屬主（owner）處理問題后，提出解決意見及方法。

1.給出解決方法并填寫AdditionalComments,還可創建附件（如：更換提交單）

2.具體操作（填表項如下）

3.填表注意：

FIXED描述的問題已經修改

INVALID描述的問題不是一個bug（輸入錯誤后，通過此項來取消）

WONTFIX描述的問題將永遠不可能被修復。

LATER描述的問題將不可能在產品的這個版本中解決.

DUPLICATE描述的問題是一個存在的bug的復件。

WORKSFORME所有要重新產生這個bug的企圖是無效的。假如有更多的信息出現，請重新分

配這個bug,而現在只把它歸檔。

2.2.2項目組長或者開發者重新指定Bug的屬主。（owner）

1.為此bug不屬于自己的范圍，可置為Assigned,等待測試人員重新指定。

2.為此bug不屬于自己的范圍，但明白誰應該負責，直接輸入被指定人的Email,進行

Ressignedo

3.操作：（可選項如下）

*Acceptbug（changestatustoASSIGNED）

*Reassignbugto

*ReassignbugtoownerandQAcontactofselectedcomponent

4.操作結果：如今bug狀態又變為New,此bug的owner變為被指定的人。

2.2.3測試人員驗證已修改的Bug.

1.測試人員查詢開發者已修改的bug,即Status為"Resolved”,Resolution為"Fixed".

進行重新測試。（可創建testcase附件）

2.經驗證無誤后，修改Resolution為VERIFIED。待整個產品公布后，修改為CLOSED。

若還有問題，REOPENED,狀態重新變為“New”,并發郵件通知。

3.具體操作（可選擇項）

1.LeaveasRESOLVEDFIXED

2.Reopenbug

3.MarkbugasVERIFIED

4.MarkbugasCLOSED

2.2.4Bug報告者（reporter）或者其他有權限的用戶修改及補充Bug

?能夠修改Bug的各項內容。

?能夠增加建立附件，增加了有關性，并加一些評論來解釋你正在做些什么與你為什么做。

?操作結果：每當一些人修改了bug報告或者加了一個評論，他們將會被加到CC列表中，

bug報告中的改變會顯在要發給屬主、寫報告者與CC列表中的人的電子郵件中。

2.2.5測試人員確認開發人員報告的Bug是否存在.

?查詢狀態為“Unconfirmed”的Bug,

?測試人員對開發人員提交的Bug進行確認，確認Bug存在。

?具體操作：選中“Confirmbug（changestatustoNew）”后，進行commit.

?操作結果：狀態變為“New”.

2.3查詢Bug

1.直接輸入BugId,點擊find查詢。能夠查看Bug的活動紀錄。

2.點擊Query,輸入條件進行查詢。

3.查詢Bug活動的歷史

4.產生報表。

5.幫助：點擊Clue.

3、關于權限的說明

1.組內成員對bug具有查詢的權利,但不能進行修改。

2.Bug的owner與reporter具有修改的權利。

3.具有特殊權限的用戶具有修改的權利。

4、BUG處理流程

1.測試人員或者開發人員發現bug后，推斷屬于哪個模塊的問題，填寫bug報告后，通過

Email通知項目組長或者直接通知開發者。

2.項目組長根據具體情況，重新reassigned分配給bug所屬的開發者。

3.開發者收到Email信息后，推斷是否為自己的修改范圍.

1）若不是，重新reassigned分配給項目組長或者應該分配的開發者。

2）若是，進行處理，resolved并給出解決方法。（可創建補丁附件及補充說明）

4.測試人員查詢開發者已修改的bug,進行重新測試。（可創建testcase附件）

1）經驗證無誤后，修改狀態為VERIFIED。待整個產品公布后，修改為CLOSED。

2）還有問題，REOPENED,狀態重新變為“New”,并發郵件通知。

5.假如這個BUG一周內一直沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直

到采取行動。

Bugzilla管理員操作指南

要緊工作內容：

1.產品(Product)、版本號(versions)與模塊(Components)的定義，同時指定模塊相應的開

發者(owner)與測試人員(QAContact)。

2.小組的定義與劃分

3.測試中Bug嚴重程度、優先級的定義

4.增加用戶，并分別設定全部用戶的分組、權限。

5.要緊參數(parameters)的設置

1)urlbase:輸入bugzilla工具所在的服務器IP地址。

2)usebuggroupsentry:設為ON,能夠分組。