Parasoft作為軟件測試工具，小編接觸過很多在這方面尋求幫助的人，所以有這方面疑惑的不止你一個人哦！

我們假定你已經安裝了靜態分析工具并配置了所有初始設置。除此以外，如果剛開始沒有確定項目需要采取的策略，入門會比較困難。小編所說的“入門”是指深入理解將靜態分析集成到現有項目中的一般方法，以及如何提高靜態分析隨著時間的推移帶來的投資回報。

什么是靜態分析？

簡單來說，靜態分析是在不執行代碼的情況下檢查源代碼和二進制代碼的過程，通常用于查找bug的前期準備或評估代碼質量。與需要運行程序的動態分析（例如Parasoft Insure ++）不同，靜態分析可以直接分析源代碼而不需要執行源代碼。

這意味著靜態分析可用于部分完整的代碼，庫和第三方源代碼。開發人員可以將靜態分析應用在編寫或修改代碼的過程中，甚至可以應用到任何代碼庫。

支持功能安全和編碼標準

在應用程序安全域中，靜態代碼分析采用了靜態應用程序安全性測試（SAST）技術。靜態分析可以支持安全漏洞檢測，同時支持bug檢測，質量指標和編碼標準一致性檢測。

另外，靜態分析工具強制要求（在某些情況下“強烈推薦”）能夠支持安全標準（如ISO 26262或EN 50128）的檢測，因為這些標準能夠檢測難以發現的缺陷并提高軟件的安全性。當然，這又回歸到安全性的問題上，因為靜態分析工具還可以幫助軟件團隊遵守主要用于驗證安全編碼的編碼標準，例如CERT甚至MISRA。

靜態分析工具優點及難點

靜態分析工具的一個優點是它們可以在項目的任何階段引入和使用，即使項目是不完整的或者只有部分編碼是有效的。引入靜態分析的最大難點在于代碼量大會產生大量的警告。因此，將靜態分析應用到項目中時的重點應該是使團隊能夠盡快高效工作，并最大限度地減少團隊被靜態分析的警告困擾的情況。這并不是說這些警告不重要，但大多數開發人員都不會修復現有或遺留代碼缺陷，至少不是立即處理。

最重要的應該是將靜態分析運用到日常流程中，以便最大化靜態分析的使用效果和可用性，然后處理最危險的bug和安全漏洞。一旦團隊變得更加熟練，你就可以專注于優化工具和流程，提高投資回報率。

如何管理早期靜態分析報告

一旦將靜態分析工具安裝到項目中，該工具通常會報告相當長的違規和警告報告。這可能是多到無法處理的，特別是在大型代碼庫中，因此如何管理這些報告將會直接影響到工具集成到項目中能否成功。

并非所有警告都是至關重要的，因此不需要立即處理所有警告。學習哪些需要立即解決而哪些需要推遲處理是成功的關鍵。如上所述，產品的成熟度和規模對方法有直接影響，下面將更詳細地概述。

底線方法

顧名思義，在這種方法中，開發人員決定在初步分析之后，他們不會讓任何更嚴重的警告和違規進入代碼庫。換句話說，他們需要分析每個警告來確定其準確性，并及時修復，如果它確實是一個bug。

團隊還可以決定在現有代碼中添加已發現的關鍵警告，并將其添加到報告工具中的bug列表中。這些類型的警告可能是嚴重的安全漏洞，如SQL注入，或嚴重的內存錯誤，如緩沖區溢出。在大多數情況下，可以推遲不太嚴重的警告以供以后分析。你可能會想，“這不僅僅會增加我們的技術債務嗎？”如果你這樣想，那你就是對的！但在這個階段，我們對此表示滿意。這些警告中的任何潛在錯誤都已經在技術債務堆中。至少現在，它們被識別出來并且以后更容易修復。

確認并推遲處理方法

如果產品已經在市場上并且正在維護中，那么識別代碼中的任何bug和安全漏洞仍然是有益的，但讓開發人員分析（更不用說修復）所有這些警告是不可行的。

在這種情況下，查看最重要的報告并確定行動方案是有意義的。其余的警告只需要確認，因為軟件團隊認識到它們存在，但它們大多數都被推遲了。（這再次增加了該組織的技術債務，但如上所述，這些漏洞在技術上已經存在作為技術債務。）這種方法不同于底線方法的地方在于確定關鍵警告后，你會推遲其余的警告，而不需要所有的都分析。

綠地方法

現有代碼很少的項目是靜態分析的理想起點。在這種情況下，軟件團隊可以調查出現的所有警告并修復發現的錯誤。與其他方法不同，你只需要管理很少的警告，因此開發人員可以解決額外的工作。這也是通過這些工具實現和實施編碼標準的理想時間，因為可以在IDE中以及在將任何代碼提交到版本控制之前識別和修復違規（你可以在此處描述的其他方案中執行此操作）。

在三個主要階段采用何種靜態分析，可以通過如何處理積壓的警告來區分，如下所示：

在三個主要階段采用靜態分析：在綠地項目中，大多數報告的警告都經過調查和修復，幾乎沒有進入技術債務堆。正在開發的項目往往會積壓大量的警告，這些警告大部分都是推遲處理，只處理嚴重警告，維護中的產品往往會推遲大多數警告。

配置與過濾

開源或輕量級靜態分析工具與商業高級靜態分析工具之間的主要區別之一在于能否配置為分析啟用哪組檢查器，并根據警告類別，文件名，嚴重性等過濾掉報告的結果屬性。這有助于突出目標——開發人員可以專注于他們感興趣的警告類型，并減少在任何時間產生的垃圾信息量。

配置檢查器和過濾結果之間也存在差異。盡管一開始限制全局配置中的規則數量似乎更好，但通常應使用過濾來限制報告范圍，而不是完全消除檢查程序。如果在配置中關閉后來證明是重要的規則，則警告存儲庫中將沒有歷史記錄，因此你將無法確定錯誤是由最近的更改引入還是在靜態分析之前已經在代碼中。

我建議使用配置將規則集限制為可預見對軟件團隊有用的規則。同樣，以最終目標為出發點：如果提高安全性是關鍵目標，那么啟用所有與安全相關的規則，禁用不太重要的規則，啟用CERT C等內置安全編碼標準。如果你正在使用Parasoft C/C++test等高級靜態分析解決方案，你可以利用其內置的管理工具來處理靜態分析報告中生成的數據，并推進未來的重點開發工作。

總結

靜態分析工具使團隊無需執行代碼，就能夠檢測和跟蹤錯誤安全漏洞。這些工具可應用于現有、傳統和第三方代碼并提供質量審查結果。

采用何種靜態分析方法在一定程度上取決于項目的成熟度。大量代碼確實會產生大量警告。但這完全是可管理的，能否成功取決于團隊如何決定處理結果。好好考慮為項目的每個成熟度階段引入不同的技術，以及如何將這些工具集成到開發人員，團隊負責人和經理的日常工作流程中。

審核編輯 ：李倩