诊断测试工具—CANoe.DiVa功能介绍

文章目录

前言

在汽车电子经典V模型框架下：

A：V模型左侧由OEM和Supplier共同指定出该项目ECU对应的诊断需求规范；

B：将需求规范释放给Supplier，其基于需求规范做功能实现（代码功能实现）；

C：V模型右侧是集成测试，测试目的是验证ECU功能实现是否是按照需求规范定义内容实现。

对于测试解决方案，传统流程如下：

一、诊断测试现状

在如上图所示，整个流程中：

首先需要工程师基于诊断需求规范提炼出诊断测试规范；

再需要工程师基于测试规范编写测试用例；

最后由测试工程师执行测试用例

在如上整个过程中，有很多的主观性存在：

1、基于需求规范提炼出测试规范时，需要工程师保证：

A：测试逻辑正确、严谨；

B：基于需求做到测试点全覆盖。

2、基于测试规范编写测试用例，需要工程师保证：

A：测试步骤正确无误；

B：测试点全覆盖；

C：具备较强的诊断知识储备，对每个步骤的预期响应了然于胸。

但活于世间，烦心事总伴身边。而心情是影响人逻辑判断正确性很大的因素，因此上述内容有很大的不确定性。

并且对于车载诊断测试实现方法目前有如下三种：

1、全手动测试

业界常用方案是将诊断数据库加载到CANoe中，在诊断控制台“Diagnostic Console”中进行手动测试。

2、半自动化测试（手动编写测试脚本，运行环境自动化运行）

基于PC端运行环境，通过编写测试脚本，实现测试目的。

本文基于业界常用工具CANoe作为运行环境，通过编辑CAPL脚本，实现对车载诊断方面测试。

3、全自动化测试解决方案（自动化生成诊断测试用例，并自动化运行测试用例）

全自动化测试解决方案优势在于大量解决测试成本（时间/金钱），避免参与者的主观性因素，大大提高测试质量。

此处以CANoe.DiVa为例，介绍下全自动化测试解决方案：

二、CANoe.DiVa功能介绍

如下图：

因为每个项目诊断需求规范都不一样，因此需要通过诊断数据库来描述该项目的诊断内容。

通过数据库贯穿整个V模型全流程，有效保证了数据的一致性和有效性。

而对于自动生成测试用例的核心如下：

在CANoe.DiVa中以库的形式已经集成了几万条测试用例，通过识别加载的CDD/ODX数据库中包含的诊断描述内容与库中测试用例Map，有交互点的就对应生成测试用。识别点可以是：

A：Service

B：DID

C：DTC

每一个交汇点对应一个测试用例。

总结

这样就可以实现通过加载诊断数据库，自动生成对应的测试用例。

将生成的测试工程加载到CANoe中，可以自动执行，达到全自动化的解决方案。