1. 背景
智能座舱是当前汽车行业开发设计和差异化竞争的焦点，当前智能座舱控制器多为整合了传统IPK、HMI、HUD、DMS等若干控制器之后的“一机多屏”的复杂系统。在软件架构上，多操作系统也是其一大特点，如整合安卓和QNX系统是最常见的方案，而在硬件接口上通常是车载以太网、CAN/CAN FD以及LVDS等。
座舱域控制器由于自身特点，其功能测试用例多达几万条甚至十几万条，完全依靠传统手动测试，需要投入大量的人力资源，难以满足越来越短的项目开发周期和软件快速迭代的需求。为了提高测试效率，需采用自动化/半自动化的方式以完成座舱域控制器的功能测试。
2. 测试内容分析
从智能座舱域部件级的功能测试角度来看，主要聚焦如下几方面的测试：
车辆和环境信息显示功能：中控、仪表、HUD、流媒体后视镜、电子后视镜、A柱等显示交互
娱乐、浏览功能：本地和在线的媒体播放、游戏以及文档和网页浏览阅读等
配置、设置和控制功能：个人账户、车辆/驾驶信息设置、APP安装/卸载等
AR导航、环视、后视、夜视等功能
车内监测：驾驶员/乘员头、脸、眼监测功能和健康监测
交互功能：语音交互、手势控制
用户APP在线和离线服务功能
连接功能：蓝牙、WiFi、USB，4G/5G等
3. 测试系统框架
从座舱自动化测试系统的角度，可将满足智能座舱测试系统划分为如下几个主要的功能模块：
常规的车载网络和IO仿真采集及故障注入
UE仿真及监测
图像仿真及UI监测
语音仿真及识别
无线信号相关的仿真
完整测试系统示意图如下所示，本文将重点介绍基于Eggplant实现UE仿真及UI监测的流程和基本方法及各种主流方案的对比。
图1：测试系统框图
4. 基于Eggplant的自动化测试简介
4.1. 软件及方案框架
Eggplant是TestPlant公司研发的一款黑盒自动化测试工具，通过VNC/RDP传输协议连接PC和DUT，可跨平台（Linux、Mac、ISO、QNX、安卓和 Windows）使用。其基于图像和OCR算法实现对DUT图像监测，方便访问图像的各种状态（颜色及亮度），同时支持在使用Flash的动态环境中运行。可通过记录用户操作流程，自动生成测试脚本。且集成的SenseTalk语言，面向非开发人员，测试者无需了解底层代码和架构，简单易用。
支持与Vector CANoe集成，通过CANoe发送操作指令，执行结果自动生成HTML格式方便查看。
图2：CANoe+vTESTstudio+Eggplant 整体方案框架
4.2. 实现流程概述
本次以安卓系统的DUT为例，进行CANoe、vTESTstudio、Eggplant联合调试，调试过程主要分为如下步骤：
· 测试系统与DUT连接设置： 打开DUT调试权限，连接PC，对安卓系统进行连接设置，生成Server端的IP地址和端口号，用于在Eggplant软件中对DUT进行连接。
图3：连接效果图
· Eggplant测试工程创建： 使用Eggplant进行UE仿真及UI监测底层脚本编写、运行并执行测试。使用Eggplant中的Log功能，对测试结果进行记录。
图4：Eggplant运行界面展示
· CANoe对Eggplant测试工程调用： 根据Eggplant软件提供的API，使用CANoe软件对Eggplant测试工程进行调用。在CANoe工程中需填写Eggplant测试工程相关信息，如：软件安装地址、测试工程存储地址、端口号和密码等信息。
图5：在CANoe工程中配置Eggplant测试工程信息
·“对手件”的仿真实现（可选）： 针对基于SOA实现的座舱域控制器，需仿真与之交互的“对手件”，如车辆域控制器、自动驾驶域控制器、网联控制器，针对此需求，可以借助新版CANoe对SOME/IP、MQTT等协议的支持，通过导入数据库（如.arxml）等方式高效的完成SOA应用的仿真，以我们的经验来看，基于CANoe实现该仿真更为高效和专业。
·测试用例实现： 基于vTESTstudio软件图形化编程方式实现测试脚本编写，编译生成可执行文件，导入到CANoe中进行测试执行。
图6：基于vTESTstudio实现测试脚本编写
·测试执行与分析： 通过CANoe对Eggplant测试结果进行读取和判断，并将原始图像等打印在测试报告中，便于对测试问题进行分析。
图7：测试报告样式
5. 方案对比
5.1. UE仿真测试方案对比
UE仿真是为模拟用户操控，如软按键单击/双击、屏幕滑动，其难点：
·适配多级窗口操作
·操作界面设计变更后和被操作对象更换后的重新适配
·实现特殊操控方式，如多指点击/滑动、两指缩放
表1：UE仿真测试方案对比
5.2. UI和UE监测测试方案对比简介
UI和UE监测用以判断功能逻辑正确性和性能，其难点：
· 多屏互动
· 显示风格切换、APP动态加载识别适配
· 动态闪烁类图标监测、屏幕响应时间监测
表2：UI和UE监测测试方案对比
6. 总结
从早期仪表/中控至现在的智能座舱，对其自动化测试的尝试，已有十多年的时间，当下的被测对象更为复杂，测试方案不断升级，测试要求也不断提高，此时需要我们从测试需求本源，结合座舱域控制器的特点，进行理性分析或复盘。我们需要自动化但不一味追求全自动化，需要细分不同测试功能，其测试工作的资源消耗，其自动化的可行性和适应性，其投入产出比等多重因素下进行综合考虑。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
