【研发日记】CANoe自动化测试的配置方式（三）—

本文主要是介绍【研发日记】CANoe自动化测试的配置方式（三）——SystemVariables数组方式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

前言

一、例程功能

二、仿真ECU

三、SystemVariables数组：

四、测试模块

五、测试运行效果

六、分析和应用

总结

前言

近期在做的一个自动化测试项目，尝试了一种以前没用过的测试配置方式，感觉效果还不错。然后又回顾了一下以前用过的其他几种方式，利用周末时间总结分享出来，希望对相关领域的网友有所帮助。

由于实际项目比较庞大，而且不便在网络公开，所以就参考其中一项典型的测试来做一个例程，重点是讲解其中自动化测试配置的用法。

一、例程功能

见《CANoe自动化测试的配置方式总结分析（一）——CAPL编程方式》

二、仿真ECU

见《CANoe自动化测试的配置方式总结分析（一）——CAPL编程方式》

三、SystemVariables数组

SystemVariables数组的创建如下图所示。测试人员在测试开始前，一次性设定全部的测试配置信息。

四、测试模块

测试模块的创建和编程代码如下。该模从SystemVariables数组自动读取测试配置信息，发送激励报文，然后与仿真ECU解析的接收报文相对比，自动判定测试结果。

void MainTest()
{for(j=0;j<4;j++)CaseEvery(j);}testcase CaseEvery(byte j)
{write("Load Cfg");TestMsg.can = 1;if(@DemoVar::IsStad[j]) TestMsg.id = @DemoVar::ID[j];else TestMsg.id = mkExtId(@DemoVar::ID[j]);TestMsg.DataLength = @DemoVar::Length[j];for(i=0;i<@DemoVar::Length[j];i++) TestMsg.byte(i) = @DemoVar::Data[j];write("Test Start");output(TestMsg);if(@DemoVar::IsStad[j]){if(TestWaitForMessage(@DemoVar::ID[j], 5000)){write("Judge Received");if(@MiddleVar::ID_r != @DemoVar::ID[j]) testCaseFail();if(@MiddleVar::IsStad_r != @DemoVar::IsStad[j]) testCaseFail();if(@MiddleVar::Data_r[0] != @DemoVar::Data[j]) testCaseFail();if(@MiddleVar::Length_r != @DemoVar::Length[j]) testCaseFail();testStepPass();}}else{if(TestWaitForMessage(mkExtId(@DemoVar::ID[j]), 5000)){write("Judge Received");if(@MiddleVar::IsStad_r == 0) @MiddleVar::ID_r = @MiddleVar::ID_r & 0x7FFFFFFF;if(@MiddleVar::ID_r != @DemoVar::ID[j]) testCaseFail();if(@MiddleVar::IsStad_r != @DemoVar::IsStad[j]) testCaseFail();if(@MiddleVar::Data_r[0] != @DemoVar::Data[j]) testCaseFail();if(@MiddleVar::Length_r != @DemoVar::Length[j]) testCaseFail();testStepPass();}}testWaitForTimeout(1000);  }

五、测试运行效果

实际测试运行的效果如下。测试配置的信息在系统变量数组中保存后，一键执行测试模块，可以看到激励报文的发送与配置信息一致。每个测试配置执行后的finished提示行是绿色，表示测试结果的判定为Pass。相反出现红色提示行时，表示Fail。

六、分析和应用

上述使用系统变量数组实现自动化测试配置的方式，特点是各个测试参数使用一个统一的配置文件（系统变量）进行配置。这种方式的优点是，在一个地方即可完成对全部自动化测试信息的配置，不需要对每个测试配置单独输入或单独编程。缺点是，这种实现方式涉及到归一化程度比较高的数据调用算法，在编程逻辑上会稍微复杂一些，在后期使用和维护时对工程师的个人能力要求会稍微高一些。整体而言，这种方式适合应用于测试项目的中期阶段，测试设计已经比较成熟，测试配置相对稳定，但是需要快速迭代和重复测试的场景。