# 十九、自動獲取用戶故障報表 我曾經受雇于在美國一間最大的互聯網服務供貨商撰寫客戶端應用程序，所開發的產品擁有 數以百萬的用戶,即使一個最罕見的錯誤都可能影響數百甚至數千的用戶。雖然如此,每次當 我們決定按下按鈕以釋出最新版本的程序時我還是充滿信心。我還記得我曾經告訴我爸「這 次的試用版本看起來棒極了。昨天我們在北美洲只收到十二個錯誤報告。」 十二個，嗯?還是十三個？ 不，是十二個。我們應用了一種日漸普及、由客戶端自動報告錯誤的技術。所得的報告都記 錄到錯誤追蹤數據庫內匯總成摘要,以便開發人員尋找并修正只在客戶端發生的錯誤。這類 錯誤往往難以在我們的測試實驗室內測得到，因為事實上我們無法全部設置或模擬成客戶所 有超乎尋常的計算機組合。 錯誤偵測及報告功能正日漸普及。現在互聯網瀏覽器和窗口系統都己經內建這類功能，而且 越來越多客戶希望他們的桌面應用程序懂得自行回報所遇到的錯誤。 能夠知道世界上每一個角落找到的每個錯誤，對于建立一份你所開發的產品能在這個瘋狂的 世界上安然無恙的信心而言非常重要。尤其對于像開發消費者應用程序領域的我們而言更 為重要。很多時候你不能倚靠客戶告訴你他們所遇到的錯誤，他們可能沒有足夠的技術背景, 更重要的是，要是沒有自動報告錯誤的機制，他們根本不會有興趣在忙著干自己重要的工作 時還抽空給你發一份完整而有用的錯誤報告。 現在我創立了自己的公司,更深深地相信自動收集客戶端錯誤的重要。差不多所有我們在Fog Creek Software編寫的程序都有好些方法能透過我們的FogBugz錯誤追蹤數據庫回報錯誤。 我們的產品CityDesk之內的產品，以至FogBugz本身(一個安裝在客戶端的網頁服務器上的 網頁應用程序)都內建了這項功能。兩者皆可以透過互聯網匯報錯誤。就連我們為內部開發 的應用程序，比如說營運Fog Creek網上商店的電子商務程序，都會用相同的方式通知開發團 隊程序運作期間所遇到的錯誤。 ## 剖釋錯誤 好吧，你的程序當掉了。在幾乎每個程序執行環境下,總有些方法能讓你由某個地方回復、重 新開始作業。以往我們只會讓程序在出問題的的地方乖乖掛掉,現在我們選擇彈出一個對話 框。 這么多年來我學到一件事，就是你所問的問題越多，想回答的人就越少。所以現在我們只會問 最少的而又能幫助分析錯誤的問題。比如說「你正在做什么？」、「你的電郵地址?」我們 強調提供電郵地址是自愿性質,以排解關于個人隱私的疑慮。令人意外的是有些盲目恐懼是 如此深入民心而且根深蒂固。在消費者市場內，許多人都己經被十一點鐘新聞報導教育成永 不要交出他們的電郵地址以避免收到垃圾郵件。結果是,如果你需要人們匯報錯誤的時候填 寫電郵地址，他們就干脆不提交報告。 基本上所有你所需要的數據都可自動取得,例如操作系統的版本,系統擁有的內存大小等等。 ## 數據收集 接下來的問題是，要收集什么樣的數據才可以幫助我們的開發人員找到造成錯誤的地方?我 們很難抗拒把所有抓得到的數據都抓起來的這種誘惑。抓下每個你可以抓到的位信息，抓下 用戶系統內所有DLL及COM控件的版本,以至把所有內存內的數據都倒出來制作一個備份(有 些會叫這做核心轉儲Core Dump)。 然而在做了開發人員幾年后、以及在從不知道自己拿著份核心轉儲數據可以干些什么的情況 下,我終于發現這些都是非必要的數據。以下都是我們實際上會收集的數據： * 產品版本 * 操作系統版本及微軟Internet Explore「版本(有相當多的窗口功能都是來自Internet Explore「和它的組件，以致這項數據對于了解包括圖象接口應用程序在內 的程序對窗口操作系統上的表現非常重要） * 發生錯誤的程序文件以及程序代碼行數錯誤消息正文 * 獨一無二的錯誤碼 * 來自用戶關于他們正在進行中的作業的描述 * 用戶的電郵地址 有這些就足夠了！這些年來我們發現單是知道發生錯誤的程序代碼行數就己經足夠幫助修正 大部份的問題。在少數以這項信息不足以解決問題的個案上，你可以透過直接聯絡遇上問題 的用戶以取得更多的信息幫忙解決問題。收集少量信息的好處在于令回報錯誤的程序變得非 常快速，進而減少用戶對回報問題感到不耐煩的機會。單是檢查所有DLL和COM控件的版本就 可以花上好一段時間,如果數據是由調制解調器上傳的話就又得花更多的時間,而這些數據是 可以提供幫助修正錯誤的有用資訊。即使你發現錯誤只會在程序應用一個微軟系統DLL的某 個版本時才會發生,你又可以做些什么?你仍然需要改寫程序來避開錯誤。 ## 致電回家 感謝上天互聯網的無處不在，在大部份情況下透過網頁傳送信息都是把信息送回家的最佳方 法。只要送出一個標準的HTTP需求，你的錯誤報告幾乎可以穿越于客戶環境內任何種類的防 火墻。更妙的是，現在幾乎每一種編程環境都有內建的鏈接庫支持發送HTTP需求及讀取響應。 舉例來說，在窗口平臺上你就可以在WININET鏈接庫內找到內建的函數式去利用Internet Explore「的網絡傳輸程序代碼來傳送HTTP需求和讀取響應。利用這些函數式最好的是，如果 用戶曾經設定他的瀏覽器透過代理服務器來在防火墻內傳取數據，WININET呼叫程序會自動 采用相同的設定操作，而過程中你無付出任何額外的努力更改或設定你的程序就能正常發揮 功用。 我們的FogBugz在收到HTTP需求送來的錯誤報告后，會傳回一個很短的XML文件表示己經收到 錯誤報告，文件亦同時包含一個展示給用戶的訊息。關于這點，稍后我將會談得更多。 如果你的應用程序是一個網頁瀏覽器應用程序，你可以采用一個更簡單的做法：展示一個包 含一張可遞交數據到服務器上的表格的網頁。你只需要將表格的行動路徑指向你的錯誤追蹤 數據庫即可。請參考圖象2。 在好些種類的應用程序當中，你或許會想將錯誤報告先寫到檔案或登錄內，等到用戶重新啟 動應用程序時才送出，而非在錯誤發生時直接送出。我稱呼這種技巧為延遲傳送。這種做 法雖然會延后收到報告的時間，但好處是一旦發生的錯誤嚴重至令你的應用程序癱瘓到無法 送出錯誤報告時，你仍然可在稍后取得報告。 現在所有要送交Fog Creek的錯誤報告都會送抵一個位于我們公眾服務服務器上的URL。而我 們的錯誤追蹤數據庫則由透過這個URL接收錯誤報告。事實上這個URL是公眾可以接觸到錯 誤追蹤數據庫的唯一路徑。除了接收報告以外的所有功能都己被死鎖，客戶可以提交錯誤報 告，但無法讀取數據庫內的任何數據。 圖象3展現的是當一個錯誤報告抵達我們的數據庫時的模樣。我們可以設定將收到的報告自 動送給開發團隊內的其中一位工作人員，不過最近為免打擾同事，我們選擇將報告都送到 被建立的虛擬人”CityDesk New Bug”手上。每次我們想要過濾出收到的報告，只需找出那些 被分派到虛擬同事手中的錯誤，然后再逐一決定是否需要跟進修正。所有需要修正的錯誤將 會被派到真實存在的同事手上。 ## 辦認重復的錯誤 應用自動錯誤報告收集時很重要的一點是，同一個錯誤可以在許多不同的人手上發生許多次， 而你絕不會希望每次同一個錯誤被報告時都會在你的錯誤追蹤數據庫內制做一個新的錯誤 記錄。我們應付這個情況的方法是以錯誤信息內的重要數據為錯誤報告編上獨特的標識符串。 字符串的編碼方法十分謹慎，分別來自兩個用戶的同一錯誤必須獲編相同的標識符串。在好 些實驗以后，我們發現最好的編法就是在字符串內加入錯誤碼、文件名、函數式名稱、錯 誤行數和產品版本。圖象3內展示了標識符串”E「「o「91 (global:lsRoot:0) V1.0.32”。字 符串說明檔案global.bas于執行函數式IsRoot位于第0行的程序代碼時發生91號錯誤，而產 品的版本為1.0 build 32。相當偶然地，我們總是將編譯版本數目為雙數的產品編為內部使 用版本，而編譯版本數目為單數的則是會送交到客戶手上的版本，這樣我就可以一眼知道某 個錯誤報告到底發生在開發人員或客戶身上。 FogBugz往后遇到標識符串相同的當機回報時，會自動附加到這個案例中，并不會重開一個 新案例。這樣能讓程序員在同一個地方看到所有相同的當機狀況。 標識符串的格式設計得花點心思。我們以前會把當機錯誤訊息整個含在標識符串里。不過很 快就發現錯誤訊息會被譯成不同的語言，于是每種錯誤都會分散成英德西法及其他幾種我 認不出的語言。我們解決的方法是把錯誤訊息放在當機報告內，但是把不隨語言而變的錯誤 標識符放在報告的標題中，這些重復的回報就少多了。 另外標題也經過特別安排，可以方便搜尋特定問題。由于我們在標題中使用「檔名：函數名： 行數」的格式(注意其中的冒號），所以只要搜尋「：函數名：」就很容易找出某函數相關的 問題。我們基于相同的原因在版本號碼前加上字母V，這樣就能搜尋V1或V1.0或V1.0.32。如 果沒有這個V字母，想找版本1時就會找出所有標題里剛好有1字符的錯誤報告了。 當錯誤被確認時，我們可以把某個旗標(FogBugz接口里的Scout Will)由「繼續回報」改成 「停止回報」，之后就會忽略標識符串相同的當機回報。我們甚至可以設定一串文字訊息(在 FogBugz接口里是針對自動送出的案例中出現的ScoutMsg),可以自動傳給往后遇到相同當 機狀況的使用者。當我們要使用避開錯誤的作法(workaround)時也會用這個功能提出建議。 就像是「嘿，下次你要存檔前要記得先拍拍自己的頭再摸摸自己的肚子！」 重復回報的常見原因之一，就是當在當機處理程序本身。這并不一定是說當機處理的程序有 問題，或許只是因為原先的當機太嚴重，以致再也沒有程序能正常運行。