錢俊磊
(上海蔚來汽車有限公司,上海 201805)
隨著電動汽車的發展,汽車電子軟件的快速迭代,對軟件測試的要求也越來越高。大多數軟件開發基本都遵循三個不同的階段:設計、開發、測試。但是,這樣的流程有比較明顯的缺陷:(1)軟件設計中存在的故障需要等到軟件開發完成以后才能被發現,間隔時間較久;(2)在軟件開發過程中,故障會不斷地積累;(3)在測試階段發現的問題往往比開發階段發現的問題要多三倍以上[1]。三個階段完成后,軟件迭代的周期往往被持續拉長,導致很多時候落后于進度計劃,成本往往超出預算,更嚴重的是可能導致軟件的市場價值大打折扣。所以持續集成和自動化測試是非常有必要的,在汽車ECU 軟件領域,如何選用合適的測試工具搭建有效的集成測試框架是工程師普遍關注的問題,特別是現在汽車軟件越來越復雜,隨著自動駕駛功能的不斷升級,被測功能越來越多,測試用例也隨之與日俱增,每個回歸測試就需要成百上千的測試用例組成,測試用例的管理也非常不便。
本文基于CANoe 和Jenkins 工具搭建了一套可持續集成的自動化測試系統,當檢測到代碼倉庫中有版本變化時,能夠自動觸發Jenkins 調度本地的CANoe 測試工程進行測試,生成并解析測試報告,并且將每次的測試結果上傳到TestRail中進行記錄,同時會通過郵件將測試結果發送給開發和測人員,相關人員及時收到測試結果,從而實現對軟件開發過程中出現的問題進行快速定位和解決,最終實現持續不斷的快速交付。
ECU 軟件的持續集成自動化測試系統框架如圖 1 所示。該系統主要由Jenkins、Git、Artifactory、TestRail、Outlook、測試臺架等組成。Jenkins 是一個持續集成服務器,作為集成測試的主要工具。Jenkins-Master 為Jenkins 的主節點,通過Web 端登錄,主要用于管理測試任務,調度Jenkins-Slaver,一個Master 可以關聯多個Salver,并且每個Slaver 可以分配多個Job,測試人員可以根據需要設置測試任務,自動完成重復測試的工作。Git 是一個分布式的版本控制工具,可以對不同的軟件版本進行高效的管理,而Artifactory 是一個軟件包存儲倉庫,不同的軟件版本經過編譯后生成的安裝包都會被存儲到這個倉庫中,方便管理和下載。TestRail 是一款全面基于Web 的測試用例管理軟件,可有效管理,跟蹤和組織軟件測試工作。
自動化測試系統的設計思路如下:(1)當開發人員提交新的變更到Git 倉庫,經過編譯生成可執行軟件包,并存儲在Artifactory 倉庫中。(2)Jenkins 輪詢檢測到Artifactory 中有新的可執行包生成,出發測試Job,通過控制Jenkins-Slaver 從而控制相應的測試臺架進行軟件的刷寫和測試;(3)Jenkins- Slaver 控制測試臺架完成測試工作,生成測試報告,通過Python 腳本解析測試報告上傳測試結果到TestRail 中,完成本次測試結果的記錄;(4)Jenkins 從TestRail 中獲取本次測試的結果,并且通過Python 腳本控制Outlook 將報告內容整理后發送給相關人員;(5)開發人員收到測試結果后,可以迅速知道自己本次改動是否成功通過測試,如果測試結失敗,也可以迅速的定位到問題點;(6)測試人員可以通過Master 對整個自動化測試系統進行管理和維護,并且能夠根據開發人員的需求對測試用例進行維護。

圖1 自動化測試系統框架
本系統中的測試臺架部分的硬件連接如圖2 示。它主要由以下部分組成Inter NUC、VN1630A、VN5610A、PCAN、RAD-Moon、ECU、Network、程控電源、樹莓派等。Jenkins-Master 作為主節點可以將不同的Job 分配給不同的Jenkins-Slaver,NUC 和樹莓派作為兩個Slaver,被分配了不同的Job,一個負責刷寫,一個負責測試。
PCAN 和RAD-Moon 組成刷寫組件,用于對ECU 進行軟件更新操作。PCAN 主要用于對ECU 進行數據回放,讓ECU 處于正常工作狀態,而RAD-Moon 為以太網連接轉換設備,將ECU 的以太網線束轉換成RJ45 的端口接入樹莓派,使樹莓派能夠通過以太網與ECU 進行連接,從而進行軟件刷寫操作。
VN1630A 和VN5610A 組成測試組件,在樹莓派通過刷寫組建完成了對ECU 的軟件更新后,NUC 就可以通過測試組件對ECU 進行相關測試任務。VN1630A 和VN5610A 都可以通過CAN 線連接到ECU,VN1630A 支持四路CAN 通道,VN5610A 支持2 路CAN 通道和2 路以太網通道。需要注意的是:當需要進行診斷測試時,需要用到VN5610A 的以太網通道連接ECU 才能夠進行DoIP 的相關測試;當所測ECU CAN 通道數大于4 個時,需要使用同步線將VN1630A和VN5610A 連接起來,組成6 通道測試組件才能夠進行相關測試。
測試用例是基于vTESTstudio 設計的,它是Vector 推出的一款強大的測試腳本編輯軟件,全面的集成環境適用于嵌入式系統的測試[2],并且支持多種語言,如CAPL、C#、Test Table、Test Diagram。

圖2 系統硬件連接圖
使用vTESTstudio 撰寫測試腳本主要由以下優點:
(1)文件復用:在vTESTstudio 中可以很容易實現testcase,parameter 等文件的復用,提高執行效率。
(2)增加測試覆蓋率:針對某一個testcase 使用分類樹區分定義輸入條件,實現各種輸入的排列組合。
(3)結構化架構:樹形化測試用例可以清晰地實現測試思路。
(4)波形仿真輸入:在.vwf 文件中可以編輯各種波形文件(正弦,指數等)對輸入信號進行仿真。
(5)變量配置:針對同一測試單元,可以根據不同的使用對象設置variant 變量區分測試過程中需要使用的參數,快速實現測試單元的跨對象移植。
(6)與CANoe 的無縫對接:vTESTstudio 生成的可執行文件可以導入CANoe 中生成測試用例,同事也可以熊CANoe 導入測試所需要的外部數據(系統變量,DBC,CDD等)。
在介紹測試用例的執行過程之前,需要先介紹一款工具——CANoe,它是德國Vector 公司研發的一款功能強大的綜合軟件工具,被廣泛的應用在汽車CAN 總線開發、仿真、測試中[3]。它可以用于所有開發和測試項相關的任務,可以輕易的構建自動化測試,用于ECU 模擬和診斷測試,能夠在開發早期檢測并糾正錯誤。
對于整個系統而言,它能夠提高測試效率和穩定性,并且配合vTESTstudio 和其他的硬件設備使用可以提供豐富多樣的測試,如ECU 測試、模塊測試、集成測試、一致性測試、回歸測試、ECU 原型測試等。除此之外,他還提供了豐富的接口,可以通過這些接口使用第三方的軟件和腳本來控制測試系統。
在使用vTESTstudio 完成了測試用例的編寫后,需要將vTESTstudio 工程加載到CANoe 工程中,導入后所有的測試用例就能被CANoe 工程執行,并生成測試報告。打開CANoe測試工程,在菜單欄中的Test Setup 界面中可以新建Test Configuration,每個Test Configuration 按照測試需求加載不同的Test Unit 生成的可執行文件(.vtuexe),從而生成測試用例,vTestsudio 和CANoe 的交互如圖3 所示。

圖3 vTESTstudio 和CANoe 的交互
要讓測試工程能被Jenkins 自動化調度,首先需要在Jenkins-Master/Slaver 節點上安裝好所需的軟件[4],Windows Slaver(NUC)上需要安裝Python3 以及相關組件和Vector 相關軟件,如CANoe、DiVA、vTESTstudio、CANdela 等。其次在Jenkins-Master 上建立Slaver 節點,為了方便對不同的Slaver 節點進行管理,采用cn-system type-number 的編碼格式對各節點進行命名,如本Windows Slaver 節點命名為cn-win--01。然后創建Job 時,需要將Vector 一類的測試用例進行區分設置,因為其只能在cn-win-01 上運行,無法在其它節點上進行操作。并且需要通過Git 將倉庫中所需要的腳本文件同步到本地,通過腳本設置測試的觸發方式,選擇輪詢源代碼倉庫發生變化時觸發構建過程。最后通過Web 登錄Jenkins-Master 界面,可以查看當前測試用例的執行情況,如圖4 所示。

圖4 Jenkins Web 界面觀察測試用例執行情況
測試完成后會生成html/xml 格式的報告,而Jenkins 對報告的處理主要分成兩部分:第一部分是將html 格式的報告保存并上傳,同時對xml 格式的報告進行解析,解析主要是通過Jenkins 調用Python 腳本執行的,主要是從報告中抓取對應的測試項和測試結果,以及失敗測試項的日志信息上傳到TestRail 中,如圖5 所示,這樣就完成對本次測試結果的一個在線記錄,方便日后回溯調查。第二部分是Jenkins 通過調用相關的Python 腳本對TestRail 中本次完成的測試結果,通過率進行抓取,并且匹配內置的UI 界面,將測試結果信息以郵件的形式發送到相關人員的郵箱中。

圖5 測試報告解析上傳
本測試實例主要以無人駕駛模塊ECU 為被測單元,該被測單元有三路CAN:Chassis CAN、ADAS CAN、PD CAN,測試的主要功能包括CAN 總線測試和診斷測試,如表1 所示。CAN 總線測試主要包括三部分:物理層,數據鏈路層、通信層,每個層級對應的測試用例,每個對應的測試項都有其評價標準,可以用于判斷測試通過與否[5]。由于物理層測試需要集成其他相關設備(如繼電器、示波器等),沒有辦法做到完全自動化,所以在此處不列為測試內容。診斷測試主要包括兩部分:基于ISO-14229 標準所定義的測試用例和基于軟件使用過程中所增加的個性化診斷測試用例。

表1 CAN 總線測試用例
本實例的自動化測試工作流程主要有如下5 步,如圖6所示:代碼提交、測試觸發、軟件刷寫、軟件測試和結果反饋,每一步環環相扣,最終形成一個閉環。

圖6 系統硬件連接圖
(1)代碼提交:由于測試人員反饋代碼問題或者開發人員根據需要增加了新的功能,并將這些改動以代碼的形式提交到Git 倉庫中。
(2)測試觸發:由于倉庫中有相應的改動提交,Jenkins會自動觸發對新的提交進行代碼編譯,并且將編譯后的軟件包存放到Artifactory 倉庫中,Jenkins 檢測到倉庫中有新的軟件包出現時會自動觸發測試任務。
(3)軟件刷寫:Jenkins-Master 節點會調度Jenkins-Slaver節點(樹莓派)通過PCAN 回放數據,讓ECU 處于正常工作狀態,隨后Jenkins 會下載Artifactory 中最新的軟件包并通過RAD-Moon 進行軟件刷寫。
(4)軟件測試:當Jenkins 完成刷寫操作后,會先確認刷寫后的軟件狀態,確認軟件版本正確后,會調度Slaver 節點(NUC)進行測試,NUC 上的CANoe 測試工程會被Python腳本觸發執行,并在測試完成后關閉該工程,上傳測試報告,刪除本地的報告。
(5)結果反饋:當測試完成后,原始報告報告會被上傳到Jenkins 上,解析后的報告會被上傳到TestRail 中,并且在控制臺也會輸出相關的日志信息,Jenkins 接收到TestRail 輸出的測試結果后,會觸發Python 腳本將測試結果以郵件的形式通知到相關人員的郵箱中。
在每次測試完成以后,CANoe 測試工程會生成基于XML 格式的測試報告,詳細記錄每一項測試用例的結果和輸出的日志信息,但是這種報告并不是自動化測試系統所需要,因為它的內容比較復雜,不能直接反映整體的測試結果,所以在該報告生成后,Jenkins 會調用Python 腳本對xml 格式 的測試報告進行解析和上傳,解析的目的是抓取每項測試用例的結果,并將失敗的測試用例所輸出的日志信息抓取并記錄在TestRail 中。最后TestRail 會將測試結果整理匯總輸出統計信息,Jenkins 會根據TestRail 提供的接口,通過Python腳本將測試結果以郵件的形式發送出來,通知到相關人員,如圖7 所示。

圖7 測試結果輸出
敏捷開發所提倡的通過盡快和持續不斷的交付有價值的軟件來滿足客戶的需要,前提是有高效的手段確保軟件的質量,軟件的持續集成所面臨的挑戰就是測試的自動化,軟件的自動化測試可以減少人力資源的重復投入,不僅節約成本,而且提高了測試效率,還能夠幫助開發人員快速定位問題,解決問題[6]。
本文設計并實現了一套基于CANoe 和Jenkins 的ECU軟件自動化測試系統,使用了Jenkins 作為自動化測試調度的主要工具,結合CANoe 和vTESTstudio 強大的測試功能,并且以無人駕駛控制模塊ECU 作為測試對象,對其進行了通信和診斷的自動化實例測試。該自動化測試系統具有非常高的實際應用價值,并且可以在此基礎上拓展其他相關軟件的集成測試。