醫療設備使用的軟件代碼比以往任何時候都多。然而，雖然軟件為醫療設備提供了更多的功能和靈活性，但它也帶來了額外的復雜性，從而增加了故障風險。今天大約 20% 的醫療設備召回是由軟件缺陷引起的，而且這個數字還在上升。

聯邦藥物管理局 （FDA） 監督在美國銷售的醫療器械的質量，希望發布醫療器械的公司必須獲得 FDA 510（k） 許可。在調查上市后失敗的同時，FDA 更加注重預防，并建議將靜態代碼分析作為方法的一部分。

復雜缺陷檢測的價值

現代靜態代碼分析工具使用復雜的技術來分析源代碼以檢測潛在的軟件缺陷。工具嘗試分析代碼中的所有邏輯路徑，提供比傳統測試形式更多的路徑和代碼覆蓋率。靜態分析工具不需要任何測試用例，甚至可以對代碼片段進行操作，發現潛在的程序崩潰、緩沖區溢出、內存泄漏、數據損壞等。靜態分析通常運行迅速，并且可以在相對較短的時間內報告一系列潛在的錯誤（參見圖 1）。

圖 1：靜態分析可以在軟件開發生命周期的早期發現潛在問題。

由于各種原因，靜態分析工具確實會產生一些錯誤的結果，通常稱為誤報和誤報。當靜態分析工具認為有錯誤而沒有錯誤時，就會發生誤報。誤報是應該報告錯誤但沒有報告。

大多數現代靜態分析工具必須在可接受的精度水平和可接受的運行時間之間找到盡可能多的好結果之間進行微妙的權衡。換句話說，在大量誤報中發現每個問題的嘈雜工具的價值可能有限，就像只發現一小部分問題的高度準確的工具一樣（參見圖 2）。

圖 2：靜態分析工具不會發現所有錯誤（誤報），并且會報告一些并非真正的錯誤（誤報）。使遺漏的錯誤和錯誤報告最小化的是良好的分析算法和適當的分析調整。

現代靜態分析工具已經改進了分析技術，可以以足夠的準確度生成有用的結果。大多數組織認識到靜態分析工具雖然不完善，但在大多數軟件開發過程中都提供了重要的價值。

充分利用靜態分析工具

現代靜態分析工具對大多數醫療設備制造商來說都是相對較新的。對于許多首次在其流程中實施靜態分析的組織而言，了解最佳實踐有助于在最短的時間內以最少的返工量充分利用工具。

調音

靜態分析工具提供了適用于所有類型代碼庫的通用設置，雖然它們可以立即發現好的錯誤，但只需針對代碼調整工具就可以大大改善結果（參見圖 3）。這有助于找到更多相關的錯誤并減少通過誤報進行的搜索，這會浪費時間并導致開發人員疲勞。

圖 3：幾乎每個靜態分析部署都應該從一個可靠的調優項目開始。調整會帶來更多更好的錯誤和更少的誤報。

許多靜態分析工具都有自己的源代碼解析器，它們可能無法理解或無法訪問所有代碼。將系統配置為分析所有代碼或調整系統以識別分析時無法訪問的接口——例如單獨驗證的第三方庫——確保結果是最佳和可重復的。實現 100% 的代碼覆蓋率對于堵住可能增加風險的漏洞非常重要。

調優有助于發現真正的問題。例如，告訴靜態分析工具內存分配機制是如何工作的，或者程序何時退出，以便該工具不會繼續沿著特定路徑跟蹤問題，可以幫助發現新問題并刪除錯誤問題。這可能是一個繁瑣的過程，需要特定的專業知識，但從長遠來看會有所回報。

調優通常是一個持續的過程，應定期審查，以確保一致地使用配置并跟上代碼和環境的變化。如果不進行持續調整，開發人員可能會錯過一些重要的錯誤，并且團隊將浪費時間檢查誤報。

配置檢查器

許多靜態分析工具附帶數百個檢查，涵蓋從并發性到安全性到 C 和 C++ 陷阱的一系列問題。許多人不一定適用于給定的應用程序。例如，為什么在分析 C 代碼時打開 C++ 特定檢查？確定正確的檢查器集需要一些試驗和錯誤以及專業知識，以了解什么是最劃算的。需要考慮的一些領域是：哪些類型的檢查器會導致真正的問題，哪些檢查器容易產生噪音，哪些檢查器可以配置為有用。一旦一個好的集合最終確定，將其鎖定，以便記錄并始終如一地運行。

在一個說明檢查器價值的真實示例中，客戶希望確保他們的靜態分析系統始終如一地運行，并要求在系統出現差異時立即收到警報。開發人員創建了一個測試套件，其中包含每個檢查器的測試用例。每當他們更改系統時，他們都會運行測試套件以確保每個檢查器確實按預期運行。如果結果失敗，他們知道他們有需要解決的配置問題。如果測試通過，開發人員會將結果放入他們的設計歷史文件中，以證明系統按照他們記錄的方式工作。該測試套件不僅為客戶提供了責任和保證，而且還降低了他們的維護和管理成本。

過程

一旦實現了全面覆蓋、調整了系統并定義了分析的廣度，開發人員就可以開始更有效地使用靜態分析。對于醫療設備，一個典型的目標是檢查報告的每一個問題。每個問題都可以通過多種不同的方式進行分類：

一個必須解決的問題。它將有一個適當的優先級來描述它的重要性以及在軟件開發過程中必須如何解決它。

正確標記的問題，但不太可能表現為現實世界的錯誤，通常是因為該工具做出了不正確的環境假設。這些類型的分類標志著潛在的調整機會。

被錯誤地標記為錯誤的問題，無論是誤報還是分析工具中的徹底錯誤。這些問題也預示著調整機會。

這些案例中的每一個都必須仔細審查。尤其應檢查誤報的正確性。每個問題都需要自由文檔，并且需要一個強大的數據保留政策來實現全面問責。如果在流程后期發現重大錯誤，這些分類缺陷報告可能會在審計過程中或在回顧中重新審查。組織通常會回到靜態分析缺陷以查看主要錯誤是如何通過該過程的。它可能標志著一個中斷的過程或一個調整分析以找到更好的錯誤的機會。

使用模式

靜態分析通常在開發人員沙箱構建中和/或通過中央構建運行（參見圖 4）。至少，在發布之前分析和評估結果是有意義的。但是，軟件開發組織不應該等到最后一刻才解決可能存在的大量錯誤，特別是當這些錯誤本可以作為規范流程的一部分更早地解決時。否則，團隊可能會錯過最后期限并在最壞的時間更改代碼。

圖 4：靜態分析可以根據業務需求、環境和使用的工具以多種不同方式部署。

組織通常將靜態分析自動化作為夜間構建或持續集成構建的一部分。通過這種方式，可以經常審查結果并在結果出現時加以處理。其他人則通過使開發人員能夠在沙盒環境中分析他們正在處理的代碼來更早地執行錯誤發現過程。開發人員可以立即獲得有關其代碼更改質量的反饋，然后在簽入前修復和驗證缺陷。循環時間越快，代碼庫中的代碼就越干凈。

無論在哪里運行，技術環境都需要保持一致，以確保結果相同。中央和開發人員構建需要保持一致。對分析設置的輕微更改可能會導致報告更多結果，并且組織不需要審查更多可能主要是誤報的問題的額外負擔。為開發人員創建一個高度自動化的系統將有助于確保一致性。

許多醫療設備公司不僅將源代碼檢查到其存儲庫中，還檢查其實際環境。這樣，可追溯性是可用的。靜態分析可執行文件和所有相關配置、狀態和其他相關項目也應定期檢查，以確保一致性和問責制。

處理積壓

大多數組織在開發大量代碼后開始使用靜態分析。通常，代碼越多，報告的錯誤就越多。因此，在推出靜態分析時，管理層必須預先分配時間來處理最初積壓的錯誤。

最好在開發周期中盡早進行靜態分析，以盡量減少積壓，然后創建一個流程來處理積壓，與由于日常代碼更改導致的日常流入錯誤流分開處理。審查缺陷需要時間，應該在開發人員之間適當分配，或者外包給一個單獨的團隊來挑選需要工作的缺陷。

文化

所有開發團隊在技術技能水平以及團隊中每個人如何定義質量方面都存在差異。在培訓和指導課程中，最常見的論點是：

“是的，這絕對是一個錯誤，但代碼一直在工作，所以我們不想更改它。”

“我們不應該讓這樣的代碼出現在我們的產品中。”

“這種情況在現實生活中永遠不會發生。”

“如果我們將來將產品移植到另一個平臺，這將成為一個錯誤。”

“如果你在這上面多花幾分鐘，你就會發現這顯然是一個錯誤。”

靜態分析將提供各種類型的錯誤，從必須解決的關鍵問題到警告。一些組織希望投機取巧，只為可證明的錯誤更改代碼。其他人則主動清理代碼并提高質量，甚至“修復”警告。團隊應該在處理靜態分析結果的方式上保持一致。審查結果、培訓/指導和頻繁的溝通是成功的關鍵。

如果使用得當，靜態分析已被證明在提高安全關鍵代碼的軟件質量方面非常有效。盡管不嚴格要求批準，但 FDA 承認其有效性。通過適當的規劃、專業知識和現實的投資，靜態分析應該會產生可觀的投資回報，并有助于向市場提供安全的代碼。

審核編輯：郭婷