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

文章目录

• 前言
• 一、诊断测试现状
• 二、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中，可以自动执行，达到全自动化的解决方案。