無痛錯誤追蹤 Painless Bug Tracking

TRS-80 Level-I BASIC 只能儲存兩個字串變數：A$ 和 B$。同樣的我腦袋裡天生就只夠放兩隻程式臭蟲(bug)。不管何時我只能記住兩隻。如果你要我記住第三隻，先前的某一隻，就會自然而然的會被遺忘在荒煙漫草的回憶中...

擁有(並使用)記錄問題的資料庫是優秀軟體團隊的標記之一。令我驚訝的是：事實上只有極少數團隊有實際進行。程式人員似乎全都自認為能用腦袋或便利貼記住所有錯誤，這件事實在錯得離譜。

如果你能專心聽一下，我想要延續我前幾篇文章無痛時程表和無痛規格的精神，說明一種能無痛地進行錯誤追蹤的方法。

首先你需要一個真正的資料庫。如果是兩人一組在週末程式課上寫些小程式，拿文字檔當資料庫大概還可以。不過只要規模再大一點，就要用真正的錯誤追蹤資料庫。市面上有無數的錯誤追蹤資料庫隨你選買。(厚臉皮自我推銷一下：我們在 Fog Creek Software 也寫了一套，名為 FogBUGZ。要我來形容的話，這是個功能強大而且使用簡單的網頁型產品。)

為了示範，讓我們跟著臭蟲走走，看著它從出生一直到某人讓它解脫為止的過程。我們將要跟著大名鼎鼎的1203號臭蟲。下面是錯誤資料庫對這隻蟲的敘述：

編號	1203
專案名稱	Bee Flogger 2.0
範圍	FTP用戶端
標題	上傳檔案會導致FTP伺服器傾印核心(dump core)
指派給	已關閉
狀態	已關閉(已解決 - 已修正)
優先度	2 - 必須修正
修正於	2.0 Alpha
版本	Build 2019
電腦 Computer	Jill的iMac，Mac OS 9.0，128M RAM，1024x768 millions of colors
說明	11/1/2000 由超級測試員 Jill發現 啟動 Bee Flogger 建立一個未命名檔案，內容只有一個"a"字 點工具列上的FTP鈕 嘗試用ftp傳至你的伺服器 錯誤：觀察；ftp伺服器停止回應。輸入ps -augx顯示ftp伺服器甚至停止執行，而且根目錄有核心傾印。 預期：不應當掉 11/1/2000 由超級測試員 Jill指派給指派給開發主管 Willie 11/2/2000 (昨天)已解決 - 開發主管 Willie不予修正 不是我們的程式，Jill，那只是 Linux 所附的 proftpd。 11/2/2000 (昨天) 已由超級測試員 Jill重新啟動(指派給開發主管 Willie) 這不對勁。我用一般 ftp 用戶端連線都不會讓 proftpd 當掉。可是用我們的程式每次都會當。Ftp伺服器不會自己「當」掉。 11/3/2000 (今天) 已由開發主管 Willie指派給程式人員 Mikey Mikey，你能不能看一下這個問題？也許你的用戶端程式碼某個地方有錯。 11/3/2000 (Today) 已解決 - 已由程式人員 Mikey修正 我想我把用戶名稱錯傳成密碼或其他東西了... 11/3/2000 (今天)已由超級測試員 Jill重新啟動(指派給程式人員 Mikey) Build 2021還是有這個問題。 11/3/2000 (今天)已由程式人員 Mikey編輯 呃。這蠻奇怪的。讓我來抓這個錯。 11/3/2000 (今天)已由程式人員 Mikey編輯 我想應該是MikeyStrCpy()的問題... 11/3/2000 (今天)已解決 - 已由程式人員Mikey修正 啊！ 修好了！ 11/3/2000 (今天)已由超級測試員Jill關閉 看起來build 2022已經修正了這個問題，所以我把這個問題關閉了。

以下是事情發生的經過。

程式員 Mikey 正為他的麥金塔軟體寫新的 FTP 用戶功能。寫到一半時由於覺得不爽，就寫了自己的字串複製函數。想藉此教訓教訓公司裡那些強迫要重複使用程式碼的傢伙！哇哈哈！

Mikey，當你不重新使用程式碼時就會出事。而現在所出的事就是 Mikey 忘記把複製好的字串加零字元作結尾。不過他一直都沒有注意到這個問題，因為大部份情況下，剛好都是把字串複製到已先清成零的記憶體裡。

同一週稍後超級測試員 Jill 正在猛操那個程式，她把額頭頂在鍵盤上滾來滾去或進行某些同等嚴荷的測試。(恰巧的是大多數優秀的測試員都叫做 Jill 或 Gillian等等。)突然間發生了非常奇怪的事情：她測試用的ftp伺服器當掉了。不要懷疑，我知道這是台 Linux 機器而 Linux 機器是不會當的(slashdot 的人拜託不要噓我)。不過這個該死的東西就是當了。而她根本沒有動過伺服器，她只不過用 Mikey 的 Mac 程式把檔案 FTP 上去而已。

現在呢，由於 Jill 是個超級優秀的測試員，所以她會小心地把所做過的事記下來了(比如在實驗手冊上精確記錄頭在鍵盤上滾動的方位)。她找一台乾淨的機器從頭開始重複每個步驟，看吧，又發生了！Linux 的 ftp daemon又當了！這麼一來一天內就發生兩次了！Linus(譯註：創造 Linux 的人)注意啦。

Jill 斜眼看看重現步驟清單。總共大約有20個步驟。其中有幾個似乎與問題無關。做了一點實驗後，Jill已經能把問題縮減到四個步驟，而且每次都能產生相同的結果。現在她已經準備好把問題發出來了。

Jill 在問題追蹤資料庫中輸入新錯誤。這裡光是輸入錯誤的動作就是有學問的：有好的錯誤報告也有不好的錯誤報告。

優良錯誤報告必備的三元素

然後主說話了，祂說「你要先取出聖撞針。然後你要數到三，不多，不少。三是你要數的數而要數的數就是三。四不是要數的數，二也不是，除非接下來要數到三。五完成不行。當數到第三個數字三時，就把你的安提阿金手榴彈投向你的敵人，那些在我眼中極其下流的人，他們必須承受」

寫一份優良錯誤報告的規則很好記。每個好的錯誤報告都要有剛好三個東西。

1. 重現的步驟，
2. 期望看到的，以及
3. 實際所看到的。

看起來很簡單，對不對？可能沒那麼容易，身為程式員，別人丟給我的問題總會缺一兩點。

如果你沒告訴我要怎樣重現問題，我可能根本不知道你講的是什麼。「程式當了而且在桌面留下一個臭臭的大便狀物體。」講得很好，寶貝。不過除非你告訴我你做了些什麼，否則我是什麼事都不會做的。現在我得承認有兩種情況是很難找出重現步驟的。有時候是根本不記得或只是在轉述「田野」中(field，譯註：指實驗室以外的環境)的錯誤。(順便提一下，為什麼他們要稱之為「田野」呢？是不是像黑麥田或其他作物呢？不管了...)還有另一個可以不提供重現步驟的場合，就是問題時有時無並非一直出現，不過你還是應該提供重現步驟，再加個小附註標明問題不是時常出現。在這些場合下要找到問題實在是很難，不過我們還是可以試試。

如果你不指明你期望看到的，我可能不明白它為什麼是個問題。開機畫面上有血跡。那又怎樣？我寫這段程式時割到手指啦。你希望看到什麼？啊，你說規格上說沒有血跡！現在我搞懂你為什麼說它是個問題了。

第三部份。你實際上看到什麼。如果你不告訴我這一點，我不會知道問題是什麼。這是理所當然的。

回到我們的故事

Anyhoo。Jill 把錯誤輸進走了。在良好的錯誤追蹤系統中，錯誤會自動分派給該專案的開發主管。這裡隱藏了第二個概念：每個錯誤隨時都要有一個人負責，一直到錯誤關閉為止。錯誤就像是個燙手山芋：當拿到燙手山芋時，你就得負責把它解決掉，或是把它丟給別人。

程式主管Willie看看這個錯誤，認為這個可能與 ftp 伺服器有關，所以就以「不予修正」把它處理掉。畢竟他們並沒有寫那個ftp伺服器。

問題被處理掉之後就會分派回開啟的人身上。這可是個重點。不是程式人員認為沒事就真的沒事了。鐵律是只有開啟錯誤的人才能關閉錯誤。程式人員可以解決問題，意思是「嗨，我覺得弄好了」，不過要實際關閉錯誤並把它從清單中拿掉，最初開啟的人必須確認問題真的已被修好，或是同意該問題基於某於原因不必修正。

Jill 收到一封電子郵件通知她問題回來了。她看看信裡開發主管 Willie 的說明。有些東西不太對勁。這套 ftp 伺服器大家用好幾年了都沒有當。只有用 Mikey 的程式才會當。所以Jill重新啟動該問題並說明她的想法，所以問題又回到 Willie 身上。這次 Willie 把問題指派給 Mikey 修正。

Mikey看看這個錯誤，認真的想了很久，結果完全誤診了這個問題。他修正了其他完全不相干的錯，然後就說把Jill開啟的問題解決掉了。

問題回到 Jill 身上，這次標示為「已解決 - 已修正」。Jill 拿最新版軟體試了她的重現步驟，看著看著 Linux 伺服器就當了。她又重新開啟問題並且直接指派回給 Mikey。

Mikey 被難到了，不過最後還是找到了錯誤的根源。(知道是什麼了嗎？我要把它當作給讀者的作業。線索可是給足了！)他把問題修好後測一測，然後 --找到了！照重現步驟去做不會再讓 ftp 伺服器當掉了。他再一次標示「已修正」把問題解決掉。Jill 也試了重現步驟，發現問題的確修好了，所以就把它關掉。

錯誤追蹤的十大建議

1. 好的測試員一定會試著把重現步驟減到最少步；這對必須追出問題的程式人員來說極為有用。
2. 要記住只有一開始開啟的人才能關閉該錯誤。其他人可以解決問題，不過只有最初看到錯誤的人可以真正確認所看到的錯誤已被修正。
3. 要解決錯誤有很多種方法。FogBUGZ中可用的解決方法有fixed(已修正)，won't fix(不予修正)，postponed(暫緩)，not repro(無法重現)，duplicate(重複的問題)，or by design(設計限制)。
4. Not Repro表示沒有人能重現該錯誤。程式人員在錯誤報告漏寫重現步驟時常常會用這一項。
5. 你需要小心追蹤程式版本。每次發給測試員的軟體都應該有個編譯ID編號，這樣可憐的測試員才不必在根本尚未修正的版本上測試同一個問題。
6. 如果你是個程式員，而且想盡辦法都無法讓測試員使用問題資料庫，只要不接受用其他方法寫的錯誤報告就可以了。如果測試員習慣用電子郵件送錯誤報告給你，你就把信退回去並加上以下簡短訊息：「請把它放進問題資料庫中。我沒法子追蹤電子郵件。」
7. 如果你是個測試員，而且想盡辦法都無法讓程式人員使用問題資料庫，只要停止向他們報告錯誤就好了 - 把錯誤直接放在資料庫裡並讓資料庫發信通知。
8. 如果你是個程式員，而且只有部份同事在用問題資料庫，只要開始在資料庫裡把錯誤分派給他們。最後他們自然會明白的。
9. 如果你是個經理，而且似乎沒人在用你花大筆費用安裝的問題資料庫，那就開始利用它把新功能分派給大家。因為問題資料庫也是個很好的「未完成功能」資料庫。
10. 要避開在問題資料庫裡增加新欄位的誘惑。每個月總會有人想出個要在資料庫裡新增欄位的好點子。什麼聰明的點子都有，比如追蹤發現問題的檔案；追蹤有多少比例的問題是可重現的；追蹤某錯誤發生的次數；追蹤某問題發生時機器上某個DLL的版本。不要屈服在這些點子之下，這一點非常重要。如果你屈服了，輸入新錯誤的畫面最後會出現上千個欄位要輸入，結果是沒有人會想輸入錯誤報告。要讓問題資料庫有效運作，一定得讓大家都用，如果「正式」輸入錯誤太麻煩，大家就會繞過錯誤資料庫。

只要你在寫程式(只有一個人寫也一樣)，如果沒有一套良好的資料庫列出程式中所有的問題，一定會產生品質低劣的程式碼。良好的軟體團隊不只會廣泛使用問題資料庫，其中成員還會習慣用問題資料庫產生待辦事項列表，並把瀏覽器首頁設成會列出所分派到的工作，還會開始祈禱他們能把問題指派給辦公室經理，叫他進多點山露汽水(Mountain Dew，譯註：百事可樂的著名飲料)。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.