点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
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消息触发,但是以太网通道读取。要考虑的因素太多,不只是要对整车网络架构有所了解,对所有控制器功能差异有所掌握,还要思考如何把这些差异做到脚本中,让同一个脚本能够跑通所有控制器。
精品活动推荐
更多文章
会员权益: (点击可进入)谈思实验室VIP会员