Bugzilla 培訓手冊

《Bugzilla 培訓手冊》由會員分享，可在線閱讀，更多相關《Bugzilla 培訓手冊（7頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 Bugzilla 系統(tǒng)管理員手冊 前言 1 培訓前的故事 1 Bugzilla介紹 2 產(chǎn)生 2 目的 2 Bugzilla操作說明 3 1、 用戶登錄及設置 3 2、Bug的處理過程 3 4、 BUG處理流程 5 Bugzilla管理員操作指南 6 主要工作內容： 6 基本操作： 6 管理group 6 管理Product 和 component 6 Bugzilla中的Bug流程 7 前言 不論你有任何借口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統(tǒng)化的管理軟件BUG的工具，你寫的程序的質量一定高不了。許多程序員覺得自己可以記得自

2、己的軟件BUG。沒門！我從來記不住超過２到３個軟件BUG。而且第二天早上起床后忙著去買這買那，好不容易記住的軟件BUG早忘掉了。你絕對需要一個系統(tǒng)來管住你的那些BUG。 軟件BUG管理系統(tǒng)功能有多有少。但最少要管理以下幾種信息： l 如何重復軟件BUG的詳細步驟 l 正常情況（無BUG）應是怎樣 l 現(xiàn)在情況（有BUG）又是怎樣 l 誰來負責修補BUG l 問題有沒有解決 這就是公司搭建Bugzilla的意義所在。 培訓前的故事 本段描述了軟件工程開發(fā)中關于管理的重要性，可跳過閱讀。 微軟Windows Word的第一版的開發(fā)項目曾被認為是“死亡之旅”項目。好

3、象永遠也做不完，永遠超時。所有人瘋狂地工作，可怎么也完成不了任務。整個項目一拖再拖，大家都覺得壓力大得受不了。最后終于做完了這個鬼項目，微軟把全組送到墨西哥的Cancun去度假，讓大家坐下來好好想想。 大家意識到由于項目經(jīng)理過于強求程序員們按時交活，結果大家只能匆匆地趕活，寫出的程序毛病百出。由于項目經(jīng)理的開發(fā)計劃并沒有考慮解決BUG的時間，大家只能把解決BUG的任務往后推，結果BUG越積越多。有一個程序員負責寫計算字體高度的程序，為了圖快，居然寫一行“return 12;”了事。他指望以后的質檢人員發(fā)現(xiàn)這段程序有毛病后報告他再改正。項目經(jīng)理的開發(fā)計劃事實上已變成一個列寫程序功能的清單，而上

4、面列的所謂程序功能遲早都會成為軟件BUG。在項目總結會上，我們稱這種工作方法為“絕對劣質之路”。記?。涸谌魏螘r候,都要把解決現(xiàn)有程序里的問題作為首要問題來抓，然后再去寫新程序。 一般說來，你越不及時地解決BUG，解決BUG的代價（時間和金錢）就會越高，隨程序開發(fā)進度而指數(shù)增長。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把它改正。你剛寫好的程序在第一次運行時發(fā)現(xiàn)了一個問題，你也很快就能解決它，因為你對你剛寫的程序還記憶猶新。如果你運行你的程序時發(fā)現(xiàn)了一個問題，可這個程序是幾天以前寫的，你可能就需要折騰一會兒，還好，你還大致記得，所以不會花太長時間。但如果你在你幾個月以前寫的程序

5、里發(fā)現(xiàn)了問題，就比較難解決了，因為你已經(jīng)忘了許多細節(jié)。這時候，你還沒準兒正忙著解決別人程序里的BUG吶，因為這家伙到加勒比海阿魯巴島度假去了。這時候，解決這一堆問題的難度不亞于從事尖端科學研究。你一定得小心翼翼地，非常系統(tǒng)化地從事，而且你很難知道多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用戶手里了，才發(fā)現(xiàn)問題，那你就等著套腰包吧。 總結起來，就一條：越早解決問題，越容易解決。 另外還有一個原因，剛寫的程序里發(fā)現(xiàn)問題，你能夠比較容易地估算解決它的時間。舉個例子，如果我問你寫一段程序去把一個列表排序需要花多長時間，你可以給我一個比較確切的估計。如果你的程序，在Internet

6、Explorer 5.5安裝以后，工作不正常。我問你要多長時間把這個問題解決，你恐怕都估計不出來，因為你根本就不知道是什么原因造成了這個問題。你可能要花三天時間才能解決，也有可能只花兩分鐘。 這個例子告訴我們，如果你的開發(fā)過程中有許多BUG沒有及時解決，那你的開發(fā)計劃肯定不可靠。反過來，如果你們已經(jīng)把已知的BUG全部解決了，要做的事只是寫新的程序，那你的開發(fā)計劃就會比較準確。 把已知的BUG全部解決，這樣做還有一個好處：你可以對競爭對手快速反擊。有些人把這叫著“讓開發(fā)中的產(chǎn)品隨時處在可以交給用戶的狀態(tài)”。如果你的競爭對手推出一個新的功能想把你的客戶搶走，你可以馬上在你的產(chǎn)品里加上這個功能，

7、立刻將新產(chǎn)品交付用戶，因為你沒有一大堆積累下來的問題要解決。 Bugzilla介紹 產(chǎn)生 Bugzilla屬于產(chǎn)品缺陷跟蹤系統(tǒng)一種，創(chuàng)始人是Terry Weissman，開始時使用一種名為“TCL”的語言創(chuàng)建的，后用Perl語言實現(xiàn)，并作為Open source發(fā)布。 目的 也許你還沒有看到一個錯誤管理系統(tǒng)所具有的價值；也許你正被大量的測試數(shù)據(jù)所淹沒，而迫切的需要一個產(chǎn)品缺陷的記錄及跟蹤的好幫手；也許你正在通過如：電子表格、數(shù)據(jù)庫等各種方式來不斷的開發(fā)和完善一個錯誤跟蹤系統(tǒng)。Mozilla公司向我們提供了一個共享的免費工具Buzilla.作為一個產(chǎn)品缺陷的記錄及跟蹤工具，它能夠為

8、你建立一個完善的Bug跟蹤體系，包括報告Bug、查詢Bug記錄并產(chǎn)生報表、處理解決、管理員系統(tǒng)初始化和設置四部分。并具有如下特點： 　　1．基于Web方式，安裝簡單、運行方便快捷、管理安全。 　　2．有利于缺陷的清楚傳達。本系統(tǒng)使用數(shù)據(jù)庫進行管理，提供全面詳盡的報告輸入項，產(chǎn)生標準化的Bug報告。 提供大量的分析選項和強大的查詢匹配能力，能根據(jù)各種條件組合進行Bug統(tǒng)計。當錯誤在它的生命周期中變化時，開發(fā)人員、測試人員、及管理人員將及時獲得動態(tài)的變化信息，允許你獲取歷史紀錄，并在檢查錯誤的狀態(tài)時參考這一記錄。 　　3．系統(tǒng)靈活，強大的可配置能力。Buzilla工具可以對軟件產(chǎn)品設定不同的

9、模塊，并針對不同的模塊設定制定的開發(fā)人員和測試人員；這樣可以實現(xiàn)提交報告時自動發(fā)給指定的責任人；并可設定不同的小組，權限也可劃分。設定不同的用戶對Bug記錄的操作權限不同，可有效控制進行管理。允許設定不同的嚴重程度和優(yōu)先級可以在錯誤的生命其中管理錯誤，從最初的報告到最后的解決，確保了錯誤不會被忽略，同時可以使注意力集中在優(yōu)先級和嚴重程度高的錯誤上。 4．自動發(fā)送Email,通知相關人員。根據(jù)設定的不同責任人，自動發(fā)送最新的動態(tài)信息，有效的幫助測試人員和開發(fā)人員進行溝通。 下面我們將按照Bugzilla的操作說明、 Bugzilla管理員的操作指南兩部分來說明這個工具的具體使用。 Bug

10、zilla操作說明 1、 用戶登錄及設置 1.1用戶登錄 1. 用戶輸入服務器地址http://192.168.1.9/cgi-bin/bugs/index.cgi。 2. 進入主頁面后，點擊【Log in to an existing account】，再點擊【login in】進入。 3. 進入注冊頁面，輸入用戶名和密碼即可登錄。用戶名為Email 地址，初始密碼為用戶名縮寫。登錄后自動進入查詢頁面。 4. 如忘記密碼，輸入用戶名,點擊【submit request】,根據(jù)收到的郵件進行重新設置。 1.2 修改密碼及設置 　　 1．Login登錄后，【Edit prefs

11、】->【accout settings】 進行密碼修改。 　　 2．【Edit prefs】->【email settings】 進行郵件設置。 　　 3．【Edit prefs】-> 【permissions】 進行權限查詢 2、Bug的處理過程 2.1 報告Bug 2.1.1測試人員報告Bug 　　1． 請先進行查詢，確認要提交的bug報告不會在原有紀錄中存在，若已經(jīng)存在，不要提交，若有什么建議，可在原有紀錄中增加注釋，告知其屬主，讓bug的屬主看到這個而自己去修改。 　　2． 若Bug不存在，創(chuàng)建一份有效的bug報告后進行提交。 　　3． 操作：點擊New，選擇產(chǎn)品后

12、，填寫下表。 　　4． 填表注意：Assigned to: 為空則默認為設定的owner, 也可手工制定。CC: 可為多人，需用"，"隔開。Desription中要詳細說明下列情況： 　　1） 發(fā)現(xiàn)問題的步驟 　　2） 執(zhí)行上述步驟后出現(xiàn)的情況 　　3） 期望應出現(xiàn)的正確結果 　　選擇group設置限定此bug對組的權限，若為空，則為公開。 　　5. 操作結果：Bug狀態(tài)（status）可以選擇Initial state 為New或Unconfirmed. 　　系統(tǒng)將自動通過Email通知項目組長或直接通知開發(fā)者。 　　6．幫助： Bug writing guidelines

13、 2.1.2 開發(fā)人員報告Bug. 　　1. 具體方法同測試人員報告。 　　2. 區(qū)別： Bug初始狀態(tài)將自動設為Unconfirmed，待測試人員確定后變?yōu)椤癗ew". 2.2 Bug的不同處理情況 2.2.1 Bug的屬主 (owner) 處理問題后，提出解決意見及方法。 　　1 . 給出解決方法并填寫Additional Comments，還可創(chuàng)建附件（如：更改提交單） 　　2．具體操作（填表項如下） 　　3 . 填表注意： 　　FIXED 描述的問題已經(jīng)修改 　　INVALID 描述的問題不是一個bug (輸入錯誤后，通過此項來取消) 　　WONTFIX 描述的問

14、題將永遠不會被修復。 　　LATER 描述的問題將不會在產(chǎn)品的這個版本中解決. 　　DUPLICATE 描述的問題是一個存在的bug的復件。 　　WORKSFORME 所有要重新產(chǎn)生這個bug的企圖是無效的。如果有更多的信息出現(xiàn)，請重新分配這個bug，而現(xiàn)在只把它歸檔。 2.2.2 項目組長或開發(fā)者重新指定Bug的屬主。（owner） 　　1． 為此bug不屬于自己的范圍，可置為 Assigned,等待測試人員重新指定。 　　2． 為此bug不屬于自己的范圍，但知道誰應該負責，直接輸入被指定人的Email， 進行Ressigned。 　　3. 操作：（可選項如下） 　　* Ac

15、cept bug (change status to ASSIGNED) 　　* Reassign bug to 　　* Reassign bug to owner and QA contact of selected component 　　4． 操作結果：此時bug狀態(tài)又變?yōu)镹ew，此bug的owner變?yōu)楸恢付ǖ娜恕? 2.2.3測試人員驗證已修改的 Bug. 　　1． 測試人員查詢開發(fā)者已修改的bug，即Status為"Resolved",Resolution為"Fixed".進行重新測試。（可創(chuàng)建test case附件） 　　2． 經(jīng)驗證無誤后，修改Resolution為

16、VERIFIED。待整個產(chǎn)品發(fā)布后，修改為CLOSED。 　　若還有問題，REOPENED，狀態(tài)重新變?yōu)椤癗ew"，并發(fā)郵件通知。 　　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 l 可以修改Bug的各項內容。 l 可以增加建立附件，增加了相關性, 并加一些評論來解釋你正在做些什么和你為什么做。 l 操作結果：每

17、當一些人修改了bug報告或加了一個評論，他們將會被加到CC列表中，bug 報告中的改變會顯在要發(fā)給屬主、寫報告者和CC列表中的人的電子郵件中。 2.2.5測試人員確認開發(fā)人員報告的Bug是否存在. l 查詢狀態(tài)為“Unconfirmed"的Bug, l 測試人員對開發(fā)人員提交的Bug進行確認，確認Bug存在。 l 具體操作：選中“Confirm bug(change status to New)"后，進行commit. l 操作結果：狀態(tài)變?yōu)椤癗ew". 2.3 查詢Bug 　　1．直接輸入Bug Id，點擊find 查詢。可以查看Bug的活動紀錄。 　　2．點擊Quer

18、y，輸入條件進行查詢。 　　3．查詢Bug活動的歷史 　　4．產(chǎn)生報表。 　　5．幫助：點擊Clue. 3、關于權限的說明 　　1． 組內成員對bug具有查詢的權利,但不能進行修改。 　　2． Bug的owner 和 reporter 具有修改的權利。 　　3． 具有特殊權限的用戶具有修改的權利。 4、 BUG處理流程 　　1． 測試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷屬于哪個模塊的問題，填寫bug報告后，通過Email通知項目組長或直接通知開發(fā)者。 　　2． 項目組長根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。 　　3． 開發(fā)者收到Email信息后，

19、判斷是否為自己的修改范圍. 　　 1） 若不是,重新reassigned分配給項目組長或應該分配的開發(fā)者。 　　 2） 若是，進行處理，resolved并給出解決方法。（可創(chuàng)建補丁附件及補充說明） 　　4． 測試人員查詢開發(fā)者已修改的bug，進行重新測試。（可創(chuàng)建test case附件） 　　 1） 經(jīng)驗證無誤后，修改狀態(tài)為VERIFIED。待整個產(chǎn)品發(fā)布后，修改為CLOSED。 　　 2） 還有問題，REOPENED，狀態(tài)重新變?yōu)椤癗ew"，并發(fā)郵件通知。 　　5． 如果這個BUG一周內一直沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直到采取行動。 B

20、ugzilla管理員操作指南 主要工作內容： 1． 產(chǎn)品（Product）、版本號(versions)和模塊(Components)的定義，同時指定模塊相應的開發(fā)者(owner)和測試人員(QA Contact)。 2． 小組的定義和劃分 3． 測試中Bug嚴重程度、優(yōu)先級的定義 4． 增加用戶，并分別設定全部用戶的分組、權限。 5． 主要參數(shù)（parameters）的設置 　　1） urlbase: 輸入bugzilla 工具所在的服務器IP地址。 　　2） usebuggroupsentry: 設為ON,可以分組。 　　3） whinedays：Bug在whineday

21、s設定的期限內若未被處理，將自動重發(fā)mail，默認為7天。 　　4） defaultpriority:設定默認的優(yōu)先級 　　5） commentonresolve：設為ON，系統(tǒng)將強制要求開發(fā)者處理完Bug 后，必須填寫修改的內容。 基本操作： 1． 創(chuàng)建默認的管理員用戶。 　　運行checksetup.pl。若不小心刪除管理員，重新運行checksetup.pl. 2． 管理用戶 1） 增加新用戶 　　點擊頁面右下角【users】,submit后，出現(xiàn)【Add new user】頁面。輸入相應輸入即可。Login name: 一般為郵件地址，可以設為其他標識。 2） 禁止一

22、個用戶 　　填寫Disabled text 輸入框即可。 3）修改用戶 　　可以修改用戶注冊名、密碼。 　　設置權限 　　QA的權限一般設為: Canconfirm, editbugs 　　Developer的權限設為: none 　　分組控制：group 管理group 1． 增加group 　　edit groupàadd groups (New User Regexp可不填/active 選擇則可選)->add 2． 修改group ,submit 即可。 管理Product 和 component 　　1)增加產(chǎn)品Product 　　2) 增加組件Component 對應一個owner(進行fixed),QA Contact（確保已fixed） 　 3) Component Number of Unconfirmed =10000,此產(chǎn)品將選擇bug的初始狀態(tài)（Unconfirmed,New） Bugzilla中的Bug流程 Bug開始 初始狀態(tài) 指派處理人員 二次指派 處理Bug 確認處理 關閉 Bug結束 重新 打開 7