01配置參數(shù)的統(tǒng)一性和便利性

測試腳本的開發(fā)人員，需要考慮到測試執(zhí)行者測試不同控制器時的參數(shù)配置。比如不同的網(wǎng)絡(luò)喚醒條件、不同的網(wǎng)絡(luò)管理消息、不同的時間參數(shù)等等。

編寫的測試腳本給他人使用時，最好是把參數(shù)配置入口放在一個地方，比如專門的參數(shù)配置文件中：

參數(shù)配置文件

再不濟(jì)可以放在CANoe的系統(tǒng)變量模塊中：

系統(tǒng)變量模塊

不建議放在CAPL代碼中配置測試參數(shù)：

CAPL變量模塊

為什么不建議放在CAPL代碼中配置參數(shù)？保證代碼的封閉和穩(wěn)定，以免造成腳本執(zhí)行錯誤。同時也能讓不懂代碼的測試人員執(zhí)行測試。即使腳本開發(fā)人員執(zhí)行測試，在代碼中配置測試參數(shù)也不是一個好的選擇。

02代碼架構(gòu)的重要性

在測試腳本開發(fā)過程中，需要考慮到如何構(gòu)建代碼，尤其是在一個大型的測試腳本中，實(shí)現(xiàn)功能眾多，邏輯復(fù)雜，如果沒有清晰的代碼架構(gòu)，不僅會增加大量的冗余代碼，還會造成調(diào)試的難度變大。

比如在每次測試用例執(zhí)行前，需要執(zhí)行測試初始化，初始化需要完成：讀取配置文件參數(shù)、獲取測試執(zhí)行時間、配置測試報告信息等。其中"讀取配置文件參數(shù)"需要獲取多個參數(shù)值，獲取多個參數(shù)值是一個重復(fù)的動作。

獲取多個參數(shù)值可以通過傳入不同的參數(shù)調(diào)用同一個函數(shù)來實(shí)現(xiàn)。然后把獲取多個參數(shù)值的功能用一個函數(shù)封裝，再把這個封裝的函數(shù)在初始化函數(shù)中調(diào)用。

代碼結(jié)構(gòu)

這樣做的好處是當(dāng)你在配置參數(shù)文件中新增參數(shù)，CAPL代碼中只需要在ReadIniFile_EthComTest()函數(shù)中調(diào)用ReadParameter()，傳入正確的參數(shù)即可。而且結(jié)構(gòu)化的代碼層次分明、邏輯清楚、調(diào)試失敗時容易定位問題點(diǎn)。

03代碼語法的細(xì)節(jié)化掌握

很多人覺得學(xué)CAPL就是學(xué)CAPL提供的函數(shù)接口，當(dāng)然很多人學(xué)不下去也是因?yàn)镃APL里的函數(shù)太多了，不知道哪個功能應(yīng)該使用哪個函數(shù)。其實(shí)學(xué)習(xí)CAPL編程和其他語言一樣，首先要做的應(yīng)該是打好基礎(chǔ)，系統(tǒng)性地學(xué)習(xí)CAPL基本語法，深入了解語法中的細(xì)節(jié)。

下面這個錯誤很多人應(yīng)該遇到過：

CAPL運(yùn)行錯誤

這種由于沒有考慮到數(shù)組大小而造成內(nèi)存溢出的問題，在CAPL編譯階段是不會出現(xiàn)的。

而像字符串類型的數(shù)據(jù)要如何定義內(nèi)存大小、如何賦值、如何讀取，看似簡單卻是調(diào)試中最容易出問題的。

04注釋說明的必要性

在開發(fā)測試腳本的過程中，需要對代碼進(jìn)行必要的注釋，有利于自己或他人后期維護(hù)。

自定義函數(shù)應(yīng)該描述函數(shù)功能、行參說明、返回值含義等。一些重要的環(huán)節(jié)也應(yīng)該對代碼進(jìn)行單獨(dú)注釋，以幫助后期維護(hù)的邏輯梳理。

注釋說明

05腳本的高可用性

域集中式的整車架構(gòu)中，多種ECU和控制器并存，對測試腳本的可用性帶來挑戰(zhàn)。尤其考慮到整車廠，編寫的測試腳本不能只是一錘子買賣，只能用來測試一個控制器，換一個件就出現(xiàn)各種奇怪的問題，這肯定是不行的！

拿CAN通信測試來說，有的控制器是本地喚醒、有的控制器是遠(yuǎn)程喚醒；有的控制器需要E2E校驗(yàn)，有的不需要；有的控制器的DTC是CAN消息觸發(fā)，但是以太網(wǎng)通道讀取。要考慮的因素太多，不只是要對整車網(wǎng)絡(luò)架構(gòu)有所了解，對所有控制器功能差異有所掌握，還要思考如何把這些差異做到腳本中，讓同一個腳本能夠跑通所有控制器。

審核編輯：湯梓紅