付耿：面向智能汽车的端到端功能安全软件测试最佳实践

前面很多嘉宾提到了，在软件定义汽车的大背景下，软件的代码复杂度越来越高，这种情况下对软件测试的重视度也需要进一步提升，这样才能确保我们的软件质量，甚至整个汽车的质量是可被信赖的。今天的分享分这四个部分。

首先我们来看一下端到端的软件测试流程；

第二块是功能安全软件测试的最佳实践；

第三块是客户案例概览；

最后为公司做个小广告。

第一部分关于软件测试流程，在谈流程之前先统一一下软件测试的定义，它是软件分析的过程，去检测存在的软件和需求的差异，并且去评估软件的功能，这里的差异就是所谓的Bug，所以我们的软件测试并不是证明软件没有Bug，而是要发现bug的存在。

这个是汽车行业最为经典的V字型开发流程，我所展示的这个比较朴素的版本则是来自于中国的功能安全标准34590-2022版中，第6部分的软件层面产品开发阶段参考模型，大家对于整个流程应该都很熟悉，我就不再一一介绍，但是对于软件测试部分稍微展开一下。在完成开发之后我们会做软件单元测试，这块其实是去检查我们的软件是否对应到软件单元设计文档的，所以单元测试与单元设计文档之间存在着这样的映射关系，完成这步之后做软件集成测试，这里是我们要去检验我们的软件是否符合软件架构的设计，包含我们的模块间接口是否符合预期，我们的模块调用关系等等是否符合预期，完成这部之后要做嵌入式软件测试，这里更多的是验证我们的软件在目标的嵌入式是否符合预期，最后做系统测试，看我们开发完的系统与系统需求和系统架构是否匹配，跟我们的产品需求是否一致，也是这里所强调的一一对应关系和可追溯性决定了我们的流程不是一字型开发流程，而是V字开发流程，所以这是保证我们软件质量的很重要的流程。

具体到软件测试，从流程的角度先做软件单元测试，再做软件集成测试，最后做嵌入式软件测试，但是这几步会用到这些方法，包含代码的静态检查，代码的动态测试，如果是基于模型开发的话还要做基于模型的测试，最后是软件故障注入测试和资源使用量测试。

对于代码的静态检查要做编码规则检查，代码质量的度量，要做语义检查，在不运行软件的情况下确保软件可以满足相关规则和要求。

代码动态测试涵盖了代码的单元和集成测试，要测量它的结构化的覆盖率，不管从语句覆盖，MC/DC等等都能符合我们的要求和标准。

基于模型的开发方法也是汽车行业主流的开发方式，对于模型的测试是往往容易被忽视的，模型测试需包含模型的动态、静态和背靠背测试三个环节，对于背靠背测试，重点则是对比模型和代码在同样测试用例下的表现是否一致。

对于软件故障注入测试，这是被功能安全标准所建议或者要求的，但又是我们容易忽视的部分，这里需要结合功能安全分析来识别可能的故障来实现全局的故障注入，最后检查故障的识别和处理机制是否符合我们的预期。

对于资源使用量的测试，我们希望在目标的嵌入式硬件下实时的检测，希望CPU、内容和任务时序等均在安全的范围内，这样才能确保我们的软件在最终的实车表现中可信赖。

接下来我们来看一下第2部分，对于代码的静态检查和代码的单元测试，代码的集成测试和软件故障注入测试，我们将结合实际客户案例来做一些分享。

首先是代码的静态检查，这里我拿的是燃料电池控制器的例子，首先定义一下规则集，既有MISRA C规则集，也有FCU规则集，最后在经过了双方的专家团队评审后明确了84个FCU规则集，对代码进行静态检查。我们要测试的软件一共包含13个模块，最后完成迭代也有7万行代码，一共进行了4次代码的静态检查，大家可以看到第一次静态检查查出了12000多个违背项，每行代码是0.45个违背项。到第二次降低到了1800多个违背项，所以说在测试过程当中我们的开发团队是在一直持续解决违背项的，从这些结果可以看到我们的代码质量是有了大幅度提升的，最后做第四次静态检查时，违背项降到2300个，但是过程中因为涉及到了代码的持续更新，所以它其实还是有产生新的违背项的。在这4次的静态检查过程中我们的团队进行了13次迭代，第4次检查前我们更新了很多新代码。在这个过程当中软件开发团队持续提升了开发能力本身，也包含了对FCU规则集的理解。所以我们不希望代码静态检查流于形式，而是希望它既可以提升软件质量，也可以提升软件开发和测试团队对软件质量的理解，将质量意识融入到团队甚至企业的基因之中。

二是软件单元测试。国内有专门的单元测试团队来做这部分测试的并不多，大部分是开发团队做自测而已，这种情况下质量是没法保证的。从我这边展示的这个例子可以看出，我们首先第一次单元测试分支覆盖率达到99.4%，发现20个错误，这样合下来是4.9乘以10的负4次方个错误每行代码。第二次单元测试分支覆盖率是99.55%，降到了5个错误，然后到第三次我们的分支覆盖率达到99.9%，MC/DC覆盖率达到99.28%，有4个错误，也就是0.96×10的负4次方个错误每行代码。总的说来，代码的错误数量和密度都逐步下降了！

接下来是FCU软件集成测试。从需求出发设计了45个测试场景，对应的开发了相关的测试用例，在Controller Tester这个动态测试工具当中执行了整个测试，测试结果有跟需求当中提取的期望值做对比，确保我们的测试用例可以回溯到需求，然后分析一下需求覆盖率和函数调用覆盖率是否符合预期，最后测出来80个错误，最常见的错误是代码实现与需求是不匹配的。

接下来是关于软件故障注入测试的必要性及方案。从功能安全标准来看，不管从系统和软件部分都有对故障注入提出要求，而且根据不同的阶段和不同的ASIL等级，有的是建议，有的是必需，所以软件故障注入测试是一定要做的。在我们这里用的是一款FIT工具，这个工具本身也是过了功能安全认证的，这个工具是我们的合作伙伴在过去20多年的开发和测试经验当中逐步迭代出来的一款工具，其实这个工具里本身提供了一些基础的软件故障模式，我们也可以自定义故障，从功能安全角度分析一些新的故障模式，这些故障模式可以在软件中通过配置去补充到基础的故障测试用例当中，最后实现软件故障的测试。这里我们推荐软件故障测试在更真实的电子电器的环境当中也就是HiL台架上来进行测试。

对于这个软件故障注入测试的具体流程，首先我们是需要对被测的MCU架构进行分析，把我们的FIT的库与被测软件集成，确保FIT工具可以运行起来，然后在FIT中运行所有的测试用例，最后获取所有的结果评估整个功能安全的设计是否有被实现。

这里我们再快速看一下我们的客户案例的分布，只强调两点，第一是这些案例涵盖了整个V字型开发流程，第二个是我们的案例涵盖了不同类型的汽车电子控制器，大家有任何需求都可以找到我们做进一步的沟通。

最后3分钟时间给公司做个广告，首先我们公司是IAE智行众维，是专注于智能网联仿真测试的企业，涵盖全套的仿真测试解决方案。基于软件定义汽车这个大背景下，今年在中国汽车工业协会、上海汽车城和上海智能汽车软件园的领导们的关怀与支持下，成立了一家新的子公司叫上海智测众维智能科技有限公司，希望能够从软件测试领域出发去更好的助力整个行业的发展。我们的业务核心是软件测试工具链和软件测试服务，但是我们也提供围绕功能安全、信息安全、预期功能安全以及ASPICE流程的认证服务和咨询服务、培训服务。

我们的软件测试工具链涵盖了代码级到系统级的完整的测试工具链，包含代码的静态测试STATIC工具，代码的动态验证CONTROLLER TESTER，到系统级的覆盖测试工具COVER，再到模型的静态MODEL INSPECTOR，模型的动态MODEL VERIFIER。再到面向功能安全的软件故障注入工具FIT，做资源使用量监控的PROV，这是我们整个的软件测试工具链的图谱，大家都任何需要都可以跟我们联系。

　　（注：本文根据现场速记整理，未经演讲嘉宾审阅）