消滅 Bug！推薦5款測試員不可不知的bug管理工具！

Bug是軟體開發過程中的“副產品”，也是開發人員最不想見到的狀況。如果沒有跟蹤和梳理各種bug和問題並及時解決，專案就會花費非常多的時間，導致整個專案的重心偏移。如果在此過程中，測試人員使用一個合適的Bug管理工具，將可以提高整個團隊的工作效率，把控產品質量，更好的完成任務。

根據每個公司性質的不同，規模的不同，所用到的bug管理工具也可能不同。你們用的bug管理工具是什麼呢？下面介紹幾款主流的bug管理工具：

JIRA（付費）

JIRA的生產者把JIRA定義為Professional Issue Tracker，即它是一個專業的問題跟蹤管理的軟體。這裡的”問題”對應的英文單詞是Issue，所以含義比較廣，包括Bug,Task,Enhancement,Improvement等等跟軟體開發相關的名詞。

跟蹤管理即對問題的整個生命週期進行記錄和管理。一個問題從建立到解決到關閉涉及到很多相關資訊，包括是什麼問題，誰發現的問題，誰處理了這個問題，如何處理的，相應的程式碼有什麼改變等等，JIRA可以方便的記錄這些資訊，並且在問題的不同狀態呈現在相應的責任人面前。

JIRA具有很多優點，對測試來說，以下3點必須知道：

1. 針對問題其預設定義了豐富的欄位來記錄問題的各種資訊，包括Issue Type, Issue summary, Issue Description, priority, assignee, reporter, resolutions等等；

2. 預設定義了工作流的一些狀態: new, open, defer, pending, resolved, reopened, closed。 預設定義了一個簡易的工作流, open-in progress-resolved-closed；

3. 支援郵件通知，郵件通知可以同工作流中和工作流之外的事件關聯；

Trac

Trac是一個為軟體開發專案需要而整合了Wiki和問題跟蹤管理系統的應用平臺，是一個開源軟體應用。Trac以簡單的方式建立了一個軟體專案管理的Web應用，以幫助開發人員更好地寫出高質量的軟體；Trac應用力求不影響現有團隊的開發過程。

Trac是以面向進度模型為專案管理模型的，很明顯的特點就是它以里程碑(Milestone)方式進行專案管理的。每個里程碑中的具體要做哪些事情，就使用Ticket來進行定義、跟蹤等。

Gitlab

Gitlab管理bug也是最近才接觸到。跟專案繫結，特別方便管理bug，隨時assign給相關開發，也可以看到開發提交bug時的Commits，每次發版可以對照相關提交，既方便測試，也可以在出現問題時找到對應開發。

Mantis

缺陷管理平臺Mantis，也做MantisBT，全稱Mantis Bug Tracker。

Mantis是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操作的形式提供專案管理及缺陷跟蹤服務。在功能上、實用性上足以滿足中小型專案的管理及跟蹤。更重要的是其開源，不需要負擔任何費用。

基本特性：

1. 個人可定製的Email通知功能，每個使用者可根據自身的工作特點只訂閱相關缺陷狀態郵件；

2. 支援多專案、多語言；

3. 許可權設定靈活，不同角色有不同許可權，每個專案可設為公開或私有狀態，每個缺陷可設為公開或私有狀態，每個缺陷可以在不同專案間移動；

4. 主頁可釋出專案相關新聞，方便資訊傳播；

5. 具有方便的缺陷關聯功能，除重複缺陷外，每個缺陷都可以連結到其他相關缺陷；

6. 缺陷報告可列印或輸出為CSV格式，1.1.7版：支援可定製的報表輸出，可定製使用者輸入域；

7. 有各種缺陷趨勢圖和柱狀圖，為專案狀態分析提供依據，如果不能滿足要求，可以把資料輸出到Excel中進一步分析；

8. 流程定製方便且符合標準，滿足一般的缺陷跟蹤。

Bugzilla

Bugzilla 是一個開源的缺陷跟蹤系統（Bug-Tracking System），它可以管理軟體開發中缺陷的提交（new），修復（resolve），關閉（close）等整個生命週期。

Bugzilla Bug報告分類

（1）待確認的（Unconfirmed）

（2）新提交的（New）

（3）已分配的（Assigned）

（4）問題未解決的（Reopened）

（5）待返測的（Resolved）

（6）待歸檔的（Verified）

（7）已歸檔的（Closed）

（8）Bug處理意見

（9）已修改的（Fixed）

（10）不是問題（Invalid）

（11）無法修改（Wontfix）

（12）以後版本解決（Later）

（13）保留（Remind）

（14）重複（Duplicate）

（15）無法重現（Worksforme）

Bugzilla指定處理人：

（1）可以指定一個處理人

（2）如不指定處理人，則系統指定管理員為預設處理人

Bugzilla連結:

輸入超連結地址，引導處理人找到與報告相關聯的資訊

Bugzilla概述：

（1）概述部分“Summary”的描述，應保證處理人在閱讀時能夠清楚提交者在進行什麼操作的時候發現了什麼問題。

（2）如果是通用元件部分的測試，則必須將這一通用元件對應的功能名稱寫入概述中，以便今後查詢。

Bugzilla平臺作業系統：

（1）測試應用的硬體平臺（Platform），通常選擇“PC”

（2）測試應用的作業系統平臺（OS）

BUG管理工具的跟蹤過程

再來說說一下bug管理工具的跟蹤過程（以BugZilla為例子）：

測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發介面人員，

開發介面將BUG分配給相關的模組的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設定為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論並確認後，拒絕這個BUG，然後測試人員關閉此問題。

如果開發人員接受了BUG，並修改好以後，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。

測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。

我以上分享的每個工具都有自己的優缺點，選擇一款適合自己的來提升工作效率。bug管理工具也不僅僅是介紹到的幾款，還有禪道，Redmine等，大家可以自己搜搜瞭解下。

關注51Testing軟體測試網，提升it技能，從不會到熟練只差一步。

歡迎加入   51軟體測試大家庭，在這裡你將獲得【最新行業資訊】，【免費測試工具安裝包】，【軟體測試技術乾貨】，【面試求職技巧】... 51與你共同學習，一起成長！期待你的加入： QQ   群：    755431660