标签: 软件测试

引言 在功能安全的开发、测试过程中概念阶段的活动一般都是由主机厂负责，而从系统开发到单元实现则是由供应商负责，对于供应商所做的一系列测试通常称为零部件级测试。根据ISO 26262功能安全标准的划分，功能安全在零部件阶段的测试包括：软件单元测试、软件集成测试、硬件集成测试、嵌入式软件测试、软硬件集成测试。本次主要探讨软件在零部件阶段的测试。 目前功能安全零部件测试的困难 来自OEM的认可压力 ：随着主机厂对功能安全的重视和投入，主机厂越来越专业，审核要求也越来越严格，不仅要求过ISO 26262产品认证和流程认证，并且亲自下场对各输入物及详细内容进行审查。 技术储备不足： 大多数零部件供应商没有专门的功能安全团队，缺少功能安全开发能力和测试能力。 资源不足： 大部分零部件供应商缺少完整的测试工具链，各阶段测试人员配备不齐。 目前国内的功能安全标准正处于由国家推荐性标准逐渐向强制性标准过渡的时期，加之在新能源汽车出海的大趋势下，功能安全标准也正在加速与国际接轨。未来功能安全标准将成为汽车供应链厂商的准入门槛之一。那么执行满足功能安全标准要求的测试已是刻不容缓且必须解决的问题，下面将依据功能安全标准和公司在软件测试方面的积累提供满足功能安全测试的解决方案。 软件单元、集成测试 软件单元、集成的静态测试 静态测试是指在不运行软件的情况下，检查软件是否符合业内通用的编码规范/建模规范，像MISRA、MAB等，尽早发现软件的数据流/控制流问题，以及选用一些代码度量的约束，来提高软件质量。 基于MBD的静态分析 模型的静态分析主要是通过选择合适的建模标准和模型度量指标来进行验证，它的分析原理就是利用模型的一些属性和结构信息来推断代码的行为和可能存在的问题。对于模型生成的代码也需要做代码静态分析。 建模规范选择： 在进行模型静态分析时，依据使用的建模工具和要求来选择建模规则。 所有基于MBD的开发都需要选择MAB建模规范； 使用了Simulink 和 Stateflow 的模型工具需要选择MISRA SLSF； 使用了TargetLink的模型工具需要选择MISRA TL； 如果需要符合ISO 26262对于模型的标准要求，需要选择定制的功能安全规范。 工具选择： 对于模型的静态测试通常选用MES的MXAM工具，MXAM是一款高度自动化的静态分析工具，可支持多种模型类型的检查，并且提供了符合ISO 26262标准的检查规范。 手写代码的静态分析 代码的静态分析主要从编码规范的检查、程序流和数据流的分析、代码度量分析等三个维度展开。它的分析原理是对编写的代码进行逐行检查，寻找潜在的错误、漏洞和不符合规范的代码结构。 编码规范选择： 在进行代码静态分析时，通常依据使用的语言和遵循的规则来选用编码规范。 C代码：通常选用最新的MISRA编码标准MISRA C 2023； C++代码： 基于C++98/03开发选用MISRA C++ 2008； 基于C++11及C++14标准选用AUTOSAR； 基于C++17的标准选用MISRA C++ 2023； 考虑信息安全时需要遵循CERT和CWE规范。 工具选择： 对于代码的静态测试通常选用Helix QAC，它支持多种编码标准，以及拥有业界领先的编码规范覆盖度，拥有丰富的命令行，更容易实现自动化，方便与持续集成系统进行融合。 软件单元、集成的动态测试 动态测试通过实际执行代码来验证软件的行为和性能是否符合预期，动态测试可以发现静态测试中未被检测到的缺陷，确保软件安全需求及安全机制执行正确，无非预期的输出，并为软件接口的一致性和完整性提供证据。 软件单元的动态测试 测试范围： 软件单元详细设计规范、软件单元接口文档。 测试方法： 基于需求的测试 ：使用不同输入来激发软件单元代码中的各种执行路径，验证输出符合预期，从而验证软件单元设计规范和分配的软件安全要求满足设计要求。 接口测试 ：考虑软件单元输入信号的无效/有效等价类和边界值，模拟输入检测输出的正确性，从而验证软件单元与接口文档的一致性、输出的正确性。 故障注入测试 ：故障注入测试一般要修改被测的软件单元（比如改变变量的值，引入代码突变或破坏CPU寄存器的值），主要用来验证软件单元的“故障检测及处理”功能的正确性，以及软件的鲁棒性。 软件集成的动态测试 测试范围： 软件架构设计文档、细化的软硬件接口规范。 测试方法： 基于需求的测试 ：验证多个单元或组件集成后的软件功能，正向、反向的功能验证。用来验证分配给软件架构的软件要求，确保软件架构能够满足系统级别的需求 接口测试 ：考虑集成的组件、模块输入信号的有效/无效等价类和边界值，模拟输入检测输出的正确性，以检查单元和单元或组件和组件之间数据的一致性和完整性。 故障注入测试 ：注入任意的接口故障以测试安全机制（例如通过损坏软件接口），以测试与安全机制相关的软硬件接口的正确性。 资源使用测试的目的是确认在最坏的情况下，资源CPU、ROM、RAM等的使用情况。只有在目标硬件上执行软件测试或目标处理器的仿真器支持资源占用测试时，才能正确评估软件资源占用情况，一般可以在PIL和HIL测试阶段进行验证。 背靠背测试针对于基于MBD的开发，要求对模型生成的代码和模型进行等效性验证。 软件动态测试环境 模型动态测试环境MIL：TPT + MATLAB/Simulink 模型的动态测试主要是对模型的功能和接口进行测试，在TPT中选择平台和被测模型，工具可以自动获取接口信息并生成测试框架。测试框架中包含test driver和被测模型，test driver在测试执行期间与被测系统（SUT）进行交互，通过测试框架将测试用例定义的输入信号激励给到被测系统（SUT），再回采被测模型的输出结果并对其进行评估。 代码动态测试环境SIL：PC端+交叉编译链 将模型生成的代码或手写代码编译成能在目标机上运行的代码，在PC端进行验证。 模型生成的代码：TPT/FUSION + MATLAB/Simulink 用于对模型生成的代码进行背靠背测试，使用TPT的FUSION DLL调用Simulink生成的代码，对模型和模型生成的代码进行相同的输入，对比测试输出结果。 手写代码：VectorCAST + 交叉编译链 VectorCAST支持300+种交叉编译链，它可以调用交叉编译工具将源码编译成目标机上的可执行代码，可以自动解析源代码生成测试套件，测试人员能够根据测试套件使用工具提供的测试用例生成方法或手动创建测试用例，然后测试套件和测试用例会被传输到模拟器或者目标板执行测试，最终将执行的结果返回到上位机界面以供查看。 二、嵌入式软件测试 嵌入式软件测试主要是验证在目标环境执行时满足软件安全需求（SSR），以及不包含与功能安全相关的非预期功能和特性。 测试范围： 软件安全需求（SSR）。 嵌入式软件测试环境 目标板+调试器 + TPT： TPT用来集成调试器，作为上位机可以进行测试用例设计及测试执行；调试器可直接访问内存，读取或修改寄存器、变量数值，以达到对软件内部输入输出参数的修改及监控，另外调试器还可以读取MCU中资源占用情况及各个函数的运行时间。 在嵌入式软件测试阶段，使用“目标板+调试器+TPT”的测试方案可以验证： 对接收到的外部故障反馈、输入信息进行处理； 与外部模块的数据通讯校验； 可以验证芯片的内置安全机制，比例处理器、内存、看门狗、程序流的监控等； 资源使用测试 三、软硬件集成测试 软硬件集成测试旨在证明所集成控制器的软件和硬件正确的交互。 测试范围： 技术安全需求（TSR）、软硬件接口规范（HSI）。 软硬件集成测试环境 控制器 + CANoe + VT System 在软硬件集成测试阶段，“控制器 + CANoe + VT System”可以被用来测试技术安全需求（TSR）的相关要求，包括：技术安全需求的验证、安全机制的验证、内部接口验证和外部接口验证等。 另外，该测试方案还可以用来补充嵌入式软件阶段的测试，使用“目标板+调试器 + TPT”的测试方案一般不能完全覆盖软件安全需求的测试，比如一些涉及到电压采集、外部通讯的收发和外部模块对自身故障的检测处理等，可以使用HIL的方案辅助验证。 控制器 + TPT + CANoe + VT System + 调试器 该测试方案主要是在普通的HIL环境下集成了调试器，可以用来测试软硬件接口（HSI）。软硬件接口的测试主要是依据接口的描述和功能进行验证，已确认硬件可以被软件正确的控制和使用。 总结 ISO 26262标准对零部件阶段的测试从模型、代码到最后的ECU都提出了要求，每个阶段的测试重点各不相同，主要目的就是为了更快更好的查出软件问题，保证质量。北汇除了能够提供上述的测试解决方案，还可以提供对应的测试服务。如果有需要或想了解更多信息，欢迎您来联系我们。

前言 在基于模型的开发（MBD）领域，模型的质量对于最终产品的成功至关重要。通过阅读本文，您可了解如何提升模型质量，并在整个开发过程中确保模型的一致性和质量。 什么是更好的建模？ 更好的建模，也被称为是创建卓越软件模型的方法，对于开发高质量的软件至关重要。这一方法的关键方面包括通过精心的布局和设计保持一致的外观，确保对象和信息不被隐藏或遮挡，并遵循结构化的方法。例如，信号流应当遵循从左到右的方向，应避免信号线交叉，所有模块名称的位置应当固定在特定位置以保持一致性。这种全面的方法可确保模型不仅在视觉上清晰明确，更能保证模型的健壮性和无误，最终提高代码质量。 如何让模型变得更好？ 为了实现更好的模型，关注几个关键方面非常重要。以下是其中部分内容的详细解析： 1. 一致的布局和设计： 布局和设计对于模型具有良好的建模风格相当重要，有助于创建外观一致的更好的模型。例如，确定模型输入端口和输出端口的数量十分重要。随意的建模风格可能会对模型的可读性和可理解性有重大影响，这也是为什么需要通过通用风格指南来确保模型易于理解的原因，尤其是对于外部评审人员来说。 信号流：信号流应当遵循从左至右的方向，即从左侧的所有输入端口到位于右侧的所有输出端口。 信号线交叉：应避免或明确信号线交叉。 模块名称：所有模块名称的位置都应固定在一个特定的位置，比如模块下方。 图1: 从左至右的信号流 2. 可读性和可理解性： 为了确保模型易于理解，通用风格指南必不可少。模型的设计不应隐藏或遮挡相关对象和信息。例如，有些模块可能难以识别，这使得他们是否是常量或其数值的含义不够清楚。一个拥有良好设计的模型应当确保模块清晰可识别、大小合适，并对常量明确命名，以避免混淆。 魔法常量："Magic constants（魔法常量）"是来源或含义不明确的值，应当避免。这些不明确的值可导致误解和错误。风格指南建议在工作区中对常量进行命名和定义，以此来增加可理解性和可维护性，帮助区分不同的常量并明确它们在模型中的作用。 信号命名：一致的信号命名可提升数据流的可理解性，并减少维护工作量。总体上讲，它还有助于提高整个模型的可理解性。 图2: 信号流的可读性和可理解性 3. 健壮性和避免错误： 除了确保模型布局的一致性和清晰的可读性，建模风格指南同样强调模型的健壮性，并避免易出错的建模模式。这些指南旨在提升生成代码的可测试性和质量。比如，一个设计不当的模型可能导致功能问题。此处考虑一个有三个操作数的乘积运算模块；根据信号流的顺序和数据类型，此操作可能会产生不同的结果，从而潜在地导致错误。为了避免这样的问题，应当采用级联（cascade）方式进行建模操作，即根据要求明确定义操作的步骤顺序。通过将以上所有推荐考虑在内并应用风格指南，最终的模型的健壮性和可靠性更加优秀，功能性显著提升，并且降低出错的可能性。 强数据类型：信号和接口的数据类型需强类型化，因为不一致的数据类型会导致代码效率低下、精度降低、或范围违规。 如何实现更好的模型？ 在MBD流程中，提高模型质量对于交付成功的最终产品至关重要。MES Model Examiner® (MXAM)和MES Model & Refactor® (MoRe)是实现这一目标必不可少的工具。值得一提的是，现在MoRe已集成在所有MXAM用户许可证中，用户获得了使用高级建模功能的权限。 MXAM提供全面的静态分析，确保模型符合AUTOSAR和ISO 26262等标准。它评估模型结构和度量指标，并提供检查建模规范的最优方法。这有助于保持模型布局和设计的一致性，使模型在视觉上清晰易读。同时，MXAM还能自动修复违背建模规范的地方，避免”魔法常量“和确保命名惯例清晰明确，提升模型的可读性和可理解性。 MoRe与MXAM相辅相成，通过在Simulink中自动创建符合建模规范的模型布局，显著降低模型重构时间，并提升一致性。这样自动化帮助最大程度上减少手动错误，提高模型的健壮性和可靠性。通过确保以级联（cascade）方式进行建模操作，MoRe降低了功能问题出现的可能性，使模型健壮性提升，并且无错误。 MXAM和MoRe可共同简化开发流程，确保创建模型的设计一致、易于理解、健壮且不易出错。这样的集成最终会带来更高质量的软件开发和更高效的工作流程。 注：本文转载自MES模赛思，作者MES模赛思

质量闸门正如其名：它们通过在软件开发生命周期（SDLC）的各个阶段作为质量里程碑（或“闸门”），确保软件的高质量交付，防止不良代码通过。在这里，我们解释了什么是质量闸门，它们如何工作，以及如何使用静态分析来实现它们。 质量闸门是什么？ 质量闸门是在 IT 或开发项目中实施的检查点，要求在进入下一个开发阶段之前达到最低阈值。质量闸门阻止了不符合标准的代码部署，有助于确保更高质量的产品。 有了质量闸门，您可以根据您为代码设置的指标和条件强制执行质量和其他评级。这是识别瓶颈和问题区域的好方法，这样您就不会在后期遇到它们。 质量闸门在 DevOps 中用于衡量开发或质量保证过程中的质量，并识别防止后期延误和返工的漏洞。它们是在重要关头实施的项目管理措施，以便团队可以有信心地向前迈进，了解他们的代码已经满足了该阶段所需的质量标准。 为什么质量闸门在 DevOps 流水线中很重要？ 质量闸门有助于确保软件的稳定性和可靠性。质量闸门的迭代性质有助于质量保证工程师和开发人员跟踪错误并尽快解决问题，从而提高质量和投资回报率。由于团队设置了通过闸门的条件，质量闸门可以根据项目的需求随时定制。 将质量闸门构建到您的开发流水线中有许多好处： 提高整体质量和维护安全 ：策略性地放置的质量闸门作为 SDLC 中质量的基准，并通过对代码的早期和频繁指出弱点来维护安全。它们可以作为左移方法的一部分，在 SDLC 的早期检测问题，并且可以有效地高效地集成到 CI/CD 流水线中。 节省代码审查时间 ：质量闸门可以作为清单，跟踪您迄今为止实现的要求，其他开发人员在评估代码时可以快速审查。 优化软件性能 ：理想情况下，代码是简洁、可维护和可复用的。质量闸门提供了帮助分析代码性能并移除冗余或拖累系统的代码的测量方法。您可以为质量闸门设置软件指标，例如圈复杂度。 持续监控代码库 ：质量闸门持续监控源代码的质量，提供组织设定的关键指标的一致反馈。 合规性验证 ：质量闸门可以设置，以确保和验证代码符合既定的编码、安全和安全标准。 质量闸门如何工作 作为持续集成的一部分，流水线质量闸门确保项目满足预定义的标准，这意味着它可以进入开发的下一个阶段。代码在满足要求前会进入一个暂存库。 质量闸门的状态有： 通过：满足要求，可以继续生产。 警告：要求可能接近满足，或者勉强通过，因此在允许代码进入下一个阶段之前应该进行验证。 失败：未满足要求。在生产可以继续之前，应该解决标记的问题。 质量闸门的最佳实践是在开发的每个关键阶段实施它们： 计划 编码 构建 测试 版本发布 部署 关键是限制它们到这些主要阶段，因为您添加的闸门越多，测试就越复杂，这可能导致昂贵成本的延误。在 CI/CD 流水线中策略性地设置质量闸门也意味着您不必按顺序设置它们，而是可以拥有多个并行流水线和并行测试或重叠测试。 使用 Klocwork 和 Helix QAC 作为质量闸门 无论您是执行增量分析、差异分析还是集成分析，静态分析/SAST 工具都旨在优化 DevOps 和 DevSecOps 流程，并且可以作为检查代码质量和安全问题的一种质量闸门类型 —— 而不会放慢开发速度。 一些静态分析工具 —— 像 Klocwork 和 Helix QAC —— 可以在新代码进入时执行合并请求分析。质量闸门防止您的提交合并到受保护的分支，直到满足设定条件。例如，您可以使用 Klocwork 作为 GitLab 或类似 CI 环境中的质量闸门。 虽然实施质量闸门需要一些初步规划，但它可以帮助简化您的 DevOps 流程。使用正确的工具构建质量闸门可以加速您的流水线，并确保您的代码质量最高。 免费试用Klocwork/Helix QAC ⏩marketing@polelink.com

静态分析可帮助面临压力的开发团队。高质量的版本需要按时交付。需要满足编码和合规性标准。错误不是一种选择。 这就是开发团队使用静态分析工具/源代码分析工具的原因。在这里，我们将讨论静态分析和使用静态代码分析器的好处，以及静态分析的局限性。 什么是静态分析？ 静态分析是一种调试方法，通过自动检查源代码来完成，而无需执行程序。这使开发人员能够了解他们的代码库，并有助于确保其合规性和安全可靠性。 什么是静态代码分析？ 静态代码分析是指静态分析工具执行的操作，即根据一组（或多组）编码规则分析一组代码。 静态代码分析和静态分析通常与源代码分析一起互换使用。 静态代码分析解决了源代码中可能导致漏洞的弱点。当然，这也可以通过手动源代码审查来实现。但是使用自动化工具要有效得多。 静态分析通常用于遵守编码准则，例如 MISRA。 它通常用于遵守行业标准，例如 ISO 26262 。 什么时候使用静态代码分析器/源代码分析工具执行静态分析？ 静态代码分析是在软件测试开始之前的开发早期进行的。对于实践DevOps的组织来说，静态代码分析发生在“创建”阶段。 静态代码分析还通过创建自动反馈循环来支持 DevOps。开发人员会很早就知道他们的代码中是否存在任何问题，解决这些问题会更容易。 静态分析与动态分析 那么， 静态分析和动态分析有什么区别 呢？ 这两种类型的代码分析都可以检测缺陷。最大的区别在于 他们在开发生命周期中发现缺陷的地方。 静态分析在运行程序之前（例如，在编码和单元测试之间）识别缺陷。 动态代码分析在运行程序后（例如，在单元测试期间）识别缺陷。然而，一些编码错误可能不会在单元测试期间出现。因此，动态测试可能会遗漏一些静态代码分析所能发现的缺陷。 静态代码分析器/静态分析工具的局限性是什么？ 静态代码分析用于开发特定阶段的特定目的。但是静态代码分析工具存在一些局限性。 不了解开发人员的意图 静态分析工具可以在该计算中检测到可能的溢出。但它不能确定功能根本不起预期的作用！ 不可静态执行的规则 一些编码规则依赖于外部文档。或者它们可以接受主观解释。 例如： CERT-C MSC04：以可读的方式始终如一地使用注释。 可能的缺陷会导致假阳性和假阴性 在某些情况下，工具只能报告可能存在缺陷。 如果我们对 foo（） 一无所知，我们就不知道x的值是多少。 结果是不可判定的。这意味着工具可能会报告实际上不存在的缺陷（假阳性）。或者他们可能无法报告真正的缺陷（假阴性）。 静态代码分析器有哪些优势？ 静态分析工具有几个好处，尤其是当您需要遵守行业标准时。 最好的静态代码分析工具提供了速度、深度和准确性。 速度 开发人员进行手动代码审查需要时间。自动化工具要快得多。 静态代码检查解决了早期的问题，并准确地指出了代码中的错误所在。因此，您将能够更快地修复这些错误。此外，早期发现的编码错误修复成本更低。 深度 测试不能覆盖所有可能的代码执行路径。但是静态 代码分析器 可以。 在构建过程中，静态代码分析器会检查代码。您将根据所应用的规则深入分析代码中可能存在的潜在问题。 下面是 Helix QAC中深入代码分析的示例 。 Helix QAC 中的代码分析示例 准确性 手动源代码审查容易出现人为错误。自动化工具不是。 他们扫描每一行代码以识别潜在问题。这有助于您确保在测试开始之前就有最高质量的代码。毕竟，当您遵守编码标准时，质量是至关重要的。 静态分析和静态代码分析器如何帮助开发人员左移？ 静态分析是确保软件应用程序可靠性、安全性和可维护性的重要技术。它帮助开发人员及早发现和解决问题，提高代码质量，增强安全性，确保法规遵从性，并提高效率。使用静态分析工具，开发人员可以构建质量更好的软件，降低安全漏洞的风险，并最大限度地减少调试和修复问题所花费的时间和精力。 术语“左移”是指在软件开发生命周期（SDLC）的早期集成自动化软件测试和分析工具的做法。传统上，测试和分析通常是在编写代码后进行的，这导致了解决问题的被动方法。通过左移，开发人员可以在问题变成问题之前发现问题，从而减少调试和维护所需的时间和精力。这在敏捷开发中尤其重要，因为频繁的代码更改和更新可能会导致许多需要解决的问题。 静态分析的一个关键好处是，它可以节省调试和测试的时间和精力。通过在开发过程的早期识别潜在问题，您可以在任何问题变得更加难以修复（且成本高昂）之前解决它们。随着时间的推移，您还将获得更高质量的应用程序，这些应用程序更可靠、更容易维护，并防止问题在整个代码库中传播，从而使以后更难识别和修复。 使用静态分析左移的好处包括： 及早发现问题。 通过将静态分析集成到开发过程中，开发人员可以尽早发现问题，使其在成为更大的问题之前得到解决。这减少了调试和维护所需的时间和精力，并有助于确保代码的可靠性和安全性。 降低成本。 在SDLC中较早地解决问题可以降低后期修复bug和其他问题的成本。这可以节省时间和资源，并降低可能影响项目时间表的延误或其他问题的风险。 提高代码质量。 静态分析有助于识别编码标准违规和其他可能影响代码质量的问题。通过尽早解决这些问题，开发人员可以确保代码编写良好、可维护且易于调试。 增强的安全性。 静态分析工具可以识别代码中的安全漏洞，允许开发人员在代码发布到生产环境之前解决这些问题。这可以降低安全漏洞和其他可能影响应用程序安全性的问题的风险。 使用静态分析左移如何帮助提高利润 通过静态分析左移还可以提高组织的估计投资回报率 （ROI） 和成本节约。 静态分析的主要优点之一是它能够在SDLC早期发现缺陷和漏洞。从长远来看，早期检测可以节省您的公司时间和金钱。根据 美国国家标准与技术研究院（NIST） 的一项研究，修复缺陷的成本随着开发周期的进展而显着增加。在需求阶段检测到的缺陷修复成本可能约为 60 美元，而在生产中检测到的缺陷可能高达 10000 美元！通过采用静态分析，组织可以减少进入生产阶段的缺陷数量，并显著降低修复缺陷的总体成本。 除了降低修复缺陷的成本外，静态分析还可以提高代码质量，从而进一步节省成本。改进的代码质量可以减少测试、调试和维护所需的时间和精力。 IBM 的一项研究发现 ，通过提高代码质量，修复缺陷的成本最多可降低 75%。 安全性是静态分析可以帮助降低成本的另一个领域，尤其是与安全漏洞和负面品牌状态相关的成本。 IBM的一项研究发现，数据泄露的成本可能在125万至819万美元之间。静态分析可以在SDLC的早期发现安全漏洞，使组织能够在部署软件之前修复这些漏洞。通过这样做，组织可以显著降低安全漏洞的风险和成本，并保护其声誉。 除了节省成本外，静态分析还可以提高生产力。通过在开发周期的早期发现缺陷，开发人员可以减少日后调试和修复缺陷所需的时间和精力。这可以为其他开发活动（如功能开发或测试）腾出时间。通过提高生产力，组织可以减少软件开发的时间和成本，并提高更快地交付软件的能力。 在软件开发中采用左移方法可以为组织带来显着的成本节约和投资回报率。通过及早发现缺陷和漏洞，公司可以显著降低修复缺陷的成本，提高代码质量和安全性，并提高生产力。这些好处可以提高客户满意度、提高软件质量并降低开发成本。 如何选择静态代码分析器？ 在决定哪种工具适合您时，需要考虑以下几点。 程序设计语言 分析器是为许多不同的编程语言设计的。因此，选择一个支持你的语言的工具是很重要的。 标准 静态分析器的主要用途之一是符合标准。因此，如果你所在的行业需要编码标准，你需要确保你的工具支持该标准。 为什么选择 Perforce 静态代码分析器工具进行静态分析？ 30多年来，Perforce静态分析解决方案一直备受信赖，能够为各行各业的关键任务项目团队提供最准确的结果。 Helix QAC 和 Klocwork 经过认证，符合编码标准和合规要求。而且它们提供的假阳性和假阴性更少。 亲身体验 Perforce 静态代码分析工具对软件质量的影响。立即注册免费试用。

如今，新车购买者的关注点更多地集中在“数字驾驶舱生态系统体验”上，而不是传统功能，如马力和燃油经济性。汽车行业已将提供这种体验作为优先事项，包括全连接的车载信息娱乐 （IVI） 系统，包括触摸屏显示器、语音命令以及集成的信息和娱乐功能。 什么是车载信息娱乐系统？ 越来越多的终端消费者希望能够完全连接到他们的“数字生态系统”体验。“智能座舱”是车载信息娱乐系统的核心，其正在成为原始设备制造商及其汽车品牌的关键差异化优势。 车载信息娱乐（IVI）是一种车辆系统的组合，用于向车辆乘客提供音频/视频接口和控制元件——触摸屏显示器、按钮面板、语音命令等。 以下是构成“智能驾驶舱”的组件或模块的快照： 用户界面： 驾驶员和乘客通过触摸或旋钮和转盘在屏幕上看到的内容和互动的内容。 主机： 包括显示器、外壳、电路板、CD/DVD 播放器、收音机和多个处理器（统称为车辆的主机）。它也是车辆所有物理输入的接口，例如音响系统和/或外部摄像头。 操作系统 （OS）： 作为信息娱乐系统的核心，操作系统控制对主机中的处理器、内存、存储和显示器的访问。 应用程序框架模块 ：管理从 Spotify 应用程序到导航和与系统交互的所有内容，例如文本转语音和语音命令。它控制所有应用程序功能以及哪些应用程序可以出现在主机中。 移动集成： 使车辆能够连接各种智能手机和设备。支持 Wi-Fi、蓝牙和即插即用程序，例如 Google Play 的 Mirror Link、Apple CarPlay 和 Android Auto，可将手机媒体和应用程序的修改版本导入屏幕。 汽车平台： 应用程序框架和操作系统之间的软件桥梁，支持多媒体、视频、导航、音频、广播、声学、软件更新、云服务等。 根据行业研究公司Frost&Sullivan最近的一份分析报告，到2025年，“车联网”将构成全球汽车市场近86%的份额。同年，IVI市场预计将达到427亿美元。 但是，IVI系统本身以及第三方应用程序也为网络犯罪分子创造了许多漏洞威胁点。汽车行业IVI系统的原始设备制造商和一级供应商必须努力确保这些系统中的嵌入式代码符合安全和安保关键标准。这样做有助于避免召回成本和对商业声誉的影响。 网络攻击给车载信息娱乐系统带来严重风险 车载信息娱乐系统在短短几年内取得了长足的发展，随着AI、ML和AR等新兴技术进入汽车领域，成为这些嵌入式“数字驾驶舱”系统的标准集成，预计该系统将进一步快速发展。虽然IVI系统目前用于提供信息和娱乐，但它们很快就会作为车辆内所有功能的主要通信部件发挥更大的作用。用户可以通过 AR 和 3D 导航和警报、交互式交通和危险警告以及与道路上其他车辆的通信方式看到更多信息。 随着IVI系统每年增加更多的功能和连接性，管理无线软件更新的开发人员必须考虑到车载网络的无数攻击面和潜在漏洞。 由于 IVI 系统连接到互联网并使用 Android、RTOS、Linux、QNX 和 Windows Embedded Automotive 以及 USB 连接、蓝牙和 Wi-Fi 运行操作系统，因此黑客可以通过多种方式找到这些入口点并利用代码中的漏洞，这可能会影响用户隐私和安全。 高达 90% 的软件安全问题是由编码错误引起的。这就是为什么确保不会发生故障的情况很重要的原因。然而，代码质量仍然没有达到许多IVI系统应有的水平，导致新车出现故障和繁琐的IVI。希望提高代码质量和车载信息娱乐网络安全的开发人员应使用编码标准和静态分析工具，作为网络安全和质量优先最佳实践的一部分。 车载信息娱乐系统编码标准的重要性 可以说，联网车辆是通过其IVI系统连接到互联网的四轮计算机。由于IVI系统是车内网络的一部分，它可能为黑客创造许多易受攻击的威胁点，他们可能能够控制驾驶员的智能手机并访问个人数据，操纵车辆安全关键系统功能，或制造系统更新程序。因此，IVI 系统开发实践必须遵守编码标准和指南。 最近还有两项有望使IVI系统受益的举措是ISO/SAE 21434标准和联合国欧洲经济委员会（UNECE） WP.29法规 。这些标准相辅相成，为汽车行业确保新一代互联汽车的安全做好准备。 ISO /SAE 21434 标准 建立在其前身 ISO 26262 的基础上 ，该标准不包括软件开发或子系统。ISO/SAE 21434 侧重于汽车电子设计和开发中固有的网络安全风险。汽车软件安全标准提供了一个结构化的流程，以确保在汽车产品的整个生命周期内将网络安全考虑因素纳入其中。 与 ISO/SAE 21434 不同，WP.29 法规要求 OEM 负责管理整个供应链的网络安全风险。 IVI 网络安全漏洞如何影响 OEM 原始设备制造商及其一级供应商需要采取措施避免其IVI嵌入式软件漏洞的负面影响，因为攻击可能会威胁到驾驶员及其乘客的隐私和安全。网络安全事件可能代价高昂且耗时，并可能导致车辆召回，最终影响利润、声誉损失和组织生产力。 IVI系统中的软件故障经常导致召回。MSN.com最近对最不可靠的家用汽车进行的一项调查显示，最新一代的汽车位居榜首，57% 的车辆出现故障，其中33%的汽车受到IVI问题的影响。 由于安全和安保问题，信息娱乐系统中的软件故障可能会导致召回。例如，故障可能允许驾驶员在驾驶时浏览互联网和看电视。软件故障也可能导致汽车屏幕在寒冷天气下熄灭。 即使故障不是很明显，恶意行为者也可能利用软件中的这种类型的漏洞，关闭影响安全和安保的关键功能。 确保IVI系统中的代码符合必要的标准和合规性要求，有助于避免召回成本以及对商业声誉和盈利能力的影响。 为什么SAST对于车载信息娱乐系统软件代码至关重要 静态应用程序安全测试 （ SAST ） 软件测试方法检查和分析应用程序源代码、字节码和二进制文件的编码和设计条件，以发现 IVI 系统软件中的安全漏洞。SAST背后的工作机制是一个静态分析工具，用于检查设计和编码缺陷。 Klocwork 是 企业 DevOps 和 DevSecOps 的理想选择 ， 是行业领先的 静态分析和 SAST 工具，适用于 C、C++、C#、Java、JavaScript、Python 和 Kotlin 设计的源代码。此外，10 家顶级汽车零部件制造商中有 9 家依靠 Perforce 静态分析工具来帮助确保其汽车软件的安全性和合规性。