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消息觸發，但是以太網通道讀取。要考慮的因素太多，不只是要對整車網絡架構有所了解，對所有控制器功能差異有所掌握，還要思考如何把這些差異做到腳本中，讓同一個腳本能夠跑通所有控制器。

審核編輯：湯梓紅