聲明：本文檔的內容主要來源于書籍《軟件調試修煉之道》作者Paul Butcher，屬于讀書筆記。

重現第一，提問第二

問題重現是實證過程的最強大武器，如果不能重現問題，你也無法證明修復了它

首先按照缺陷報告的描述的步驟來做， 抓住重點，包含三個控制因素

軟件本身：確保你使用的軟件版本和bug提交的版本一致，使用相同的編譯工具和相同的編譯參數。

軟件運行環境：如果要與外界環境交互，則確保使用相同外部系統。比如測距儀，需要在同樣的光照環境、溫度和供電方式。

提供的輸入：如果軟件代碼的運行和配置參數相關，則應該使用相同配置。

?

控制輸入之詳細說明

軟件的輸入可能時本地文件，也可能是用戶的一系列操作或者是第三方設備

推測可能的輸入：

• 回溯工作：錯誤位置明確時，該方法可能可以重現問題，或者提供有效線索
• 探測可能輸入值：利用邊界值分析法和分支覆蓋法，經驗表明，這兩處最易出錯
• 利用錯誤條件：編碼時，人的天性是關注正常的情況，于是未處理的錯誤條件很可能誘發一系列bug,因此模擬錯誤條件可能可以重現問題
• 引入隨機性：選取一系列不同的輸入值，也叫模糊測試。該模糊測試器的關鍵特征是，可以根據一些列規則重新創建曾經的輸入，以便能夠隨意重現問題

記錄輸入值：

• 程序日志：在JAVA中有日志功能，可以打開或者關閉，C語言可以采用獨立文本
• 外部日志：這個在客戶端和服務器端的軟件中采用，獨立的系統可以忽略

注意負載和壓力：

• 有些缺陷只有軟件在某種壓力下運行是才能表現出來，這個在服務器端軟件最明顯，其必須通過壓力測試；測距儀軟件需要注意的在電池電量供應不足情況下，是否會運行出錯！

改進問題重現

如何才能讓問題重現即可靠又方便，并且代價最小？

• 最小化反饋周期：
• 將問題重現最小化：第一次就做到最小化不太可能，需要逐步刪除不必要的方面，縮小問題重現的范圍。
• 最大限度的減少重現所需的時間：有些bug只是需要時間來重現，因此需要采取措施使其早些發生，比如懷疑資源泄露，則可以故意營造資源耗盡的局面。

將不確定的缺陷變為確定的：

• 軟件之美在于它的確定性，不確定性往往有以下幾個原因：
• 開始于不可預知的狀態：比如C/C++程序，使用未初始化的內存或變量。
• 與外部系統進行交互：這種情況，最好的選擇是使用你能控制的東西代替外部系統，比如使用串口助手模擬外設發送指令。
• 故意使用隨機性：軟件中的隨機函數，都是偽隨機，只要種子一樣，結果就相同
• 多線程：PC端的軟件叫多線程，嵌入式端一般叫多任務，可以采取措施增加競爭情況，是問題更容易實現

自動化：

• 采用自動化測試，不但可以加快進程還可以見笑犯錯誤的幾率
• 自動化測試：需要構建自動化測試框架和用戶借口測試工具
• 重放日志文件：如果bug重現需要通過日志，則需要通過重放日志構造相同的操作序列

迭代：

• 在診斷過程中，隨著獲得軟件運行信息越來越多，你可以使用這些信息不斷改進你的重現。逐步縮小導致bug發生的范圍，比如縮小到一個函數、一個變量、一段語句。 通過反復優化確保你的重現問題的程序既方便又可靠！

如果真的不能重現怎么辦？

缺陷真的存在嗎？

• 用戶一般不會惡意報告缺陷，極有可能是軟件出錯了，也有可能是不清楚為何這樣，誤解了軟件的一些方面。

在相同的區域解決不同的問題

• 重現問題的區域還有其它缺陷嗎？如果有，也要一查到底。這樣做可以清理這個區域的代碼、使你從整體上更好的了解代碼，并找到重現問題的關鍵因素。

讓其他人參與其中

• 開發人員很容易有盲點，其工作重點是讓編寫的軟件可以正確運行，而不是證明這個軟件有缺陷，因此讓別人參與進來時必要的。

充分利用用戶群體

• 如果缺陷出現在外部系統中，獲取應該讓用戶為你收集重要信息，不過這種方法往往并不理想。

推測

• 雖然實證方法是最好的，但是其不是唯一的解決辦法，純邏輯推理就是其中一種。該方法費時費力，在其它方法無效時，往往可以起到作用。該方法需要把自己融入到軟件中，執行到每一步時，考慮有哪些錯誤的可能性，并嘗試解釋你跟蹤的缺陷。

總結

以上是生活随笔為你收集整理的读书笔记软件调试之道 ：问题的核心-重现问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。