希望你和這個世界交手多年，依然心懷坦誠，興趣盎然。(心情標籤)
相信每個在Android開發路途的程序猿都會對bug情有獨鍾.╰(￣▽￣)╭對於一個新手來說更是如此,對於那些無厘頭的bug,附有情緒的bug,周而復始的bug,陰魂不散的bug……只想說操碎了心,有時候只是爲了參數的賦值,棧內存溢出比較明顯的問題依舊會掙扎半個多小時.,甚至更長時間ㄟ(≧◇≦)ㄏ. 有些憔悴,但依舊欣慰自己也收穫挺多的,今天這篇博客分享一些收集到開發過程中遇到bug,以及常見的error出現後,對其進行判斷與調試從編碼，測試和調試三個方面得出的bug方法經驗門道. 由於入行較淺,後續才發覺積累的重要性.確顯小菜鳥一枚啊…(*￣ω￣)
♥編碼
事件順序：
在處理事件時，提出下列問題會很有成效：事件可以以不同的順序到達嗎？如果我們沒有接收到此事件會怎麼樣？如果此事件接連發生兩次會怎麼樣？哪怕通常不會發生，但系統（或交互系統）其他部分的bug可能會導致事件發生呢。過早：
這是第一點“事件順序”的一個特例，但它確實會引起一些棘手的bug，因此我把它單獨拎出來說明。例如，如果信令消息在配置和啓動程序完成之前就被過早接收，那麼可能就會有很多奇怪的行爲發生。另一個例子：連接在被放進空閒列表之前就被標記爲down。在調試這類問題時，我們總是假定在空閒列表中的時候連接被設置爲down（但當時爲什麼不把它放到列表外面呢？）。這是我們思考的不足，沒有考慮到有時候事情會過早發生.悄無聲息的故障：
一些最難跟蹤的bug有部分是由那些靜靜失敗並擴展而不是拋出錯誤的代碼所導致的。例如，沒有檢查代碼卻返回錯誤的系統調用（如bind）。又如：解析代碼在它遇到錯誤元素的時候只是返回而非拋出錯誤。在錯誤狀態中持續了一段時間的調用，會使調試變得更難。最好一旦檢測到故障就返回錯誤。IF ~else：
有一些bug是因爲沒有正確考慮到如果條件爲false時會發生什麼而引起的。幾乎在所有的情況下，都應該有一個else部分來應對每一條if語句。此外，如果你在if語句的分支中設置變量，那麼或許你在另一個分支中也要設置。與此種情況相關的是標記被設置的情況。只添加用於設置的標記的條件不難，但是很容易忘了添加當標記應該再次重置時的條件。留下一個永遠設置的標誌可能會導致之後接連不斷的bug。改變假設：
許多一開始最難預防的bug是因爲改變了假設所造成的。例如，在開始時，可能每天只有一個客戶事件。於是很多代碼是在這樣的假設下寫下的。但是後來，設計改變了，允許每天有多個客戶事件了。發生這種情況時，很難改變新設計影響到的所有情況。找到關於改變的所有顯式依賴關係不難，難的是要找到所有隱性依賴於舊的設計的情況。例如，可能會有獲取給定某一天所有客戶事件的代碼。其中的隱含假設是結果集永遠不會超過客戶的數量。日誌記錄：
可視化程序做什麼至關重要，特別是當邏輯很複雜的時候。確保補充足夠多的（但不要太多）日誌記錄，這樣你就可以說明爲什麼程序要這麼做。如果一切正常，那也沒關係，但要是有問題發生，你會很慶幸自己添加了這些日誌。
♦測試
零和null：
如果可行的話，確保總是用零和null來測試。對於字符串，這意味着要測試長度爲零的字符串以及字符串爲null兩種情況。又如：測試TCP連接的斷開，要在發送數據給它發送之前。不使用這些組合方法測試是導致bug出現的首位原因。添加和刪除：
通常，新的功能包括能夠添加新的配置到系統中——例如，一個用於手機號碼轉換的新的配置文件。測試它能否添加新的配置文件是很自然的。但是，我發現我們很容易忘記去測試刪除配置文件是不是同樣ok錯誤處理：
處理錯誤的代碼往往是難以測試的。最好有能檢查錯誤處理代碼的自動測試，但有時這是不可能的。我有時會使用的一招是臨時修改代碼，使得錯誤處理代碼運行起來。要做到這一點最簡單的方法是反轉if語句——例如，從if error_count > 0改成error_count == 0。另一個例子是拼錯數據庫列名，從而導致期望的錯誤處理代碼運行。隨機輸入：
通常，揭露bug測試的一種測試方法是使用隨機輸入。例如，H.323協議的ASN.1解碼使用二進制數據操作。通過發送隨機字節去解碼，我們發現瞭解碼器中的幾個bug。另一個例子是用測試呼叫來生成腳本，此時呼叫持續時間，接聽延遲，第一方掛斷等等都是隨機生成的。這些測試腳本會暴露許多bug，特別是一起發生的事件會產生併攏干擾。檢查不應該發生的動作：
通常測試包括檢查期望動作是不是發生了。但我們很容易忽視相反的情況——忘記檢查不應該發生的動作是不是的確沒有發生。
bug調試經驗總結擁有工具：
我創建了自己的小工具，以使得測試更加簡單。例如，當我用VoIP SIP協議工作時，我寫了一個能夠用正是我想要的標題和值回覆的小腳本。這個工具使得測試很多邊界情況變得容易起來。另一個例子是可以進行API調用的一個命令行工具。通過啓動逐漸添加所需小功能，我得到了一些非常有用的工具。自己寫工具的好處是，我得到的正是我想要的。
bug調試經驗總結
♠調試
討論：
幫助我最多的調試技術是與同學亦與同事討論問題。通常情況下，只是和他們說明問題，就會讓我意識到問題的癥結。此外，即使他們不是很熟悉有問題的代碼，他們也往往能提出一些好點子,這對我解決bug還是很有幫助的.密切關注：
通常，如果調試問題花了很長時間，往往是因爲我做了錯誤的假設。例如，我認爲問題發生在某一方法中，但事實卻是它甚至從來沒有到達那個方法。或者，被拋出的異常不是我以爲的那個。或者，我認爲軟件的最新版本上正在運行，但其實是一箇舊版本。因此，一定要覈實細節，而不是假設。人們更容易看到自己希望看到的東西，而不是事實。測試修復：
如果bug修復已準備就緒，那就必須進行測試。首先在修復前運行代碼，並觀察該bug。然後應用修復並重複測試案例。到此爲止錯誤行爲應消失。遵循這些步驟可以確保它確實是一個bug，並且此次修復的確可以解決這個問題。簡單而有必要。
