CANoe自动化测试的配置方式总结分析(二)——Panel接口方式

本文总结了使用CANoe Panel接口进行自动化测试配置的方法,包括Panel接口创建、测试模块编程以及测试运行效果。通过Panel接口,测试人员能输入灵活的测试参数,实现广泛覆盖,适用于测试设计初期。虽然需要手动输入且数据转化稍复杂,但能避免对每个配置单独编程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

文章目录

前言

一、例程功能

二、仿真ECU

三、Panel接口

四、测试模块

五、测试运行效果

配置1:

配置2:

配置3:

配置4:

六、分析和应用

总结


前言

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

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

一、例程功能

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

二、仿真ECU

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

三、Panel接口

        Panel接口的创建如下图所示。测试人员在每个测试开始前,手动输入测试配置信息。

四、测试模块

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

testcase Case1()
{
  byte buf[100];
  long copiedSize;
  int i;
  
  write("Load Cfg");
  TestMsg.can = 1;
  if(@PanelVar::IsStad) TestMsg.id = @PanelVar::ID;
  else TestMsg.id = mkExtId(@PanelVar::ID);
  TestMsg.DataLength = @PanelVar::Length;
  copiedSize = @PanelVar::Length;
  sysGetVariableData(sysvar::PanelVar::Data,buf,copiedSize);
  for(i=0;i<@PanelVar::Length;i++) TestMsg.byte(i) = buf[i];

  write("Test Start");
  output(TestMsg);
  
  if(@PanelVar::IsStad)
  {
    if(TestWaitForMessage(@PanelVar::ID, 5000))
    {
      write("Judge Received");
      if(@MiddleVar::ID_r != @PanelVar::ID) testCaseFail();
      if(@MiddleVar::IsStad_r != @PanelVar::IsStad) testCaseFail();
      if(@MiddleVar::Data_r[0] != buf[0]) testCaseFail();
      if(@MiddleVar::Length_r != @PanelVar::Length) testCaseFail();
      testStepPass();
    }
  }
  else
  {
    if(TestWaitForMessage(mkExtId(@PanelVar::ID),5000))
    {
      write("Judge Received");
      @MiddleVar::ID_r = @MiddleVar::ID_r & 0x7FFFFFFF;
      if(@MiddleVar::ID_r != @PanelVar::ID) testCaseFail();
      if(@MiddleVar::IsStad_r != @PanelVar::IsStad) testCaseFail();
      if(@MiddleVar::Data_r[0] != buf[0]) testCaseFail();
      if(@MiddleVar::Length_r != @PanelVar::Length) testCaseFail();
      testStepPass();
    }
  }
  
  testWaitForTimeout(1000);  

}

五、测试运行效果

        实际测试运行的效果如下。每个测试配置的信息输入后,一键执行测试模块,可以看到激励报文的发送与Panel接口定义的报文一致。每个测试配置执行后的finished提示行是绿色,表示测试结果的判定为Pass。相反出现红色提示行时,表示Fail。

配置1:

 

配置2:

 

配置3:

 

配置4:

 

六、分析和应用

        上述使用Panel接口实现自动化测试配置的方式,特点是各个测试参数不再是一个固定值,而是可以灵活输入,比如标准帧的CAN ID可以是从0x00到0x7FF的任意值。这种方式的优点是,测试配置可以实现最大的覆盖度,而且一次编程即可实现,不需对每个测试配置单独编程。缺点是,每个测试配置都要单独输入,而且测试配置需要从Panel接口加载到测试模块,接口中调用的数据类型比较多样,在数据转化时会稍微复杂一些。整体而言,这种方式适合应用于测试项目的早期阶段,测试设计还不很成熟,需要反复摸索测试配置。

总结

        以上就是本人在对CANoe自动化测试配置方式进行总结分析时,讲解的第二种实现方式。主要讲解了实现该方式的详细代码,展示了实际运行效果,最后分析了这种配置方式的特点以及适用场景。

        后续还会更新后面几种CANoe自动化测试配置的实现方式,欢迎评论区留言、点赞、收藏和关注,这些鼓励都将成为笔者持续分享的动力。

        另外,上述例程使用的Demo工程可以到笔者的主页查找和下载。


        版权声明:原创文章,转载和引用请注明出处与链接,侵权必究! 

### 如何在 CANoe 中使用 TestCase #### 测试脚本结构 为了有效利用 CANoe 的 TestCase 功能,理解测试脚本的层级至关重要。测试脚本通常由多个部分组成,包括但不限于初始化、执行逻辑以及清理操作。这些组件共同作用以确保测试案例可以被正确加载并运行[^1]。 ```python def setup_test_environment(): """ 初始化测试环境 """ pass def execute_test_case(test_case_id): """ 执行特定ID的测试用例 """ print(f"Executing Test Case {test_case_id}") def cleanup_after_test(): """ 清理测试后的资源 """ pass ``` #### 启用 TestCase 启用 TestCase 需要通过 Python 脚本来实现自动化流程。这涉及到与 CANoe API 的交互来启动和管理测试过程。具体来说,可以通过调用相应的命令来激活预定义好的测试集或单个测试项。 ```python import canoe_api # 假设这是用于访问CANoe功能的一个API库 canoe_api.enable_test_case("MyTestCase") # 替换为实际存在的TestCase名称 ``` #### 控制 Panel 来影响 Test Module 运行 除了直接编程方式外,还可以借助 CANoe 提供的图形界面工具——Panel面板来进行更直观的操作。例如,在 flash test module 场景下,可将系统变量同 panel 上的控件关联起来以便于实时调整参数值[^3]。 ```xml <!-- XML配置片段展示如何连接Panel上的按钮到内部变量 --> <Button ID="StartFlashButton"> <Action>SetSystemVariable('IsFlashing', True)</Action> </Button> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Mr.Cssust

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值