測試跟蹤工具Bugzilla介紹

也許你還沒有看到一個錯誤管理系統所具有的價值；也許你正被大量的測試資料所淹沒，而迫切的需要一個產品缺陷的記錄及跟蹤的好幫手；也許你正在通過如：電子表格、資料庫等各種方式來不斷的開發和完善一個錯誤跟蹤系統。Mozilla公司向我們提供了一個共享的免費工具Buzilla.作為一個產品缺陷的記錄及跟蹤工具，它能夠為你建立一個完善的Bug跟蹤體系，包括報告Bug、查詢Bug記錄併產生報表、處理解決、管理員系統初始化和設定四部分。並具有如下特點：

　　1。基於Web方式，安裝簡單、執行方便快捷、管理安全。

　　2。有利於缺陷的清楚傳達。本系統使用資料庫進行管理，提供全面詳盡的報告輸入項，產生標準化的Bug報告。 提供大量的分析選項和強大的查詢匹配能力，能根據各種條件組合進行Bug統計。當錯誤在它的生命週期中變化時，開發人員、測試人員、及管理人員將及時獲得動態的變化資訊，允許你獲取歷史紀錄，並在檢查錯誤的狀態時參考這一記錄。

　　3。系統靈活，強大的可配置能力。Buzilla工具可以對軟體產品設定不同的模組，並針對不同的模組設定製定的開發人員和測試人員；這樣可以實現提交報告時自動發給指定的責任人；並可設定不同的小組，許可權也可劃分。設定不同的使用者對Bug記錄的操作許可權不同，可有效控制進行管理。允許設定不同的嚴重程度和優先順序可以在錯誤的生命其中管理錯誤，從最初的報告到最後的解決，確保了錯誤不會被忽略，同時可以使注意力集中在優先順序和嚴重程度高的錯誤上。

　　4。自動傳送Email,通知相關人員。根據設定的不同責任人，自動傳送最新的動態資訊，有效的幫助測試人員和開發人員進行溝通。

　　下面我們將按照Bugzilla的操作說明、 Bugzilla管理員的操作指南兩部分來說明這個工具的具體使用。本文有不少觀點來自個人使用心得，有不妥之處，敬請斧正。

Bugzilla操作說明

1、 使用者登入及設定

1.1使用者登入
　　1． 使用者輸入伺服器地址http://192.168.1.6/bugzilla/。
　　2． 進入主頁面後，點選【Forget the currently stored login】，再點選【login in】進入。
　　3． 進入註冊頁面，輸入使用者名稱和密碼即可登入。使用者名稱為Email 地址，初始密碼為使用者名稱縮寫。
　　4． 如忘記密碼，輸入使用者名稱,點選【submit request】,根據收到的郵件進行重新設定。

1.2、修改密碼及設定
　　1．Login登入後，【Edit prefs】->【accout settings】 進行密碼修改。
　　2．【Edit prefs】->【email settings】 進行郵件設定。
　　3．【Edit prefs】-> 【permissions】 進行許可權查詢

2、Bug的處理過程

2.1、報告Bug

2.1.1測試人員報告Bug
　　1． 請先進行查詢，確認要提交的bug報告不會在原有紀錄中存在，若已經存在，不要提交，若有什麼建議，可在原有紀錄中增加註釋，告知其屬主，讓bug的屬主看到這個而自己去修改。
　　2． 若Bug不存在，建立一份有效的bug報告後進行提交。
　　3． 操作：點選New，選擇產品後，填寫下表。
　　4． 填表注意：Assigned to: 為空則預設為設定的 owner, 也可手工制定。CC: 可為多人，需用"，"隔開。Desription中要詳細說明下列情況：
　　1） 發現問題的步驟
　　2） 執行上述步驟後出現的情況。
　　3） 期望應出現的正確結果。
　　選擇group設定限定此bug對組的許可權，若為空，則為公開。
　　5. 操作結果：Bug狀態（status）可以選擇Initial state 為New或Unconfirmed.
　　系統將自動通過Email通知專案組長或直接通知開發者。
　　6．幫助： Bug writing guidelines

2.1.2 開發人員報告Bug.
　　1. 具體方法同測試人員報告。
　　2. 區別： Bug初始狀態將自動設為Unconfirmed，待測試人員確定後變為“New".

2.2、Bug的不同處理情況

2.2.1 Bug的屬主 (owner) 處理問題後，提出解決意見及方法。
　　1 . 給出解決方法並填寫Additional Comments，還可建立附件（如：更改提交單）
　　2．具體操作（填表項如下）
　　3 . 填表注意：
　　FIXED 描述的問題已經修改
　　INVALID 描述的問題不是一個bug (輸入錯誤後，通過此項來取消)
　　WONTFIX 描述的問題將永遠不會被修復。
　　LATER 描述的問題將不會在產品的這個版本中解決.
　　DUPLICATE 描述的問題是一個存在的bug的復件。
　　WORKSFORME 所有要重新產生這個bug的企圖是無效的。如果有更多的資訊出現，請重新分配這個bug，而現在只把它歸檔。

2.2.2 專案組長或開發者重新指定Bug的屬主。（owner）
　　1． 為此bug不屬於自己的範圍，可置為 Assigned,等待測試人員重新指定。
　　2． 為此bug不屬於自己的範圍，但知道誰應該負責，直接輸入被指定人的Email， 進行Ressigned。
　　3. 操作：（可選項如下）
　　* Accept bug (change status to ASSIGNED)
　　* Reassign bug to
　　* Reassign bug to owner and QA contact of selected component
　　4． 操作結果：此時bug狀態又變為New，此bug的owner變為被指定的人。

2.2.3測試人員驗證已修改的 Bug.
　　1． 測試人員查詢開發者已修改的bug，即Status為"Resolved",Resolution為"Fixed".進行重新測試。（可建立test case附件）
　　2． 經驗證無誤後，修改Resolution為VERIFIED。待整個產品釋出後，修改為CLOSED。
　　若還有問題，REOPENED，狀態重新變為“New"，併發郵件通知。
　　3． 具體操作（可選擇項）
　　　1. Leave as RESOLVED FIXED
　　　2. Reopen bug
　　　3. Mark bug as VERIFIED
　　　4. Mark bug as CLOSED

2.2.4 Bug報告者（reporter）或其他有許可權的使用者修改及補充Bug
　　1. 可以修改Bug的各項內容。
　　2. 可以增加建立附件，增加了相關性, 並加一些評論來解釋你正在做些什麼和你為什麼做。
　　3． 操作結果：每當一些人修改了bug報告或加了一個評論，他們將會被加到CC列表中，bug報告中的改變會顯在要發給屬主、寫報告者和CC列表中的人的電子郵件中。

2.2.5測試人員確認開發人員報告的Bug是否存在.
　　1. 查詢狀態為“Unconfirmed"的Bug,
　　2. 測試人員對開發人員提交的Bug進行確認，確認Bug存在。
　　3. 具體操作：選中“Confirm bug(change status to New)"後，進行commit.
　　4. 操作結果：狀態變為“New".

2.3、查詢Bug

　　1．直接輸入Bug Id，點選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，進行重新測試。（可建立test case附件）
　　1） 經驗證無誤後，修改狀態為VERIFIED。待整個產品釋出後，修改為CLOSED。
　　2） 還有問題，REOPENED，狀態重新變為“New"，併發郵件通知。
　　5． 如果這個BUG一週內一直沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直到採取行動。

5、一個Bug的生存週期

Bugzilla管理員操作指南

1、主要工作內容：

1． 1產品（Product）、版本號(versions)和模組(Components)的定義，同時指定模組相應的開發者(owner)和測試人員(QA Contact)。

1．2小組的定義和劃分

1．3測試中Bug嚴重程度、優先順序的定義

1． 4增加使用者，並分別設定全部使用者的分組、許可權。

1． 5主要引數（parameters）的設定
　　1） urlbase: 輸入bugzilla 工具所在的伺服器IP地址。
　　2） usebuggroupsentry: 設為ON,可以分組。
　　3） whinedays：Bug在whinedays設定的期限內若未被處理，將自動重發mail，預設為7天。
　　4） defaultpriority:設定預設的優先順序
　　5） commentonresolve：設為ON，系統將強制要求開發者處理完Bug 後，必須填寫修改的內容。

2、基本操作：

2．1建立預設的管理員使用者。
　　執行checksetup.pl。若不小心刪除管理員，重新執行checksetup.pl.

2．2 管理使用者

2．1 增加新使用者
　　點選頁面右下角【users】,submit後，出現【Add new user】頁面。輸入相應輸入即可。Login name: 一般為郵件地址，可以設為其他標識。

2．2 禁止一個使用者
　　填寫Disabled text 輸入框即可。

2．3 修改使用者
　　可以修改使用者註冊名、密碼。
　　設定許可權
　　QA的許可權一般設為: Canconfirm, editbugs
　　Developer的許可權設為: none
　　分組控制：group

3、管理group

3.1．增加group
　　edit groupàadd groups (New User Regexp可不填/active 選擇則可選)->add

3.2修改group ,submit 即可。
　　4、管理Product 和 component
　　a)增加Product
　　b) Component 對應一個owner(進行fixed),QA Contact（確保已fixed）
　　c) Component Number of Unconfirmed =10000,此產品將選擇bug的初始狀態（Unconfirmed,New）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-436089/，如需轉載，請註明出處，否則將追究法律責任。