CANoe编写CAPL测试脚本的几点思考

01配置参数的统一性和便利性

测试脚本的开发人员，需要考虑到测试执行者测试不同控制器时的参数配置。比如不同的网络唤醒条件、不同的网络管理消息、不同的时间参数等等。

编写的测试脚本给他人使用时，最好是把参数配置入口放在一个地方，比如专门的参数配置文件中：

参数配置文件

再不济可以放在CANoe的系统变量模块中：

系统变量模块

不建议放在CAPL代码中配置测试参数：

CAPL变量模块

为什么不建议放在CAPL代码中配置参数？保证代码的封闭和稳定，以免造成脚本执行错误。同时也能让不懂代码的测试人员执行测试。即使脚本开发人员执行测试，在代码中配置测试参数也不是一个好的选择。

02代码架构的重要性

在测试脚本开发过程中，需要考虑到如何构建代码，尤其是在一个大型的测试脚本中，实现功能众多，逻辑复杂，如果没有清晰的代码架构，不仅会增加大量的冗余代码，还会造成调试的难度变大。

比如在每次测试用例执行前，需要执行测试初始化，初始化需要完成：读取配置文件参数、获取测试执行时间、配置测试报告信息等。其中"读取配置文件参数"需要获取多个参数值，获取多个参数值是一个重复的动作。

获取多个参数值可以通过传入不同的参数调用同一个函数来实现。然后把获取多个参数值的功能用一个函数封装，再把这个封装的函数在初始化函数中调用。

代码结构

这样做的好处是当你在配置参数文件中新增参数，CAPL代码中只需要在ReadIniFile_EthComTest()函数中调用ReadParameter()，传入正确的参数即可。而且结构化的代码层次分明、逻辑清楚、调试失败时容易定位问题点。

03代码语法的细节化掌握

很多人觉得学CAPL就是学CAPL提供的函数接口，当然很多人学不下去也是因为CAPL里的函数太多了，不知道哪个功能应该使用哪个函数。其实学习CAPL编程和其他语言一样，首先要做的应该是打好基础，系统性地学习CAPL基本语法，深入了解语法中的细节。

下面这个错误很多人应该遇到过：

CAPL运行错误

这种由于没有考虑到数组大小而造成内存溢出的问题，在CAPL编译阶段是不会出现的。

而像字符串类型的数据要如何定义内存大小、如何赋值、如何读取，看似简单却是调试中最容易出问题的。

04注释说明的必要性

在开发测试脚本的过程中，需要对代码进行必要的注释，有利于自己或他人后期维护。

自定义函数应该描述函数功能、行参说明、返回值含义等。一些重要的环节也应该对代码进行单独注释，以帮助后期维护的逻辑梳理。

注释说明

05脚本的高可用性

域集中式的整车架构中，多种ECU和控制器并存，对测试脚本的可用性带来挑战。尤其考虑到整车厂，编写的测试脚本不能只是一锤子买卖，只能用来测试一个控制器，换一个件就出现各种奇怪的问题，这肯定是不行的！

拿CAN通信测试来说，有的控制器是本地唤醒、有的控制器是远程唤醒；有的控制器需要E2E校验，有的不需要；有的控制器的DTC是CAN消息触发，但是以太网通道读取。要考虑的因素太多，不只是要对整车网络架构有所了解，对所有控制器功能差异有所掌握，还要思考如何把这些差异做到脚本中，让同一个脚本能够跑通所有控制器。

审核编辑：汤梓红