基于CANoe 和Jenkins 的ECU 軟件自動(dòng)化 測(cè)試系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

錢俊磊

（上海蔚來汽車有限公司，上海 201805）

1 前言

隨著電動(dòng)汽車的發(fā)展，汽車電子軟件的快速迭代，對(duì)軟件測(cè)試的要求也越來越高。大多數(shù)軟件開發(fā)基本都遵循三個(gè)不同的階段：設(shè)計(jì)、開發(fā)、測(cè)試。但是，這樣的流程有比較明顯的缺陷：（1）軟件設(shè)計(jì)中存在的故障需要等到軟件開發(fā)完成以后才能被發(fā)現(xiàn)，間隔時(shí)間較久；（2）在軟件開發(fā)過程中，故障會(huì)不斷地積累；（3）在測(cè)試階段發(fā)現(xiàn)的問題往往比開發(fā)階段發(fā)現(xiàn)的問題要多三倍以上[1]。三個(gè)階段完成后，軟件迭代的周期往往被持續(xù)拉長(zhǎng)，導(dǎo)致很多時(shí)候落后于進(jìn)度計(jì)劃，成本往往超出預(yù)算，更嚴(yán)重的是可能導(dǎo)致軟件的市場(chǎng)價(jià)值大打折扣。所以持續(xù)集成和自動(dòng)化測(cè)試是非常有必要的，在汽車ECU 軟件領(lǐng)域，如何選用合適的測(cè)試工具搭建有效的集成測(cè)試框架是工程師普遍關(guān)注的問題，特別是現(xiàn)在汽車軟件越來越復(fù)雜，隨著自動(dòng)駕駛功能的不斷升級(jí)，被測(cè)功能越來越多，測(cè)試用例也隨之與日俱增，每個(gè)回歸測(cè)試就需要成百上千的測(cè)試用例組成，測(cè)試用例的管理也非常不便。

本文基于CANoe 和Jenkins 工具搭建了一套可持續(xù)集成的自動(dòng)化測(cè)試系統(tǒng)，當(dāng)檢測(cè)到代碼倉(cāng)庫(kù)中有版本變化時(shí)，能夠自動(dòng)觸發(fā)Jenkins 調(diào)度本地的CANoe 測(cè)試工程進(jìn)行測(cè)試，生成并解析測(cè)試報(bào)告，并且將每次的測(cè)試結(jié)果上傳到TestRail中進(jìn)行記錄，同時(shí)會(huì)通過郵件將測(cè)試結(jié)果發(fā)送給開發(fā)和測(cè)人員，相關(guān)人員及時(shí)收到測(cè)試結(jié)果，從而實(shí)現(xiàn)對(duì)軟件開發(fā)過程中出現(xiàn)的問題進(jìn)行快速定位和解決，最終實(shí)現(xiàn)持續(xù)不斷的快速交付。

2 自動(dòng)化測(cè)試系統(tǒng)設(shè)計(jì)

2.1 自動(dòng)化測(cè)試系統(tǒng)框架

ECU 軟件的持續(xù)集成自動(dòng)化測(cè)試系統(tǒng)框架如圖 1 所示。該系統(tǒng)主要由Jenkins、Git、Artifactory、TestRail、Outlook、測(cè)試臺(tái)架等組成。Jenkins 是一個(gè)持續(xù)集成服務(wù)器，作為集成測(cè)試的主要工具。Jenkins-Master 為Jenkins 的主節(jié)點(diǎn)，通過Web 端登錄，主要用于管理測(cè)試任務(wù)，調(diào)度Jenkins-Slaver，一個(gè)Master 可以關(guān)聯(lián)多個(gè)Salver，并且每個(gè)Slaver 可以分配多個(gè)Job，測(cè)試人員可以根據(jù)需要設(shè)置測(cè)試任務(wù)，自動(dòng)完成重復(fù)測(cè)試的工作。Git 是一個(gè)分布式的版本控制工具，可以對(duì)不同的軟件版本進(jìn)行高效的管理，而Artifactory 是一個(gè)軟件包存儲(chǔ)倉(cāng)庫(kù)，不同的軟件版本經(jīng)過編譯后生成的安裝包都會(huì)被存儲(chǔ)到這個(gè)倉(cāng)庫(kù)中，方便管理和下載。TestRail 是一款全面基于Web 的測(cè)試用例管理軟件，可有效管理，跟蹤和組織軟件測(cè)試工作。

自動(dòng)化測(cè)試系統(tǒng)的設(shè)計(jì)思路如下：(1)當(dāng)開發(fā)人員提交新的變更到Git 倉(cāng)庫(kù)，經(jīng)過編譯生成可執(zhí)行軟件包，并存儲(chǔ)在Artifactory 倉(cāng)庫(kù)中。(2)Jenkins 輪詢檢測(cè)到Artifactory 中有新的可執(zhí)行包生成，出發(fā)測(cè)試Job，通過控制Jenkins-Slaver 從而控制相應(yīng)的測(cè)試臺(tái)架進(jìn)行軟件的刷寫和測(cè)試；(3)Jenkins- Slaver 控制測(cè)試臺(tái)架完成測(cè)試工作，生成測(cè)試報(bào)告，通過Python 腳本解析測(cè)試報(bào)告上傳測(cè)試結(jié)果到TestRail 中，完成本次測(cè)試結(jié)果的記錄；(4)Jenkins 從TestRail 中獲取本次測(cè)試的結(jié)果，并且通過Python 腳本控制Outlook 將報(bào)告內(nèi)容整理后發(fā)送給相關(guān)人員；(5)開發(fā)人員收到測(cè)試結(jié)果后，可以迅速知道自己本次改動(dòng)是否成功通過測(cè)試，如果測(cè)試結(jié)失敗，也可以迅速的定位到問題點(diǎn)；(6)測(cè)試人員可以通過Master 對(duì)整個(gè)自動(dòng)化測(cè)試系統(tǒng)進(jìn)行管理和維護(hù)，并且能夠根據(jù)開發(fā)人員的需求對(duì)測(cè)試用例進(jìn)行維護(hù)。

圖1 自動(dòng)化測(cè)試系統(tǒng)框架

2.2 測(cè)試臺(tái)架搭建

本系統(tǒng)中的測(cè)試臺(tái)架部分的硬件連接如圖2 示。它主要由以下部分組成Inter NUC、VN1630A、VN5610A、PCAN、RAD-Moon、ECU、Network、程控電源、樹莓派等。Jenkins-Master 作為主節(jié)點(diǎn)可以將不同的Job 分配給不同的Jenkins-Slaver，NUC 和樹莓派作為兩個(gè)Slaver，被分配了不同的Job，一個(gè)負(fù)責(zé)刷寫，一個(gè)負(fù)責(zé)測(cè)試。

PCAN 和RAD-Moon 組成刷寫組件，用于對(duì)ECU 進(jìn)行軟件更新操作。PCAN 主要用于對(duì)ECU 進(jìn)行數(shù)據(jù)回放，讓ECU 處于正常工作狀態(tài)，而RAD-Moon 為以太網(wǎng)連接轉(zhuǎn)換設(shè)備，將ECU 的以太網(wǎng)線束轉(zhuǎn)換成RJ45 的端口接入樹莓派，使樹莓派能夠通過以太網(wǎng)與ECU 進(jìn)行連接，從而進(jìn)行軟件刷寫操作。

VN1630A 和VN5610A 組成測(cè)試組件，在樹莓派通過刷寫組建完成了對(duì)ECU 的軟件更新后，NUC 就可以通過測(cè)試組件對(duì)ECU 進(jìn)行相關(guān)測(cè)試任務(wù)。VN1630A 和VN5610A 都可以通過CAN 線連接到ECU，VN1630A 支持四路CAN 通道，VN5610A 支持2 路CAN 通道和2 路以太網(wǎng)通道。需要注意的是：當(dāng)需要進(jìn)行診斷測(cè)試時(shí)，需要用到VN5610A 的以太網(wǎng)通道連接ECU 才能夠進(jìn)行DoIP 的相關(guān)測(cè)試；當(dāng)所測(cè)ECU CAN 通道數(shù)大于4 個(gè)時(shí)，需要使用同步線將VN1630A和VN5610A 連接起來，組成6 通道測(cè)試組件才能夠進(jìn)行相關(guān)測(cè)試。

3 自動(dòng)化測(cè)試系統(tǒng)配置

3.1 測(cè)試試用例設(shè)計(jì)

測(cè)試用例是基于vTESTstudio 設(shè)計(jì)的，它是Vector 推出的一款強(qiáng)大的測(cè)試腳本編輯軟件，全面的集成環(huán)境適用于嵌入式系統(tǒng)的測(cè)試[2]，并且支持多種語(yǔ)言，如CAPL、C#、Test Table、Test Diagram。

圖2 系統(tǒng)硬件連接圖

使用vTESTstudio 撰寫測(cè)試腳本主要由以下優(yōu)點(diǎn)：

（1）文件復(fù)用：在vTESTstudio 中可以很容易實(shí)現(xiàn)testcase，parameter 等文件的復(fù)用，提高執(zhí)行效率。

（2）增加測(cè)試覆蓋率：針對(duì)某一個(gè)testcase 使用分類樹區(qū)分定義輸入條件，實(shí)現(xiàn)各種輸入的排列組合。

（3）結(jié)構(gòu)化架構(gòu)：樹形化測(cè)試用例可以清晰地實(shí)現(xiàn)測(cè)試思路。

（4）波形仿真輸入：在.vwf 文件中可以編輯各種波形文件（正弦，指數(shù)等）對(duì)輸入信號(hào)進(jìn)行仿真。

（5）變量配置：針對(duì)同一測(cè)試單元，可以根據(jù)不同的使用對(duì)象設(shè)置variant 變量區(qū)分測(cè)試過程中需要使用的參數(shù)，快速實(shí)現(xiàn)測(cè)試單元的跨對(duì)象移植。

（6）與CANoe 的無(wú)縫對(duì)接：vTESTstudio 生成的可執(zhí)行文件可以導(dǎo)入CANoe 中生成測(cè)試用例，同事也可以熊CANoe 導(dǎo)入測(cè)試所需要的外部數(shù)據(jù)（系統(tǒng)變量，DBC，CDD等）。

3.2 測(cè)試用例執(zhí)行

在介紹測(cè)試用例的執(zhí)行過程之前，需要先介紹一款工具——CANoe，它是德國(guó)Vector 公司研發(fā)的一款功能強(qiáng)大的綜合軟件工具，被廣泛的應(yīng)用在汽車CAN 總線開發(fā)、仿真、測(cè)試中[3]。它可以用于所有開發(fā)和測(cè)試項(xiàng)相關(guān)的任務(wù)，可以輕易的構(gòu)建自動(dòng)化測(cè)試，用于ECU 模擬和診斷測(cè)試，能夠在開發(fā)早期檢測(cè)并糾正錯(cuò)誤。

對(duì)于整個(gè)系統(tǒng)而言，它能夠提高測(cè)試效率和穩(wěn)定性，并且配合vTESTstudio 和其他的硬件設(shè)備使用可以提供豐富多樣的測(cè)試，如ECU 測(cè)試、模塊測(cè)試、集成測(cè)試、一致性測(cè)試、回歸測(cè)試、ECU 原型測(cè)試等。除此之外，他還提供了豐富的接口，可以通過這些接口使用第三方的軟件和腳本來控制測(cè)試系統(tǒng)。

在使用vTESTstudio 完成了測(cè)試用例的編寫后，需要將vTESTstudio 工程加載到CANoe 工程中，導(dǎo)入后所有的測(cè)試用例就能被CANoe 工程執(zhí)行，并生成測(cè)試報(bào)告。打開CANoe測(cè)試工程，在菜單欄中的Test Setup 界面中可以新建Test Configuration，每個(gè)Test Configuration 按照測(cè)試需求加載不同的Test Unit 生成的可執(zhí)行文件（.vtuexe），從而生成測(cè)試用例，vTestsudio 和CANoe 的交互如圖3 所示。

圖3 vTESTstudio 和CANoe 的交互

3.3 測(cè)試工程調(diào)度

要讓測(cè)試工程能被Jenkins 自動(dòng)化調(diào)度，首先需要在Jenkins-Master/Slaver 節(jié)點(diǎn)上安裝好所需的軟件[4]，Windows Slaver(NUC)上需要安裝Python3 以及相關(guān)組件和Vector 相關(guān)軟件，如CANoe、DiVA、vTESTstudio、CANdela 等。其次在Jenkins-Master 上建立Slaver 節(jié)點(diǎn)，為了方便對(duì)不同的Slaver 節(jié)點(diǎn)進(jìn)行管理，采用cn-system type-number 的編碼格式對(duì)各節(jié)點(diǎn)進(jìn)行命名，如本W(wǎng)indows Slaver 節(jié)點(diǎn)命名為cn-win--01。然后創(chuàng)建Job 時(shí)，需要將Vector 一類的測(cè)試用例進(jìn)行區(qū)分設(shè)置，因?yàn)槠渲荒茉赾n-win-01 上運(yùn)行，無(wú)法在其它節(jié)點(diǎn)上進(jìn)行操作。并且需要通過Git 將倉(cāng)庫(kù)中所需要的腳本文件同步到本地，通過腳本設(shè)置測(cè)試的觸發(fā)方式，選擇輪詢?cè)创a倉(cāng)庫(kù)發(fā)生變化時(shí)觸發(fā)構(gòu)建過程。最后通過Web 登錄Jenkins-Master 界面，可以查看當(dāng)前測(cè)試用例的執(zhí)行情況，如圖4 所示。

圖4 Jenkins Web 界面觀察測(cè)試用例執(zhí)行情況

3.4 測(cè)試報(bào)告處理

測(cè)試完成后會(huì)生成html/xml 格式的報(bào)告，而Jenkins 對(duì)報(bào)告的處理主要分成兩部分：第一部分是將html 格式的報(bào)告保存并上傳，同時(shí)對(duì)xml 格式的報(bào)告進(jìn)行解析，解析主要是通過Jenkins 調(diào)用Python 腳本執(zhí)行的，主要是從報(bào)告中抓取對(duì)應(yīng)的測(cè)試項(xiàng)和測(cè)試結(jié)果，以及失敗測(cè)試項(xiàng)的日志信息上傳到TestRail 中，如圖5 所示，這樣就完成對(duì)本次測(cè)試結(jié)果的一個(gè)在線記錄，方便日后回溯調(diào)查。第二部分是Jenkins 通過調(diào)用相關(guān)的Python 腳本對(duì)TestRail 中本次完成的測(cè)試結(jié)果，通過率進(jìn)行抓取，并且匹配內(nèi)置的UI 界面，將測(cè)試結(jié)果信息以郵件的形式發(fā)送到相關(guān)人員的郵箱中。

圖5 測(cè)試報(bào)告解析上傳

4 ECU 軟件通信和診斷測(cè)試實(shí)例

4.1 測(cè)試對(duì)象

本測(cè)試實(shí)例主要以無(wú)人駕駛模塊ECU 為被測(cè)單元，該被測(cè)單元有三路CAN：Chassis CAN、ADAS CAN、PD CAN，測(cè)試的主要功能包括CAN 總線測(cè)試和診斷測(cè)試，如表1 所示。CAN 總線測(cè)試主要包括三部分：物理層，數(shù)據(jù)鏈路層、通信層，每個(gè)層級(jí)對(duì)應(yīng)的測(cè)試用例，每個(gè)對(duì)應(yīng)的測(cè)試項(xiàng)都有其評(píng)價(jià)標(biāo)準(zhǔn)，可以用于判斷測(cè)試通過與否[5]。由于物理層測(cè)試需要集成其他相關(guān)設(shè)備（如繼電器、示波器等），沒有辦法做到完全自動(dòng)化，所以在此處不列為測(cè)試內(nèi)容。診斷測(cè)試主要包括兩部分：基于ISO-14229 標(biāo)準(zhǔn)所定義的測(cè)試用例和基于軟件使用過程中所增加的個(gè)性化診斷測(cè)試用例。

表1 CAN 總線測(cè)試用例

4.2 測(cè)試流程

本實(shí)例的自動(dòng)化測(cè)試工作流程主要有如下5 步，如圖6所示：代碼提交、測(cè)試觸發(fā)、軟件刷寫、軟件測(cè)試和結(jié)果反饋，每一步環(huán)環(huán)相扣，最終形成一個(gè)閉環(huán)。

圖6 系統(tǒng)硬件連接圖

（1）代碼提交：由于測(cè)試人員反饋代碼問題或者開發(fā)人員根據(jù)需要增加了新的功能，并將這些改動(dòng)以代碼的形式提交到Git 倉(cāng)庫(kù)中。

（2）測(cè)試觸發(fā)：由于倉(cāng)庫(kù)中有相應(yīng)的改動(dòng)提交，Jenkins會(huì)自動(dòng)觸發(fā)對(duì)新的提交進(jìn)行代碼編譯，并且將編譯后的軟件包存放到Artifactory 倉(cāng)庫(kù)中，Jenkins 檢測(cè)到倉(cāng)庫(kù)中有新的軟件包出現(xiàn)時(shí)會(huì)自動(dòng)觸發(fā)測(cè)試任務(wù)。

（3）軟件刷寫：Jenkins-Master 節(jié)點(diǎn)會(huì)調(diào)度Jenkins-Slaver節(jié)點(diǎn)（樹莓派）通過PCAN 回放數(shù)據(jù)，讓ECU 處于正常工作狀態(tài)，隨后Jenkins 會(huì)下載Artifactory 中最新的軟件包并通過RAD-Moon 進(jìn)行軟件刷寫。

（4）軟件測(cè)試：當(dāng)Jenkins 完成刷寫操作后，會(huì)先確認(rèn)刷寫后的軟件狀態(tài)，確認(rèn)軟件版本正確后，會(huì)調(diào)度Slaver 節(jié)點(diǎn)（NUC）進(jìn)行測(cè)試，NUC 上的CANoe 測(cè)試工程會(huì)被Python腳本觸發(fā)執(zhí)行，并在測(cè)試完成后關(guān)閉該工程，上傳測(cè)試報(bào)告，刪除本地的報(bào)告。

（5）結(jié)果反饋：當(dāng)測(cè)試完成后，原始報(bào)告報(bào)告會(huì)被上傳到Jenkins 上，解析后的報(bào)告會(huì)被上傳到TestRail 中，并且在控制臺(tái)也會(huì)輸出相關(guān)的日志信息，Jenkins 接收到TestRail 輸出的測(cè)試結(jié)果后，會(huì)觸發(fā)Python 腳本將測(cè)試結(jié)果以郵件的形式通知到相關(guān)人員的郵箱中。

4.3 測(cè)試結(jié)果

在每次測(cè)試完成以后，CANoe 測(cè)試工程會(huì)生成基于XML 格式的測(cè)試報(bào)告，詳細(xì)記錄每一項(xiàng)測(cè)試用例的結(jié)果和輸出的日志信息，但是這種報(bào)告并不是自動(dòng)化測(cè)試系統(tǒng)所需要，因?yàn)樗膬?nèi)容比較復(fù)雜，不能直接反映整體的測(cè)試結(jié)果，所以在該報(bào)告生成后，Jenkins 會(huì)調(diào)用Python 腳本對(duì)xml 格式 的測(cè)試報(bào)告進(jìn)行解析和上傳，解析的目的是抓取每項(xiàng)測(cè)試用例的結(jié)果，并將失敗的測(cè)試用例所輸出的日志信息抓取并記錄在TestRail 中。最后TestRail 會(huì)將測(cè)試結(jié)果整理匯總輸出統(tǒng)計(jì)信息，Jenkins 會(huì)根據(jù)TestRail 提供的接口，通過Python腳本將測(cè)試結(jié)果以郵件的形式發(fā)送出來，通知到相關(guān)人員，如圖7 所示。

圖7 測(cè)試結(jié)果輸出

5 結(jié)束語(yǔ)

敏捷開發(fā)所提倡的通過盡快和持續(xù)不斷的交付有價(jià)值的軟件來滿足客戶的需要，前提是有高效的手段確保軟件的質(zhì)量，軟件的持續(xù)集成所面臨的挑戰(zhàn)就是測(cè)試的自動(dòng)化，軟件的自動(dòng)化測(cè)試可以減少人力資源的重復(fù)投入，不僅節(jié)約成本，而且提高了測(cè)試效率，還能夠幫助開發(fā)人員快速定位問題，解決問題[6]。

本文設(shè)計(jì)并實(shí)現(xiàn)了一套基于CANoe 和Jenkins 的ECU軟件自動(dòng)化測(cè)試系統(tǒng)，使用了Jenkins 作為自動(dòng)化測(cè)試調(diào)度的主要工具，結(jié)合CANoe 和vTESTstudio 強(qiáng)大的測(cè)試功能，并且以無(wú)人駕駛控制模塊ECU 作為測(cè)試對(duì)象，對(duì)其進(jìn)行了通信和診斷的自動(dòng)化實(shí)例測(cè)試。該自動(dòng)化測(cè)試系統(tǒng)具有非常高的實(shí)際應(yīng)用價(jià)值，并且可以在此基礎(chǔ)上拓展其他相關(guān)軟件的集成測(cè)試。