遇到程式碼缺陷不要慌，馬上教你快速檢測和修復

摘要：人類思維中總存在缺陷，寫出的程式碼一樣會存在缺陷，導致軟體系統出現不符合預期的行為。本文討論了軟體缺陷的定義、分類、檢測和修復。

人類思維中總存在缺陷，寫出的程式碼一樣會存在缺陷，導致軟體系統出現不符合預期的行為。自動化地檢測和修復缺陷是提高軟體開發效率和軟體質量的重要手段。本文討論了軟體缺陷的定義、分類、檢測和修復。

軟體缺陷與其分類

計算機學科中的中文詞彙很多是從英文翻譯過來的，有時不能夠準確地描述或刻畫詞彙真實的含義。在軟體領域，你能想到的和缺陷相關的詞彙可能有：bug，defect，fault，error，failure，exception等等。說實話，我一直也沒搞懂這些詞彙的區別。但理解這些詞彙的區別不僅僅是文字遊戲，也能夠幫助我們理解針對它們的檢測和修復技術的不同。於是我google了一下，但大多文章對這些詞彙的定義都不太一致。以下是我比較認同的這些詞彙在軟體程式碼上的定義。

· Fault/Bug：軟體中出現不符合業務邏輯的程式碼，比如+號寫成-號；

· Error：軟體執行中出現不符合預期的值，比如a的值為2，被計算成3；

· Failure：軟體與人的互動中出現不符合預期的行為，比如程式崩潰。因此Fault可能導致Error，最終可能導致Failure，注意這裡是可能，並不是一定；

· Defect：一種Defect是一類程式碼自身缺陷的統稱（歸納），比如記憶體洩漏。

Fault通常需要從Error，Failure中檢測到，也就是比較程式的執行結果與預期的規範（Specification）是否吻合。這個過程其實就是debugging（除錯）和testing（測試）。Fault也可以稱為業務邏輯相關的缺陷。而Defect是程式碼本身的問題，不依賴於執行結果和預期的規範的一種軟體問題，因此Defect通常是透過靜態地掃描（不執行）程式碼來檢測的。

缺陷的檢測和修復現狀

從上文可以看到，Fault是透過測試來檢測的，而Defect是透過靜態分析來檢測。在企業中，Fault檢測的普及率和認可度通常比Defect檢測的高，主要原因有如下幾點：

（1）Fault會直接影響軟體的行為，被視為比較嚴重的問題，而很多Defect不能直接影響軟體的行為，或者在很特殊的場景下才影響軟體的行為，開發人員覺得可有可無；

（2）Fault引起的軟體錯誤容易被觀測，有直接證據證明軟體中存在錯誤，開發人員會傾向去修改，而Defect通常比較難觀測；

（3）測試的門檻低一些，測試人員只需要寫一些測試指令碼就可以，但靜態分析需要有程式分析方面技術的積累；

（4）靜態分析固有的一些缺點（耗時，誤報）引起開發人員的不滿。

自動修復方面，這幾年在學術界比較熱門，慢慢也在企業中開始使用，但目前應該還處於初級階段。與檢測相反，Fault的自動修復難度是比較大的，因為涉及到業務邏輯，需要人工加入一些邏輯，當然最近也有很多學術研究使用機器學習來自動學習Fault的自動修復；而很多的Defect的修復是不需要加入業務邏輯相關的程式碼，所以自動化程度反而可以達到較高水平，不過目前也沒有看到這方面的自動化工具。

Defect的檢測和修復的問題和展望

我們不難發現，Fault的檢測已經比較成熟；而Defect的檢測受重視程度還不夠。以前我們可能只關注軟體的正確性，所以Fault的檢測和修復比較受歡迎，但Defect也會影響軟體的質量，同樣需要受到關注。

最近公司在提倡提升軟體工程能力，打造高可信的軟體產品，也是強調我們不僅僅要關注軟體功能的正確性，也需要關注非功能方面的質量，寫出“優美”的程式碼。因此，Defect的自動檢測和修復是一個比較有價值的方向，以下是一些可能做的事情：

（1）對開發人員加強Defect方面的培訓，讓開發人員瞭解常見的Defect，在編碼時儘量地避免寫出這樣的Defect，這比後續的檢測和修復付出的代價要少很多。現在公司雖然有很多的程式設計規範定義不同的Defect，但開發人員可能並沒有用心去學習，如何讓開發人員意識到Defect的危害是比較關鍵的；

（2）加強程式碼的Review的機制。這一點我個人深有體會：沒有Review時，寫的程式碼就比較隨意，有Review時就會考慮得全面一些，畢竟要給別人看；

（3）Defect的自動檢測。對於Fault的檢測，人比機器更擅長（比如寫測試用例），但對於Defect的檢測，機器比人更擅長（比如列舉程式路徑），因此Defect的檢測是更適合自動化的。目前公司也引入了一些Defect的自動檢測工具，如coverity，fortify，findbugs等等，但這些工具通常只是作為黑盒來使用。這樣能夠覆蓋更多的Defect，同時也帶來一些問題：同樣的Defect例項被不同工具重複報告出來，新增一些Defect檢測規則比較難，處理Defect例外場景比較難。因此，我們可能需要一個統一的Defect檢測工具。

（4）Defect的自動修復。Defect的檢測除了耗時和誤報外，另一個不受歡迎的地方是開發人員不知道怎麼修復。因此，Defect的自動修復也是提高Defect受重視程度的一個有效途徑。而且，相比Fault的自動修復，Defect的自動修復對於機器而言是要簡單一些的，因為Defect的類別是有限的可以列舉的，同時Defect的性質是比較形式化不依賴於業務邏輯的。未來希望能開發出一個統一的Defect修復工具。

本文分享自華為雲社群《遇到程式碼缺陷不要慌，馬上教你快速檢測和修復》，原文作者：APTX-486977 。