爲何修復每一個 bug 後都要問這 3 個問題？

你是否曾經修復了一個 bug ，隨後又發現了一個跟剛修復 bug 有關的 bug ，又或是修復 bug 的方式引發了另外一個 bug ？當我修改 bug 時，我會問本身三個問題，以確保我已經仔細考慮了它的意義。每次你認爲發現並修改了一個 bug 時，可使用這些問題來提升生產力和代碼質量。

這些問題背後的主要思想就是：每個 bug 都是底層進程的一個不良表現。你必須處理這些症狀，但若是你僅僅是處理這些外在症狀，你就會有永遠解決不完的問題。你應該找到產生 bug 的進程，而且修復這個進程。當你肯定究竟發生了什麼和發生這些的緣由時，也許你就會明白產生 bug 的基礎進程不是隨機的，而是可控的。

在問這三個問題前，你須要克服面對 bug 的這種天生的抗拒，仔細分析 bug 。查看代碼並解釋出錯的緣由，從能觀察到的現象開始，向後分析，不斷地問爲何，直到你能夠找到產生 bug 的模式。一般，你該跟同事一塊兒作這件事, 由於解釋你認爲會發生的事情，將迫使你面對一些假設——這些程序是作什麼的。

「它溢出了，由於下標J越界了。」

「爲何？」

「J 是 10，但數組最大下標爲 9。」

「爲何？」

「J 是一個字符串長度，數組的起始下標是 0，因此字符串長度爲 1 的最後一個字符的索引是 0。」

找到 bug 後，查找其餘意外狀況。檢查程序出錯時主要的程序變量的值，是否能夠解釋這些值。

「爲何 name 是 null？」

「爲何它老是輸出錯誤信息呢？」

記錄下你作了哪些操做，發生了哪些變化。你須要知道究竟發生了什麼，這樣作就意味着你時刻有一把標尺和歷史記錄。

當完成這些步驟後，你能夠準備問第一個問題了。

1. 其餘地方也會出現這個錯誤嗎？

查看代碼中使用相同模式的地方，系統地改變模式找出相似的 bug 。

「我還在其餘什麼地方使用長度做爲下標的嗎？」

「全部數組的起始下標都同樣嗎？」

「對於一個長度爲 0 的字符串會發生什麼？」

試着描述這部分代碼中應該是正確的，可是這些 bug 沒有遵循的規則。尋找這個不變量 [ 1 ]的過程將幫助你找到其餘潛在的 bug 。

「起始偏移加上長度減去1就是結束的下標，除非數組長度爲 0」。

對於你發現的每個 bug ，你均可以解決一批 bug ，這是很是高效的。嘗試用歸納性的語言描述這些 bug 也能提高你對程序的理解程度，並幫助您避免在程序中引入更多的 bug 。

2. 這個 bug 後面隱藏着什麼其它的 bug ？

一旦你肯定了如何修復這個 bug ，你就須要考慮一下修復後會發生什麼。這個執行失敗的語句後面的語句也可能有問題，可是程序尚未執行到此就不知道有沒有 bug ，或者有些代碼由於你修復 bug 而第一次出如今程序中，這些代碼也可能有問題。查看這些未執行的語句，檢查代碼中的 bug 。

「下一條語句會正常運行嗎？」

當你在想程序的控制流的時候，能夠弄清楚還有哪些地方程序沒有執行到。

「是否有我歷來沒有測試過的功能組合？」

在程序中插樁（instrumentation）並不會耗費太多時間，在運行程序各個部分的過程當中就能夠進行檢查，可是你會驚訝地發現開發者測試過的代碼還有不少都不能正常運行。

「我能夠測試出全部的錯誤信息嗎？」

注意一個地方的改動可能會引發其餘地方的 bug 。一些變量的局部改動可能會在執行時違反後來的假設。

「若是僅是從 J 中減去 1，當長度爲 0 時，後面的語句會操做數組中 -1 位置的元素。」

若是程序已經作了大量改動，就要仔細考慮是否有必要增長另一個補丁，或者是時候考慮從新設計和從新實現了。

（有時候調 Bug 就是這樣的）

3.我應該作些什麼防止相似 bug 的產生呢？

問問本身如何改變編程方法，根據定義避免 bug 的出現，經過改變方法或者工具，常常能夠移除整個類的錯誤而不用一個一個的解決 bug 。

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

從「 bug 是什麼時候引入的」這個問題開始：在程序開發生命週期的哪個階段能夠阻止 bug 的產生？

「設計是沒問題的；我在編程時引入了 bug 。」

仔細檢查 bug 產生的緣由，考慮 bug 產生時正在運行的進程，並想一想怎麼改變它來阻止 bug 的產生。

「將偏移的數據類型和長度分離出來將會在編譯時捕獲這個錯誤。」

「每個文本項能夠用隱藏了下標計算的宏輸出，而後我就能夠一次找到它。」

不要知足於膚淺的答案。假如你對於一個 bug 的解釋是，「我記不清了」，那還怎麼改進這個過程，讓你再也不須要記住它？你能夠更改編程語言，使被忽略的細節能夠徹底隱藏，不然你遺漏的部分會被檢測到從而致使編譯問題。對這個問題域，你可能使用了預處理器或者智能的編輯器，有默認值，錯誤檢查，智能提示和快速文檔。這個 bug 多是編程團隊溝通的問題，亦或是須要討論的設計衝突。

思考發現 bug 的方式，並問問本身如何能更早發現它。測試怎麼能夠更嚴密一些？可否進行自動化測試？是否要添加代碼實時檢測功能，以即可以及時捕獲錯誤信息？

「我應該在個人測試單元中嘗試長度爲 0 的數組」。

「我應該進行下標檢查，提早捕獲不符合的下標」。

有必要建立一些系統方法和自動化工具，用於編譯、構建和測試，它們能夠減小長時間的調試和查明具體事實的過程。

這個技巧的應用

養成這樣一種習慣：每當你發現一個 bug 時，問本身這三個問題，甚至你沒必要等到有 bug 時才使用這三個問題。

在設計和審查過程當中，你均可以用這三個問題來處理你獲得的每一條意見。審閱意見是潛在的溝經過程的結果，使你能夠有所改進。若是你認爲讀者評論是錯誤的，好比，你可能會問是什麼使你的文章沒被理解，如何更好地與審稿人溝通。

設計評審和代碼審查是找出 bug 的強有力手段，你能夠對審查過程出現的每個缺陷都提出三個問題。若是審查完全，前兩個問題不會出現太多新的 bug ，但第三個問題能夠幫助你找到方法，用來避免將來可能會出現的 bug 。

擴展閱讀

• 學軟件測試最好的幾本書，這8本書能幫你不少
• 軟件測試7年的工程師，講述當初是怎麼突破的瓶頸？少走彎路