【摘要】文章系統闡述了車聯網（Telematics）系統測試的一般流程及主要測試方法。通過具體Telematics系統測試實例詳細介紹測試過程中關鍵技術應用、主要測試問題及其原因分析并取得了較好的測試結果。Telematics后臺信息應用服務平臺為問題高發區，車載終端問題主要為本地功能無法實現，無線通信網絡問題為小概率事件。另外，在測試過程及時截取并準確分析log文件可以高效定位問題根源，提高測試效率。
1.車聯網Telematics概念
1.1定義
車聯網是以車內網、車際網和車載移動互聯網為基礎，按照約定的通信協議和數據交互標準，在車-X（X：車、路、行人及互聯網等）之間，進行無線通訊和信息交換，以實現智能化交通管理、智能動態信息服務和車輛智能化控制的一體化網絡，是物聯網技術在交通系統領域的典型應用。
圖1 Telematics系統架構
車載信息終端：采集CAN網絡數據及GPS數據等信息，經過處理打包，通過無線通信網絡傳送給后臺信息服務平臺。
無線通信網絡：應用3G/4G、Wi- Fi等現代網絡通信的技術與手段,實現車載終端與后臺服務平臺的信息傳輸。
后臺信息服務平臺：借助互聯網技術整合第三方內容和數據并對海量信息進行融合處理,以實現車輛檢測、道路救援、實時交通、網上預約等服務與應用。
2.Telematics測試技術
2.1 Telematics系統特點
? 車載信息終端集成多種通信與數據IO硬件，并提供對多種通信協議、數據處理及應用服務的支持，系統非常復雜。
? Telematics具有多設備組成性，涉及眾多廠商，信息數據流轉鏈路復雜、網絡異構且涉及海量信息整合，數據挖掘、大規模數據計算。
? 實時性、可靠性要求：網絡節點（車輛）具有高動態性、拓撲變化頻繁，且受到的干擾因素較多包括路邊建筑物、天氣狀況、道路交通狀況等。
2.2 Telematics測試方法
Telematics系統的復雜性決定了測試過程必需從多角度、多維度對系統進行綜合性測試，主要測試技術如圖所示，
圖2 Telematics測試方法
從系統整體實現角度出發，需要進行功能、及性能測試。其中，功能測試涵蓋功能實現、需求驗證、用戶體驗（功能合理性）；性能測試包括穩定性、可靠性、安全性、壓力測試（負載）。
測試周期的不同階段需要對系統進行單元測試、集成測試、系統測試。如：車載終端單元測試，車內網集成測試，接入系統平臺進行系統化測試。
從被測對象的特性及運行狀況，又可靈活采用動態測試、靜態測試、白盒測試、黑盒測試等。
2.3 Telematics測試流程
測試流程遵循通用測試流程：測試需求分析、測試策略分析（用例設計）、測試環境搭建、測試執行、系統測試回歸。
圖3 Telematics 測試流程
測試策略分析以測試需求說明為輸入，通過對功能邏輯分析、特性分析、因果分析、場景分析、優先級分析等加工輸出系統測試用例。
圖4 Telematics測試策略分析
3.測試案例
某合資廠某車型Telematics系統級測試，該系統采用NGTP架構，車載終端為WinCE系統與車身BodyCAN鏈接并集成GPS通訊模塊；無線通訊modem通過嵌入SIM卡接入中國聯通3G網絡，后臺服務平臺為Microsoft 云計算平臺，并接入第三方服務機構如E-call。整個系統采用松耦合設計，可擴展性比較高。
3.1系統介紹
1、系統結構
圖5 Telematics測試案例系統架構
2、功能圖
圖6 測試案例系統功能
3.2、測試策略分析、測試用例設計
測試策略分析以測試需求說明為輸入，通過對功能邏輯分析、特性分析、因果分析、場景分析、優先級分析等加工輸出系統測試用例。
輸入文檔主要包含系統方案，功能定義文檔，CAN網絡結構文檔，通信矩陣，信號DBC，各種測試所需數據，應用服務類型定義等。
1、系統數據流轉圖
圖7 系統數據流轉圖
數據流轉主要分為車內網（CAN）數據流轉與車際網數據流轉。車際網數據
基于NGTP協議，以請求（request）—響應（response）服務的形式與server進行交互傳輸。
2、策略、特性分析
Telematics功能實現依賴于數據的可靠性傳輸，不同的功能服務對應不同的數據鏈路。為此，按數據在系統中流轉的方向不同我們將測試分為如下三部分：
1）單向上行服務測試：主要為本地CAN網絡數據的采集打包上傳server以便對車輛狀況進行統計分析。
2）單向下行服務測試：主要為server推送至車載終端的信息服務。如：保養預約提醒、車輛健康度結果、駕駛安全性經濟性指數、天氣信息等。
3）雙向request-response服務測試：由終端發起請求，server根據請求信息到數據庫調用相關數據必要時進入第三方平臺調取數據并對數據進行加工處理，最后反饋給終端結果信息。
3、測試形式
考慮Telematics測試復雜性，兼顧測試效率采用靜態測試與動態測試相結合的方式。測試周期各階段包含終端單元測試、CAN網絡集成、終端與server集成測試，實車系統測試。
? 靜態測試主要為臺架測試：通過CANoe工具模擬CAN網絡，主要實現終端本地功能、車內網控制器間交叉、車輛數據相關功能、及極端狀況下測試如E-call測試。
? 動態道路實車測試主要實現基于位置（GPS）的信息服務如實時交通、智能停車；不同路況下的無線通信及系統功能可靠性、穩定性、時效性測試；以及對時效性較高的互聯網服務進行現場驗證。
4、測試工具
1）CANoe：用于采集CAN網絡車輛數據。
2）終端log分析工具：分析request、response包內數據。
3）3Gmodel解析工具：實時監控3G連接及服務數據的傳輸狀態。
4）web服務推送工具：用于集成測試階段模擬server推送服務信息。
5、測試用例示例
測試用例需明確：前提條件、測試步驟、期望結果、實際結果、測試狀態。
圖8 測試用例開發
3.3測試環境搭建
測試環境主要分為兩部分：實驗室臺架測試見圖6、道路實車路試見圖7。
實驗室臺架測試環境：BCM與IC為真實控制器，其余（含PTCAN）控制器為CANoe模擬，車載終端與IC由privateCAN連接，車載終端外接GPS天線與3Gmodel。
道路實車測試攜帶獨立導航儀、GPS定位儀、聯通3G手機等輔助設備對實時行車信息進行驗證。
圖9 Telematics臺架測試實施 圖10 Telematics實車道路測試實施
3.4測試實施
測試實施階段主要工作如下：執行測試用例、詳細記錄測試結果及bug列表、截取log文件、借助測試工具及log文件對問題原因分析及定位、缺陷跟蹤。
測試結果分析與評價工作中的重點是問題定位，明確的問題定位有利于高效的問題解決。因為Telematics功能的實現依賴于數據流轉多個環節，測試問題的原因究竟歸于哪個環節的判定尤為重要，這也是Telematics測試的難點，故在測試過程中對log的有效準確分析非常必要。
問題Log分析舉例：
1）問題描述：**餐廳預訂失敗。
2）NGTP協議Log文件：
圖11 原始log
3）log解析：
解析后的數據描述代碼：
圖12 解析后的log
紅色標注內容經過解碼后為：‘當前預訂失敗’，即server餐飲預訂服務沒有成功，問題出在遠程應用服務程序。
3.5系統回歸測試
回歸測試工作的主要內容如下：
? 歷史復測問題；
? 記錄復測問題狀態及信息
? 確認問題關閉與重開；
3.6測試結果及評價
本地終端常見問題為功能實現錯誤，重啟、死機，車載數據上傳失敗等占比約18%，發生頻率中等。
網絡通信類問題如：GPS無信號、通信網絡無信號、網絡超時嚴重、數據丟失、信號差等約占10%屬低頻問題，常見的原因有：a、路況原因（如：建筑物遮擋）b、通信模塊性能（如：長時間工作后10h以上性能下降）c、通信網絡覆蓋盲區（山區）、信號漫游臨界區域（城市邊界）。
應用服務類問題：實時交通、智能停車信息與實際不符，酒店、餐飲預訂失敗，信息服務如天氣信息無法獲取，駕駛數據或第三方數據偏差嚴重，網絡超時等，占比63%為高頻問題。可能的原因比較多，如應用服務功能本身無法實現，第三方數據整合丟失，數據融合或算法錯誤，系統性能低，服務數據分發錯誤，網絡原因等。此類問題一般涉及多節點、流轉復雜，且原因排查比較困難，這也同樣為系統集成及測試提出了更高要求。
車載CAN網絡內交叉功能，接口和功能合理性、用戶體驗度等問題分別為占比為6%與3%屬小概率事件。
圖13 測試案例問題分布圖
4 總結及展望
本文結合具體測試案例系統分析了車聯網的測試技術、方法，并在實際測試中取得了較滿意的測試結果。車聯網測試問題原因分析及定位比較困難，及時記錄并分析各環節log文件會大大提高測試效率。測試問題高發于信息服務功能、階段上處在數據融合及流轉環節，一方面印證了車聯網技術復雜、網絡異構、融合多方參與的特點；另一方面，也對車聯網架構及通信協議向統一化、標準化方向發展有一定促進意義。
車聯網的海量信息及數據流轉復雜等特點預示著自動化測試技術也是未來車聯網測試技術的一個發展方向。
