医疗设备软件中静态和动态分析的5个技巧

---

随着网络安全日益成为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. 不要低估为预期用途验证工具的必要性和努力。

如果您需要采用静态和动态分析的帮助，请。