調試策略，小技巧以及陷阱 軟件測試工程師
使用合適的工具
如果你正尋找分段錯誤，你就會想用調試器。如果你正要處理奇怪的內存問題(或難以診斷的分段錯誤)，那么在Linux中使用Valgrind或在Windows中使用Purify吧。
調試問題
有時候我們想出一個解決方案后卻發現方案很難執行。事實上，換個角度問題或許可以更明朗。當我看到有人竭力調試一個復雜的大規模的代碼時，我首先想到的是問問自己是否有更簡便的辦法。通常情況下，一旦你的代碼寫得很糟糕，你反而能清楚意識到好的代碼應是怎樣的。請記住，不能因為代碼是你寫的就要保留它!
訣竅是，明白你是要解決初始問題，還是要解決某一特定方案。如果是解決方案，那么你的問題就可能根本不是由初始問題造成，也許你過慮了或者嘗試了一種錯誤的做法。例如，我最近需要分析文件并輸入一些數據到Access數據庫以還原分析工具。我的第一反應是編寫一個與Access直接對接的Ruby腳本，使用SQL查詢向數據庫輸入所有數據。由于我審視 了Ruby可以為此提供的支持，我很快意識到對這個問題的“解決辦法”要比理論上的久得多。于是我掉轉方向，寫了個只是輸出一個逗號分隔值文件的腳本，如此，我大約花了一小時完成數據輸入。
關于錯誤代碼
人們往往不愿拋出他們已經寫了和重寫過的錯誤碼。原因之一是，寫完的代碼標志著工作的完成，再提出來會覺得走了回頭路。但是在你調試時，重寫代碼似乎更具吸引力，因為你可能通過重寫代碼節省了調試的時間。訣竅在于，移除不良代碼不需要重寫整個程序(除非它無可救藥)，只需要重寫有問題的部分。
你的第二稿可能更清潔且漏洞更少，你也可以避免重寫代碼等問題，這樣你能說清楚它的工作原理。
另一方面，當你絕對相信，看起來可怕的代碼是要使用的正確代碼時，你會想用你的理由為其注釋，以防某人(或自己)犯同樣的錯。
避免“復制/粘貼”帶來的錯誤
每當你復制并粘貼大量代碼時，你都留給了自己一大堆麻煩。即便你還沒有調試，你也將不得不這樣做。如果你忘了在什么地方復制過代碼，你很可能將重復調試相同的代碼。
避免復制/粘貼綜合癥的最好方法是盡可能使用函數概括重復代碼。有些東西在C + +中不容易避免，無論正在做什么你都會為循環寫很多代碼，所以你不能提取整個循環過程。但是，如果在多個地方存在同樣的循環本體，就可能是應該退出到單獨函數的一個信號。作為獎勵，代碼變得更簡單，你也可以重復使用這一函數，而不必找到一大堆代碼去復制。
何時復制代碼
雖然復制代碼通常是危險的，但有些時候它可能是最好的選擇。例如，如果您需要對一大段代碼進行縮減和不規則調整，其余部分保持不變，那么復制，粘貼和仔細編輯是可以的。通過復制代碼可以避免因打字有誤而帶來的新錯誤。
早期測試
退出代碼并把它變成函數的優點之一是，你可以分別測試這些函數。這意味著你可以避免調試由原函數中的簡單錯誤引發的大問題。這樣的單元測試需要一定的訓練和對錯誤代碼有良好的判斷力。
早期測試的另一個優點是你會更關心你具體界面的類別。如果因為你使用的是斷言而不是一個例外或錯誤代碼而無法測試錯誤操作，這表明，你應該使用某種形式的錯誤報告，而不是斷言。如果你的接口類別不靈敏，或你的函數有著無法被理解，更不用說被記住的自變量。那么是時候在編碼前重新考慮一下。
編譯器警告
文章來源于領測軟件測試網 http://www.kjueaiud.com/