[筆記]缺陷(Bug)修復
彙整一下之前看的資料
「發現缺陷，理解缺陷，通常佔了工作的90%」。
「對於程式員而言，最大的痛苦，莫過於去修別人的BUG」
什麼是bug
程式錯誤（英語：Bug）：在程式設計中的術語，是指在軟體運行中因為程式本身有錯誤而造成的功能不正常、當機、資料遺失、非正常中斷等現象。
bug的特性
- 「BUG是不允許被暫緩的，OK？」。
- 「BUG是怎麼產生的？」多次反工，等於無功。
- 「WOW，又是這個BUG」她總是重複出現。
- 「修一個BUG，我改了3個項目」，開發版本與測試版本都的修改。
- 「我討厭你IE6」，瀏覽器兼容是很大的一個BUG。
- 「緊急的，一般性，重要的」自己一定要分清哪些是重要的。
- 「這個問題他以前解決過，但是今天他沒來」第二個人來解決這個同樣的問題遇到的麻煩。
- 「在XP上有問題，win2003沒問題」，樣式也的兼容操作系統。
- 「這是BUG嗎？真的這麼修嗎？我怎麼感覺是需求變了？我在改需求？」。
如何有效報告bug
bug報告的首要目的是讓程式員親眼看到錯誤。如果您不能親自做給他們看，給他們能使程式出錯的詳細的操作步驟。
如果首要目的不能達成，程式員不能看到程式出錯。這就需要bug報告的第二個目的來描述程式的什麼地方出毛病了。詳細的描述每一件事情：您看到了什麼，您想看到什麼，把錯誤消息記下來，尤其是「錯誤號碼」。
當您的電腦做了什麼您料想不到的事，不要動！在您平靜下來之前什麼都別做。不要做您認為不安全的事。
儘量試著自己「診斷」程式出錯的原因（如果您認為自己可以的話）。即使做出了「診斷」，您仍然應該報告「症狀」。
如果程式員需要，請準備好額外的信息。如果他們不需要，就不會問您要。他們不會故意為難自己。您手頭上一定要有程式的版本號碼，它很可能是必需品。
表述清楚，確保您的意思不能被曲解。
總的來說，最重要的是要做到精確。程式員喜歡精確。
查找和修復
下面讓我們來看看如何發現並修復Bug。當調試時，Paul Butcher把每個步驟都進行了很好的描述。經驗豐富的程式員會很熟悉這種結構化和紀律性的步驟要領。
1. 確定查找目標，審查Bug報告：看看該Bug描述是否很合理並且提供了足夠的信息去發現和重現。檢查一下該報告以前是否遇到過，如果是，可以檢查以前是如何處理的。
2. 清理桌面：找到正確的程式碼並檢查、清理工作空間。
3. 設置與之匹配的測試環境：這可能是微不足道的，或者是不可能出現的，如果客戶是在一個你無法訪問的配置下運行。
4. 對程式碼的理解已經毫無問題，並且通過現有的測試套件。
5. 釣魚時間：重現並且診斷錯誤。如果你不能重現這個錯誤，那麼就無法去修復。
6. 寫新的（失敗的）開發測試報告或者修復現有測試報告來捕捉Bug。
7. 進行修復：確定沒有破壞其他功能模塊。這裡可能會包括，在修復之前對程式碼進行重構使程式碼更容易被理解，並且使整個修復更安全。在後面的回歸測試中確保沒有引入任何新的錯誤。
8. 努力讓程式碼更安全，更清潔：做一些循序漸進的重構確保程式碼更健壯並且易於維護的。
9. 修復完成後，讓他人進行審查，確保你沒有做一些愚蠢的事情。
10. 再次檢查。
11. 檢查該Bug在其他分支中是否存在：如果你不是主線，你可以在裡面進行合併然後在程式碼裡面進行處理並且瀏覽所有相同的評論和測試報告。
12. 結束並且進行思考和總結：明白是哪裡出錯了？為什麼？是否真正理解自己的修復？在別的地方還會發現這個錯誤嗎？在《程式員修煉之道》，Andy Hunt和Dave Thomas也同樣問了這樣的問題：「如果你花了很長時間去修復這個Bug，問問自己，到底是為什麼？」在將來，如何讓該Bug更容易被發現和修復？如何提高修複方法或許是使用工具？思考的是否深入，要看這個Bug影響和所花的時間有多長？
發現和修復需要多久
設置測試環境所需的時間，重現一個Bug或者修復可能遠遠超過在程式碼中查找和修復的時間。但是對於那種小缺陷，在發現時即可修復。
在軟體開發中，關於大多數軟體缺陷來自哪裡？Dewayne Perry 在《軟體之道》中 解釋到：發現一個Bug（理解並重現Bug）比多久去修復更難。研究發現，大多數Bug（幾乎3/4）很容易被發現和理解，並且不會花多少時間去修復：5 天或更少（這是在大型實時系統與一個重量級的SDLC中，經過大量檢查和測試發現的）。這裡有一個長期隱藏型Bug，可能需要花更長的時間修復，即使這個 Bug微不足道：
| 發現/修復工作 | 小於5天修復 | 大於5天 |
| 缺陷可以重現 | 72.5% | 18.4% |
| 很難或者不能重現 | 5.9% | 3.2% |
所以在你發現Bug的時候，可以和自己打賭，它很快就會被修復，這個命中率會很高。但是當打賭失敗時，你可能會錯很多，或者徹底來個大錯特錯。
開發質量指標
1. 開發和測試、PM一起展開設計評審：雙重檢查。
2. 需要結對review的程式碼的百分比：觀點是–100%。這不僅是為了指出程式碼中的錯誤，更是一種重要的方式，能讓高級開發人員指導更多初級開發人員使用更好的開發經驗，比如採用設計模式和程式碼重用。
3. 單元測試程式碼覆蓋率：一些人可能會想像這是一個有爭議性的論斷。但就像bug的數目沒有盡頭，而是一個未知數一樣，程式碼覆蓋率也是。
4. 程式碼覆蓋率缺口分析：那些沒有覆蓋的程式碼，我們是否遺漏了什麼？
5. 靜態程式碼檢查。
準備上線質量指標
這只是整個過程的一個階段。有很多階段1的質量評估方法在這有對應的部分：
● 測試計劃是否被開發和PM review？
● 測試程式碼結對review的百分比。
● 集成測試程式碼的覆蓋率（和往常同樣的說明）。
然後是這個階段特有的部分：
● 有記錄的測試結果：這個對性能測試和壓力測試尤為重要，因為它提供了我們所知的能在生產中接受的基準指標。
● 所發現的bug數目和嚴重程度。重點就在這了，因為它是一個有效的質量/風險指示器。但它不能放在真空中，它必須和第1、第3階段的結果在一起才能說明問題。
● 難道發現大量的、很嚴重的bug，就意味著超級有效的第二階段會把這個產品所有的風險排除？或者意味著階段1質量非常糟糕時，我們可以期望更多的災難折磨我們的客戶？
● 難道一個很少的bug數意味著我們階段2的工具是在浪費時間？或者意味著階段1非常給力然後帶來了高質量的程式碼？
上線後質量指標
線上測試（TiP），它是一個有效的針對軟體產品的測試方法。這種方法的接受程度（不是方法本身）還有點新。然而線上監控就不新鮮了。亞馬遜就是一個很好的例子，快速開發和良好支撐的監控工具，加上其它工具使得亞馬遜能對產品發佈作出快速響應（也就是補丁），這已經成為亞馬遜各種服務的質量保證制度的一部分。你也 許會問，即使你能找到線上缺陷並快速修復，難道就允許將這些缺陷帶到生產中？「質量」，是的，你只要問問亞馬遜的用戶他們是否遇到過問題，或者看看亞馬遜的用戶滿意分數就明白了。
既然我們承認產品有一個合理的質量階段，那為什麼不在第2階段把所有的問題找出來，而不用管第3階段呢？問題的答案是成本。如果我們嘗試用第二階段的大規模預先測試找到所有的問題，那我們就會因為不斷增加的成本而得到越來越少的回報。在前面兩個階段的基礎上，用上第3階段是一個合理的、划算的方式，能讓各種產品的質量最大化。那對第二階段的bug數這意味著什麼呢？它意味著我們應該非常強烈地意識到找出那些bug我們所付出的代價，並確保它有所值。
Bug與軟體質量
對軟體質量來說，統計所有過去的bug是沒什麼用的，相對來說更實際的工作更有用些。但是做bug統計的人很多，並且很容易生成統計報告。 Douglas Hubbard 在《How to Measure Anything: Finding the Value of Intangibles in Business》把這個現象解釋成為衡量量倒置(Measurement Inversion) :
衡量一個變量的經濟價值通常與它通常所受到的關注度多少成反比。
一個常見的需要bug報告的藉口是，管理者們需要知道軟體的質量現狀。由Bug來判斷軟體質量，這跟由濕度判斷好天氣一樣不靠譜。有可能今天不會下雨，但這並不意味著我會喜歡它，除非外面是零下10度。Alan Weiss在《Million Dollar Consulting》這本書裡已經解釋的很好了：
質量，我耐心的解讀這個詞，並不是一些管理者眼中的那些，缺陷什麼的。但是在消費者的眼中，質量就是有價值的東西。
衡量軟體質量的報告很容易生成，但是價值很低，為什麼不花一點更多的時間去確定實際的產品質量，然後再做出報告呢？一個有用的報告，再次強調一下，是為了同管理者們一起幫助他們做規劃，他們是要根據這些報告要做哪方面的決定，並且這些決定對他們來說有多大的價值。無論他們最終怎麼樣，這才是報告信息的價值。由於來源的不確定性，這些決定和調查可以幫助我們衡量並減少不確定性。
如果客戶是快樂的，存在一些漏洞也是問題不大的。如果客戶抱怨，跟多少bug是無關的。
Bug迷思
開發管理者感興趣的一個度量指標是：你們發現了多少個bug？然後，當得到的回答是一個很高的數目或是一個很嚴重的缺陷（如：3個嚴重的bug！），就會得 到熱烈的鼓掌。 不過，我感覺這樣做是不對的！我的第一反應是，好吧，讓我換種說法… 「在我們的產品中，我們在設計和實現過程中出現了多少嚴重的缺陷？」「僅僅3個？」「太棒啦！（鼓掌）」 或者是：「哦，測試團隊，你找出了多少個我們程式的致命錯誤？」「才3個？」，帶著得意的笑容，「感謝測試團隊（鼓掌）」 這表明，詢問「多少個bug？」是種錯誤的方法
哪些問題該被解決
身為創業者，重點其實不是去磨練你解決問題的能力，更重要的根本是你判斷哪些問題該被解決的能力。在你有限的時間裡面，如果沒辦法解決一個很痛的問題，那你成功的機率微乎其微。也就是說，其實你不應該花太多時間在 bugs 上面，你只需要解決「阻止使用者體驗核心功能」的那些蟲蟲就夠了。
參考資料
