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

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检查

对