目录[-]

目录：

  1. 引言：车载测试的系统性思维
  2. 测试计划指定：明确目标与范围
  3. 测试环境搭建：软硬件工具准备
  4. 测试用例设计与理解
  5. 测试执行策略
  6. T-Box与IVI之间的关系
  7. 实战：如何测试T-Box、TSP、IVI

————————————————————

1.引言：车载测试的系统性思维

 

测试不仅仅是简单的执行测试用例，对于车载系统这类复杂系统而言，测试的本质是“验证”和“确认”，其成功取决于执行前的计划与准备。测试用例不能糊弄了事，需创建一个可复用、可扩展的车载测试框架。

————

2.测试计划指定：明确目标与范围

 

2.1 测试目标的定义

  • 功能测试：验证单个功能是否按照需求规格工作。例如：仪表盘能否正确显示车速、转速。
  • 性能测试：检验系统在特定负荷下的表现。例如，CAN总线的负载率、消息的延迟是否在允许范围内。
  • 协议一致性测试：确保设备严格遵循行业标准（如CAN、LIN、AutoSTAR等），这是设备间通信的基石。

2.2 测试范围的界定

  • T-Box 与远程服务：涉及网络连接、数据上传、远程控制等功能。
  • 组合仪表：包括警告灯、指示灯、里程信息、多媒体信息等显示逻辑。
  • CAN网络通信：通信总线负载、错误帧、消息调度与信号准确性。

2.3 资源与时间规划

  • 人员：明确测试负责人、硬件工程师、软件工程师的角色。
  • 设备：根据测试范围，列出所需的CANoe硬件、VCU、ECU、线束、电源等。
  • 周期：为环境搭建、用例执行、问题修复与回归测试预留合理时间。

————

3.测试环境搭建：软硬件工具准备

 

3.1.硬件配置清单（测试台架包括）

  • 核心接口：如 Vector 的VN系列接口卡，连接 PC 与车载网络。
  • 辅助工具：ZCANPRO、CANoe等硬件，用于模拟节点或监控总线。
  • 被测件：真实的ECU、T-Box或仪表盘，并对其提供稳定的直流电源和可靠的线束连接。

3.2 软件工具准备

  • CANoe 工程：一个完整的工程、配置仿真节点、数据库和分析窗口。
  • DBC 文件：通信的“字典”，在测试之前，需保证导入的DBC文件正确、信号和报文定义准确。
  • ZCANPRO软件：配合软硬件进行数据收发、仿真和诊断。

3.3 环境验证方法

  • 总线通信检查：使用CANoe测量总线负载，确认无大量错误帧，并能接收到预期的报文。
  • 硬件连接状态确认：所有硬件、设备供电正常，通信连接是否正确，确保物理层万无一失。

————

4.测试用例设计与理解

 

4.1 测试用例设计原则

  • 覆盖核心功能：确保所有功能点都能测试到。
  • 覆盖边界条件：针对信号的阈值进行测试（如车速为0、最小值、最大值+1等）。
  • 示例：在仪表测试中，不仅要测试正常车速下的显示，也要测试超速时的警告提示，以及信号丢失的默认值显示。

4.2 用例分类与优先级

  • 基础通信测试：确保“通信成功”。例如，检查关键报文是否周期性地在总线上出现。
  • 功能逻辑测试：验证“逻辑正确”。例如，验证当接收到特定的门信号时，仪表盘上的车门图标是否正确点亮。
  • 性能与异常测试：验证“稳定性”。例如，长期运行硬件设备，在长时间开机时，发送报文验证功能。

4.3 用例理解与评审

  • 理解DBC与工程配置：测试工程师需读懂DBC文件，理解每个信号的含义和编码方式，清楚CANoe工程每个仿真模块的作用。
  • 用例与协议关联性分析：每个测试用例都应能追溯到具体的协议规定或需求文档，确保测试的有效性和目的性。

————

5.测试执行策略：由简到难，循序渐进

 

5.1 执行顺序规划

  • 先基础后复杂：从最基本的CAN通信测试开始，确保物理层和数据链路层正常，再逐步进行应用层的复杂功能测试。
  • 先静态后动态：先进行配置检查（如DBC文件版本、工程配置），再进行仿真测试（使用CAPL脚本模拟部分ECU），最后进行实机测试（连接所有ECU）。

5.2 问题定位与日志分析

  • 使用CANoe进行故障回放或分析：记录故障时的总线数据，通过回放功能进行重现和分析，精确定位问题时间点。

5.3 测试报告与总结

  • 记录测试结果：清晰记录每个用例的通过/失败状态。
  • 问题清单：详细描述每隔缺陷的现象、复现步骤、严重程度，并附上日志和截图。
  • 改进建议：从测试过程中总结出系统设计、软件实现或测试流程本身的优化建议。

————

6.T-Box与IVI之间的关系

 

测试对象：

  • 集成式 T-Box（Telematics Box）

架构特点：

  • T-Box 作为一个独立的功能模块，在物理上与 IVI（中控娱乐系统）主机集成在一个外壳里。
  • 在电气上，T-Box 与 IVI 主机是独立的两个系统单元，通过内部CAN总线或以太网进行交互。

测试核心：

  • 将整个集成主机视为一个“黑盒”，重点关注对外（车辆网络、云端）和对内（T-Box与IVI交互）的通信行为。
  • T-Box：
    • 是车辆的“通讯员”，负责与外界（云端、卫星）沟通，并监听车辆网络。
  • 中控屏：
    • 是车辆的“平板电脑”，它是一个主动的智能设备，它与T-Box共同协作来实现功能。
  • 对外通信（对外交互）
    • 对车：通过CAN总线，跟车身、电池等零部件“通信”。
    • 对云：通过 4G/5G 网络，与TSP、手机App后台服务器“通信”。
  • 对内通信
    • T-Box 和 中控屏之间，通过内部网络（CAN、以太网较常见）交互。

一些常见的通过T-Box传输给中控显示的内容：

  1. 网络与连接状态类
    1. 移动网络信号强度：也就是手机右上角的“信号格”。
    2. 网络类型：显示 4G、5G 图标。
    3. Wi-Fi 连接状态：显示是否连接到Wi-Fi，以及信号强度。
    4. 热点状态：当车辆开启车载热点时，显示热点已激活。
  2. 车辆状态与报警类
    1. 车门/车窗未关提醒：T-Box 通过CAN总线获得车门状态，然后触发中控屏显示动画警告。
    2. 车辆防盗警报通知：当车辆被撞或非法进入时，T-Box接收到警报信号，在中控屏上弹出严重警告。
    3. 胎压异常报警：胎压数据通过CAN总线传给T-Box，T-Box再转给中控屏，显示具体的动画，那个方向的胎压存在问题。
  3. 远程控制状态与结果类
    1. 远程空调控制：中控显示空调页，且显示“空调已开启”，并显示设定的温度。
    2. 车窗/天窗远程通风：显示“车窗正在开启”。
    3. 车辆定位/寻车：中控屏显示“正在向服务器发送位置”，或者直接显示“指令已执行”。
  4. 导航与位置服务类
    1. GPS定位状态：显示GPS图标，表示正在定位或已定位。
    2. 导航目的地下发：用户在手机APP上设置目的地，发送到云端，再通过T-Box推送给中控导航系统，并自动开始导航。
  5. 系统与更新类
    1. OTA升级提示：当T-Box检测到有新的软件版本时，会触发中控屏弹出升级提示窗口。
    2. 系统时间：车辆的时间经常是通过T-Box从网络获取并同步给中控屏幕的。

————

7.实战：如何测试T-Box、TSP、IVI

 

核心思想：采用由内到外，分模块与端对端结合的策略。先确保各个模块自身功能正确，再验证二者之间的接口，最后进行完整的用户体验流程测试。先“单元测试”，后“集成测试”。

T-Box 测试方法设计

第一步：明确测试范围与架构分析

  1. 界定测试边界：
    • 上游接口：车辆内部网络（主要是 CAN/CAN FD 总线，可能涉及车载以太网）。
    • 下游接口：蜂窝网络（通信用）、GNSS天线（定位用）。
    • 核心测试目标：T-Box 的协议转换能力、数据处理逻辑、网络管理和故障恢复机制。
    • 关联系统：TSP平台、IVI系统。
  2. 搭建测试环境：
    • 必备环境：T-Box 测试台架，包括T-Box被测件、电池、线束。
    • 工具准备：
      • 网络及报文模拟与监控工具：CANoe用于模拟整车网络、监控T-Box的CAN报文收发。
      • 无线信号模拟器：
        • 蜂窝模拟器：模拟基站，用于创建可控的网络环境（如4G/5G信号强度、网络制式）。
        • GNSS模拟器：模拟卫星，用于提供精准、可重复的定位信号（静态坐标或动态轨迹）。
      • TSP后台模拟器/真实后台：用于接收T-Box上报的数据，并向下发送远程控制指令。
      • 电源：模拟车辆电源工况，通常使用稳定的直流供电电源（如正常供电、低压、断电）。

第二步：设计测试用例与执行

将测试分为五个关键维度，并按步骤执行：

  1. 业务功能测试
  2. 性能与稳定性测试
  3. 协议一致性与容错测试
  4. 定位功能
  5. 网络功能

维度1：业务功能测试（上传-下达功能是否正确）

  • 目标：验证 T-Box 最核心的“上传-下达”功能。
  • 方法：
    1. 车辆数据上报验证：
      • 步骤：使用CANoe模拟整车CAN网络，周期性地发送特定的车辆信号（如：车速60km/h，左前门状态=开启）。
      • 验证：TSP后台是否收到T-Box上传的报文信息。
    2. 远程控制指令执行验证：
      • 步骤：通过 TSP 后台向 T-Box 下发一条“远程解锁”指令。
      • 验证：CANoe是否在CAN总线上捕获一条符合DBC文件定义的、信号值为“解锁车门”的报文。同时，T-Box是否向TSP返回“指令执行成功”的确认。
    3. 事件触发报警验证：
      • 步骤：使用车辆模拟器（CANoe）发送一条“碰撞信号”或“SOS报警”。
      • 验证：TSP后台是否成功创建一条高优先级的告警事件，并触发业务流程（如：在管理后台生成一条记录）
      • 真实案例：别克汽车安吉星功能，当触发比较严重的交通事故如撞车、追尾等，安吉星相关人员会打电话给车主，询问是否有人员伤亡，是否需要安吉星人员帮忙报警、打救护车电话。在报警、拨打救护车电话时，安吉星人员也掌握车主的准确位置。

维度2：性能与负载测试（它的性能如何）

  • 目标：验证TSP在长期运行、高并发、大数据量下的处理能力。
  • 方法：
    1. 通信响应时间测试：
      • 步骤：使用CANoe发送一条信号，并精准记录从发送到TSP后台接收到信号的时间差。
      • 验证：延迟时间是否在要求范围内（如：关键信号小于2秒）。
    2. 网络适应性测试：
      • 步骤：使用蜂窝模拟器，逐步降低信号，并观察T-Box的数据上报成功率。模拟网络切换和断线重连。
      • 验证：T-Box在弱信号下，是否能降级工作，断线后是否能在网络恢复时自动、快速重连，并补发缓存数据。
    3. 耐久性与压力测试：
      • 步骤：在台架测试环境下，T-Box持续工作12小时甚至更久，再高频次的发送各种事件。
      • 验证：T-Box是否出现死机、重启、内存泄露或数据丢失的现象。可通过adb命令，将T-Box对应设备通过usb线连接到电脑进行调试。

维度三：协议一致性与容错测试（它是否遵循规则、出错时的表现）

  • 目标：验证T-Box严格遵循通信协议，并能处理异常情况。
  • 方法：
    1. 报文一致性测试：
      • 步骤：使用CANoe的CAPL脚本，精确校验T-Box发出的所有CAN报文的周期、信号精度、初始值、边界值等，是否符合DBC定义。
      • 验证：任何不符合DBC的报文都是缺陷。
    2. 非法报文与错误注入测试：
      • 步骤：使用CANoe向T-Box发送错误帧、非法报文ID、信号值超出合理范围的报文。
      • 验证：T-Box的电源管理模块能否正常工作，在异常恢复后，能否自动进入正常状态。

维度四：定位功能测试（它的定位是否准确、是否支持复杂环境）

  • 目标；验证GNSS定位功能。
  • 方法：
    1. 定位精度与首次定位时间测试；
      • 步骤：使用GNSS模拟器模拟一个静态坐标（如：北京天安门）和一条动态轨迹，记录从T-Box启动到输出第一个有效定位数据的时间。
      • 验证：T-Box上报给TSP的位置信息是否与GNSS模拟器设定一致，精度是否准确（小于5米），冷启动、热启动的定位时间是否满足要求。
    2. 复杂环境模拟：
      • 步骤：使用GNSS模拟器，模拟山路（信号差）、隧道（信号丢失）等场合。
      • 验证：在信号丢失期间，到信号恢复，定位能否恢复。
      • 真实案例1：在美行科技测试导航期间，经常出现实车测试在途径五爱隧道时，定位到浑河里，并且，在出了隧道后，GPS定位也没有恢复。
      • 真实案例2：实车测试，走本溪盘山公路时，有几率出现，GPS定位不在道路上，而是定位到了道路以外的群山之中。
      • 真实案例3：冷启动，打开“高德地图”，有几率出现GPS定位失效，一直处于灰色信号，并且无法恢复，系统缺乏超时复位机制。

维度五：蜂窝网络测试（它的网络连接可靠么）

  • 目标：验证T-Box在真实网络场景下的注册、连接、数据传输和恢复能力。
  • 方法：
    1. 网络注册测试：
      • 步骤：使用蜂窝模拟器，模拟不同运营商（移动、联通、电信）的网络，以及不同网络制式（4G/5G），控制T-Box上电或唤醒。
      • 验证：T-Box能否在规定的时间内成功注册到网络，并且获得IP地址，检查是否符合设计。
    2. 数据传输稳定性测试：
      • 步骤：在T-Box成功注册网络后，使用CANoe持续模拟车辆数据，监控TSP后台的数据传输。
      • 验证：长时间运行下， 数据传输链路是否稳定，有无异常断连、数据丢包或传输错误。
    3. 网络切换与漫游测试：
      • 步骤：使用蜂窝模拟器，模拟T-Box在行驶中发生基站切换，以及不同国家、地区的网络漫游场景。
      • 验证：T-Box在切换和漫游过程中，业务是否中断、中断时间多长，能否自动恢复。
    4. 弱信号与断网恢复：
      • 步骤：使用蜂窝模拟器，逐步降低信号强度，持续一段时间，最后回复信号。
      • 验证：
        • 在弱信号时，T-Box能否通过降低速度、重试机制，尽力维持通信。
        • 断网期间，T-Box是否具备数据缓存机制。
        • 网络恢复后，T-Box能否自动重连，并成功补发缓存数据。

IVI与T-Box、TSP交互的核心逻辑

 

IVI——》T-Box——》TSP：IVI将用户通过触摸、语音等方式发起的服务请求（如设置导航目的地、查询车辆状态等）发送给T-Box，由T-Box将请求转发给TSP云端服务器；同时，IVI也会将本地用户的偏好和设置同步给T-Box并上报到TSP。

TSP——》T-Box——》IVI：TSP云端服务器将处理后的服务数据、以及来自手机APP的远程命令（如下发开启空调命令）下发给T-Box，由T-Box转发给IVI进行显示与播报；同时，TSP下发的各类通知（如服务到期提醒、车辆告警信息等）通过IVI呈现给用户。

通俗点解释：

  1. IVI是前台：直接面向最终用户（驾驶员、乘客），接收请求（触屏点击），并将经过T-Box和TSP处理后的数据，以直观的形式显示出来。
  2. T-Box是通信兵：负责前台和总部之间传递消息，它并不面向用户也不生成服务，但是所有的内外通信必须经过他。
  3. TSP是指挥总部：处理来自IVI或者手机APP发来的请求，并下达给T-Box指令。

 

 

END