軟硬體調試九法：第五條規則 一次只改一個地方

標籤：

1、隔離關鍵元素就像小學生物課，考察陽光對植物生長的影響，則需要保持養分、灌溉、生長溫度等完全一致，一個有陽光照射，一個沒有陽光照射，這樣才能比較出陽光對植物的生產的影響.bug尋找過程也要如此,在尋找一個具有多個參數的函數的計算錯誤時，固定其它參數，同時修改一個參數的輸入值，驗證輸出結果是否正確，從而可以確定是哪個參數導致的計算錯誤，確定bug。 2、一次只改一個測試軟體工程師有時為了修複一個問題而修改了一個地方，但這個修改沒有解決問題，而他又認為這不會產生影響，這是一個錯誤的假設，這個改動可能的確對解決問題有影響，因此沒有解決問題的改動要及時恢複。否則可能產生無法預料的錯誤。一次只改變一個參數，以便確定哪個參數有影響！與第一條互為補充！硬體也是類似，如果同時更換多個器件，你無法判斷到底是哪個器件導致系統出現問題，也要一次只更換一個，測實驗證沒有問題後再更換下一個！ 3、與正常情況比較        使用兩個例子，一個成功的，一個失敗的，對比示波器的觀察結果、代碼、調試輸出以及其它任何插樁工具 顯示結果，往往比較容易找到bug！如果兩個之間又很多不同，比如代碼改變了很多，則必須不斷的解釋這些差別，並且不斷減少他們之間的差別直至只與bug有關。       因為你不知道哪些方面與bug有關，因此應該對一切能夠測試的地方進行測試，如果證明無關，則把它從調試日誌中刪除。大量資料對比尋找，這個不是很容易做到，既不適合初學者，也不適合軟體自動化分析，需要一個充滿智慧的大腦，從大量對比資料中，快速找到差別。案例：以前有一個項目，設計一個獨立的下載編程器，之前公司使用的是通過PC上廠家提供的下載軟體通過串口進行下載，但是無法滿足安裝現場的升級維護需求。通過監控監控擷取到的通訊命令碼和格式後，編寫完程式下載編程器可以工作了，但是總會執行下載一段後，出現下載失敗，於是我把下載器發送的串口資料和上位機軟體發送的串口進行位元組對比，發現上位機軟體有的資料包長度會改變，仔細對比內容發現，通訊協議中為了防止內容中的位元組與通訊命令碼的起始位元組衝突，進行了替換處理，即使用兩個位元組的不同內容替換內容中與命令碼相同的位元組內容。下載編程器採用同樣的操作後，下載過程不再出錯！ 4、確認自上次正常以來的你修改的地方      有時，正常的系統和錯誤的系統之間的區別是有一項改動導致的，因此一種非常有效方法就是找出第一個導致bug的版本，這個需要連續測試，直至找到沒有bug的版本，一旦找到後，就可以把問題範圍限制到這兩個版本之間的差別。如果兩個版本不是大幅度修改，bug往往比較容易找到。 通常新的設計會出問題，這也是我們在產品發布前總要對新設計進行測試的原因，有的可能時前後部分不相容（比如工裝探針的分布順序，間距改動），也有較為複雜的，就是問題存在了很長時間，知識莫些地方被改變後才暴露出來 案例：在32位系統中，比如8位指標向32位指標強制轉換時，如果以前版本軟體編譯時間8位指標的地址4位元組對齊，那麼賦值轉換不會出現問題，運行也正常；當軟體修改，重新編譯後，8位指標的地址不是4位元組對齊，那麼就會出現資料錯亂甚至死機、看門狗複位等問題。這種問題，只對比代碼的修改處，時看不出問題的，需要綜合考慮代碼修改的影響，除了代碼邏輯、功能的影響外，還有編譯的影響、代碼布局的影響等。

軟硬體調試九法：第五條規則 一次只改一個地方