测试环境主要分为两部分：实验室台架测试见图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文件会大大提高测试效率。测试问题高发于信息服务功能、阶段上处在数据融合及流转环节，一方面印证了车联网技术复杂、网络异构、融合多方参与的特点；另一方面，也对车联网架构及通信协议向统一化、标准化方向发展有一定促进意义。
