“過多的誤報(bào)”可能是避免進(jìn)行靜態(tài)分析的最常見借口。但是靜態(tài)分析不必太吵。

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

從那時(shí)起，靜態(tài)分析研究人員一直在努力擴(kuò)大可檢測(cè)的范圍，擴(kuò)展靜態(tài)分析的功能，并識(shí)別缺陷，而不僅僅是一些弱代碼。但是它仍然遭受誤報(bào)。靜態(tài)分析已經(jīng)改變了用戶的注意力，從強(qiáng)化代碼到尋找錯(cuò)誤，這是很棒的，但是現(xiàn)在人們進(jìn)行靜態(tài)代碼分析時(shí)遇到的最常見障礙之一就是試圖弄清他們得到的結(jié)果。

盡管人們確實(shí)說“我希望靜態(tài)分析能夠捕獲____”（將您喜歡的無法找到的錯(cuò)誤命名），但聽到“哇，我得到的結(jié)果太多了！”的說法更為常見。或“靜態(tài)分析很吵！”或“靜態(tài)分析中誤報(bào)率很高！”因此，作為軟件測(cè)試組織，我們的工作是繼續(xù)為客戶解決該問題——繼續(xù)提供工具和功能，以幫助您對(duì)所獲得的結(jié)果進(jìn)行排序，并了解哪些風(fēng)險(xiǎn)最大。

靜態(tài)分析中的誤報(bào)是什么？

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

基于模式的分析中的誤報(bào)

基于模式的靜態(tài)分析實(shí)際上沒有誤報(bào)。如果該工具報(bào)告實(shí)際上沒有違反靜態(tài)分析規(guī)則，則表明該規(guī)則存在錯(cuò)誤（因?yàn)橐?guī)則不應(yīng)含糊不清）。如果該規(guī)則沒有明確的模式可尋，那就是錯(cuò)誤的規(guī)則。

我并不是說每個(gè)報(bào)告的違反規(guī)則都表明存在缺陷。違反僅表示找到了模式，表明代碼有缺陷，容易產(chǎn)生缺陷。

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

基于流的分析中的誤報(bào)

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

這里重要的是，真正的誤報(bào)是完全錯(cuò)誤的。例如，假設(shè)您使用的靜態(tài)分析工具說您正在讀取空指針。如果您看一下代碼，發(fā)現(xiàn)實(shí)際上是不可能的，那么您肯定會(huì)誤判。

另一方面，如果您根本不擔(dān)心代碼中的空值（因?yàn)樗鼈兪窃谄渌胤教幚淼模敲丛撓ⅲm然對(duì)您并不重要）也不是錯(cuò)誤的肯定。這是真的，而且碰巧并不重要。來自流量分析工具的消息的范圍從“真實(shí)和重要”到“真實(shí)和不重要”，“真實(shí)和不可能”到“不真實(shí)”。這里有很多變體，每種變體的處理方式應(yīng)不同。

這里也有一個(gè)常見的陷阱。就像上面的null示例一樣，您可能會(huì)認(rèn)為null值無法做到這一點(diǎn)，但是該工具找到了實(shí)現(xiàn)它的方法。如果對(duì)您的應(yīng)用程序很重要，請(qǐng)確保進(jìn)行檢查并可能對(duì)此加以保護(hù)。

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

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

運(yùn)行時(shí)錯(cuò)誤檢測(cè)

補(bǔ)充流分析的一種很棒但通常被忽略的方法是運(yùn)行時(shí)錯(cuò)誤檢測(cè)。運(yùn)行時(shí)錯(cuò)誤檢測(cè)可以幫助您發(fā)現(xiàn)比流分析所能發(fā)現(xiàn)的復(fù)雜得多的問題，并且您可以確信情況確實(shí)發(fā)生了。運(yùn)行時(shí)錯(cuò)誤檢測(cè)不會(huì)像靜態(tài)分析那樣具有誤報(bào)率。當(dāng)發(fā)現(xiàn)缺陷時(shí)，是因?yàn)樗鼘?shí)際上觀察到了它在執(zhí)行過程中發(fā)生的情況-沒有涉及任何假設(shè)。

您的運(yùn)行時(shí)規(guī)則集應(yīng)與靜態(tài)分析規(guī)則集緊密匹配。規(guī)則可以發(fā)現(xiàn)相同類型的問題，但是運(yùn)行時(shí)分析具有大量可用的執(zhí)行路徑。這是因?yàn)樵谶\(yùn)行時(shí)，存根，設(shè)置，初始化等對(duì)于流分析的方式都沒有問題。唯一的限制是它只能與您的測(cè)試套件一樣好，因?yàn)樗鼤?huì)檢查您的測(cè)試套件恰好執(zhí)行的路徑。如果您使用C或C++進(jìn)行編程，尤其是在IoT等嵌入式設(shè)備中，請(qǐng)查看Insure++——它在運(yùn)行時(shí)發(fā)現(xiàn)的錯(cuò)誤比其他任何工具都多。您可以在運(yùn)行時(shí)準(zhǔn)確地找到它們，而不必陷入諸如線程問題，內(nèi)存泄漏和競(jìng)爭(zhēng)條件之類的棘手問題中。

值得嗎？

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

如果部署正確，則靜態(tài)分析不一定會(huì)帶來嘈雜的令人不愉快的體驗(yàn)。看看我們?cè)?/span>Parasoft的工作方式有何不同，特別是利用Parasoft DTP的全部功能通過智能分析來管理結(jié)果，使您始終專注于軟件中的風(fēng)險(xiǎn)，而不是追逐不重要的問題。