為什麼軟體測試人員都不透過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的工具初學者只要掌握一個就行了，因為都是大同小異的，瞭解其流程即可。