假設您有一個在軟件相當複雜的部分的功能測試中發現的錯誤。 它可能源於數據庫中的錯誤/意外數據，中間層代碼或前端中的某些數據。Bug狩獵策略？
好。我們都去過那裏。
你有單元測試寫&運行，調試/日誌記錄語句插入，SQL語句來寫&運行，要檢查與螢火蟲的事情，等
比方說，第一步是拿出您想調查的潛在原因列表。
現在，你必須決定什麼樣的順序做的事情在
，你會：
我有一種感覺，第一種策略是最常用的。也許只是因爲我沒有和很多初級開發人員一起工作，而更多的高級開發人員往往擁有像樣的直覺。或者，也許我們只是認爲我們有直覺，但應該採用更系統的方法。
有什麼想法？
我發現Rubber Duck Debugging策略也很好。
我會說這沒關係，只要它有記錄和有條不紊。在編程中有點奇怪的是，有時候以隨機順序執行操作比花費大量時間試圖找出「最佳」方式更有效率。
永遠不要低估直覺;這是經驗讓你擡頭。我幾乎總是從你可能認爲是我的「直覺」的感覺開始。我查看錯誤，並檢查我認爲可能導致此類問題的步驟。
我在這種情況下的第一步通常是按順序檢查事情，以最快速度減少要檢查的事項數量。你幾乎可以把它看作是對二進制搜索錯誤：「好吧，POST參數看起來是正確的，所以我可以排除表單提交之前的一切，」等。
這就是說，如果我有一個強大的感覺問題可能在某個特定的地方，我會先檢查一下。
我傾向於帶着直覺和分而治之的方法;在我認爲「錯誤」的地方隔離大小遞減的代碼塊。
如果你不知道，或者不明白代碼庫，這是行不通的 - 如果是這樣的話，找一個有能力的人，並帶着自己的直覺去做。
首先，我嘗試瞭解錯誤，然後根據直覺來做所有你建議的事情。 這確實是一個權衡你是如何確定一個特定的原因，以及測試多麼容易。
此外，當我調查的原因我試圖直接加入真正的快速檢查，因爲我反正檢查代碼（添加一些臨時調試輸出語句，添加斷言和等）
根據我的經驗， （1）30分鐘左右可能是最好的。
如果沒有出現，請與其他人討論。
與其他人交談（即使他們不是技術人員）可以提供幫助。
這是一個認知怪癖。我們是語言生物，因此將內在直覺轉化爲聲音的活動迫使您從另一個角度來看問題。 – Satanicpuppy 2009-12-04 16:14:43
+1。我忘了提及與某人談論此事。我經常發現解釋行爲可能會導致燈泡掉在你的頭上，並在現場解決問題。 – z5h 2009-12-04 16:16:01
我的訂單：
沖洗，起泡，重複直到發現問題的最初原因。乏味和機械，但會讓你在那裏。
除...偶爾在第3步迭代中的測試不會失敗;最常見的是因爲一些不相關的系統破壞內存是導致無效狀態的原因，或者是因爲問題是線程/定時/未初始化的數據依賴性，並且引入測試會改變定時和/或數據佈局以足以改變或隱藏症狀。在這一點上，至少對於這個海報來說，這個過程變得更加直觀了，在用較少干擾的形式取代健康測試和選擇性地禁用模塊以排除腐敗來源之間交替進行。
下面是一些有用的提示：
一般情況下，我開始，我認爲最有可能的罪魁禍首，然後排序每個是多麼容易否定假設的子集，並用最簡單的假設開始的一個子集。
無論順序如何，重要的是你如何處理你的假設。 開始嘗試反駁每個假設而不是驗證它，並且您將覆蓋更多地面（請參閱Richards J. Heuer，Jr.的Psychology of Intelligence Analysis，免費PDF）。
+1。偉大的（獨特的）信息。 – z5h 2009-12-04 19:29:59
我與@moonshadow，但我會補充一點，這取決於失敗是什麼。也就是說，某種失敗有相當衆所周知的原因，我會從已知的原因開始
例如，在Windows系統上「訪問衝突」錯誤幾乎總是由於嘗試使用或查看（訪問）未分配的內存。要找出這樣一個錯誤的來源，最好查看內存分配（或不分配）的所有地方。
如果它知道，「問題」是由於錯誤的數據，則修復可能需要更改數據驗證或收購，甚至一次錯誤跟蹤分析。
還有一點，同時通過錯誤以爲它往往是非常值得的努力，試圖創建它創建一個小程序。
我通常這樣做：
1）一種新的功能性測試案例（一個或多個）添加到自動迴歸測試系統。我通常開始有自己的迴歸測試系統軟件項目，
所有這些工作的目標是確保一旦發現任何錯誤，它不應該再次出現在簽入代碼或生產系統中。再現隨機和長期問題也更容易。
不檢查任何代碼，除非它進行過夜自動化迴歸測試。
我通常在產品代碼與產品代碼之間寫1：1比例測試代碼。用於20K行C++代碼的20萬行TCL專家。 （5年前）。例如：
我不希望QA團隊使用我的測試系統進行自動測試，因爲我的所有簽入代碼都必須通過測試。在我將代碼提交給QA團隊之前，我通常會進行2周的長期迴歸測試。
QA團隊運行手動測試用例還確保我的程序具有足夠的內置診斷信息來捕獲任何未來的錯誤。我們的目標是有足夠的診斷信息來解決2小時內95％的錯誤<。我在最後一個項目中做到了這一點。 （RBG Networks的視頻網絡設備。）
2）添加診斷例程（現在的web基礎）獲取所有內部信息。 （當前狀態，日誌等）。 >我的代碼（c/C++，特別是）的50％是診斷代碼。
3）添加更多詳細信息記錄我不明白的故障區域。
4）分析信息。
5）嘗試修復這個錯誤。
6）運行過夜/週末迴歸測試。當我在R & D時，我通常要求至少有5-10個測試系統24x7連續運行迴歸測試。這通常可以在代碼達到SQA之前幫助ID和解決內存，資源和長期性能問題。
一旦嵌入式系統不時啓動進入Linux提示符。我添加了一個測試用例，它可以一次又一次地重複使用可編程插座對系統進行循環，並確保它能夠「看到」命令提示符並開始在一夜之間運行測試。我們能夠快速識別FPGA代碼問題，並確保5000次電源循環後系統始終保持運行。增加了一個測試用例，並且構建了一個新的Verilog代碼簽入/ FPGA代碼。這個測試案例已經運行。這再也不是問題。
我建議閱讀通過思考調試。
Andreas Zeller在系統調試研究方面也做了一些工作。
6.谷歌的錯誤或發佈在stackoverflow – catchmeifyoutry 2009-12-04 16:11:47
一個想法 - 這應該是社區維基。 – IAdapter 2009-12-04 16:39:12
@ 01，儘管在meta上閱讀它們，但我仍然不完全理解社區wiki問題的推理或好處。看來我並不是唯一一個被這個功能困惑的人。但我想我會嘗試一下（至少一次）看看會發生什麼。 – z5h 2009-12-04 16:48:52