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

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

原創 大規模網絡運維 做者：博爲峯網校 時間：2018-08-14 16:40:32  364  0

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技能，從不會到熟練只差一步。