“過多的誤報”可能是避免進行靜態分析的最常見借口。但是靜態分析不必太吵。

幾年前，靜態代碼分析中的最大挑戰是試圖找到越來越多的有趣檢查對象。在90年代初期的Parasoft原始CodeWizard產品中，我們根據Scott Meyers的書《Effective C++》中的條款制定了30條規則。我想將其視為“程序員的直覺”。我曾向Scott提過一次，雖然他沒有想到過……但是確實給了他一個很好的笑聲。

從那時起，靜態分析研究人員一直在努力擴大可檢測的范圍，擴展靜態分析的功能，并識別缺陷，而不僅僅是一些弱代碼。但是它仍然遭受誤報。靜態分析已經改變了用戶的注意力，從強化代碼到尋找錯誤，這是很棒的，但是現在人們進行靜態代碼分析時遇到的最常見障礙之一就是試圖弄清他們得到的結果。

盡管人們確實說“我希望靜態分析能夠捕獲____”（將您喜歡的無法找到的錯誤命名），但聽到“哇，我得到的結果太多了！”的說法更為常見。或“靜態分析很吵！”或“靜態分析中誤報率很高！”因此，作為軟件測試組織，我們的工作是繼續為客戶解決該問題——繼續提供工具和功能，以幫助您對所獲得的結果進行排序，并了解哪些風險最大。

靜態分析中的誤報是什么？

在靜態分析的上下文中，當靜態分析工具錯誤地報告違反了靜態分析規則時，就會出現“誤報”。當然，這可以是主觀的。有時，開發人員陷入了將任何他們不喜歡的錯誤消息標記為“誤報”的陷阱，但這并不是真的。在許多情況下，他們只是不同意該規則，他們不了解該規則在這種情況下的適用方式，或者他們認為該規則通常不重要（或在這種情況下）。我稱之為噪音，而不是誤報。我在這里發現的有趣之處在于，該工具越聰明，就越有可能產生開發人員乍看之下可能無法理解的發現。

基于模式的分析中的誤報

基于模式的靜態分析實際上沒有誤報。如果該工具報告實際上沒有違反靜態分析規則，則表明該規則存在錯誤（因為規則不應含糊不清）。如果該規則沒有明確的模式可尋，那就是錯誤的規則。

我并不是說每個報告的違反規則都表明存在缺陷。違反僅表示找到了模式，表明代碼有缺陷，容易產生缺陷。

當我查看違規時，我會問自己這個規則是否適用于我的代碼。如果適用，我會修復代碼。如果沒有，我將禁止違規。最好直接在代碼中禁止違反靜態分析的行為，以便團隊成員可以看到它，而不必再次進行審查。否則，您將不斷地反復審查相同的違規行為；這就像嘗試拼寫檢查，但切勿在字典中添加“特殊”字詞。代碼內抑制的優點在于它獨立于靜態分析引擎。任何人都可以查看該代碼，并查看該代碼已被審查，并且該模式在該代碼中被視為可以接受。如果您需要證明符合編碼標準，則此功能特別有用。而且，如果確實需要合規性，則可以輕松地將現有配置用于這些標準，例如CWE，MISRA，IEC 62304，DO-178B/C等。

基于流的分析中的誤報

使用基于流的分析，誤報不僅是方法固有的，而且是相關的，因此需要加以解決。流分析無法避免誤報，原因與單元測試無法生成完美的單元測試用例相同。分析必須確定代碼的預期行為。有時候，太多的選擇無法知道什么是現實的。有時，您只是根本沒有足夠的信息來了解系統其他部分的情況。

這里重要的是，真正的誤報是完全錯誤的。例如，假設您使用的靜態分析工具說您正在讀取空指針。如果您看一下代碼，發現實際上是不可能的，那么您肯定會誤判。

另一方面，如果您根本不擔心代碼中的空值（因為它們是在其他地方處理的），那么該消息（雖然對您并不重要）也不是錯誤的肯定。這是真的，而且碰巧并不重要。來自流量分析工具的消息的范圍從“真實和重要”到“真實和不重要”，“真實和不可能”到“不真實”。這里有很多變體，每種變體的處理方式應不同。

這里也有一個常見的陷阱。就像上面的null示例一樣，您可能會認為null值無法做到這一點，但是該工具找到了實現它的方法。如果對您的應用程序很重要，請確保進行檢查并可能對此加以保護。

了解流量分析既有力量又有弱點，這一點至關重要。流分析的功能在于它遍歷代碼并嘗試查找熱點并在熱點周圍發現問題。缺點是必須假設才能嘗試遍歷代碼，并且遍歷得越遠，產生可能性越大的可能性就越大。

真正的問題是，如果您開始認為由于流程分析是干凈的而已經清理了所有代碼，那么您就在自欺欺人。確實，您發現了一些錯誤，對此深表感謝。缺少流分析錯誤只是意味著您一無所獲，而不是代碼很干凈。如果您要構建對安全至關重要的軟件，則最好確保使用的是C/C++test，dotTEST或Jtest之類的工具，同時具有兩種類型的靜態分析

運行時錯誤檢測

補充流分析的一種很棒但通常被忽略的方法是運行時錯誤檢測。運行時錯誤檢測可以幫助您發現比流分析所能發現的復雜得多的問題，并且您可以確信情況確實發生了。運行時錯誤檢測不會像靜態分析那樣具有誤報率。當發現缺陷時，是因為它實際上觀察到了它在執行過程中發生的情況-沒有涉及任何假設。

您的運行時規則集應與靜態分析規則集緊密匹配。規則可以發現相同類型的問題，但是運行時分析具有大量可用的執行路徑。這是因為在運行時，存根，設置，初始化等對于流分析的方式都沒有問題。唯一的限制是它只能與您的測試套件一樣好，因為它會檢查您的測試套件恰好執行的路徑。如果您使用C或C++進行編程，尤其是在IoT等嵌入式設備中，請查看Insure++——它在運行時發現的錯誤比其他任何工具都多。您可以在運行時準確地找到它們，而不必陷入諸如線程問題，內存泄漏和競爭條件之類的棘手問題中。

值得嗎？

我對誤報的處理方法是：如果要花3天的時間來修復錯誤，則最好花20分鐘的時間來檢查誤報…只要我可以標記它，而不必再次查看它。在正確的背景下查看它是一個問題。例如，假設您有線程問題。線程問題極難發現。如果要查找與線程相關的問題，可能需要花費數周的時間才能對其進行跟蹤。我希望編寫代碼時不會出現任何問題。換句話說，我試圖將我的過程從發現轉向預防。 

如果部署正確，則靜態分析不一定會帶來嘈雜的令人不愉快的體驗。看看我們在Parasoft的工作方式有何不同，特別是利用Parasoft DTP的全部功能通過智能分析來管理結果，使您始終專注于軟件中的風險，而不是追逐不重要的問題。