別讓你發現的缺陷跑掉

（建議使用Firefox瀏覽器，IE可能會有亂碼）

假定只有一個開發人員，比如你；假定只有一個使用者，比如老趙。現在來看看你們之間關於Bug方面的互動。每當你給老趙程式的一個新版本，老趙就開始玩它。由於經常出現問題，他會經常來打擾你。於是你厭煩了，跟他約法三章，“每天下午四點，我們討論你發現的Bug！”

第一天，老趙發現了2個Bug。下午四點，向你彙報。哈，這兩個都是小問題！老趙說的時候，你就順手改好了！

第二天，老趙發現了10個Bug。下午四點，向你彙報，彙報了7個。因為他沒全記住。你一邊聽，一邊翻白眼，因為好像有幾個解決起來有點困難…… 等明天上午，好好想想。

第三天，上午，你在改Bug。改好了3個。因為你忘了3個。還有1個，老趙說不清楚，讓他重新示範一下，可這次又沒出現異常情況。你把改好後的程式的最新版本給老趙，老趙欣然接受，但是一炷香的功夫，他就嚷嚷起來了。

其實只要對此做一點改進，就能基本解決問題了：老趙把10個Bug寫在紙上。在下午四點，你們一起過一遍這張紙上的內容，然後你把這張紙放在電腦旁邊直到Bug都被解決。這張紙，就是最簡單的Bug跟蹤系統。

Bug跟蹤系統，學名叫缺陷跟蹤系統(Defect Tracking System)。據此推算，Bug的學名叫缺陷（Defect）。本書自此處開始，改稱呼它為缺陷。

通常使用的缺陷跟蹤系統，當然比上面那個複雜得多，因為實際情況常常複雜得多。不只一個開發人員，可能是一大幫；不只一個使用者，可能來自五湖四海；恐怕不是使用者直接找開發人員，而是有客服人員、產品經理等等在其中，堅守崗位；另外，缺陷不光是被使用者發現，事實上，相當多的缺陷是被測試團隊發現。

有些Team Dev使用MS Excel等試算表來處理缺陷跟蹤，這比用小紙條前進了不少。但是，通常仍然是不夠方便的。比如，由於不能兩個人同時修改一個MS Excel檔案，所以經常需要相互等待，甚至發生修改丟失的情況。再比如，如果缺陷數量多了，用一個表格來瀏覽，也會很不方便。對於某一個程式員來講，可能沒幾個缺陷是歸自己解決的，可是卻要為此，在成百上千個缺陷條目裡找自己的名字。

基本的建議是，安裝並使用缺陷跟蹤軟體。在這樣的軟體裡，每一個缺陷是一個條目。缺陷被發現的時候，就被錄入到這樣的軟體裡。之後，軟體協助我們跟蹤它，跟蹤一個缺陷的整個生命週期，直到確認這個缺陷已經被消滅。

[Bugzilla] 這是開源世界當前最為流行的缺陷跟蹤軟體，準確地講，是變更要求管理軟體。類似的開源軟體還有Mantis和Trac。

[BugFree] 這是中國人自己的變更要求管理軟體，開源，使用者廣泛。

[ClearQuest] IBM Rational公司出品。功能強大的商用變更要求管理系統。它能夠跟ClearCase很好的整合：能夠將ClearCase中的活動（即任務單元），與一條變更請求記錄（比如缺陷記錄）關聯起來。更多的功能，我們隨後介紹。類似的商用軟體還有Telelogic Change等。

 其實老趙在把小紙條交給你之前，自己偷偷複印了一張。這隻老狐狸。

 變更要求管理將在下一章中講述。在這裡只要知道，對缺陷的管理，屬於變更要求管理，因為修複缺陷的請求，是變更請求中的一類。

註明：上文出自《未雨綢繆——理解軟體組態管理》原稿，如果對此書感興趣可以訪問互動網擷取該書目錄等詳細資料，如果興趣實在難以磨滅，歡迎購買。好書，定價才45元。

相關推薦：

《軟體調試》電子書下載

《軟體調試》與《Windows進階調試》比較之我見

惱人不休的問題：什麼是軟體組態管理？