The Joel on Software Translation Project:無痛錯誤追蹤

From The Joel on Software Translation Project

Jump to: navigation, search

Contents

無痛錯誤追蹤

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
編輯:Jeff Wang 王家麒
November 8, 2000 A part of Joel on Software, http://www.joelonsoftware.com

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


Fog Creek Software製作了一套易用的問題追蹤軟體,名為FogBUGZ

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


Personal tools