# 十一、難伺候的故障修復 TRS-80 Level-I BASIC只能儲存兩個字符串變量姊和郎.同樣的我腦袋里天生就 只夠放兩只程序臭蟲(bug).不管何時我只能記住兩只臭蟲.如果你要我記住第 三只，先前的某一只，就會自然而然的被遺忘在荒煙漫草的回憶中。 擁有記錄問題的數據庫是優秀軟件團隊的標記之一.事實上只有極少數團隊有 實際進行，這一點一直令我很驚訝.程序人員似乎全都自認能用腦袋或立可貼 記住所有錯誤，這件事實在錯得離譜. 如果你能專心聽一下，我想要延續我前幾篇文章無痛時程表和無痛規格的精神, 說明一種能無痛地進行錯誤追蹤的方法. 首先你需要一個真正的數據庫.如果是兩人一組在周末程序課上寫些小程序， 拿文本文件當數據庫大概還可以.不過只要規模再大一點就要用真正的錯誤追 蹤數據庫.市面上有無數的錯誤追蹤數據庫隨你選買.（厚臉皮自我推銷一下： 我們在Fog Creek Software也寫了一套，名為FogBUGZ.要我來形容的話，這是個功能強大而且使用簡單的網頁型產品.） 為了示范作用，讓我們跟著臭蟲走走，看著它從出生一直到某人讓它解脫為止 的生活.我們將要跟著大名鼎鼎的1203號臭蟲.下面是錯誤數據庫對這只蟲的敘述： ``` 1203 Bee Flogger 2.0 FTP客戶端 上傳檔案會導致FTP服務器傾印核心(dump core) 已關閉 結束(已解決-已修正） 2 -必須修正 2.0 Alpha Build 2019 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 (昨天）已解決-開發主管不予修正 不是我們的程序，Jill,那只是Linux所附的proftpd. 11/2/2000 (昨天）已由超級測試員Jill重新啟動(指派給開 發主管Willie) 這不對勁.我用一般ftp客戶端聯機都不會讓proftpd當掉.可是 用我們的程序每次都會當.Ftp服務器不會自己"當"掉. 11/3/2000 (今天）己由開發主管Willie指派給裎序人貝 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忘記把復制好的字符串加零字符作結尾.不過他一直都沒有注意到這個問題，因為 大部份情況下，剛好都是把字符串復制到已先清成零的內存里. 同一周稍后超級測試員Jiii正在猛操那個程序，她把額頭頂在鍵盤上滾來滾去 或進行某些同等嚴荷的測試.（恰巧的是大多數優秀的測試員都叫做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「ep「o(無法重現）duplicate(重復的問題），〇「by design(設計限制）. 4. Not Repro表示沒有人能重現該錯誤.程序人員在錯誤報告漏寫重現步驟 時常常會用這一項. 5. 你需要小心追蹤程序版本.每次發給測試員的軟件都應該有個編譯ID編 號，這樣可憐的測試員才不必在根本尚未修正的版本上測試同一個問題. 6. 如果你是個程序員，而且想盡辦法都無法讓測試員使用問題數據庫，只 要不接受用其他方法寫的錯誤報告就可以了.如果測試員習慣用電子郵件 送錯誤報告給你，你就把信退回去并加上以下簡短訊息：”請把它放進問 題數據庫中.我沒法子追蹤電子郵件 7. 如果你是個測試員，而且想盡辦法都無法讓程序人員使用問題數據庫， 只要停止向他們報告錯誤就好了-把錯誤直接放在數據庫里并讓數據 庫發信通知. 8. 如果你是個程序員，而且只有部份同事在用問題數據庫，只要開始在數 據庫里把錯誤分派給他們.最后他們自然會明白的. 9. 如果你是個經理，而且似乎沒人在用你花大筆費用安裝的問題數據庫，那就開始利用它把新功能分派給大家.因為問題數據庫也是個很好的”未 完成功能〃數據庫. 10. 要避開在問題數據庫里增加新字段的誘惑.每個月總會有人想出個要在 數據庫里新增字段的好點子.什么聰明的點子都有，比如追蹤發現問題 的檔案；追蹤有多少比例的問題是可重現的；追蹤某錯誤發生的次數； 追蹤某問題發生時機器上某個DLL的版本.不要屈服在這些點子之下，這 一點非常重要.如果你屈服了，輸入新錯誤的畫面最后會出現上千個字 段要輸入，結果是沒有人會想輸入錯誤報告.要讓問題數據庫有效運作， 一定得讓大家都用，如果〃正式〃輸入錯誤太麻煩，大家就會繞過錯誤數 據庫. 只要你在寫程序（只有一個人寫也一樣），如果沒有一套良好的數據庫列出程序 中所有的問題，一定會產生質量低劣的程序代碼.良好的軟件團隊不只會廣泛 使用問題數據庫，其中成員還會習慣用問題數據庫產生待辦事項列表，并把瀏 覽器首頁設成會列出所分派到的工作，還會開始祈禱他們能把問題指派給辦公 室經理，叫他進多點山露汽水(Mountain Dew，譯注:百事可樂的著名飲料）. Fog Creek Software制作了 一套易用的問題追蹤軟件，名為FogBUGZ.