測試工程師如何有效地報告缺陷(Bug)

　　自由軟件開發者Simon Tatham針對如何有效地報告Bug發表了自己的看法，他列舉了一系列拙劣Bug報告的例子，并提出了改正建議。

　　Simon首先列舉了一系列拙劣Bug報告的例子，包括：

　　在報告中說“不好用”;

　　所報告內容毫無意義;

　　在報告中用戶沒有提供足夠的信息;

　　在報告中提供了錯誤信息;

　　所報告的問題是由于用戶的過失而產生的;

　　所報告的問題是由于其他程序的錯誤而產生的;

　　所報告的問題是由于網絡錯誤而產生的;

　　接著，他點出了報告Bug的目的：

　　簡單地說，報告bug的目的是為了讓程序員看到程序的錯誤。您可以親自示范，也可以給出能導致程序出錯的、詳盡的操作步驟。如果程序出錯了，程序員會收集額外的信息直到找到錯誤的原因;如果程序沒有出錯，那么他們會請您繼續關注這個問題，收集相關的信息。

　　在bug報告里，要設法搞清什么是事實(例如：“我在電腦旁”和“XX出現了”)什么是推測(例如：“我想問題可能是出在……”)。如果愿意的話，您可以省去推測，但是千萬別省略事實。

　　然后，Simon針對Bug報告的不同問題分別提出了自己的見解：

　　“程序不好用”

　　程序員不是弱智：如果程序一點都不好用，他們不可能不知道。他們不知道一定是因為程序在他們看來工作得很正常。所以，或者是您作過一些與他們不同的操作，或者是您的環境與他們不同。他們需要信息，報告bug也是為了提供信息。信息總是越多越好。

　　許多程序，特別是自由軟件，會公布一個“已知bug列表”。如果您找到的bug在列表里已經有了，那就不必再報告了，但是如果您認為自己掌握的信息比列表中的豐富，那無論如何也要與程序員聯系。您提供的信息可能會使他們更簡單地修復bug。

　　“演示給我看”

　　報告bug的最好的方法之一是“演示”給程序員看。讓程序員站在電腦前，運行他們的程序，指出程序的錯誤。讓他們看著您啟動電腦、運行程序、如何進行操作以及程序對您的輸入有何反應。

　　他們對自己寫的軟件了如指掌，他們知道哪些地方不會出問題，而哪些地方最可能出問題。他們本能地知道應該注意什么。在程序真的出錯之前，他們可能已經注意到某些地方不對勁，這些都會給他們一些線索。他們會觀察程序測試中的每一個細節，并且選出他們認為有用的信息。

　　這些可能還不夠。也許他們覺得還需要更多的信息，會請您重復剛才的操作。他們可能在這期間需要與您交流一下，以便在他們需要的時候讓bug重新出現。他們可能會改變一些操作，看看這個錯誤的產生是個別問題還是相關的一類問題。如果您不走運，他們可能需要坐下來，拿出一堆開發工具，花上幾個小時來好好地研究一下。但是最重要的是在程序出錯的時候讓程序員在電腦旁。一旦他們看到了問題，他們通常會找到原因并開始試著修改。

　　“哪兒出錯了?在我看來一切正常哦!”

　　如果您給了程序員一長串輸入和指令，他們執行以后沒有出現錯誤，那是因為您沒有給他們足夠的信息，可能錯誤不是在每臺計算機上都出現，您的系統可能和他們的在某些地方不一樣。有時候程序的行為可能和您預想的不一樣，這也許是誤會，但是您會認為程序出錯了，程序員卻認為這是對的。

　　同樣也要描述發生了什么。精確的描述您看到了什么。告訴他們為什么您覺得自己所看到的是錯誤的，最好再告訴他們，您認為自己應該看到什么。如果您只是說：“程序出錯了”，那您很可能漏掉了非常重要的信息。

　　如果您看到了錯誤消息，一定要仔細、準確的告訴程序員，這確實很重要。在這種情況下，程序員只要修正錯誤，而不用去找錯誤。他們需要知道是什么出問題了，系統所報的錯誤消息正好幫助了他們。如果您沒有更好的方法記住這些消息，就把它們寫下來。只報告“程序出了一個錯”是毫無意義的，除非您把錯誤消息一塊報上來。

　　特殊情況下，如果有錯誤消息號，一定要把這些號碼告訴程序員。不要以為您看不出任何意義，它就沒有意義。錯誤消息號包含了能被程序員讀懂的各種信息，并且很有可能包含重要的線索。給錯誤消息編號是因為用語言描述計算機錯誤常常令人費解。用這種方式告訴您錯誤的所在是一個最好的辦法。

　　在這種情形下，程序員的排錯工作會十分高效。他們不知道發生了什么，也不可能到現場去觀察，所以他們一直在搜尋有價值的線索。錯誤消息、錯誤消息號以及一些莫名其妙的延遲，都是很重要的線索，就像辦案時的指紋一樣重要，保存好。

　　如果您使用UNIX系統，程序可能會產生一個內核輸出(coredump)。內核輸出是特別有用的線索來源，別扔了它們。另一方面，大多數程序員不喜歡收到含有大量內核輸出文件的EMAIL，所以在發郵件之前最好先問一下。還有一點要注意：內核輸出文件記錄了完整的程序狀態，也就是說任何秘密(可能當時程序正在處理一些私人信息或秘密數據)都可能包含在內核輸出文件里。

　　除此之外，Simon還舉了其他一些例子，他最后總結到：

　　bug報告的首要目的是讓程序員親眼看到錯誤。如果您不能親自做給他們看，給他們能使程序出錯的詳細的操作步驟。

　　如果首要目的不能達成，程序員不能看到程序出錯。這就需要bug報告的第二個目的來描述程序的什么地方出毛病了。詳細的描述每一件事情：您看到了什么，您想看到什么，把錯誤消息記下來，尤其是“錯誤消息號”。

　　當您的計算機做了什么您料想不到的事，不要動!在您平靜下來之前什么都別做。不要做您認為不安全的事。

　　盡量試著自己“診斷”程序出錯的原因(如果您認為自己可以的話)。即使做出了“診斷”，您仍然應該報告“癥狀”。

　　如果程序員需要，請準備好額外的信息。如果他們不需要，就不會問您要。他們不會故意為難自己。您手頭上一定要有程序的版本號，它很可能是必需品。

　　表述清楚，確保您的意思不能被曲解。

原文轉自：http://www.anti-gravitydesign.com