閱讀手冊：手冊裏有正確使用系統的方法。
仔細閱讀每個細節：出現問題的地方可能就在你不感興趣的那一章，不要懼怕手冊的厚度。
掌握基礎知識：知道什麼是正常的，才能知道什麼是錯誤的。
瞭解工作流程：有助於定位bug。
瞭解工具：調試工具能幹什麼，不能幹什麼。
查閱細節：去閱讀手冊，而不是猜測或回想手冊上的內容。
規則2：製造失敗
製造失敗：目的是爲了觀察它，找到原因，並檢查是否已修復。
從頭開始：bug可能由一系列操作或者運行造成的，回到最初狀態開始製造失敗。
引發失敗：試着讓失敗出現，而不是被動的等，尤其是間歇性失敗。
但不要模擬失敗：不要猜測失敗產生的機理而去模擬一個系統，模擬的系統可能沒有體現bug的根源，甚至產生新的bug。
查找不受你控制的條件（正是它導致了間歇性失敗）：改變能改變的任何參數，或者將變量設成常量，知道bug再次出現並一直出現。
記錄每件事情，並找到間歇性bug的特徵：記錄運行狀態，分析並找到出現bug時的狀態特徵。
不要過於相信統計數據：獲得足夠多的信息並分析，不要猜測。
要認識到“那”是可能會發生的：bug的根源可能是意想不到的，不要大喊“不可楞！！！”。
永遠不要丟掉一個調試工具：沒準哪天就能派上用場。
規則3：不要想，而要看
觀察失敗：發現bug不要猜測問題根源，而是要仔細觀察bug到底是什麼地方造成了bug。
查看細節：縮小範圍。
植入插裝工具：使用源代碼調試器、調試日誌、狀態消息和printf。
添加外部插裝工具：使用分析器、示波器、量表、金屬檢測儀、心電圖儀和肥皂泡。
不要害怕深入研究：不要害怕找到更多的bug，雖然軟件已經是成品，bug還是必須要修復的。
注意海森堡效應：測不準原理。當你爲了觀察失敗而改變系統或插裝工具時，避免所做的改變影響系統。
猜測只是爲了確定搜索的重點：猜測還是必要的，但不要過多的猜測。
規則4：分而治之
通過逐次逼近縮小搜索範圍：猜測1～100內的一個數字，只需7次。
確定範圍：不要把初始範圍設定的太小，如果數字是135而你卻認爲他在1～100內，那麼你必須擴大範圍。
確定你位於bug的哪一側：在某一點檢查系統，如果狀態正確，則bug位於上游，反之位於下游。
使用易於查看的測試模式：從乾淨、清澈的水開始，以便當排放物進入河流時很容易看到它。
從有問題的一段開始搜索：正確的部分總是多於錯誤的部分，應該從有問題的地方開始，向後追查原因，不要在正確的地方浪費時間。
修復已知bug。bug互相保護，互相隱藏：因此一旦找到，立即修復它們。
首先消除噪聲干擾：注意那些導致系統問題的干擾因素，但對一些無足輕重的問題不要過於極端，也不要爲了追求完美而去修改所有地方，雖然他看起來不美，但它可以正確工作。
規則5：一次只改一個地方
隔離關鍵因素：當你觀察某一個bug的問題時，不要改變與此bug不相關的因素。
用雙手抓住黃銅杆：不要猜測並改變系統的不同部分，以便看看他們是否對問題有影響，這可能引起更多錯誤。
一次只改一個測試：使用步槍，而不是霰彈槍。
與正常情況進行比較：如果所有出錯的情況都有一些特徵，而這些特徵是正常情況所沒有的，那麼你就找到了問題所在。
確定自從上一次正常工作以來你改變了什麼地方：這個改變的地方是一個很好的調試起點。
規則6：保持審計跟蹤
把你的操作、操作的順序和結果全部記錄下來：當出現bug時你能查看之前更多的細節。
要知道，任何細節都可能是重要的：不要忽略不起眼或者不可能的細節。
把事件關聯到一起：儘量詳細並量化的描述問題。
用於設計的審計跟蹤在測試中也非常有用：Git、CVS、Subversion……
把事情記錄下來：好記性不如爛筆頭。
規則7：檢查插頭
置疑你的假設：是否運行了正確的代碼？問題的根源可能沒有想象的那麼複雜。
從頭開始：可能一開始就錯了，以後怎麼都不對了。
對工具進行測試：你的工具好用麼？你會用麼？（見規則1）
規則8：獲得全新的觀點
徵求別人的意見：
獲取專業知識：
聽取別人的經驗：
幫助無處不在：同事、供應商、網絡、書店……
放下面子：
報告症狀，而不要講你的理論：不要把別人拖進你的思維定勢中。
你提出的問題不必十分肯定：提出任何你覺得可以的因素，沒準哪個就有幫助。
規則9：如果你不修復bug，它將依然存在
查證問題確實已被修復：不要假設bug已經修復了，你修改的地方可能不是造成bug的根本。
查證確實是你的修復措施解決了問題：撤銷這個修復，看看bug是否再次出現。
要知道，bug從來不會自己消失：就算你再也找不到它了，它還是會在某一天跳出來，不要有僥倖心理。
從根本上解決問題：不要敷衍。
對過程進行修復：如果總是出現同類bug，檢查最初的設計方案。