* 收集“現場數據”
BUG是表象，我們要發現內部原因還是需要更多的表象數據去推理。我們需要收集到足夠的“現場數據”。比較初級的、基本的、也是被大家常用的方法就加print語句，將BUG現場周圍的“證據”輸出到屏幕上或者文件中，這樣你能更直觀的看到;當然我這里是不推薦Print語句的，因為不夠專業、不夠高效;拿起你的源代碼調試工具，諸如GDB來完成這一功能吧;有時候現場數據可以通過你的程序運行日志而直接得到這樣就更簡單了，調試階段這種日志要保持盡量詳細且必要;如果是運行在客戶現場的程序，你無法添加Print，也無法GDB調試，那么你需要在測試環境下重現BUG表象，然后再利用工具收集數據。重現BUG表象多數情況較容易，但是也不乏找不到重現條件的時候;這時候你就只能根據已有的運行日志等通過“順藤摸瓜”的業務邏輯分析去“猜測”可能的重現步驟，逐一嘗試，做好嘗試記錄，隔一段時間對記錄進行分析，找出一些“蛛絲馬跡”，也許會幫助你節省些時間。
* 定位問題所在
有了“現場數據”，需要你用“火眼金睛”從這一堆數據中找出你真正需要的;如果無法直接識別出真數據，那么可以根據數據做幾組不同數據組合的模擬測試，在數據變化中“去偽存真”，找到那個“真悟空”。有了信賴的真實數據，你一般都可以根據代碼邏輯推理出問題所在。但有些時候還是需要通過隔離代碼、縮小嫌疑代碼范圍等方法才能鎖定一些較難BUG的具體問題所在。
* Fix and Test
既然找到問題所在了，那剩下的工作就是修正它并重現驗證;新用例同時也補充了你的單元測試用例庫。如果修正失敗，那就從頭開始新一輪分析過程吧。
BUG真的是種類繁多，情況多樣。 上面也僅僅是一些常見BUG解決過程的體會。如果你已經在一個BUG上整整消耗了一天時間了，那么建議你休息一會兒，小憩一會兒，甚至是睡一覺到天亮。也許夢中你會發現問題所在。要知道大腦潛意識是會幫助我們的，估計很多人都有過類似經歷，不是嗎?
定期回顧你自己“出產”的BUG列表，你會發現很多BUG是你在預防階段做的不夠好而導致的，特別是一些涉及內存操作的BUG，如果前期預防工作沒有做好的話，那么后期解決BUG花費的精力會很多;定期回顧還有一個好處就是強化你的思維意識，讓你以后盡量不再犯同一個錯誤。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
