五顆星星的故事

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

擁有記錄問題的資料庫是優秀軟體團隊的標記之一. 事實上只有極少數團隊有實際進行, 這一點一直令我很驚訝. 程式人員似乎全都自認能用腦袋或立可貼記住所有錯誤, 這件事實在錯得離譜.

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

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

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

以下是實際發生的事情.

程式員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, 譯註:百事可樂的著名飲料).