基于功能安全的汽车嵌入式软件单元验证技术研究

1研究背景随着汽车使用场景的增加和辅助驾驶功能的扩展，汽车嵌入式软件的集成度和复杂性也随之增加，愈加庞大的软件系统意味着存在更多难以发现的安全风险。传统的软件开发和测试流程难以满足现阶段对汽车软件安全性的要求。ISO26262《道路车辆功能安全》国际标准是为满足道路车辆上特定电子电器系统的需求而编写，适用于道路车辆上特定的由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动，目前已成为非常前沿的汽车安全相关标准。其主要基于汽车电子行业公认的“V模型”，强调通过各开发阶段的测试和验证来降低风险。软件单元验证作为软件测试的第一道关卡，能够尽早发现代码漏洞、降低开发成本、缩短开发周期，能有效提高软件质量，是软件测试中最重要的部分。基于功能安全的软件单元验证是为了证明软件最小单元满足软件设计，以及安全措施得到实施，并满足根据所需ASIL等级分配的软件要求而开展的活动，兼顾软件安全要求和非安全要求。为了保证验证的充分性和完整性，功能安全要求通过评审、分析和测试等组合方法对软件进行单元验证。本文基于ISO26262《道路车辆功能安全》国际标准第6部分第9章节“Softwareunitverification”中的要求，对符合功能安全的软件单元验证技术进行详细研究，对汽车软件开发和测试从业人员具有一定的参考意义。2软件单元验证流程软件单元验证流程如图1所示。按照静态测试在先、动态测试在后的准则进行，每一步都需要有上一步的输出资料作为输入，且上一步未评审通过不可进入下一步，保证验证过程可靠且闭环。开始前，需要有《软件单元设计规范》《软件接口规范》《软件开发环境文档》等文档作为验证过程的需求输入。需要注意的是，功能安全侧重于对活动过程的检查和确认，因此对重要步骤的审查是非常有必要的。图1软件单元验证流程图2.1编制和评审软件单元测试计划测试负责人根据各模块ASIL等级要求对单元测试的各项工作内容编制单元测试计划，规定时间进度要求，确认测试的范围、方法、测试用例设计方法、覆盖率要求等，输出《软件单元测试计划》。测试小组内部对《软件单元测试计划》内的各项工作安排进行评审，评审通过则开始静态测试，若评审不通过，则修改计划再次评审直到通过。2.2执行和评审静态测试根据要求对模型或代码执行静态测试，确认对建模规范、编码规范、软件质量度量以及相关文档的符合性，记录测试执行结果并输出《软件单元验证静态代码分析报告》。对于需要修改的缺陷执行缺陷修正，对于不需要修改的缺陷进行分析说明。根据测试结果评审静态测试是否通过，评审通过则进行动态测试，若评审不通过，通知开发组修改代码直到再次评审通过。2.3编制和评审软件单元测试说明测试工程师依据《软件详细设计说明》《软件单元验证测试策略》和ASIL等级要求编写用例的ID、名称、设计方法、预置条件、执行步骤、预期结果、判断准则，输出《软件单元测试说明》，根据追溯一致性要求需要建立软件详细设计与软件单元测试用例的追溯关系。评审小组评审通过，则开始执行单元测试，若评审不通过，测试组修改测试用例直至再次评审通过。2.4执行单元测试测试工程师搭建测试环境并执行软件单元测试，测试覆盖率需达到要求。若覆盖率未达标，测试发现缺陷，需按照《问题解决管理过程规范》流程执行分析、处理。对测试用例未通过的情形，测试工程师根据策略执行回归测试并记录结果。对不能通过测试验证的非功能需求，进行评审或采用其他方法验证。依据测试记录和结果输出《软件单元测试记录》。2.5编制和评审软件单元测试报告测试工程师依据软件单元测试记录和结果，编制《软件单元测试报告》。报告内容主要包括：测试目标、测试结果、结果分析、测试结论和意见。评审小组评审《软件单元测试报告》，评审内容主要包括：从技术角度检查静态验证、测试用例的执行情况；确认测试执行符合策略要求；确保建立追溯关系的一致性。评审通过则结束软件单元验证活动。3软件单元验证方法表1列出了目前常用的软件单元验证方法，大致可分为评审、分析、测试3大类，分别对应1a-1c、1d-1i和1j-1n。标准要求通过这些方法的适当组合，对软件单元设计和已实现的软件单元进行验证，来证明软件的功能和特性满足软件安全要求。不同ASIL等级对不同方法的推荐度不一样，其中“++”为特别推荐，“+”为推荐，“o”为不推荐。为满足单元验证的完整性和充分性，通常会在不同大类中选择所有无重复项目的“++”项进行组合测试。注意，如果代码保留了模型特性，可以通过在模型层面执行验证来替代在源码层面执行验证，但需要证明该模型具有足够的置信度。表1软件单元验证方法以ASILB等级为例，可选择检查+静态代码分析+基于需求的测试+接口测试方法进行组合验证。3.1检查对开发文档、代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性等进行检查。将所有与文档和代码相关的检查项列举在《软件单元验证检查审查单》中，根据检查结果给予“通过”“建议”和“不通过”，审查通过率高于90%判定为通过。3.2静态代码分析在不运行应用程序的情况下,对软件的源代码的语义、结构和行为进行分析,由此找出程序中的不规范、不合理或者可能造成程序运行异常的代码。静态代码分析可借助软件对源代码进行静态分析。图2为HelixQAC软件对某代码进行静态分析的结果示意图，编码规范遵守MISRAC++。图2HelixQAC静态分析结果3.3基于需求的测试基于需求的测试是根据单元设计文档提取明确要求进行的测试活动。通过分析各接口具有的意义、值的范围及算法，确认需求的输入值和预期值，对单元代码进行测试，从而实现基于设计需求的单元测试。3.4接口测试根据所测单元代码被调用的输入参数与该单元的形式参数在个数、属性、量纲、顺序上是否一致等方面设计测试用例进行测试。基于需求的测试和接口测试范围存在重叠，通常以基于需求的测试为主，接口测试进行查缺补漏。此过程需要根据软件详细设计文档、安全需求文档和接口文档进行测试用例设计，保证测试用例对功能、安全需求和接口的100%覆盖。图3为VectorCAST软件对某源代码进行单元测试的结果示意图，测试结果和预期结果一致，测试通过。图3VectorCAST单元测试结果4软件单元测试用例得出方法标准要求使用表2列出的软件单元测试用例得出方法。表2软件单元测试用例得出方法1）需求分析法。根据《软件详细设计文档》中的功能描述来设计测试用例，每一个测试用例用来检验一个或者多个测试需求。每个测试用例需要与测试需求编号一一对应形成追溯关系，需求覆盖率需要达到100%。所有功能安全等级均要求使用此方法。2）等价类划分法。根据被测函数的输入、输出范围划分有效等价类和无效等价类。针对每一个等价类设计至少一个有效等价类和一个无效等价类测试用例来确保被测程序单元的处理是完整的。此方法适用于具有取值范围或值为个数的函数输入单元。3）边界值分析法。边界值分析法使用与等价类划分法相同的划分，但是边界值分析假定错误更多地存在于两个划分的边界上，需相应地为边界上及两侧的情况设计测试用例。此方法适用于对接口、接近边界的值与边界交叉的值较为敏感的函数单元。4）错误推测法。根据以往测试经验和其他一些测试技术，猜测错误的类型及在特定的软件中错误发生的位置，并设计测试用例去发现它们。此方法适用于存在易错代码的函数单元，通常基于经验学习和专家判断中收集的数据。5软件单元层面结构覆盖率度量对单元测试完整性的另一个重要评估标准是软件单元层面的结构覆盖率要求，结构覆盖率分析可以发现测试用例的不足、需求的缺陷、无效代码或非预期功能，因此标准要求按照表3列出的度量对结构覆盖率进行测试。表3软件单元层面结构覆盖率度量1）语句覆盖率是指被测试到的语句数量/可执行的语句总数×100%。2）分支覆盖率是指被测试到的分支数量/总分支总数×100%。3）MC/DC（修改条件/决策覆盖率）要求在一个程序中每一种输入输出至少出现一次，每一个判定中的每一个条件必须产生所有输出结果至少一次，每一个判定必须产生所有可能的输出结果至少一次，并且每一个判定中的每一个条件都能独立影响一个判定结果，因此MC/DC是最可靠的覆盖率。但由于其时间成本过高，目前只在功能安全要求最高的ASILD中实施。实际进行软件单元测试用例设计时，可以将测试用例导出方法与MC/DC标准相结合，提高测试效率、测试力度和测试充分性。当软件只需要满足ASILB等级时，选择语句覆盖和分支覆盖并满足覆盖率要求即可。图4为VectorCAST软件对某源代码进行单元测试的覆盖率统计结果。需要注意的是，无理由的覆盖率无目标值或低目标值会被认为不满足功能安全要求。图4VectorCAST单元测试覆盖率统计结果对于可接受的死代码（用于调试的代码）或不同软件配置的代码区段，可以给出接受所达到的覆盖率水平的理由，或使用补充方法（代码走审查）验证未被覆盖的代码。如果认为已实现的结构覆盖率不充分，需要定义额外的测试用例或提供基于其他方法可补充覆盖率以达到要求的理由，此部分证据可在《软件单元验证测试报告》中提供。6结论功能安全是当下汽车