編譯器可以發現許多潛在的錯誤。一些這樣的錯誤包括使用未初始化變量，在條件句，或C + +中意外將檢查平等轉讓，與混合類型相關的錯誤，如指針和綁定約束。
格式輸出謊言
由于操作系統通常緩沖I/O，所以在調試過程中使用格式輸出是危險的�？赡艿脑�，使用調試器找出有問題的代碼行，而不是縮小被格式輸出和進位輸出弄亂的代碼。
清除輸出
有些時候你要在日志文件中跟蹤一些情況，需要從程序啟動到出現錯誤時的所有數據。為了確保你收集了所有數據，一定要清除它：你可以用C 刷新緩沖區，或用C++輸出endl 。 fflush把你要寫入的文件指針的錯誤清除。
檢查輔助函數
人們很容易激動時忘記這點：總是確認您的輔助函數運行正常，特別是在看似簡單的代碼缺失時。如果可能的話，先分離每個輔助函數并對它們進行單獨測試，然后再進行代碼測試。
當原因不能立刻生效時
即使輔助函數不是導致問題的直接原因，其副作用也可能導致潛在問題。舉例來說，如果你有一個可以返回NULL的輔助函數，且你把它的輸出傳到處理C 字符串的庫函數，你會看到直接原因是因為解除了NULL指針關聯，但真正的原因是因為你寫了問題函數(或是你沒有在調用NULL后進行檢查)。
代碼可以多處使用
調試時的另一個問題是，你發現的問題由某種特別的函數調用引起，在那個函數里設置一個斷點，然后會發現，在整個代碼中對同一個函數有數百次調用。
最顯而易見的辦法是在沖擊斷點后檢查調用棧，或在出錯調用前有效設置斷點。不幸的是，如果同樣的調用出現1000次但在1001次時失敗了，這就不一定起作用了�？赡艿�解決方案包括清點函數調用次數，然后逐步通過設置在函數中的斷點，或使用一個靜態變量作為計數器。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
