1. 配置参数的统一性和便利性

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

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

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

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

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

2. 代码架构的重要性

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

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

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

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

3. 代码语法的细节化掌握

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

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

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

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

4. 注释说明的必要性

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

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

5. 脚本的高可用性

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

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

以上几点思考对于各位开发大神来说算不得什么，但我还是在某些专业做总线测试解决方案的服务商那里看到了这些问题，这是不应该的！行业在发展也在内卷，我们所能做的只有不断地完善自己，只为赚取那碎银几两，唉！

---

《CAPL编程语言系统性课程》今年已经开了两期了，经过不断优化，目前已经完结。有感兴趣的可以报名学习，课程内容包含：视频（50小时）、课件、代码、习题讲解、答疑，所有内容一次性释出，无需等待。参加人数有70+，好评率100%。

参加CAPL课程的人有资格优先报名明年的《以太网通信测试课程》