如何處理靜態分析儀輸出

Question

我們已開始在代碼庫中使用靜態分析器（Coverity）。 我們收到了大量的警告（數十萬），我們很快就被驚呆了，整個團隊需要幾個月才能清除所有這些警告（一點也不可能）。

我們到目前為止討論的選項是

1）雇用承包商來整理警告並修復它們 - 他的缺點是：我們可能需要非常經驗的人來做所有這些修改，並且沒有承包商需要了解代碼。

2）過濾掉警告並僅處理危險警告 - 這里的問題是我們的靜態分析輸出總是被警告混亂，使我們難以隔離問題。 過濾警告也是一項重大努力。

無論哪種方式，將我們的代碼帶到一個狀態，當靜態分析器對我們來說是一個有用的工具似乎是一個巨大的任務。

那么如何才能使用靜態分析儀，而無需將當前的開發工作納入完整的支架？

Answer 1

每周一天：開啟分析; 挑選100個最煩人的警告; 解決它們; 關閉分析。 簡而言之：不要驚慌; 你的代碼按原樣運行（不是嗎？）; 以一口大小的方式處理警告。

如果您發現相同類型的警告再次出現（錯誤的編碼實踐），請教育您的團隊將來避免使用它們。

我用一個舊的代碼庫做了這個：我早上進入（在團隊的其他成員之前），在編譯器上調高警告/分析級別，修復一些警告，然后將其設置回默認值。

Answer 2

1. 對於遺留代碼。 優先考慮這些漏洞錯誤並制定計划來處理它們。 平衡錯誤修復和新功能開發。 新功能總是更重要。
2. 對於新代碼。 使其成為整合過程的一部分：在簽入新代碼之前，確保它們沒有覆蓋。

Answer 3

首先要做的是調整分析設置; Coverity支持可能會給你一個相當通用的配置。

• 對缺陷的代表性樣本進行分類，如果檢查器似乎沒有產生比噪聲更多的信號，請暫時將其關閉。 （Coverity的大多數跳棋都很好，但是沒有人是完美的，聽起來你需要做一些無情的優先排序。）
  • 從長遠來看，將其中的一些檢查器重新打開，但在報告中將它們標記為低優先級。 （這比它應該更難;我一直認為Coverity需要閱讀一些關於缺陷排名的文章，名叫道森恩格勒。:-)
  • 在更長的運行中，嘗試默認禁用的檢查器; 其中一些人發現了令人印象深刻的錯 雖然你確實需要關閉一些虛假的警告，但解析警告卻非常有用。
• 對於您實際上即將修復的代碼庫的哪個部分，請切實可行。 使用組件跳過對您不會修復缺陷的代碼的分析，至少目前是這樣。 （例如，從理論上講，如果您的產品包含第三方代碼，那么您應對其質量負責，並且應修補其中的錯誤。在實踐中，此類錯誤很少得到修復。如果它是成熟的第三方代碼，則為假積極率會很高。）
  • 設置組件和排除是很棘手的，但是一旦完成，它們運行良好 - 我的一個負面預測正則表達式有超過一百個析取。
  • 組件還有助於為缺陷分配個人責任，我發現這對於修復缺陷至關重要。
• 僅針對新缺陷設置報告，並讓人們觀看該URL。 新的缺陷存在於活動代碼中，並且更容易開始使用“無新警告”策略。

讓我以幾個免責聲明結束：

• 您可能想在Coverity支持論壇（ http://forums.coverity.com/ ）中重新提出這個問題，該論壇不是非常活躍，但我們不必擔心違反NDA。 我有一個我認為值得啟用的跳棋列表。

• 我這樣做是為了生活，也許你想聘請我們（ http://codeintegritysolutions.com/ ）; 我今天在斯坦福大學就這個問題發表演講。 聘請顧問進行調整很有意義; 在公司外面有人做分類是比較棘手的。 有一個局外人做修復工作仍然比較棘手; 從錯誤中吸取教訓比修復錯誤更重要。

  • 對於我們的企業博客，我已經將我的斯坦福談話的某些部分擴展了一點： http ： //codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html 。

Answer 4

對於您的承包商選項，您可能會采用更溫和的方式，讓他們只修復明確的問題，本地問題並且不需要完全理解您的代碼。 我猜想大量的Coverity命中是可能的NULL指針解引用或可能的寫入超過緩沖區的末尾，可以通過簡單的檢查來解決，這些檢查完全是有問題的代碼本地的，並且不需要理解大圖。

我承認 - 在使用preFAST / preFIX或者微軟調用的工具之前，我已經完成了這樣的工作，其中很多都是機械式的變化。 非常適合承包商或甚至實習生。 但是會有一些需要更多分析的東西 - 只要確保承包商明白他們不應該試圖深入研究。

對他們很好 - 這是苦差事，所以做任何你可以愉快的事情。

Answer 5

人們告訴我們第一次使用時會忽略所有警告。 然后在下一個差異構建中，它會逐漸增加新的警告：你應該修復它。 然后，在您使用該工具幾個月后，您會對它感到滿意，然后返回並開始修復舊的警告。

Answer 6

嘗試其他靜態分析儀。 我以前使用Parasoft C ++ Test，它有一種方便的方法來根據嚴重程度過濾警告。

Answer 7

這是否意味着您根據需要定制它有問題？
如

“”可定制分析

Coverity Static Analysis提供了通過修改部署的檢查器數量或特定於單個檢查器的設置（例如空指針解除引用的閾值）來微調分析的功能。 為特定代碼塊或應用程序配置Coverity的功能允許開發人員選擇最適合其應用程序的性能級別，從而獲得更准確可靠的結果。 Coverity軟件開發工具包允許您通過創建自定義檢查器來檢測C和C ++代碼中的唯一缺陷類型。 除了創建用於查找並發性，異常處理和其他關鍵問題的自定義檢查器之外，還可以使用此功能。“
http://www.coverity.com/products/static-analysis.html

Answer 8

Coverity的典型開箱即用分析配置往往會為每千行代碼提供一到三個缺陷。 如果您有數十萬個缺陷，並且您的代碼行數遠遠少於1億行，我可以保證您的分析配置不正確或對您的組織不是最理想的。

除了調整分析配置本身，您還可以通過影響確定優先級 - 默認的“高”，“中”和“低”映射應該足以讓您開始，直到您了解哪些子類別最容易受到影響你的申請。

第三，如果您的代碼庫很大（並且不是），則將其細分為組件，以便每個團隊或開發人員組只能查看他們直接維護的代碼 - 這樣可以處理更易於管理的工作塊，以及它還允許您對組件進行優先級排序（服務器代碼中的缺陷比客戶端代碼中的缺陷，測試代碼或第三方代碼等更為重要）。