在寻求无错误软件的过程中增强静态代码分析

嵌入式软件无处不在，并在各种设备中提供关键功能，从最新的智能手机和游戏小工具到救生医疗设备。创建嵌入式软件的工程组织明白，确保代码质量是一个关键的差异化因素和竞争优势。与其他测试和验证方法一起，许多公司利用代码测试和现代静态分析的优势在开发早期识别缺陷。在过去几年中，嵌入式市场研究公司 VDC Research 的各种报告表明，采用静态分析作为关键测试自动化工具的公司增长强劲。现代静态分析可以说是应对确保复杂软件质量挑战的最具成本效益、自动化和可重复的方法。

推动这种增长的一个重要原因是，用于识别关键缺陷（如内存损坏、资源泄漏、空指针取消引用和无效内存访问）的技术已经成熟到可以发现大量难以发现的遍历函数的缺陷的程度现在可以准确地完成文件边界，从而导致非常少的误报。然而，真正的创新在于为每个已识别的缺陷提供上下文信息。开发人员需要知道缺陷存在的原因、会产生什么影响以及需要修复的地方。

需要修复的问题的答案并不像知道文件名和行号那么简单。用于版本控制、代码重用和代码组件重用以提高开发效率的代码分支和合并允许缺陷进入多个版本和产品。

考虑一个软件团队的情况，该团队拥有多个产品的不同版本的分支。由于代码复制，其中一个分支中的错误可能存在于一个或多个其他分支中。在另一种情况下，考虑创建框架以支持智能手机应用程序的团队。因为他们可能将框架移植到 Windows、Android 或 iPhone 等各种平台上，所以静态分析结果清楚地表明已识别的缺陷是仅存在于一个地方还是存在于多个平台上，这一点至关重要。同样，当软件是通过从多个来源聚合创建的时，如果在各种产品中使用特定组件，那将是一场噩梦，因为一个第三方组件的缺陷最终可能会影响包含它的所有不同产品。

不同版本操作系统的多个分支

想象一个负责为移动智能手机创建新操作系统 （OS） 的软件开发团队。由于必须支持多个手机供应商 （OEM），因此源代码控制管理系统中的每个供应商都需要一个开发分支。此外，每个供应商通常都有针对不同版本和产品代的多个分支。画面开始变得非常复杂。

对代码的每个分支执行的静态分析会生成一个缺陷列表。但是，根据引入缺陷的时间，它可能存在于所有版本或子集中。当孤立地查看单个分支中的单个缺陷时，开发人员面临的挑战是他们无法在不知道缺陷存在于何处的情况下评估缺陷的严重性。不限于单个版本或一个 OEM 客户端的缺陷将是严重的，修复它需要优先于其他任何事情。此外，编写代码来修复缺陷的开发人员需要准确地知道需要签入源代码控制管理系统中的哪些分支。

图 1：由于代码分支和合并导致的重复缺陷。

适用于多个平台的单一框架

在分支的另一面，通常需要编写设计为在多个平台上运行的代码。诸如移动应用程序框架之类的软件组件通常被构建为在各种类型的移动电话平台上运行。对于嵌入式设备，一个常见的要求是构建相同代码库的 32 位和 64 位版本。我们举一个简单的例子：

gcc --m32 -c foo.c

// 32 位编译。包含空指针取消引用缺陷。

gcc -c foo.c

// 64 位编译。包含相同的空指针取消引用缺陷。

在 32 位和 64 位二进制文件中触发的foo.c中的缺陷将被检测并报告为单个缺陷。但是，由于源代码相同，因此复杂的分析不会将其报告为重复缺陷。在失去开发人员对静态分析解决方案的信任方面，重复与误报一样有害。

共享通用代码组件

在最后一个示例中，考虑一个为一系列网络交换机开发平台软件的团队。由于平台软件提供的功能必须在所有产品中实现，因此该代码组件将被共享（参见图 2）。对于在这个团队工作的开发人员来说，静态分析报告的缺陷严重性的最佳评估不仅是它对一个交换机产品的影响，还包括使用该平台软件组件的所有产品的信息。

图 2：单个软件组件在多个产品中重复使用。

产品通常是通过组合许多这样的共享组件来创建的。每个组件不仅是一个项目本身，而且是使用它的各种其他项目的一部分。分析结果需要确定此共享组件中的缺陷对使用它的各个项目有影响。

消除代码测试中的猜测

采用静态分析等现代开发人员测试方法是嵌入式软件行业的一个积极趋势。该技术已经成熟到可以成为软件工程师武器库中强大武器的程度。无需创建复杂的测试用例和测试基础设施，静态分析就可以在编写和编译代码时自动发现关键缺陷。但是，要使静态分析成为开发人员最有价值的工具，分析必须提供诸如“此缺陷的影响是什么？”之类的问题的答案。和“我需要在哪里检查修复？” 帮助确定修复已识别缺陷的优先级，并消除猜测以确保软件尽可能无错误。

审核编辑：郭婷