錯誤資訊； 所報告的問題是由於使用者的過失而產生的； 所報告的問題是由於其他程式的錯誤而產生的； 所報告的問題是由於網路錯誤而產生的； 這便是為什麼「技術支援」被認為是一件可怕的工作，因為有拙劣的bug報告需要處理。然而並不是所有的bug報告都令人生厭：我在業餘時間維護自由軟體，有時我會收到非常清晰、有幫助並且
「有內容」
的bug報告。 在這裡我會盡力闡明如何寫乙個好的bug報告。我非常希望每乙個人在報告bug之前都讀一下這篇短文，當然我也希望使用者在給我想
問題可能是出在……」）。如果願意的話，您可以省去推測，但是千萬別省略事實。 當您報告bug的時候（既然您已經這麼做了），一定是希望bug得到及時修正。所以此時針對程式設計師的任何過激或褻瀆的言語（甚至謾罵）都是與事無補的——因為這可能是程式設計師的錯誤，也有可能是您的錯誤，也許您有權對他們發火，但是如果您能多提供一些有用的資訊（而不是激憤之詞）或許bug會被更快的修正。除此以外，請記住：如果是免費軟體，作者提供給我們已經是出於好心，所以要是太多的人對他們無禮，他們可能就要「收起」這份好心了。程式設計師不是弱智：如果程式一點都不好用，他們不可能不知道。他們不知道一定是因為程式在他們看來工作得很正常。所以，或者是您作過一些與他們不同的操作，或者是您的環境與他們不同。他們需要資訊，報告bug也是為了提供資訊。資訊總是越多越好。 許多程式，特別是自由軟體，會公布乙個「已知bug列表」。如果您找到的bug在列表裡已經有了，那就不必再報告了，但是如果您認為自己掌握的資訊比列表中的豐富，那無論如何也要與程式設計師聯絡。您提供的資訊可能會使他們更簡單地修復bug。 本文中提到的都是一些指導方針，沒有哪一條是必須恪守的準則。不同的程式設計師會喜歡不同形式的bug報告。如果程式附帶了一套報告bug的準則，一定要讀。如果它與本文中提到的規則相牴觸，那麼請以它為準。 如果您不是報告bug，而是尋求幫助，您應該說明您曾經到**找過答案，（例如：我看了第四章和第五章的第二節，但我找不到解決的辦法。）這會使程式設計師了解使用者喜歡到**去找答案，從而使程式設計師把幫助文件做得更容易使用。報告bug的最好的方法之一是「演示」給程式設計師看。讓程式設計師站在電腦前，執行他們的程式，指出程式的錯誤。讓他們看著您啟動電腦、執行程式、如何進行操作以及程式對您的輸入有何反應。 他們對自己寫的軟體瞭如指掌，他們知道哪些地方不會出問題，而哪些地方最可能出問題。他們本能地知道應該注意什麼。在程式真的出錯之前，他們可能已經注意到某些地方不對勁，這些都會給他們一些線索。他們會觀察程式測試中的每乙個
細節，並且選出他們認為有用的資訊。 這些可能還不夠。也許他們覺得還需要更多的資訊，會請您重複剛才的操作。他們可能在這期間需要與您交流一下，以便在他們需要的時候讓bug重新出現。他們可能會改變一些操作，看看這個錯誤的產生是個別問題還是相關的一類問題。如果您不走運，他們可能需要坐下來，拿出一堆開發工具，花上幾個小時來
好好地研究一下。但是最重要的是在程式出錯的時候讓程式設計師在電腦旁。一旦他們看到了問題，他們通常會找到原因並開始試著修改。如今是網路時代，是資訊交流的時代。我可以點一下滑鼠把自己的程式送到俄羅斯的某個朋友那裡，當然他也可以用同樣簡單的方法給我一些建議。但是如果我的程式出了什麼問題，我
不可能在他旁邊。「演示」是很好的辦法，但是常常做不到。 如果您必須報告bug，而此時程式設計師又不在您身邊，那麼您就要想辦法讓bug
重現如果您給了程式設計師一長串輸入和指令，他們執行以後沒有出現錯誤，那是因為您沒有給他們足夠的資訊，可能錯誤不是在每台計算機上都出現，您的系統可能和他們的在某些地方不一樣。有時候程式的行為可能和您預想的不一樣，這也許是誤會，但是您會認為程式出錯了，程式設計師卻認為這是對的。 同樣也要描述發生了什麼。精確的描述您看到了什麼。告訴他們為什麼您覺得自己所看到的是錯誤的，最好再告訴他們，您認為自己應該看到什麼。如果您只是說：「程式出錯了」，那您很可能漏掉了非常重要的資訊。 如果您看到了錯誤訊息，一定要仔細、準確的告訴程式設計師，這
確實很重要。在這種情況下，程式設計師只要修正錯誤，而不用去找錯誤。他們需要知道是什麼出問題了，系統所報的錯誤訊息正好幫助了他們。如果您沒有更好的方法記住這些訊息，就把它們寫下來。只報告「程式出了乙個錯」是毫無意義的，除非您把錯誤訊息一塊報上來。 特殊情況下，如果有錯誤訊息號，
一定要把這些號碼告訴程式設計師。不要以為您看不出任何意義，它就沒有意義。錯誤訊息號包含了能被程式設計師讀懂的各種資訊，並且很有可能包含重要的線索。給錯誤訊息編號是因為用語言描述計算機錯誤常常令人費解。用這種方式告訴您錯誤的所在是乙個最好的辦法。 在這種情形下，程式設計師的排錯工作會十分高效。他們不知道發生了什麼，也不可能到現場去觀察，所以他們一直在搜尋有價值的線索。錯誤訊息、錯誤訊息號以及一些莫名其妙的延遲，都是很重要的線索，就像辦案時的指紋一樣重要，儲存好。 如果您使用unix系統，程式可能會產生乙個核心輸出（coredump）。核心輸出是特別有用的線索**，別扔了它們。另一方面，大多數程式設計師不喜歡收到含有大量核心輸出檔案的email，所以在發郵件之前最好先問一下。還有一點要注意：核心輸出檔案記錄了完整的程式狀態，也就是說任何秘密（可能當時程式正在處理一些私人資訊或秘密資料）都可能包含在核心輸出檔案裡。當乙個錯誤或bug發生的時候，您可能會做許多事情。但是大多數人會使事情變的更糟。我的乙個朋友在學校裡誤刪了她所有的word檔案，在找人幫忙之前她重灌了word，又執行了一遍碎片整理程式，這些操作對於恢復檔案是毫無益處的，因為這些操作搞亂了磁碟的檔案區塊。恐怕在這個世界上沒有一種反刪除軟體能恢復她的檔案了。如果她不做任何操作，或許還有一線希望。 這種使用者彷彿乙隻被逼到牆角的鼬（黃鼠狼、紫貂一類的動物——譯者注）：背靠牆壁，面對死亡的降臨奮起反撲，瘋狂攻擊。他們認為做點什麼總比什麼都不做強。然而這些在處理計算機軟體問題時並不適用。 不要做鼬，做乙隻羚羊。當乙隻羚羊面對料想不到的情況或受到驚嚇時，它會一動不動，是為了不吸引任何注意，與此同時也在思考解決問題的最好辦法（如果羚羊有一條技術支援**，此時佔線。）。然後，一旦它找到了最安全的行動方案，它便去做。 當程式出毛病的時候，立刻停止正在做的
任何操作想
去幫助他們，使他們的工作變的更簡單。不過千萬別忘了報告「症狀」，否則只會使事情變得更糟。「間歇性錯誤」著實讓程式設計師發愁。相比之下，進行一系列簡單的操作便能導致錯誤發生的問題是簡單的。程式設計師可以在乙個便於觀察的條件下重複那些操作，觀察每乙個細節。太多的問題在這種情況下不能解決，例如：程式每星期出一次錯，或者偶然出一次錯，或者在程式設計師面前從不出錯（程式設計師一離開就出錯。——譯者）。當然還有就是程式的截止日期到了，那肯定要出錯。 大多數「間歇性錯誤」並不是真正的「間歇」。其中的大多數錯誤與某些地方是有聯絡的。有一些錯誤可能是記憶體洩漏產生的，有一些可能是別的程式在不恰當的時候修改某個重要檔案造成的，還有一些可能發生在每乙個小時的前半個小時中（我確實遇到過這種事情）。 同樣，如果您能使bug重現，而程式設計師不能，那很有可能是他們的計算機和您的計算機在某些地方是不同的，這種不同引起了問題。我曾寫過乙個程式，它的視窗可以
蜷縮成乙個小球呆在螢幕的左上角，它在別的計算機上只能在 800x600 的解析度工作，但是在我的機器上卻可以在 1024x768 下工作。 程式設計師想要了解任何與您發現的問題相關的事情。有可能的話您到另一台機器上試試，多試幾次，兩次，三次，看看問題是不是經常發生。如果問題出現在您進行了一系列操作之後，不是您想讓它出現它就會出現，這就有可能是長時間的執行或處理大檔案所導致的錯誤。程式崩潰的時候，您要盡可能的記住您都做了些什麼，並且如果您看到任何圖形,也別忘了提一下。您提供的任何事情都是有幫助的。即使只是概括性的描述（例如：當後台有emacs執行時，程式常常出錯），這雖然不能提供導致問題的直接線索，但是可能幫助程式設計師重現問題。 最重要的是：程式設計師想要確定他們正在處理的是乙個真正的「間歇性錯誤」呢，還是乙個在另一類特定的計算機上才出現的錯誤。他們想知道有關您計算機的許多細節，以便了解您的機器與他們的有什麼不同。有許多細節都依仗特定的程式，但是有一件東西您一定要提供——版本號。程式的版本、作業系統的版本以及與問題有關的程式的版本。表意清楚在乙份bug報告裡是最基本的要求。如果程式設計師不知道您說的是什麼意思，那您就跟沒說一樣。我收到的bug報告來自世界各地，有許多是來自非英語國家，他們通常為自己的英文不好而表示歉意。總的來說，這些使用者發來的bug報告通常是清晰而且有用的。幾乎所有不清晰的bug報告都是來自母語是英語的人，他們總是以為只要自己隨便說說，程式設計師就能明白。宣告：
opl（opencontent license）
，請在複製和使用本文時自覺遵守opl。 對本文的任何意見和批評請傳送至： 英文版：
中文版：
如何有效地報告Bug？
simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話，您可以省去推測，但是千萬別省略事實。然後，simon針對bug報告的不同問題分別提出了自己...
如何有效地報告Bug？
作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 ...
乾貨 如何有效地報告 Bug
拙劣的bug 電腦程式 中的錯誤或程式執行時的瑕疵 譯者注 報告例子 技術支援 很可怕的工作？因為有拙劣的bug報告需要處理。好的bug報告的特性 非常清晰 有幫助並且 有內容 報告bug的最好的方法之一是 演示 給程式設計師看。讓程式設計師站在電腦前，執行他們的程式，指出程式的錯誤。讓他們看著您啟...