關鍵字：軟件測試 軟件調試
說到程序員，各位大腦中第一反應就是編碼;但我們知道軟件開發可不僅僅只有編碼，調試也占據了程序員很大一部分精力。程序員“簡單”的工作中，80%的時間都是在編碼和調試(現在文檔工作也不少)。調試的對象是BUG，BUG是什么呢?BUG就是編碼過程的伴生品。既然將之詮釋為“伴生品”，那就意味著“凡是軟件，內必有BUG”。也許有人不同意這樣的觀點，但無關大礙，因為如何看待BUG本身就可以看成是一個哲學范疇的話題，大可見仁見智。
調試前，首先做好心理準備。
調試BUG的過程可以用“艱苦卓絕”來形容;特別是一些“又臭又硬”的BUG，難于重現，難于定位，甚至在投入相當大的精力后仍然無法Fix。所以調試BUG前就要擺正心態，要保持清醒、保持耐心，甚至要做好打“持久戰”的打算。要知道Unix下還有一些BUG也是在隱藏了幾十年后才被Fixed。
預防BUG的發生，降低BUG發生概率。
我們還需要清醒的認識到：事實證明與編碼相比，調試BUG的成本是更高的。BUG可簡單分為產品Release前BUG和Release后的BUG。無論哪一種，你都要經歷收集數據、重現BUG、定位問題、修正問題和Accepted等多個步驟后才能重新Release。這其中以Release后的BUG花費的成本為更高。既然如此，我們何不采用一些手段來相對的預防BUG的發生，降低BUG發生的概率呢!這里說說我想到的。從一個軟件的整個生命周期來看，保證軟件質量應從需求開始，但這里我們主要關注編碼階段。從個體開發者角度我們可以從以下三個方面考慮：
* 充分的靜態代碼檢查
充分利用你手頭上的工具對你編寫的代碼做嚴格的檢查，這些工具包括編譯器(盡可能將警告級別提升到你可以接受的最高級別)、LINT工具等。這將幫你將代碼中潛在的細小問題發掘出來，避免這些問題在事后成為隱藏的大BUG。
* 調試版添加斷言
充分利用斷言Assertions這把發現BUG的利器，借鑒契約式編程的一些規則，在你的調試版代碼中適當的地方添加Assertions。這樣的方法同樣可以幫助你及時發現代碼中隱藏的缺陷。
* 充分的單元測試
充分的單元測試提高代碼覆蓋率，減少業務邏輯遺失導致的BUG;單元測試用例還可以結合斷言發現更多程序潛在問題。如果能做到測試先行，也許效果會更好。
* 代碼同級評審
讓其他人來審核你的代碼，提前幫你發現潛在的問題;如果能做到結對編程，
也許效果會更好。
從組織的角度來看，持續集成的實踐可以讓組員更加及時的發現編碼階段的問題，不讓問題遺漏到后面階段成為嚴重BUG。
如果很好的實施了上述這些手段后，你的BUG發生率會大大降低，但是前面說過：BUG不能避免，一旦BUG發生了，該怎么辦?其實與BUG做艱苦卓絕的斗爭，也是有一定方法的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/