隨著網(wǎng)絡(luò)安全日益成為FDA的重點(diǎn)，針對(duì)靜態(tài)和動(dòng)態(tài)代碼分析的特定要求，工程師必須使這些實(shí)踐自動(dòng)化并將其集成到現(xiàn)有的開發(fā)工作流程中。在此文中，Auriga的Andrey Shastin分享了一些多年交付經(jīng)驗(yàn)沉淀下來的技巧。

在Auriga，我們已經(jīng)為醫(yī)療設(shè)備提供了近20年的許多軟件開發(fā)項(xiàng)目，從相對(duì)簡(jiǎn)單的血糖儀到更復(fù)雜的系統(tǒng)，例如輸液泵、病人監(jiān)護(hù)儀和肺通氣裝置。實(shí)施靜態(tài)和動(dòng)態(tài)代碼分析實(shí)踐并將其部署在這些項(xiàng)目上是我們流程的組成部分，在這里，我將分享一些實(shí)踐經(jīng)驗(yàn)和挑戰(zhàn)中的一些技巧。

靜態(tài)代碼分析

靜態(tài)分析是一種自動(dòng)檢查是否符合眾所周知的編碼準(zhǔn)則（即MISRA，CERT，AUTOSAR，JSF）并檢測(cè)潛在錯(cuò)誤（如空指針解引用、被零除和緩沖區(qū)溢出）的實(shí)踐?，F(xiàn)代靜態(tài)分析工具還通過將手動(dòng)工作量減少了至少30％來補(bǔ)充了傳統(tǒng)的代碼檢查實(shí)踐。

在大多數(shù)情況下，針對(duì)您當(dāng)前代碼進(jìn)行的靜態(tài)分析工具的首次運(yùn)行將顯示成千上萬個(gè)錯(cuò)誤（我們?cè)诘谝淮芜\(yùn)行中甚至遇到了20000+），當(dāng)然這可能令人難以置信，因?yàn)檫@看起來需要多年才能修復(fù)所有這些錯(cuò)誤。不過，這里有一些專家的技巧來解決這個(gè)問題。

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

有紀(jì)律的開發(fā)團(tuán)隊(duì)通常使用–Wall和–Werror（在GCC中）或/Wall/WX（在Visual Studio中）進(jìn)行編譯，或在其他編譯器中使用類似的選項(xiàng)。修復(fù)編譯器警告是為靜態(tài)分析執(zhí)行做準(zhǔn)備的簡(jiǎn)便且廉價(jià)的方法。我們已經(jīng)看到，以“偏執(zhí)”模式查看編譯器的輸出可以減少靜態(tài)分析違例的總體數(shù)量。

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

在使編譯器干dry之后，請(qǐng)使用靜態(tài)分析工具，該工具應(yīng)更深入地研究代碼并為您提供更多提示。

技巧2：在流程的早期階段采用靜態(tài)分析

如果您當(dāng)前正在開發(fā)醫(yī)療設(shè)備軟件，那么您應(yīng)該準(zhǔn)備解決自動(dòng)靜態(tài)代碼分析實(shí)踐的問題。幾乎可以肯定，靜態(tài)分析將是內(nèi)部/外部審核甚至是上市前提交過程中討論的主題。

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

以下是靜態(tài)分析報(bào)告中的一些示例，這些示例可以通過簡(jiǎn)單的腳本或訓(xùn)練有素的實(shí)習(xí)生輕松解決：

1）調(diào)用析構(gòu)函數(shù)中的clear函數(shù)：

a.析構(gòu)函數(shù)“?CTitle”不應(yīng)調(diào)用不在try上下文中的函數(shù)“clear_”

b.析構(gòu)函數(shù)“?THelper”不應(yīng)調(diào)用不在try上下文中的函數(shù)“removeModule”

2）檢查NULL：

a.“pMP”可能為空

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

3）可能在錯(cuò)誤的部分聲明：

a.數(shù)據(jù)成員“D_FILE_1”被聲明為“public”

4）非恒定參數(shù)：

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

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

動(dòng)態(tài)分析

靜態(tài)分析將源代碼解釋為文本，并基于解析器輸出得出所有結(jié)論，而無需執(zhí)行單個(gè)指令，而動(dòng)態(tài)分析則為代碼提供了不同的視角。它檢查正在運(yùn)行的代碼、顯示代碼覆蓋率、單元測(cè)試的充分性和質(zhì)量、內(nèi)存泄漏以及其他潛在的弱點(diǎn)問題。

技巧3：在您的運(yùn)行時(shí)環(huán)境中保持靈活性

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

因此，當(dāng)設(shè)備上的內(nèi)存量太少而無法運(yùn)行測(cè)試并收集代碼覆蓋率時(shí)，目標(biāo)平臺(tái)可能不適合收集單元和集成測(cè)試的代碼覆蓋率。

如果不支持您的主要目標(biāo)平臺(tái)，請(qǐng)搜索有效的替代方案。動(dòng)態(tài)分析工具可能會(huì)支持一個(gè)具有更多接口和內(nèi)存的姊妹平臺(tái)，因此您可以將其用于單元測(cè)試和某些集成測(cè)試。另一種選擇是使用運(yùn)行ARM快速模型和QEMU的硬件模擬器。

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

有很多編譯器、構(gòu)建工具、框架和方法來運(yùn)行它們。動(dòng)態(tài)分析工具支持一些常見的構(gòu)建技術(shù)，并在內(nèi)部假定開發(fā)人員如何應(yīng)用它們。因此，即使代碼是可移植的，根據(jù)項(xiàng)目的構(gòu)建系統(tǒng)的工作方式，項(xiàng)目團(tuán)隊(duì)很可能也需要額外的時(shí)間來調(diào)整動(dòng)態(tài)分析工具的設(shè)置。

強(qiáng)烈建議預(yù)先估計(jì)所有工作，以便從長(zhǎng)遠(yuǎn)角度為將來的開發(fā)和支持選擇最佳方法。

技巧4：不要過分依賴自動(dòng)生成的測(cè)試用例

現(xiàn)代動(dòng)態(tài)分析工具會(huì)自動(dòng)生成多套單元測(cè)試，以增加代碼覆蓋率。但是工具只是工具——它們與打算如何使用生產(chǎn)代碼的各種情況無關(guān)，特別是當(dāng)您嘗試增加代碼覆蓋率并跨越純單元測(cè)試和集成測(cè)試之間的邊界時(shí)。您仍然必須手動(dòng)更新生成的單元測(cè)試，甚至編寫新的單元測(cè)試，因?yàn)橹挥心来a在正面和負(fù)面測(cè)試結(jié)果中打算做什么。

根據(jù)我們的經(jīng)驗(yàn)，關(guān)鍵區(qū)域中的一組選定文件可以具有自動(dòng)生成的單元測(cè)試，范圍涵蓋每個(gè)文件的40％到100％。但平均而言，對(duì)于整個(gè)項(xiàng)目，數(shù)字可能從25％到60％不等。

此外，僅使用源代碼作為輸入的自動(dòng)生成的單元測(cè)試通?？梢栽阱e(cuò)誤代碼上完美運(yùn)行。自動(dòng)生成應(yīng)該用作啟動(dòng)單元測(cè)試過程的好方法。手動(dòng)創(chuàng)建測(cè)試用例的過程提高了代碼的質(zhì)量，因?yàn)樗鼤?huì)強(qiáng)制進(jìn)行額外的代碼審查并在設(shè)計(jì)上提供不同的優(yōu)勢(shì)。

技巧5：不要低估工具鑒定/驗(yàn)證的工作量

FDA要求在正式開發(fā)過程中使用的任何工具均應(yīng)對(duì)預(yù)期用途有效，以確保其執(zhí)行預(yù)期的操作并產(chǎn)生正確的結(jié)果。通常，這是一種稱為IUV（預(yù)期使用驗(yàn)證）的特殊測(cè)試協(xié)議。

業(yè)界領(lǐng)先的靜態(tài)和動(dòng)態(tài)分析工具供應(yīng)商可以幫助您生成必要的過程和文檔，這對(duì)最大程度地減少您的工作量非常有幫助。Parasoft的價(jià)值特別大，因?yàn)樗梢允沽鞒痰拇蟛糠肿詣?dòng)化。與任何其他通用軟件包一樣，您可能需要保留一些精力來審閱和調(diào)整文檔，以使其與自己的QMS程序同步。例如，Parasoft的工具資格認(rèn)證軟件提供了一組在您的環(huán)境中執(zhí)行的測(cè)試用例，以驗(yàn)證靜態(tài)和動(dòng)態(tài)分析功能。

綜上所述

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

如果您需要采用靜態(tài)和動(dòng)態(tài)分析的幫助，請(qǐng)。