隨著網絡安全日益成為FDA的重點，針對靜態和動態代碼分析的特定要求，工程師必須使這些實踐自動化并將其集成到現有的開發工作流程中。在此文中，Auriga的Andrey Shastin分享了一些多年交付經驗沉淀下來的技巧。

在Auriga，我們已經為醫療設備提供了近20年的許多軟件開發項目，從相對簡單的血糖儀到更復雜的系統，例如輸液泵、病人監護儀和肺通氣裝置。實施靜態和動態代碼分析實踐并將其部署在這些項目上是我們流程的組成部分，在這里，我將分享一些實踐經驗和挑戰中的一些技巧。

靜態代碼分析

靜態分析是一種自動檢查是否符合眾所周知的編碼準則（即MISRA，CERT，AUTOSAR，JSF）并檢測潛在錯誤（如空指針解引用、被零除和緩沖區溢出）的實踐。現代靜態分析工具還通過將手動工作量減少了至少30％來補充了傳統的代碼檢查實踐。

在大多數情況下，針對您當前代碼進行的靜態分析工具的首次運行將顯示成千上萬個錯誤（我們在第一次運行中甚至遇到了20000+），當然這可能令人難以置信，因為這看起來需要多年才能修復所有這些錯誤。不過，這里有一些專家的技巧來解決這個問題。

技巧1：編譯器是您的朋友

有紀律的開發團隊通常使用–Wall和–Werror（在GCC中）或/Wall/WX（在Visual Studio中）進行編譯，或在其他編譯器中使用類似的選項。修復編譯器警告是為靜態分析執行做準備的簡便且廉價的方法。我們已經看到，以“偏執”模式查看編譯器的輸出可以減少靜態分析違例的總體數量。

修復所有編譯器警告是一件好事，但在許多項目中，僅出于合規性原因，僅使用編譯器是不夠的，甚至是可以接受的選項。

在使編譯器干dry之后，請使用靜態分析工具，該工具應更深入地研究代碼并為您提供更多提示。

技巧2：在流程的早期階段采用靜態分析

如果您當前正在開發醫療設備軟件，那么您應該準備解決自動靜態代碼分析實踐的問題。幾乎可以肯定，靜態分析將是內部/外部審核甚至是上市前提交過程中討論的主題。

關鍵是要以這樣一種方式來部署工具，即在專注于提高質量的同時，開發不會失去速度，并且不會處理工具的特質和噪音。這是一種平衡的行為，需要Auriga工程師多年來積累的實踐和專業知識，但是我們發現，在發現所報告錯誤的根本原因的同時，您可能會發現其中許多易于修復 。

以下是靜態分析報告中的一些示例，這些示例可以通過簡單的腳本或訓練有素的實習生輕松解決：

1）調用析構函數中的clear函數：

a.析構函數“?CTitle”不應調用不在try上下文中的函數“clear_”

b.析構函數“?THelper”不應調用不在try上下文中的函數“removeModule”

2）檢查NULL：

a.“pMP”可能為空

b.“((NPage*)this)->pSysCfg_”可能為空

3）可能在錯誤的部分聲明：

a.數據成員“D_FILE_1”被聲明為“public”

4）非恒定參數：

a.字符串文字“MCollection”作為非常量對象的指針傳遞給函數“FixedBlockHeap”

在停機期間，您可以擱置許多對現有代碼的違規并進行處理。但是，在開發代碼時切勿引入新的違規行為（技術部門），這一點很重要。例如，Parasoft C/C++test具有使工程師能夠過濾噪聲并專注于修復最近最關鍵的靜態分析違規的功能。

動態分析

靜態分析將源代碼解釋為文本，并基于解析器輸出得出所有結論，而無需執行單個指令，而動態分析則為代碼提供了不同的視角。它檢查正在運行的代碼、顯示代碼覆蓋率、單元測試的充分性和質量、內存泄漏以及其他潛在的弱點問題。

技巧3：在您的運行時環境中保持靈活性

術語“嵌入式”涵蓋許多設備：從具有千字節RAM的8位MCU和閃存，到具有千兆字節RAM和高速SSD的64位多核CPU。如果設備的日常運行需要最少的內存和處理能力，那么制造商可能會選擇僅針對其需求的硬件，以解決尺寸、重量或成本方面的限制。盡管它們通常會留有一定的軟件更新和維護能力，但在使用動態分析工具對軟件進行檢測時可能仍然不足，因為該過程將需要大量的RAM（與正常操作模式相比）和存儲空間，收集測試和代碼覆蓋率結果。

因此，當設備上的內存量太少而無法運行測試并收集代碼覆蓋率時，目標平臺可能不適合收集單元和集成測試的代碼覆蓋率。

如果不支持您的主要目標平臺，請搜索有效的替代方案。動態分析工具可能會支持一個具有更多接口和內存的姊妹平臺，因此您可以將其用于單元測試和某些集成測試。另一種選擇是使用運行ARM快速模型和QEMU的硬件模擬器。

盡管最希望在目標平臺上運行測試，但許多團隊選擇退出在開發人員的工作站（例如Linux，Mac，Windows）上執行單元和某些應用程序集成測試，以受益于更快的開發周期和大量可用工具用于通用開發平臺。在這種情況下，您將需要移植嵌入式代碼以使用主機編譯器進行編譯，這可能會帶來一些挑戰。

有很多編譯器、構建工具、框架和方法來運行它們。動態分析工具支持一些常見的構建技術，并在內部假定開發人員如何應用它們。因此，即使代碼是可移植的，根據項目的構建系統的工作方式，項目團隊很可能也需要額外的時間來調整動態分析工具的設置。

強烈建議預先估計所有工作，以便從長遠角度為將來的開發和支持選擇最佳方法。

技巧4：不要過分依賴自動生成的測試用例

現代動態分析工具會自動生成多套單元測試，以增加代碼覆蓋率。但是工具只是工具——它們與打算如何使用生產代碼的各種情況無關，特別是當您嘗試增加代碼覆蓋率并跨越純單元測試和集成測試之間的邊界時。您仍然必須手動更新生成的單元測試，甚至編寫新的單元測試，因為只有您知道代碼在正面和負面測試結果中打算做什么。

根據我們的經驗，關鍵區域中的一組選定文件可以具有自動生成的單元測試，范圍涵蓋每個文件的40％到100％。但平均而言，對于整個項目，數字可能從25％到60％不等。

此外，僅使用源代碼作為輸入的自動生成的單元測試通常可以在錯誤代碼上完美運行。自動生成應該用作啟動單元測試過程的好方法。手動創建測試用例的過程提高了代碼的質量，因為它會強制進行額外的代碼審查并在設計上提供不同的優勢。

技巧5：不要低估工具鑒定/驗證的工作量

FDA要求在正式開發過程中使用的任何工具均應對預期用途有效，以確保其執行預期的操作并產生正確的結果。通常，這是一種稱為IUV（預期使用驗證）的特殊測試協議。

業界領先的靜態和動態分析工具供應商可以幫助您生成必要的過程和文檔，這對最大程度地減少您的工作量非常有幫助。Parasoft的價值特別大，因為它可以使流程的大部分自動化。與任何其他通用軟件包一樣，您可能需要保留一些精力來審閱和調整文檔，以使其與自己的QMS程序同步。例如，Parasoft的工具資格認證軟件提供了一組在您的環境中執行的測試用例，以驗證靜態和動態分析功能。

綜上所述

1. 將編譯器警告視為錯誤。稍后，對于同一編譯器的較新版本，警告可能會變成錯誤。警告通常意味著編譯器會隱式執行某些操作。
2. 在項目早期運行靜態分析工具，并修復出現的問題。
3. 保持代碼可移植。即使您不打算將產品移植到另一個平臺，將來也可以選擇這樣做。另一方面，這也將有助于保持代碼的清潔、可維護和可讀性，這對于回顧和進一步支持始終很有幫助。
4. 不要過度依賴自動生成的測試用例來提高代碼質量。
5. 不要低估為預期用途驗證工具的必要性和努力。

如果您需要采用靜態和動態分析的幫助，請。