軟工藝術 : [轉貼]無痛錯誤追蹤

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在問題追蹤資料庫中輸入新錯誤. 這裡光是輸入錯誤的動作就是有學問的: 有好的錯誤報告也有不好的錯誤報告.

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

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

-- 聖杯傳奇

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

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

如果你沒告訴我要怎樣重現問題, 我可能根本不知道你講的是什麼."程式當了而且在桌面留下一個臭臭的大便狀物體."講得很好, 寶貝. 不過除非你告訴我 你做了些什麼, 否則我是什麼事都不會做的. 現在我得承認有兩種情況是很難找出重現步驟的. 有時候是根本不記得或只是在轉述"田野"中(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, 譯註:百事可樂的著名飲料).