如何處理靜態分析儀輸出

Question

我們已經開始在我們的代碼庫上使用靜態分析儀（Coverity）。我們很快就被我們收到的數十萬條警告（數十萬條警告）驚呆了，整個團隊需要幾個月的時間才能清除所有警告（不可能）。

我們討論的選項至今都

1）僱用承包商理清警告，並解決這些問題 - 他的缺點：我們可能會需要很經驗的人做所有的這些修改，並沒有承包商會需要了解代碼。

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

無論哪種方式，當我們的代碼進入狀態時，靜態分析器對我們來說可能是一個有用的工具，似乎是一項艱鉅的任務。

那麼如何在靜態分析儀下工作，而不需要將當前的開發工作變成一個完整的靜態工作？

Answer 1

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

• 對缺陷的代表性樣本進行分類，並且如果檢查程序似乎沒有產生比噪聲更多的信號，請立即關閉它。 （大多數Coverity的棋子都不錯，但沒有人是完美的，這聽起來像你需要做一些無情的優先級。）
  • 從長遠來看，把一些人的棋子回來，但在你的報告將它們標記低優先級。 （這比應該更難;我一直認爲Coverity需要閱讀幾篇有關Dawson Engler的缺陷排名的論文。:-)
  • 在更長時間的運行中，嘗試禁用的跳棋默認;其中一些發現令人印象深刻的錯誤。解析警告是驚人的有用的，但你確實需要關閉一些假的。
• 對於你的代碼庫的哪個部分你很快就會修復，這是玩世不恭的現實。至少現在，使用組件可以跳過對你不會修復缺陷的代碼的分析。 （例如，理論上，如果你的產品包含第三方代碼，你就要對其質量負責，並且應該修補其中的錯誤，實際上，這樣的錯誤很少得到修復，如果它是成熟的第三方代碼， ）
  • 設置組件和排除是非常棘手的，但一旦完成，它們就會很好地工作 - 我的一個負面預測正則表達式有超過一百個分離符。
  • 組件還有助於指定個人對缺陷的責任，我發現這些缺陷對於修復缺陷至關重要。
• 只設置新的缺陷報告，並讓人們觀看該URL。新的缺陷處於活動代碼中，並且更容易開始使用「無新警告」策略。

讓我有一對夫婦免責聲明的結尾：

• 您可能需要重新問這個問題在Coverity的支持論壇（http://forums.coverity.com/），這是不是很活躍，但如果我們不不必擔心違反NDA。我有一份我覺得值得使用的跳棋的列表。

• 我以此爲生，也許你想聘請我們（http://codeintegritysolutions.com/）;我今天在斯坦福大學就這個問題發表演講。聘請顧問進行調整很有意義;讓公司外部的人做分流是棘手的。有外人做這些修復仍然更加棘手。從錯誤中學習比修復它們更重要。

  • 我這一擴大一點與我的談話斯坦福大學的某些部分，爲我們的企業博客：http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html。

Answer 2

嘗試其他靜態分析儀。我曾經使用過Parasoft C++ Test，它有一個方便的方法來根據它們的嚴肅性過濾警告。

Answer 3

這是否意味着您在根據需要定製它時遇到問題？
作爲

「」定製的分析

Coverity的靜態分析提供了微調的能力通過修改部署的跳棋的數目，或諸如用於空指針閾值特定於單個檢驗器的設置，分析解引用。爲特定代碼塊或應用程序配置Coverity的能力允許開發人員選擇最適合其應用程序的性能級別，從而獲得更準確和可靠的結果。 Coverity軟件開發工具包允許您通過創建自定義檢查器來檢測C和C++代碼中的獨特缺陷類型。這是除了尋找併發性，異常處理等關鍵問題創建自定義跳棋「」
http://www.coverity.com/products/static-analysis.html

Answer 4

一天一個星期：打開分析;挑選最令人討厭的100個警告;修復它們;關閉分析。總之：不要驚慌;你的代碼按原樣運行（不是嗎？）;通過一小撮大塊的警告工作。

如果您發現相同類型的警告不斷出現（錯誤的編碼習慣），請教您的團隊以避免將來再次出現這些警告。我在一個早期的代碼基礎上做了這個工作：在清晨（在團隊的其他部分之前），調整編譯器的警告/分析級別，修復一些警告，然後將其設置回來到默認值。

Answer 5

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

我承認 - 在使用preFAST/preFIX或任何工具從Microsoft調用之前，我已經完成了這樣的工作，其中很多是機械式的變化。非常適合承包商或甚至實習生。但是會有些東西需要更多的分析 - 只要確保承包商清楚他們不應該試圖深入瞭解事情。

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

Answer 6

1. 對於遺留代碼。優先考慮這些問題，並制定計劃來處理這些問題。平衡錯誤修復和新功能開發。新功能總是更重要。
2. 用於新代碼。使其成爲您的集成過程的一部分：在檢查新代碼之前，確保它們沒有覆蓋。

Answer 7

的Coverity的人告訴我們「忽略」的所有警告你使用它的第一次。然後在下一個差異版本中，它將增加新的警告：您應該修復哪些警告。然後，在使用該工具幾個月後，如果您對此感到滿意，則可以返回並開始修復舊警告。

Answer 8

Coverity的典型即用型分析配置每千行代碼傾向於給出一到三個缺陷。如果您有數十萬個缺陷，並且您的代碼數量遠遠少於1億行，那麼我可以保證您的分析配置對您的組織來說不正確或不理想。

除了調整分析配置本身，您可以通過影響優先 - 默認的「高」，「中」和「低」映射應該足以讓您開始，直到您感覺到哪些子類別傾向於對您的應用程序造成最大的損害。第三，如果你的代碼庫很大（並且不是）將代碼塊分成多個組件，以便每個團隊或一組開發人員只能看看他們直接維護的代碼 - 這允許更多可管理的工作塊並且它還可以讓您優先考慮組件（服務器代碼中的缺陷比客戶端代碼，測試代碼或第三方代碼中的缺陷更重要）。