也談軟件測試的調試

也談軟件測試的調試 軟件測試方法

每年二月末到三月初，公司都會安排一批實習生到各個部門實習。雖說去年經濟危機了，但公司的實習生數量似乎并沒有減少。起碼我們部門“新同事”的數量基本與去年持平。按慣例，每位新同事都會有一名導師，與此同時各個部門還會根據自身的業務特點對這批學生進行有針對性的集中培訓和交流。比起我入司那會兒，現在的實習生已經算是幸福多了。我那會兒實習生人數少，部門沒有安排什么培訓，完全靠導師安排自己努力學習。此次培訓的內容是經過老員工們討論和對新員工的需求調查后才確定的。其中新同事們普遍對如何進行程序調試這塊比較感興趣，我負責準備和實施了這個題目。雖說有過幾年調試程序的經驗，但是自已也沒有系統的總結過，這次培訓后順便在這里做一下總結和記錄。

　　說到程序員，各位大腦中第一反應就是編碼；但我們知道軟件開發可不僅僅只有編碼，調試也占據了程序員很大一部分精力。程序員“簡單”的工作中，80%的時間都是在編碼和調試（現在文檔工作也不少）。調試的對象是BUG，BUG是什么呢？BUG就是編碼過程的伴生品。既然將之詮釋為“伴生品”，那就意味著“凡是軟件，內必有BUG”。也許有人不同意這樣的觀點，但無關大礙，因為如何看待BUG本身就可以看成是一個哲學范疇的話題，大可見仁見智。

　　調試前，首先做好心理準備。

　　調試BUG的過程可以用“艱苦卓絕”來形容；特別是一些“又臭又硬”的BUG，難于重現，難于定位，甚至在投入相當大的精力后仍然無法Fix。所以調試BUG前就要擺正心態，要保持清醒、保持耐心，甚至要做好打“持久戰”的打算。要知道Unix下還有一些BUG也是在隱藏了幾十年后才被Fixed。

　　預防BUG的發生，降低BUG發生概率。

　　我們還需要清醒的認識到：事實證明與編碼相比，調試BUG的成本是更高的。BUG可簡單分為產品Release前BUG和Release后的BUG。無論哪一種，你都要經歷收集數據、重現BUG、定位問題、修正問題和Aclearcase/" target="_blank" >ccepted等多個步驟后才能重新Release。這其中以Release后的BUG花費的成本為更高。既然如此，我們何不采用一些手段來相對的預防BUG的發生，降低BUG發生的概率呢！這里說說我想到的。從一個軟件的整個生命周期來看，保證軟件質量應從需求開始，但這里我們主要關注編碼階段。從個體開發者角度我們可以從以下三個方面考慮：

　　* 充分的靜態代碼檢查

　　充分利用你手頭上的工具對你編寫的代碼做嚴格的檢查，這些工具包括編譯器（盡可能將警告級別提升到你可以接受的最高級別）、LINT工具等。這將幫你將代碼中潛在的細小問題發掘出來，避免這些問題在事后成為隱藏的大BUG。

　　* 調試版添加斷言

　　充分利用斷言Assertions這把發現BUG的利器，借鑒契約式編程的一些規則，在你的調試版代碼中適當的地方添加Assertions。這樣的方法同樣可以幫助你及時發現代碼中隱藏的缺陷。

　　* 充分的單元測試

　　充分的單元測試提高代碼覆蓋率，減少業務邏輯遺失導致的BUG；單元測試用例還可以結合斷言發現更多程序潛在問題。如果能做到測試先行，也許效果會更好。

　　* 代碼同級評審

　　讓其他人來審核你的代碼，提前幫你發現潛在的問題；如果能做到結對編程，也許效果會更好。

　　從組織的角度來看，持續集成的實踐可以讓組員更加及時的發現編碼階段的問題，不讓問題遺漏到后面階段成為嚴重BUG。

　　如果很好的實施了上述這些手段后，你的BUG發生率會大大降低，但是前面說過：BUG不能避免，一旦BUG發生了，該怎么辦？其實與BUG做艱苦卓絕的斗爭，也是有一定方法的。

原文轉自：http://www.anti-gravitydesign.com