bugzilla作為測試人員常見的測試工具，被所有人熟悉和使用著。

可是，bugzilla究竟給我們帶來了些什么呢？

第一，bugzilla給了測試人員話語權。我們通過它，作為一個平等互利的角色向開發(fā)人員，官方的，正式的發(fā)出我們的成果宣言：一個bug。

第二，bugzilla給了測試人員平等權。測試人員不再是開發(fā)人員的幫手，大家是從不同的視圖來看待一個產品的質量。 bugzilla是作為開發(fā)人員和測試人員交流的平臺。 同時，這個交流平臺也連接了項目管理，過程管理，需求人員，設計人員，銷售人員，技術支持人員，和終客戶，是大家能有一個平臺去交換各自的想法。

第三，bugzilla使得測試人員能使用一個標準化的對象去進行信息內容的溝通。

第四，bugzilla使得測試人員能夠更加迅速的了解產品的當前質量狀態(tài)，從而調整各種計劃和工作。

第五，bugzilla使得測試人員能夠積極的參與到產品的管理過程中，對整個產品的管理提供更多的技術細節(jié)和過程參數(shù)。

對于如何使用bugzilla進行項目管理，我們不妨舉幾個例子：

例子一：我們在測試過程中，經常會遇到這種現(xiàn)象，是一個模塊會突然爆發(fā)出很多bug來。難道bug真的那么多嗎，其實很多時候，是因為開發(fā)人員在修改一個bug時，引起其他已經修復的bug被reopen或者導致更多的新bug。

我們如果有一個機制，去監(jiān)控 近3天內，新加的bug的原因。那么，這種問題能夠作為一個風險進入我們的風險管理過程。如果有相應的風險管理，那么執(zhí)行。如果沒有，需要加入。并且，根據實際情況，我們來判斷，還有多少潛藏的bug會以這種方式出現(xiàn)。

例子二，我們在做測試計劃的時候，很難說我們的測試各個階段都能夠很詳細的制定出內容來。比如回歸測試，到底哪些東西要做回歸測試呢，什么樣的頻度，什么樣的深度？

我們可以在功能測試結束前的2周，對現(xiàn)有的bug進行分析，依據bug的在各個模塊的分布數(shù)量，優(yōu)先級的加權等，來確定哪些需要重點進行回歸，那些可以忽略。從而對各個模塊的功能測試用例進行篩檢，從而得到回歸測試需要執(zhí)行的規(guī)模和頻度。

例子三，當一個產品被release之后，或者一個sprint結束之后，我們也可以對bug進行分析，通過bugzilla自帶的很多圖表，我們能夠對上個階段的產品質量有一個很直接的可視化分析，然后寫出QA角度的分析報告來，提供給管理層和開發(fā)團隊作為參考，從而在下一個階段中能夠更好的提高質量和效率。甚至，可以以QA的視角，去管理下個階段的開發(fā)過程和質量保證過程。

總之，bugzilla不是僅僅作為我們QA跟開發(fā)交流的工具，還可以作為測試驅動開發(fā)的工具，可以作為產品質量衡量的工具。