為什么軟件測試人員都不通過QQ、微信、郵件上報Bug？

十多年前，客戶在使用過程中遇到了 Bug，直接就截個圖，或者是用 Word 文檔整理在一起，從 QQ 或者郵件上把 Bug 信息發送給開發，開發收到后再修復更新上線。

而現在正規的軟件項目已經不會再用這種原始的方式來報 Bug 了，而是會借助測試工具來幫助報告和跟蹤 Bug，即使你偶爾能看到有項目還在采用原始方式報 Bug，你肯定也會覺得這樣做不專業。

但不知道你有沒有仔細想過這個問題，為什么現在不通過 QQ/ 微信 / 郵件報 Bug，又有哪些測試工具可以幫助你更好地發現、報告和跟蹤軟件中的 Bug 呢？今天我們會展開討論這個問題。

Bug 跟蹤工具

我想你對與 Bug 這個詞一定不陌生，它是我們軟件中的缺陷或錯誤。這個詞的誕生也很有意思。1947 年 9 月 9 日，一只小飛蛾鉆進了哈佛大學的一臺計算機電路里，導致系統無法工作，操作員把飛蛾貼在計算機日志上，寫下了“首個發現 Bug 的實際案例”。

雖然 Bug 的歷史已經有 60 多年了，然而 Bug 跟蹤工具卻沒有出現太久。軟件項目中最早也是通過郵件、即時通訊等原始方式報告 Bug，直到 1992 年才有第一個專業的 Bug 跟蹤軟件GNATS。

在這之后才逐步有了像 Bugzilla、Jira、MantisBT 等專業的 Bug 跟蹤工具。而現在，Bug 跟蹤工具已經成為軟件項目中必不可少的工具之一。那么，Bug 跟蹤工具是怎么逐步替代 QQ、郵件等方式來處理 Bug 的呢？

為什么要使用 Bug 跟蹤工具？

我們在上一篇學習了軟件測試相關的理論知識，軟件測試的主要工作就是發現 Bug、報告 Bug 和跟蹤 Bug。測試人員發現 Bug 只是第一步，還需要報告 Bug 讓開發人員可以知曉和定位，并且跟蹤整個 Bug 修復的過程。

用 QQ 或者郵件報 Bug 的這種方式，看起來快捷簡單，但是問題很多：

• Bug 不能有效被跟蹤，不知道一個 Bug 是不是已經被修復了；
• 效率很低，開發人員頻繁的被這樣的報 Bug 的消息打斷，不得不停下手頭的工作去甄別 Bug；
• 不能直觀的了解當前項目的 Bug 狀態，比如說：修復了多少，還有多少沒有修復，近期 Bug 數量是增加了還是減少了。

不難看出，通過 QQ 等方式報告的 Bug，都是文字配合圖片等信息，很難檢索和分類，而 Bug 跟蹤工具，采用結構化的數據來定義 Bug，每一個 Bug 都有一些關鍵的信息可以對 Bug 進行分類和檢索。

在 Bug 跟蹤工具使用中，一個基本的 Bug 信息包括：

• 標題；
• 描述（包括期望結果、實際結果和重現步驟等關鍵信息）；
• 優先級；
• 指派人；
• 狀態（New、Open、 Rejected、Fixed 等）；
• 其他。

那這樣的話，就很容易的對 Bug 進行分類和檢索，比如說：

• 張三想查看所有分配給他的 Bug，那只要列出所有指派人是張三的 Bug；
• 想列出所有未解決的 Bug，只要列出所有狀態不是 Close 或 Rejected 的 Bug 即可。

這樣對于開發人員來說，可以直觀的看到自己有哪些 Bug 需要處理，Bug 的描述信息也可以幫助重現 Bug、快速定位到 Bug 的原因；對于項目經理或者測試人員來說，可以直觀的看到哪些 Bug 還沒解決，及時了解項目進展。

在軟件項目中，要把好的實踐流程化，把好的流程工具化。Bug 跟蹤工具則很好的貫徹了這一點，將 Bug 的解決過程流程化。

你平時在 Bug 跟蹤系統中看到的 Bug 狀態，看起來只是一個有限的狀態列表，但背后其實是一套解決 Bug 的流程。就像下面這張圖表示的這樣，一個 Bug 從創建到最后結束，其實是有一個完整的流程的。

通過這樣的流程，開發人員就可以集中對 Bug 進行分配、按照優先級分別解決，而測試人員則可以第一時間知道 Bug 處理的狀態變化，及時驗證，方便跟蹤整個過程。

使用 Bug 跟蹤工具的注意事項

報告 Bug 的目的是為了能跟蹤 Bug，以及幫助開發人員重現直到解決問題。要想做到測試和開發高效協作，這里面有一些需要注意的事項。

首先，所有的 Bug 都應該通過 Bug 跟蹤系統管理和跟蹤，不應該再通過 QQ/ 微信 / 郵件的方式跟蹤 Bug。如果客戶、同事通過 Bug 跟蹤系統之外的其他途徑反饋 Bug，應該統一提交到 Bug 跟蹤系統管理跟蹤起來。

然后，不能把多條 Bug 合并成一條，一個 Bug 創建一個獨立的 Ticket。我遇到過有些測試為了省事，把幾條 Bug 合并成一個 Ticket 來報，導致的問題就是，必須這幾條 Bug 都修復了，這個 Ticket 才能改變狀態，如果其中一個 Bug 沒有驗證通過，需要 Reopen 整個 Ticket。

再有，描述清楚如何重現 Bug 非常重要。一個 Bug 如果無法重現，也沒有日志、截圖等輔助信息，那是非常難以定位的，會浪費很多開發人員定位 Bug 的時間。

最后，不要把 Bug 跟蹤系統當成討論板用。在項目中一個常見的場景是，一個 Ticket 下面，跟討論版一樣添加了很多留言，開發認為不是 Bug，測試認為是一個 Bug，開發又覺得是產品設計沒定義清楚，應該讓產品經理來講清楚，皮球踢來踢去，最后問題還沒解決。

Bug 跟蹤系統的主要功能是用來跟蹤 Bug 的，不是用來討論和扯皮的。遇到上面的情況，其中一方就應該主動一點，拉上相關人面對面討論，當面確認清楚這個 Bug 到底是什么問題，然后馬上解決掉。

總結：工具有很多例如：Bugzilla、Jira、MantisBT，禪道。現在很多公司都用禪道進行項目的管理，之前文章也有發過禪道的相關文章，以及公眾號也有提供禪道的安裝包，大家可以自行下載，搭建。管理bug的工具初學者只要掌握一個就行了，因為都是大同小異的，了解其流程即可。