1、隔離關鍵元素
就像小學生物課，考察陽光對植物生長的影響，則需要保持養分、灌溉、生長溫度等完全一致，乙個有陽光照射，乙個沒有陽光照射，這樣才能比較出陽光對植物的生產的影響.bug查詢過程也要如此,在查詢乙個具有多個引數的函式的計算錯誤時，固定其它引數，同時修改乙個引數的輸入值，驗證輸出結果是否正確，從而可以確定是哪個引數導致的計算錯誤，確定bug。
2、一次只改乙個測試
軟體工程師有時為了修復乙個問題而修改了乙個地方，但這個修改沒有解決問題，而他又認為這不會產生影響，這是乙個錯誤的假設，這個改動可能的確對解決問題有影響，因此沒有解決問題的改動要及時恢復。否則可能產生無法預料的錯誤。一次只改變乙個引數，以便確定哪個引數有影響！與第一條互為補充！
硬體也是類似，如果同時更換多個器件，你無法判斷到底是哪個器件導致系統出現問題，也要一次只更換乙個，測試驗證沒有問題後再更換下乙個！
3、與正常情況比較
使用兩個例子，乙個成功的，乙個失敗的，對比示波器的觀察結果、**、除錯輸出以及其它任何插樁工具 顯示結果，往往比較容易找到bug！如果兩個之間又很多不同，比如**改變了很多，則必須不斷的解釋這些差別，並且不斷減少他們之間的差別直至只與bug有關。
因為你不知道哪些方面與bug有關，因此應該對一切能夠測試的地方進行測試，如果證明無關，則把它從除錯日誌中刪除。大量資料對比查詢，這個不是很容易做到，既不適合初學者，也不適合軟體自動化分析，需要乙個充滿智慧型的大腦，從大量對比資料中，快速找到差別。
4、確認自上次正常以來的你修改的地方
有時，正常的系統和錯誤的系統之間的區別是有一項改動導致的，因此一種非常有效的方法就是找出第乙個導致bug的版本，這個需要連續測試，直至找到沒有bug的版本，一旦找到後，就可以把問題範圍限制到這兩個版本之間的差別。如果兩個版本不是大幅度修改，bug往往比較容易找到。
通常新的設計會出問題，這也是我們在產品發布前總要對新設計進行測試的原因，有的可能時前後部分不相容（比如工裝探針的分布順序，間距改動），也有較為複雜的，就是問題存在了很長時間，知識莫些地方被改變後才暴露出來
案例：在32位系統中，比如8位指標向32位指標強制轉換時，如果以前版本軟體編譯時8位指標的位址4位元組對齊，那麼賦值轉換不會出現問題，執行也正常；當軟體修改，重新編譯後，8位指標的位址不是4位元組對齊，那麼就會出現資料錯亂甚至宕機、看門狗復位等問題。這種問題，只對比**的修改處，時看不出問題的，需要綜合考慮**修改的影響，除了**邏輯、功能的影響外，還有編譯的影響、**布局的影響等。
軟硬體除錯九法 第六條規則 保持審計跟蹤
1 把你的操作 操作順序和結果全部記錄下來 要記錄所做的事 做事的順序 以及發生的結果，每次做完都要全部記錄。就像除錯硬體一樣，必須指導每個步驟以及執行結果，才能確定下一步關注的重點。2 要知道，任何細節都可能是重要的 有時bug報告可能就有一句簡單的話，比如儀器顯示出錯了，或者儀器無法正常工作，這...
軟硬體除錯九法 第三條規則 不要想而要看
憑空想象，問題的原因很多，實際的原因只有看了才能發現！如果猜測失敗是如何發生的，那麼常常會修復一些不是bug的問題，不僅浪費時間 還會破壞其它地方，因此不要這樣做。在醫學領域，有聽診器 抽血化驗 x透視 b超等方法。同樣 在軟體中，觀察的方法有設定斷點 新增除錯語句 監視程式值 以及檢查記憶體等方法...
除錯九法 軟硬體錯誤的排查之道
理解系統 這是第一條股則，因為它是最重要的。製造失敗 雖然看起來很簡單，但如果不製造失敗的話，除錯就會變得很困難。不要想，而要看 憑空想象，問題可能有幾千條原因。而實際原因只有去看了才能發現。分而治之 當bug的藏身之地不斷被縮小一半時，它將很難再隱藏下去。一次只改乙個地方 我們在生活中要有一點先見...