第四篇：集成测试（流程与实战）

4.1 集成测试基础概念✓

4.1.1 什么是集成测试

定义：集成测试（Integration Testing）是在单元测试完成后，将多个已验证的模块/组件按照设计要求组合在一起，验证模块间接口正确性、数据交互完整性以及协同工作能力的测试阶段。

车载测试中的定位：

单元测试 → 集成测试 → 系统测试 → 验收测试
  (白盒)    (灰盒)      (黑盒)      (黑盒)
  模块内    模块间       整车级      客户视角

集成测试是承上启下的关键环节——单元测试只保证单个模块"自己能跑"，集成测试保证多个模块"凑在一起能正确协作"。在车载领域，一个功能往往涉及多个 ECU（Electronic Control Unit，电子控制单元）协同，例如"一键启动"涉及 BCM（车身控制模块）、PEPS（无钥匙进入启动）、仪表、发动机 ECU 等多个模块，集成测试就是验证这些模块间的信号交互是否正确。

4.1.2 集成测试 vs 其他测试阶段

关键区别：集成测试不关心模块内部实现（那是单元测试的事），也不关心整车用户体验（那是系统/验收测试的事），它聚焦的是"模块之间的接口和交互"。

4.1.3 车载集成测试的特殊性

与纯软件（如 Web/App）集成测试相比，车载集成测试有以下本质差异：

1. 多域协同，跨域交互复杂

• 座舱域（Infotainment）、智驾域（ADAS）、车身域（Body）、动力域（Powertrain）、底盘域（Chassis）
• 一个用户操作可能触发跨 3-5 个域的信号流转，例如"驾驶员开门上车"涉及车身域（门状态）、座舱域（座椅记忆/欢迎界面）、动力域（上电准备）

2. 多总线混合通信

• CAN（Controller Area Network，控制器局域网）：车身控制、动力传动
• LIN（Local Interconnect Network，局域互联网络）：车窗、座椅、后视镜等低速设备
• Automotive Ethernet：智驾大数据传输、诊断（DoIP）、OTA
• 集成测试需验证跨总线信号网关转发的正确性和实时性

3. 软硬件深度耦合

• HMI（Human-Machine Interface，人机界面）上层应用 ↔ 中间件（Android Auto/AUTOSAR）↔ 底层驱动 ↔ 硬件外设
• 一个"蓝牙连接失败"可能是 App 问题、协议栈问题、驱动问题或天线硬件问题，集成测试需逐层定位

4. 实时性与安全性要求极高

• 动力/底盘相关信号延迟要求毫秒级，超时可能导致功能安全事故
• 需遵循 ISO 26262 功能安全标准，ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）等级越高，测试越严格

4.2 汽车开发周期中的集成测试✓

4.2.1 汽车开发全流程回顾

汽车产品开发遵循严格的阶段门（Stage-Gate）流程，主流车企（大众、通用、比亚迪等）普遍采用以下 10 个阶段：

4.2.2 集成测试介入节点与重点

PPV 阶段（工艺验证）—— 集成测试启动

• 准入条件：首个可运行的集成版本（Alpha 版）、基础测试环境就绪
• 测试重点：核心功能冒烟测试，验证模块间基本通信是否打通
• 典型活动：CAN 总线信号连通性测试、上电启动流程验证、基础 HMI 功能冒烟
• 退出标准：核心功能无阻塞性问题，可进入全量集成测试

PP 阶段（预试生产）—— 集成测试全面展开

• 测试重点：全量集成用例执行、跨域功能验证、异常场景测试
• 典型活动：每日版本冒烟 + 轮次全量测试、缺陷跟踪闭环、性能基线测试
• 退出标准：严重及以上缺陷清零，一般缺陷率低于阈值，核心功能稳定

P 阶段（试生产）—— 集成回归测试

• 测试重点：针对 PP 阶段缺陷修复的回归验证、量产配置适配测试
• 典型活动：每轮版本回归测试、量产硬件差异验证、老化/稳定性测试
• 退出标准：回归用例 100% 通过，无新增严重缺陷

SOP 前后 —— 集成验收锁定

• 测试重点：最终量产版本集成验收、已知问题清单确认、交付文档归档
• 典型活动：Golden Sample（黄金样车）测试、交付评审、测试报告签署
• 退出标准：验收通过，版本锁定为量产基准版本

4.2.3 版本管理与迭代节奏

版本类型定义：

车企典型迭代节奏：

• 开发团队：每日构建（Daily Build），开发自测
• 集成测试：每周 1-2 个提测版本，执行冒烟 + 全量
• 稳定版交付：集成团队每周选出一个稳定版（RC）交付系统测试
• 系统测试：每周一版本节奏，基于集成稳定版执行系统级测试

4.3 集成测试五大核心流程✓

4.3.1 需求分析与用例设计

核心输入文档：

用例设计四大方法：

1. 等价类划分：将输入域划分为有效等价类和无效等价类，每个等价类选取代表性数据
2. 车载示例：蓝牙配对密码（4-8 位数字）→ 有效类（4位、6位、8位）、无效类（3位、9位、含字母）
3. 边界值分析：针对等价类边界取值，包括最小值、略大于最小值、正常值、略小于最大值、最大值
4. 车载示例：温度显示范围（-40°C ~ 85°C）→ 边界值 -40、-39、0、84、85
5. 场景法：基于用户使用场景，通过基本流和备选流组合设计用例
6. 车载示例："导航目的地设置"场景 → 基本流（语音输入→识别→规划→开始导航）、备选流（识别失败→手动输入、网络异常→离线地图）
7. 错误推测法：基于经验推测可能出错的情况，针对性设计用例
8. 车载示例：蓝牙连接时突然来电、OTA 升级中断电、USB 插拔频繁切换

用例编写规范：每条用例包含用例编号、所属模块、前置条件、测试步骤、预期结果、优先级（P0/P1/P2）、用例类型（功能/接口/异常/性能）。

4.3.2 版本获取与刷写

版本获取流程：

1. 从版本管理平台（如 GitLab CI 制品库、内部 FTP、OTA 后台）获取当日待验证版本
2. 核对版本号、构建时间、变更说明，确认是目标版本
3. 校验文件 MD5/SHA256，确保文件完整未损坏

车载常见刷写方式：

刷写注意事项：

• 车辆电量充足（建议接稳压电源或电瓶充电器），防止刷写中途断电
• 刷写前确认版本与硬件配置匹配（不同车型/配置可能有不同版本）
• 刷写过程中不要操作车辆、不要断电、不要拔插诊断设备
• 刷写完成后需验证版本号、执行功能自检，确认刷写成功
• 保留上一个稳定版本，必要时可回退

4.3.3 测试执行

座舱测试 vs 智驾测试差异：

三层执行策略：

┌─────────────────────────────────────┐
│  第一层：冒烟测试（Smoke Test）       │
│  目的：快速验证版本是否可测            │
│  范围：核心功能 20-30 条用例          │
│  时长：30 分钟 ~ 1 小时               │
│  通过标准：P0 用例 100% 通过          │
│  不通过 → 打回开发，版本作废           │
├─────────────────────────────────────┤
│  第二层：全量测试（Full Test）         │
│  目的：覆盖全部集成测试用例            │
│  范围：该模块/域全部用例               │
│  时长：1-3 天（视用例规模）            │
│  通过标准：按轮次缺陷收敛曲线评估       │
├─────────────────────────────────────┤
│  第三层：回归测试（Regression Test）   │
│  目的：验证缺陷修复，确保无引入新问题   │
│  范围：缺陷关联用例 + 受影响功能用例    │
│  时长：每轮版本 0.5-1 天               │
│  通过标准：回归用例 100% 通过          │
└─────────────────────────────────────┘

测试执行注意事项：

• 执行前确认测试环境（硬件版本、软件版本、配置参数）与用例要求一致
• 严格按照用例步骤执行，不要随意跳过或修改步骤
• 实际结果与预期不符时，先复现确认，再提缺陷
• 执行过程中做好记录（用例执行状态、缺陷编号、备注）
• 每日同步测试进度，遇到阻塞问题及时反馈

4.3.4 缺陷管理与提票流程

标准提票四步流程：

发现 BUG
   ↓
① 回归验证（确认可复现，记录复现概率）
   ↓
② 拉日志（应用日志 + 系统日志 + 总线日志，时间对齐）
   ↓
③ 拍摄视频/截图（记录复现操作过程和异常现象）
   ↓
④ 提交缺陷票（含完整信息，指派给对应开发）

缺陷分级标准：

缺陷生命周期：

新建(New) → 指派(Assigned) → 修复中(Fixed) → 待验证(Resolved)
    ↑              ↓              ↓
    │         驳回(Rejected)   验证通过 → 关闭(Closed)
    │         (非问题/重复)     验证不通过 → 重新打开(Reopened)
    └──────────────────────────────────────────────────────┘

一个高质量缺陷单应包含：

• 缺陷标题：简洁描述问题（如"[蓝牙] 连接 iPhone 15 后播放音乐无声音"）
• 所属模块/域：如座舱-蓝牙
• 缺陷等级：P0/P1/P2/P3
• 前置条件：测试环境、版本号、硬件配置
• 复现步骤：1/2/3... 清晰可执行
• 预期结果：按需求应该是什么
• 实际结果：实际发生了什么
• 复现概率：必现/偶发（X 次出现 Y 次）
• 附件：日志文件、视频、截图
• 指派给：对应开发人员

常用缺陷管理工具：Jira（外企/新势力主流）、禅道（国内车企常用）、Redmine、TestRail。

4.3.5 测试日报与沟通机制

测试日报标准模板：

==================== 集成测试日报 ====================
日期：2026-08-21
测试版本：V2.3.1_RC3
测试人员：张三、李四
======================================================

一、今日测试进度
- 冒烟测试：25/25 通过 ✅
- 全量测试：蓝牙模块 80/120，导航模块 60/90
- 回归测试：上轮缺陷 15 个，验证通过 12 个，3 个未修复

二、缺陷统计
- 今日新增：8 个（P0:0, P1:2, P2:4, P3:2）
- 累计未关闭：23 个（P0:0, P1:5, P2:12, P3:6）
- 今日关闭：5 个

三、风险与阻塞
- ⚠️ 蓝牙 P1 缺陷"连接 iPhone 15 无声"已 3 天未修复，影响蓝牙模块测试
- ⚠️ 导航模块今日提测版本冒烟不通过，已打回，影响导航测试进度

四、明日计划
- 继续蓝牙模块剩余 40 条用例
- 导航模块等待新版本提测
- 验证今日修复的 5 个缺陷

======================================================

沟通渠道：

• 邮件：正式日报发送给项目组全体（项目经理、开发、测试、产品），留痕可追溯
• 微信群/飞书群：图片版日报快速同步，@相关责任人提醒紧急问题
• 每日站会：15 分钟站会，同步进度、风险、需要协调的事项
• 缺陷评审会：每周 1-2 次，评审争议缺陷、确认缺陷优先级、跟踪严重缺陷进度

扩展报告类型：

• 测试周报：本周测试总结、缺陷趋势分析、风险评估、下周计划
• 测试月报：月度质量分析、缺陷收敛曲线、版本质量评估、测试效率指标
• 版本测试报告：每个版本测试完成后的总结报告，包含测试范围、用例执行率、缺陷统计、质量评估、是否可发布的结论
• 测试总结报告：项目结束后的整体测试总结，经验教训沉淀

4.4 组织架构与协作✓

4.4.1 项目团队角色与职责

4.4.2 集成测试与开发的协作机制

需求评审阶段：

• 测试提前介入需求评审，从可测试性角度提出意见
• 关注需求是否明确、是否有量化指标、是否有异常场景定义
• 如需求模糊，当场提出并要求产品澄清，避免后期理解偏差

用例评审：

• 测试编写完用例后，组织开发参与用例评审
• 开发确认用例是否覆盖了所有功能点、是否有理解偏差
• 测试确认用例的可执行性、前置条件是否合理

提测标准（DoD - Definition of Done）：
开发提测必须满足：

1. 代码已合入集成分支，构建通过
2. 开发自测通过，提供自测报告
3. 提供《变更说明》：本次变更内容、影响范围、测试建议
4. 冒烟用例（开发自测的核心用例）100% 通过
5. 数据库/配置变更已提供升级脚本

缺陷沟通规范：

• 测试提缺陷必须包含：复现步骤、日志、视频三要素
• 开发收到缺陷后 24 小时内响应（确认/驳回/询问）
• 如开发认为"不是问题"，需在缺陷评论中说明理由并引用需求依据，由产品/测试主管评审
• 严重缺陷每日同步进度，直至关闭

4.4.3 集成测试与系统测试的衔接

稳定版交付标准：
集成测试交付系统测试的版本必须满足：

1. 阻塞性（P0）缺陷清零
2. 严重（P1）缺陷率低于 5%（或按项目约定阈值）
3. 核心功能冒烟用例 100% 通过
4. 集成测试用例执行率 ≥ 95%
5. 性能指标达到基线要求（如启动时间、响应延迟）

交付物清单：

• 《版本测试报告》：测试范围、用例执行情况、缺陷统计、质量评估
• 《已知问题清单》：未修复缺陷列表、影响范围、规避方案
• 《用例执行记录》：用例通过率、未执行用例及原因
• 《变更说明》：本版本相对于上一版本的变更内容

交接会议：

• 集成测试主管向系统测试团队介绍版本情况
• 说明版本亮点、已知风险、测试建议重点
• 系统测试团队提问，确认测试范围和优先级
• 会议纪要存档，作为交付确认依据

4.5 专项测试技术✓

4.5.1 总线通信测试

CAN 总线测试要点：

• 报文周期：验证报文发送周期是否符合规范（如 10ms、100ms、1s），周期抖动是否在允许范围内
• 信号值：验证信号物理值是否正确（如车速、转速、温度），初始值、范围、精度是否符合 DBC 定义
• DBC 文件：DBC（Database CAN）是 CAN 信号定义文件，测试需基于 DBC 解析报文，确认信号定义与实际一致
• 总线负载：验证总线负载率是否在合理范围（一般 < 30%，高峰 < 60%），过高会导致报文延迟或丢失
• 错误帧：监控总线是否有错误帧（Error Frame），频繁错误帧说明总线物理层或节点有问题

LIN 总线测试要点：

• 主从节点通信：验证主节点（Master）调度表（Schedule Table）是否正确轮询从节点（Slave）
• 唤醒机制：验证从节点可通过总线唤醒信号唤醒主节点（如车门 LIN 从节点唤醒 BCM）
• 调度表切换：验证不同场景下调度表切换是否正确（如正常模式/诊断模式/休眠模式）

Automotive Ethernet 测试要点：

• SOME/IP：Scalable service-Oriented MiddlewarE over IP，验证服务发现（Service Discovery）、服务订阅、远程调用是否正常
• DoIP：Diagnostic over Internet Protocol，验证基于以太网的诊断通信是否正常（UDS over DoIP）
• TSN：Time-Sensitive Networking，时间敏感网络，验证时间同步、流量调度是否符合要求

常用工具：

• CANoe（Vector）：总线仿真、分析、测试一体化工具，车载测试行业标准
• Wireshark：以太网报文抓包分析
• PCAN / ValueCAN：USB 转 CAN 适配器
• Python + python-can / can-isotp：自动化总线测试脚本

4.5.2 诊断协议测试（UDS）

UDS 基础：
UDS（Unified Diagnostic Services，统一诊断服务）是基于 ISO 14229 标准的诊断协议，是车载 ECU 诊断的通用标准。UDS 基于请求-响应模式，测试端（Client）发送请求，ECU（Server）响应。

核心服务速查表：

UDS 测试用例设计思路：

• 正向测试：每个服务在正确会话、正确安全等级下，发送合法请求，验证响应正确
• 异常测试：
• 会话不匹配：在默认会话下发送需要扩展会话的服务（如 0x2E 写数据），验证拒绝响应（NRC 0x7F 服务不支持/0x7E 会话不支持）
• 安全等级不足：未通过 0x27 安全访问就发送需要安全的服务，验证拒绝响应（NRC 0x33 安全访问被拒绝）
• 参数非法：发送非法的 DID、数据长度、子功能，验证拒绝响应（NRC 0x31 请求超出范围）
• 时序异常：0x27 安全访问种子超时后再发送密钥，验证拒绝响应

常用工具：CANoe（UDS 面板）、Vector DiVa（自动化 UDS 测试）、PCAN-UDS、Python（python-uds / can-isotp）。

4.5.3 OTA 测试

OTA 升级流程：

版本检测 → 下载 → 校验 → 安装 → 重启 → 版本验证
   ↓         ↓       ↓       ↓       ↓       ↓
  云端推送  差分包/  MD5/   写入    A/B分区  读取版本
  主动查询  全量包   SHA256  Flash   切换     号确认

升级方式：

• 全量升级：下载完整固件包，覆盖写入。优点是简单可靠，缺点是包体大、下载时间长
• 差分升级（A/B 分区）：设备有 A/B 两个系统分区，当前运行在 A 分区，升级包写入 B 分区，写入完成后重启切换到 B 分区。优点是升级失败可回退到 A 分区，不影响使用；缺点是需要双倍 Flash 空间

OTA 测试场景矩阵：

OTA 测试工具：OTA 后台管理平台（推送版本、查看升级状态）、CANoe（监控升级过程总线信号）、电源模拟器（模拟断电/低压）、网络损伤仪（模拟弱网/断网）。

4.5.4 HMI 集成测试

多屏交互测试：

• 仪表、中控、副驾屏、HUD（Head-Up Display，抬头显示）之间的状态同步
• 例如：中控设置导航目的地 → 仪表显示导航箭头 → HUD 显示转向提示
• 测试关注点：状态同步实时性（延迟 < 500ms）、多屏显示一致性、异常状态处理（某屏故障时其他屏不崩溃）

语音交互集成测试：

• 语音指令 → 语音识别（ASR）→ 语义理解（NLU）→ 执行指令 → HMI 反馈
• 测试关注点：识别准确率、响应速度、多轮对话、跨域指令（如"导航到最近的充电站并打开空调"涉及导航+空调两个域）
• 常见问题：识别错误、语义理解偏差、执行后无反馈、语音与 HMI 不同步

手机互联测试：

• CarPlay（苹果）、HiCar（华为）、CarLife（百度）、Android Auto（谷歌）
• 测试关注点：连接稳定性（有线/无线）、数据同步（通讯录、音乐、导航）、通话质量、多手机切换、连接异常恢复

4.5.5 电源与休眠唤醒测试

静态电流测试：

• 车辆休眠后，各模块电流消耗总和（即暗电流）需在标准范围内（一般 < 50mA，高端车型 < 30mA）
• 测试方法：车辆锁车休眠后，用电流探头或万用表串联电瓶，测量休眠 30 分钟后的稳定电流
• 超标的危害：车辆停放 1-2 周后电瓶亏电，无法启动

休眠唤醒流程：

KL15 下电（熄火）
   ↓
各模块收到下电信号，执行休眠准备（保存数据、关闭外设）
   ↓
模块进入休眠模式（低功耗，仅保留唤醒检测）
   ↓
唤醒源触发（车门打开、遥控钥匙、远程 App、定时唤醒）
   ↓
对应模块唤醒 → 通过总线唤醒其他模块 → 系统上电就绪

异常场景测试：

• 低压启动：模拟电瓶电压低（如 9V），验证模块是否能正常启动或进入欠压保护
• 掉电恢复：运行中突然断电，恢复供电后模块是否能正常启动、数据是否丢失
• 休眠中总线唤醒：休眠状态下发送总线唤醒信号，验证模块是否正确唤醒
• 唤醒风暴：多个唤醒源短时间内频繁触发，验证模块是否能正确处理不崩溃

4.5.5.2 冷启动 vs 热启动

核心判断标准：锁车后是否超过“10 分钟阈值”（不同车型略有差异：银河 A7 为 10 分钟，赛力斯 SF5 海外版为 5 分钟，吉利油车为 3 分钟）：

• 热启动（相当于“待机唤醒”）：锁车后 10 分钟内回到车上启动。此时车辆没完全下电，还处于“待机状态”，屏幕直接点亮，几乎不用等
• 冷启动（相当于“重新开机”）：锁车后超过 10 分钟再启动。此时车辆已自动完全下电，中控、仪表都要重新启动，还会出现启动动画

冷启动 vs 热启动对比：

座舱如何判断是冷启动还是热启动：

• 看开机画面：最直接的方法。启动时看到完整品牌 Logo 动画 → 基本是冷启动；屏幕瞬间点亮直接进入主界面或桌面 → 热启动
• 感受启动速度：冷启动需等待（10 秒以上）；热启动非常迅速（2~3 秒内）
• 留意功能响应：冷启动后，倒车影像、语音助手等功能的初次响应可能有延迟；热启动后这些功能通常即刻可用
• 观察停车时长：经验法则。熄火超过一定时间（通常 24 小时，具体因车而异），下次启动大概率是冷启动
• 参考车辆状态：部分高端车型会根据电瓶电量自动决定启动方式。电瓶电量不足时，系统可能自动关闭“休眠”模式，强制冷启动以保证下次能正常点火

快启中所谓的“断电”：

• 断掉（冷启动）：核心计算单元的供电，包括 SoC（系统级芯片）的 CPU 核心、GPU（图形处理器）以及最重要的 DDR 内存（运行内存）。内存一旦断电，临时数据全部丢失，下次开机必须重新从闪存（eMMC/UFS）加载完整操作系统，这就是冷启动慢的根本原因
• 不断（热启动/快启）：常电待机单元的供电。车辆熄火后，车机保留 PMIC 自身、唤醒控制器（CAN 收发器）和 DDR 内存的自刷新电压。此时内存数据被保留，屏幕和 CPU 核心处于“休眠断电”状态。一旦开门或按启动键，CPU 核心瞬间恢复供电，直接从保留的内存数据中恢复系统 —— 这就是“秒开”的原理

座舱冷 / 热启动判断经验（思维导图：电源管理）：

• 有快启功能的车型：24 小时内启动车辆无开机动画，实际上车辆已经是冷启动状态
• 快启下如何判断是冷启动：看语音、360、多媒体等模块首次打开是否有延迟，有延迟即为冷启动
• 热启动判断：上电无开机动画、应用打开响应较快

4.5.5.3 电源模式迁移（油车 / 电车 / 混动）

（1）油车电源模式迁移图：

（2）电源工作模式说明：

（3）电源状态机切换（中控 MMI）：

（4）电车电源模式迁移图（EV without SSB，【考点】usage mode）：

车辆模式分为 Abandoned → Inactive → Convenience → Active → Driving 五个状态：

五种模式说明（模式定义卡片）：

模式切换补充说明：

• Inactive → Abandoned：下电后中控仪表熄屏，但座椅和车窗部分功能可以用，此时车辆总线通讯没有断；进入 Abandoned 后总线通讯全部断开，座椅车窗无法调节
• Convenience：解锁车辆后打开主驾车门，中控仪表点亮的状态。该模式娱乐功能可以使用，座椅车窗等可以调节，动力底盘无法使用
• Active：从 Convenience 进入该模式后，娱乐功能和底盘功能使用最大化，除了动力其它功能全开
• 目的：将用户的使用意图，转化成整车可识别的模式语言，指导功能何时可用

（5）新能源混动车辆电源状态：

休眠 Sleep → OFF 下电 → ACC 附件上电 → ON(IG-ON) 低压全上电 → READY 高压就绪（可行驶）

1. Sleep 整车休眠（人在车内坐着看现象：完全下电后中控锁灯和双闪背光灯熄灭）：

• 整车深度低功耗，绝大多数 ECU 休眠，只有唤醒模块工作
• 12V 休眠电流满足规格，CAN/LIN 总线静默
• 仪表黑屏，车机关闭
• 唤醒源：开门、遥控钥匙、启动按键、CAN 信号、充电枪插入等
• 电源模式：OFF/休眠。KL30 有电 ✅（为防盗系统、无钥匙进入模块等随时待命的关键部件供电），KL15 断电 ❌

2. OFF 下电状态（车辆下电锁车后，中控锁灯和双闪背光灯亮着）：

• 遥控/手机解锁：OFF → ACC
• 按下解锁键后，由 KL30 供电的接收模块收到信号，唤醒车辆部分网络进入 ACC 模式。中控屏点亮、音响等附件可以使用，但核心驱动系统并未上电
• KL30 有电 ✅，KL15 断电 ❌

3. ACC 附件上电（中控仪表熄屏状态下，人在车内短按一次启动键，或拉开车门再关闭车门，此时中控仪表会点亮）：

• 触发：不踩刹车，按 1 次启动键
• 仅部分低压附件供电：车机、音响、USB
• 高压电池不上电，不能行驶；BMS、MCU 无高压输出，空调压缩机不工作
• ⚠️ 风险：长时间 ACC 会耗亏 12V 蓄电池
• 打开主驾驶车门：ACC →（可能）ON。大部分车型开门只是物理操作，不改变电源模式；部分具备“智能上电”功能的车型（如比亚迪）会识别用车意图直接进入 ON（高压）模式，KL15 继电器吸合，整车上低压电，甚至高压继电器吸合接通高压电池

4. ON（IG-ON）低压全上电：

• 触发：不踩刹车，按第 2 次启动键（前提是中控仪表完全黑屏下电的状态）
• 整车所有 ECU 低压唤醒、自检，仪表全点亮
• CAN 总线全部激活，诊断仪可连接所有控制器
• ⚠️ 高压仍然断开，车辆不能行驶
• 场景：车间诊断、刷写程序（不需要启动车辆）
• 踩下刹车踏板：ACC → ON / READY

5. READY 就绪状态（可行驶）：

• 预充完成，高压回路完全闭合，BMS 输出高压，MCU 待命
• 仪表显示 READY 标识，踩电门车辆可以行驶
• 空调压缩机、PTC、电机全部可以工作
• 挂入 D/R 挡：READY。KL30 有电 ✅，KL15 上电 ✅

油车 vs 电车电源模式对照：

4.5.5.4 车辆模式介绍：CMM（Car Mode）

CMM 将车辆生命周期划分为不同阶段，目的是：统一模式语言（建立整车功能有效性的统一要求）；保持电池状态良好（尤其 Factory 和 Transport）；特殊工况的特殊需求模式统一（Dyno）。

4.5.5.5 台架环境要求与电气基本要求

常态工作环境（5.1）：

• 温度：18℃ ~ 28℃
• 相对湿度：25% ~ 75%
• 气压：86 kPa ~ 106 kPa

温度范围（5.2）：

• 工作温度：-30℃ ~ 75℃
• 存储温度：-40℃ ~ 85℃
• 低温存储：-40℃ 存储 120h
• 高温存储：85℃ 存储 120h

电气基本要求（5.3）【考点】：

• 标称电压：12V；工作电压范围：9V ~ 16V（在此电压下中控仪表正常点亮，超过或低于会进入高低压保护状态 —— 熄屏）
• 过（高/低）电压保护：
• 电压高于 18.5V，MMI 进入 Power Save Mode 状态；电压恢复到 18V 以下后，MMI 重新进入 Power On 状态
• 电压低于 8V，MMI 进入 Power Save Mode 状态；电压恢复到 8.5V 以上后，MMI 重新进入 Power On 状态
• 休眠电流要求：整车 < 50mA（极力整车在 30mA 左右）【使用电流卡钳量电流 —— 小电瓶正极线】，ECU 静态功耗 < 10mA，防止亏电
• 💡 备注：赛力斯某一项目静态电流要求小于等于 0.005A

4.6 实战与缺陷排查✓

4.6.1 测试用例设计实战

场景法实战：整车启动场景

基本流：
1. 驾驶员携带钥匙靠近车辆
2. 无钥匙进入（PEPS）检测到合法钥匙，解锁车门
3. 驾驶员开门上车，关闭车门
4. 按启动按钮，PEPS 验证钥匙在车内
5. 系统上电（ACC → ON → START）
6. 发动机启动，仪表显示就绪
7. 中控屏启动，显示欢迎界面，加载用户配置

备选流：
- 钥匙电量低：提示"钥匙电量不足"，但仍可启动（使用应急启动区域）
- 钥匙不在车内：按启动按钮提示"未检测到钥匙"，无法启动
- 车门未关：启动时提示"车门未关闭"，但可启动（或按策略禁止启动）
- 电瓶低压：启动时提示"电量不足"，启动后发电机充电
- 启动按钮故障：长按启动按钮强制启动（应急模式）

接口用例实战：模块间信号交互

以"空调温度设置"为例，涉及空调控制面板 → 空调 ECU → 仪表显示：

1. 前置条件：车辆上电，空调系统正常
2. 测试步骤：
3. 在空调控制面板设置温度为 22°C
4. 用 CANoe 监控空调 ECU 发出的温度信号（如 AmbTemp_Setpoint）
5. 观察仪表/中控显示的温度值
6. 预期结果：
7. 空调 ECU 发出的信号值 = 22°C（精度 ±0.5°C）
8. 信号发送周期符合规范（如 100ms）
9. 仪表/中控显示值 = 22°C，延迟 < 500ms
10. 异常用例：
11. 设置温度为最大值（如 32°C），验证信号不溢出
12. 设置温度为最小值（如 16°C），验证信号不下溢
13. 快速连续调节温度（1 秒内调 10 次），验证信号不丢失、显示不卡顿

异常用例实战：错误注入

• 发送非法 CAN 报文（如校验位错误、信号值超出范围），验证接收模块是否能正确忽略或报错
• 模拟总线负载 100%（报文洪水攻击），验证关键功能是否仍能正常工作
• 模拟某 ECU 不响应（掉线），验证其他模块是否能降级处理，不导致整车功能瘫痪

4.6.2 常见缺陷类型与排查思路

4.6.3 日志分析方法

日志类型：

日志分析标准化步骤：

1. 稳定复现
   └─ 确保问题可复现，记录复现步骤和概率

2. 同步抓取多源日志
   ├─ 应用日志（ADB logcat，时间戳精确到 ms）
   ├─ 系统日志（dmesg，内核事件）
   ├─ 总线日志（CANoe，全程录制）
   └─ 视频（车内摄像头，记录操作过程）
   └─ 关键：所有日志时间必须对齐（使用同一时间源，NTP 同步）

3. 定位异常时间点
   ├─ 从视频中找到异常发生的精确时间点
   ├─ 在应用日志中搜索该时间点前后的 ERROR/Exception
   ├─ 在系统日志中查找该时间点前后的 kernel panic/oops
   └─ 在总线日志中查看该时间点前后的异常报文

4. 沿调用链追溯根因
   ├─ 从异常现象反向追溯：现象 → 直接原因 → 触发条件 → 根因
   ├─ 跨模块追踪：A 模块发出信号 → B 模块接收处理 → C 模块执行
   └─ 对比正常/异常日志：找差异点，差异点就是问题所在

5. 验证结论
   ├─ 根据分析结论，构造条件验证（如修改信号值、模拟触发条件）
   └─ 确认修复方案后，回归验证

常用分析工具：

• CANoe：总线日志分析，可按信号/报文筛选、绘图、统计
• Wireshark：以太网报文分析，支持 SOME/IP、DoIP 解析
• ADB + logcat：Android 日志查看，支持 grep 过滤
• Python + pandas：大规模日志数据分析、统计、可视化
• 010 Editor / HxD：二进制日志文件分析

4.6.4 测试环境与工具链

硬件环境：

测试工具：

• 总线工具：CANoe（Vector，行业标准，支持仿真+分析+测试）、PCAN（PEAK，性价比高）、ValueCAN（Intrepid）
• 诊断工具：Vector CANoe DiVa（UDS 自动化测试）、VCX SE（原厂诊断仪）、ELM327（OBD 通用诊断）
• 自动化工具：Python（python-can、can-isotp、pytest）、TESTBASE（车载测试自动化平台）、Vector vTESTstudio
• 性能测试：CANstress（总线压力测试）、电源模拟器（电压波动/掉电模拟）、网络损伤仪（弱网/延迟模拟）

管理工具：

• 缺陷管理：Jira、禅道、Redmine
• 用例管理：TestLink、禅道、TestRail、Polarion
• 版本管理：Git（GitLab/GitHub）、SVN
• 持续集成：Jenkins、GitLab CI
• 项目管理：Jira、禅道、飞书项目、Teambition

测试设备与硬件实操（思维导图：设备名称）：

CAN 盒子 / 总线工具硬件选型：

• CANoe（Vector）：VN1630A、VN1640A、VN7640
• ZCANPRO（周立功）：USBCANFD-200U、USBCANFD-100U / 400U
• TSMaster（同星）、PCAN（PEAK）

4.7 面试高频考点✓

4.7.1 基础概念题

Q1：集成测试与系统测试的区别？

Q2：冒烟测试的目的和范围？为什么集成测试要先做冒烟？

Q3：什么是回归测试？回归测试的范围如何确定？

4.7.2 流程与方法题

Q1：简述集成测试的完整流程。

Q2：如何设计一个高质量的集成测试用例？

Q3：缺陷提票的标准流程是什么？一个好的缺陷单应包含哪些信息？

4.7.3 技术深度题

Q1：CAN 报文丢帧如何排查？

Q2：UDS 刷写失败的常见原因有哪些？

Q3：OTA 升级到一半断电了，车辆会怎样？如何测试这种场景？

Q4：多 ECU 状态不一致如何定位是哪个模块的问题？

4.7.4 场景应变题

Q1：版本提测后冒烟不通过，你作为集成测试如何处理？

Q2：开发认为你提的缺陷"不是问题"，如何沟通推进？

Q3：项目周期压缩，测试时间不足，如何取舍和风险控制？

Q4：回归测试时发现一个不在本次变更范围内的老问题，如何处理？

4.8 集成测试定义与测试环境搭建✓

集成测试定义：是开发写的代码集成开发合成整包，第一个测试阶段，简称冒烟测试，主功能验证。

4.8.1 集成测试周期表

4.8.2 测试环境搭建

测试环境：硬件环境、软件环境。

硬件环境：测试必需的台架设备（电源、IVI屏幕、仪表、FM天线、GPS天线、喇叭、外置功放、DVR）。

软件环境：下载软件版本（每日版本：\10.33.14.24\share_folder\Release\）。

软件的刷写参考（SOC刷机手顺）

4.8.2.1 硬件架构图

一个软件升级包 2-3G。

4.8.2.2 各功能模块介绍

CMS（Camera Monitoring System）：沙雕设计之一：无敌反光镜（就是没有反光镜，用的摄像头）。
沙雕设计师之二，赛车方向盘（半幅方向盘）。

FM（Frequency Modulation）：调频广播，通过改变载波频率来传输音频信号，具有音质好、噪声低的特点，主要用于传输高质量音乐和广播节目。本地电台。
AM（Amplitude Modulation）：调幅广播，通过改变载波幅度传输音频信号，传播距离较远，但音质相对较差，常用于新闻、谈话类广播节目。全国中央电台。

IVI（In-Vehicle Infotainment）大屏：车载信息娱乐系统，整合车辆的多媒体播放（音乐、视频等）、导航、蓝牙电话、车辆状态显示等功能，通过中控显示屏操作，是车内人与车、外界信息交互的重要界面。

IC仪表：车辆仪表盘，显示车辆重要信息，如车速、发动机转速、油量、水温、里程、剩余里程，充电显示，电量显示，灯光，仪表多媒体交互，地图导航交互，上下功能切换，各信号指示灯，故障灯，智驾显示等，部分还具备故障提示、驾驶辅助系统状态显示等功能，帮助驾驶员实时了解车辆运行状况。

HUD（Head-Up Display）抬头显示：抬头显示器，将车辆关键信息（如车速、导航提示、专项灯时候要有左视图，驾驶辅助系统警告等）投影到驾驶员前方挡风玻璃上，使驾驶员无需低头看仪表盘或中控屏就能获取重要信息，保持视线始终向前，提升驾驶安全性和便利性。

USB-用户：用于用户连接外部USB设备，如U盘、移动硬盘等，可读取其中的多媒体文件（音乐、视频、图片）进行播放，也能用于软件升级、数据传输，还可给支持USB充电的设备充电。本地升级。

以太网（千兆）：提供高速数据传输通道，用于车载网络中设备间通信，如连接车载电脑、摄像头、传感器等。支持高带宽应用，满足高清视频流传输（如AVM图像传输）、大量数据交互（如智能驾驶系统数据传输）需求，保障车载系统高效稳定运行。

4.9 冒烟测试与版本验证✓

4.9.1 冒烟测试流程

4.9.2 Changelist测试流程

Changelist（合入单）：集成测试时候遇到难点，就是这个。

1. 里面有开发优化的很多底层代码会加入其中，开发也不写出测试流程，我们测试要验证给结果，就得沟通，浪费大量时间。
2. 后面系统以及验收测试，提交的BUG，开发修复后我们要验证，他们提BUG时候很多设计报文信号的前置条件没有写明，我们在复现时候需要查看相关需求，或者找对应提BUG的后端测试人员咨询测试条件，也会浪费大量时间。

4.9.3 版本发布及测试版本要求

集成测试每天发布一个版本进行验证，每周选择一个版本发布到系统测试，怎么发布？邮件。

1. 版本的正常发布
2. 版本无严重问题，可正常发布
3. 版本有严重问题，阻塞功能很少
4. 版本不能发布
5. 有严重问题，导致功能阻塞大于70%
6. 有严重问题，阻塞功能很少，但交付方不同意该问题的流出，导致版本不能发布
7. 无严重问题，开发要求的changelist未合入完，需要第二天重新出版本，导致当天版本不能发布

测试版本要求

版本发布判定速查（思维导图：设备名称）：

• 正常发布：①版本无严重问题；②版本有问题，但阻塞功能很少
• 不能发布：①版本有严重问题，阻塞功能达到 70%（如 100 条用例有 70 条无法测试；实际发布标准以公司要求为准）；②版本无严重问题，但 BUG 下游测试不接受

合入单 / 变更单里有什么（思维导图：设备名称）：

• 开发修复的 BUG → 需要我们在里面看了之后进行回归测试
• 需求的修改内容 → 需要看了之后进行测试

4.10 测试维度与用例规范✓

4.10.1 冒烟测试测试维度

💡 边角案例：极少出现的。写用例时候如何能覆盖更全面。写用例还需要思考正向反向用例。等价类边界值流程法都是手法，用例覆盖更全面需要从测试维度出发方能覆盖全面。

4.10.2 测试用例常用设计方法

4.10.3 测试用例规范

4.10.3.1 用例模板

4.10.3.2 测试用例的更新与维护策略

1. 需求变更触发维护：依据需求变更、changelist 变更清单，识别功能改动，同步新增、修改、删除对应测试用例，保证用例与实现一致。
2. 缺陷驱动补全用例：分析版本缺陷，若属于用例设计遗漏，将缺陷场景转化为测试用例，纳入回归套件，避免重复漏测。
3. 持续迭代优化：承认测试用例无法做到绝对完备，随着对业务理解加深，持续完善用例，清理重复、失效用例。
4. 分层管理用例库：不同项目独立维护用例，项目内部按模块拆分；下线功能及时归档废弃用例。
5. 团队版本对齐：用例修改后进行评审，保留修改记录，团队共用同一套用例基线。

4.10.3.3 什么时候需要维护测试用例

1. 需求发生变更；
2. 开发代码变更（changelist）；
3. 发现 bug，发现原来用例有遗漏；
4. 老功能下线，清理无效用例；
5. 对业务理解加深，优化原有用例。

4.11 BUG 管理与规范✓

4.11.1 BUG级别（严重程度）

A级（必现的只能在集成测试这边出现，系统测试那边不能出现）

1. 测试过程中出现的非操作引起的死机、自动重启过大
2. 通话无声、回音、接通后对方听不到声音
3. 操作无法进行计算超过24C/4操作硬件才恢复正常的缺陷
4. 手机蓝牙连接后，使用播放音乐无声
5. 一级菜单key操作失效/失效，导致在大软件主题下所有的功能无法进入和缺陷的缺陷如：功能主菜单无法进入
6. 操作系统70%不能测试

B级（A级B级BUG这种BUG不多，个别版本中有部分）

A级B级BUG出现后，找来开发看后，第一时间提票到平台，并且在工作群中@对应开发主管以及集成人员，让他们第一时间知道本版本严重BUG有哪些。

1. 机械寿命说明书中已功能没有实现
2. 多媒体过程中出现记忆错误、黑屏/花屏画面闪烁，且闪烁量时间超过正常操作1倍或以上，用户体验非常差
3. 页面转换异常且无声/无声，声音出现断续杂音/杂音
4. 系统错误，频繁提示应用程序错误
5. 系统性能严重低于预期指标(<50%)，如：操作十分不流畅，切换频率响应时间过长，应用启动加载时间过长，应用切换加载时间过长等
6. 花机，无操作死机，8-9秒可恢复
7. 蓝牙通话效果特别差（蓝牙通话听不清，无法测试，声漂乱等）
8. 蓝牙连接成功后，无法正常使用（蓝牙媒体，无声漂乱等）
9. 蓝牙通话效果特别差（蓝牙通话听不清，无法测试，声漂乱等）

下图中是点击APP出现的crash，定义B级BUG：在工程模式中可以设置捕捉CRASH，当点击APP出现崩溃闪退时出现下图场景CRASH。输入法发生ANR、崩溃crash、异常日志输出。

C级（BUG提票最多的是C级）

1. 功能已经实现，但功能呈现的显示模式/设计风格/显示内容等与预期/规范不符
2. 功能需求说明书中已做功能，在特定操作下导致不可用，但可复位问题
3. 迁移过程出现黑屏/花屏等问题可复位：常输出时，会出现短暂的杂音/噪音，且出现在特定位置与页面
4. 出现让用户厌烦的重复的问候和：关键页面如导航等导航系统弹错遮挡，提示信息要不断电一直显示导致其他功能无法使用等
5. 切、换曲、偶合的同步性缺陷（如：曲声、页面框架的打票，不能保持同步）
6. 数据加载显示问题：字段显示错误

下图中是C级文字折叠

下图中是英文模式，中间有中文，定义C级

不图中是输入法左边栏日未对齐：定义C级

D级

1. 影响微小类问题
2. 再现率低，可复位偶发性问题
3. 性能略差低于预期目标(<10%)
4. 显示内容的文字(位置/大小/图片/色差等参考值，与预期/规范有轻微偏差，不会造成功能性影响的缺陷
5. 建议类问题：式样本身不合理，提出建议，同类产品更优的体验建议

下图中文字框，左右到顶，没有空气感，太拥挤，定义D级BUG。

4.11.2 Bug严重等级定义（表格版）

4.11.3 Bug提交规则

提BUG模板（核心）：

标题：【集成】【模块】链接wifi失败
版本信息：主线NS阀：刷机时候刷那个版本，提票时候版本信息就写那个版本
SOC版本：CDC_7901301-RA19_SW2.12.B_220930_2435_03
MCU版本：MCU_7901301-RA19_SW2.12.B_220930_2435_00
硬件版本：
c样件
环境信息：
台架
预置条件：
1.KL15 ON
2.空调界面已展开
3.空调处于打开状态AC_ctrlFeedback: ac_systemOnOffSts =0x1: ON
4.自动模式处于关闭状态AC_ctrlFeedback: ac_autoStatus=0x0:OFF
操作步骤：
点击自动按钮
实际结果：
未下发信号
预期结果：
IVI发送3帧信号"ivi_hvacAutoModeReq =0x1: KEY_PRESS"，然后周期发送ivi_hvacAutoModeReq =0x0: INVALID
出现概率：
失败率30%左右
问题时间：
2025/5/28 09:34:28
备注：无
log/及附件【图片，视频】：

BUG关闭条件：公司规定谁提票谁关闭，以下是关闭条件。

验证bug的规则：

【验证版本】
SOC版本：CDC_7901301-RA19_SW2.10.3.B_240321_2435_01
MCU版本：MCU_7901301-RA19_SW2.10.3.B_240321_2435_00
【验证环境】
台架/实车
【验证结果】
Pass/Failed（未复现（具体版本可能根据bug情况改变））
【处理结果】
关闭/重新打开的情况
【验证次数】
10次
【备注】
复现日志或者附件条件

关闭规则：

• A级bug：必须同等验证1个版本关闭，偶因bug验证3个版本才能关闭
• B级bug：必须及偶现问题验证1个版本后关闭，特别低概率出现的bug验证2个版本后关闭
• C/D级bug：必须及偶现问题验证1个版本后关闭

节点bug的关闭规则：

1. 要在节点版本上验证的上一次出现的Bug后再关闭（合入在节点changelist中）（当bug提过来时，在bug下备注"下个nc节点版本验证"）
2. 节点版本已经验证通过的，如bug描述为偶现问题，就在节点后的主版上关闭（当bug提过来时，在bug下备注"下个nc节点版本验证"）
3. 节点版本含有督导导致有品质问题未合入节点，就在节点后的主版上关闭（当bug提过来时，在bug下备注"下个nc节点版本验证"）

标签的标注：

1. 问题只有节点才有的适配只在"重现步骤"标注【节点】，如【OTS2】
2. 主线和节点都有这个问题就在"重现步骤"标注【节点/主线】，如【OTS2/主线】
3. 只有主线有的，就不标标签

关闭bug的责任人：

1. 创建者在项目中，创建者验证后关闭自己提交的bug
2. 创建者不在项目中，项目测试人员验证后将测试结果备注在bug后面，通知创建者关闭bug，若创建者需长期，项目测试人员验证通过后将测试结果备注在bug后面并关闭
3. 创建者在项目中，但创建者的问题又复现，上传复现日志并备注后将bug重新激活
4. 创建者不在项目中，项目测试人员又复现问题，上传复现日志并备注后，通知创建者重新激活，创建者需长期，验证人员可直接重新激活
5. 备注：原则上自己的bug自己跟踪，但是遇到创建者转到其他项目的情况下由bug所在项目的测试人员跟踪，规则如上

禅道 / 缺陷平台管理要点（思维导图：通讯矩阵、禅道）：

• BUG 处理 2437 原则：严重问题 24 小时内给出 BUG 原因及解决措施、3 天内给出验证版本并关闭问题；非严重问题 7 天内给出版本验证后关闭
• BUG 状态流转：激活（刚新建的 BUG 状态）→ 已确认（开发看见后点击确认该问题）→ 待解决（开发正在解决的状态）→ 已解决（开发已解决，测试需要回归验证）→ 关闭（验证没问题即关闭）
• 关闭 BUG 的责任人：谁提的谁关闭；处理别人的 BUG 时需有领导的授权
• 标题命名方式：【项目代号 / 部门简称】【BUG 模块】描述
• BUG 描述内容：版本信息、测试环境（台架 / 实车；生产环境为用户使用环境，测试（演示）环境为测试使用环境）、样件信息（如供应商 1 用 A 样件、供应商 2 用 B 样件）、前置条件、操作步骤、预期结果、实际结果、BUG 概率、BUG 时间、备注
• 关闭 / 激活 / 跟踪时 BUG 的描述内容：版本信息、测试环境、验证结果（pass 必现 BUG / fail / 暂未复现 偶现 BUG）、处理结果（关闭 / 激活 / 继续跟踪 N 个版本）、验证次数（注意次数一定要 ≥ 10 次）、备注

4.11.4 BUG优先级划分（P0-P3）

4.11.5 偶现BUG版本跟踪规则

偶现缺陷因复现概率低，需跨版本持续跟踪验证，防止"假修复"。各优先级偶现BUG的版本跟踪要求如下：

4.11.6 其他企业BUG分级参考（S-A-B-C）

部分车企采用S-A-B-C四级分级体系，与上述P0-P3 / A-B-C-D体系对应关系如下，供跨企业协作时参考：

4.11.7 BUG流转状态详解

标准缺陷生命周期包含以下五个状态，各状态间的转换条件与责任人需明确：

激活(New) → 已确认(Confirmed) → 待解决(In Progress) → 已解决(Resolved) → 关闭(Closed)
    ↑              ↓                    ↓                     |
    │         驳回(Rejected)      延期(Deferred)             │
    │         (非问题/重复/需求变更)                           │
    └──────────────────── 重新打开(Reopened) ←────────────────┘

• 激活（New）：测试工程师提交缺陷，初始状态。需包含完整的标题、模块、优先级、前置条件、复现步骤、预期结果、实际结果、复现概率、日志/视频附件。
• 已确认（Confirmed）：开发或测试负责人确认缺陷有效，分配给对应开发工程师。若为非问题、重复缺陷或需求变更，则驳回并注明原因。
• 待解决（In Progress）：开发工程师已接受缺陷，正在分析修复。
• 已解决（Resolved）：开发完成修复，代码合入版本，通知测试回归验证。
• 关闭（Closed）：测试回归验证通过，按版本跟踪规则确认无复现后关闭。
• 重新打开（Reopened）：回归验证不通过，或已关闭缺陷在后续版本复现，重新激活并附复现证据。

4.11.8 座舱BUG发现后处理流程

座舱域缺陷以界面交互、多媒体、连接类问题为主，发现后按以下流程处理：

1. 拍摄视频：立即录制复现操作全过程，视频中需语音解说出现的问题及时间点。
2. 复现确认：重复操作2次以上，确认是偶现还是必现（必现1次即可，偶现需记录5-10次中的出现次数）。
3. 拉取日志：通过U盘导出或adb logcat抓取应用日志、系统日志，记录BUG发生的精确时间点（精确到秒）。
4. 打点标注：在视频或日志中标记BUG发生时间点，便于开发定位。
5. 提交缺陷票：按标准模板提票至缺陷管理平台，指派对应模块开发负责人。
6. 回归验证：开发修复后，在新版本按复现步骤验证，通过则关闭，不通过则重新打开。

4.11.9 智驾BUG发现后处理流程

智驾域（ADAS / 自动驾驶）缺陷涉及行车安全，处理流程比座舱更严格，需双备份验证：

1. 打点标注：发现问题后立即在测试车辆打点器上按标记键，记录问题发生的精确时间点与位置。
2. 拉取全量日志：打包智驾域控制器全量日志（CAN/CAN FD总线数据 + 摄像头视频 + 激光雷达点云 + 应用日志），循环覆盖录制需保存问题发生前后30分钟数据。
3. 上传至缺陷管理平台：将日志包上传至公司缺陷管理平台（如阿里云OSS），并在缺陷单中附下载链接。
4. 提交缺陷票：按智驾缺陷模板提票，需包含路况、天气、周边车辆、ACC/APA设置参数等详细场景信息。
5. 双备份验证：智驾BUG修复后需在HIL台架和实车场地双重验证，确认修复有效且未引入回归问题。

4.11.10 开发解决方案分类

开发处理缺陷时，解决方案通常为以下六类之一，测试工程师需根据解决方案类型决定后续验证策略：

4.11.11 重点场景化：智驾与座舱特殊要求

不同域的缺陷验证有特殊要求，测试工程师需根据所属域调整验证策略：

智驾域特殊要求：

• 修复验证需双备份（HIL台架 + 实车场地），确保修复有效且无回归。
• 偶现缺陷需增加路试里程（建议500公里以上），覆盖高速、城区、泊车等多场景。
• 涉及功能安全（ISO 26262）的缺陷，需同步安全工程师评估，确认修复不引入新的安全风险。

座舱域特殊要求：

• 多媒体类缺陷需验证音频通道（车机扬声器 / 蓝牙通话 / 语音播报）互不干扰。
• 多屏交互缺陷需验证中控、仪表、HUD、副驾屏的信息同步一致性。
• 连接类缺陷（蓝牙 / WiFi / CarPlay）需覆盖多品牌手机、多系统版本的兼容性测试。

4.12 测试报告、发布与周报✓

• 09 daily版本-封面内容

• 09 daily版本-变更履历

• 09 daily版本-结果汇总

• 09 daily版本-changelist

• 09 daily版本-测试结果

• 09 Release版本-封面内容

• 09 Release版本-变更履历

Release版本的变更履历、结果汇总与daily版本的统计方式一致。

• 节点版本：统计当前节点的所有合入单
• 周版本：统计包括当前测试的周版本及到周一的测试了的所有合入单

• 09 Release版本-Smoking Test

Release版本冒烟用例与daily用例的区别：Release：用例统计在一个sheet页，daily：一个模块一个sheet页。
填写内容：实际结果、执行人、测试版本、执行日期。

4.12.1 测试结果的发布

4.12.1.1 邮件发布

报告汇总信息：Daily Build Version集成测试结果报告、Release Version报告。

Daily Build Version集成测试结果报告发布：

• 收件人：业务负责人、项目经理、项目经理主管、质量管控负责人、集成测试负责人
• 抄送人：业务负责人、软件开发负责人、座舱软件测试副负责人、系统测试部门人员
• 主题格式：TS-集成测试报告（中科创达）【集成测试】Daily Build Version集成测试结果（注意：如需要爆雷改为首项，项目爆雷测试的项目首项为：如【SAI OS】）
• 添加附件：测试日报表（测试用例）
• 正文格式：

Hi all,
    【SAI OS 智能座舱软件平台项目】【集成测试】结果如下，附件为本次版本2023/05/11集成测试结果，请查收
1. 版本信息：（如下例）
    版本编号（车载域控制器中读取）
    SOC版本：CDC_7901301-XH01_SW1.00.A_230511_10001_00
    MCU版本：MCU_7901301-XH01_SW1.00.A_230511_10001_00
2. 测试结果：通过红方（集成测试用例汇总）
3. 测试结果
    数据（Severe集成测试结果-集成测试用例汇总）

Release Version报告发送信息-内部邮件：

• 收件人：业务负责人、项目经理、项目经理主管、质量管控负责人、集成测试负责人
• 抄送人：业务负责人、软件开发负责人、座舱软件测试副负责人、系统测试部门人员
• 主题格式：Seres-SAI_OS_ReleaseVersionReport（暴力版）、TS-SAI-OS_ReleaseVersionReport（中科创达）（无论此为信息聚焦热修）
• 正文格式：

Hi all,
    总评审，该版本下周下载（W18）释放成测试使用，请注意查收！（注意：下载时间记得更新）
备注：节点版本如最新，上面图位本版，xx版本用于xxmm车查看，请注意查收！
1. 版本信息（如下载）
    SOC版本：CDC_7901301-XH01_SW1.00.A_230526_10001_01
    MCU版本：MCU_7901301-XH01_SW1.00.A_230526_10001_00
2. 版本下载地址：xxxxxxxxxxxxxxxxxxxx
3. 严重问题总结
    数据（无严重问题时删除）
4. 测试结果-红方（无关注为集成测试用例汇总）
    数据（Severe-集成测试报告-集成测试用例汇总）
5. 测试结果-黄方
    数据（Severe-集成测试报告-集成测试用例汇总）

Release Version Report报告发送信息-外部邮件：

• 转发给合作方部件

严重问题导致版本不可用的话术：

• 严重问题导致版本不能发布，邮件和每日测试结果也需要发布，邮件正文将统一添加在正文第一句话中，格式如下：

该版本由于xxx严重问题，导致该版本不可用，测试结果如下：

4.12.1.2 微信发布

微信发布测试结果的格式。

无严重问题：

1. 今日xx版本测试结果
   截图（集成测试用例汇总表）

有严重问题：

@开发负责人 @集成负责人，当前版本发现的（问题），导致且（满屏状百分之几的功能）不能测试，仍为激活状态，需要尽快解决
  截图（新增问题汇总表）
  1. 历史严重问题如下（Release版本才统计并发送）
  截图（历史严重问题汇总表）
  2. 今日xx版本测试结果如下
  截图（集成测试用例汇总表）

4.12.2 周报的统计

周报统计最少要1.5-2小时不停。

我们要把一周的报表数据全部打开，周报内容包裹每天验证的版本号，回归验证的数量，当天pass和fail数量，把日报表中的核心内容，整理到周报表中，作为一周数据的输出。

我们把整理好的周报表周一发给组长统计。

日报 / 周报内容参考（思维导图：设备名称，不同车企口径）：

4.13 难点、面试与用例维护✓

4.13.1 1. 开发新增加的功能

由于保证验证百分百覆盖测试，必须要每条合入都要验证到，开发新增加功能，简短一句话带过，集成测试人员看不明白怎么测试给结果，这个时候要第一时间跟对应开发去沟通，测试方案，怎么验证。经常要等回复，这是难点之一。

4.13.2 2. 后方系统测试已修复BUG合入单

在合入单中有ID号的就是测试人员提的BUG：系统测试提交的BUG描述比较模糊，未按标准流程提票，因为集成测试是在系统测试上层，所有后方的BUG都要先经过集成测试验证，有很多信号类测试用例，要添加很多报文信号，而后方系统测试简单几句话描述过去，我们在测试这种合入BUG时候，需要去需求中寻找测试流程，要添加哪些报文信号，有时候要找十几分钟或者半小时一条合入，有时候要跟提票的后方系统沟通问一下测试流程，要添加哪些报文信号，不管是那种都比较麻烦。这是难点之一。

4.13.3 面试题与实操要点

4.13.3.1 面试题：你们怎么拉包线刷，新版本发布？

首先我版本发布了，我要先去把这个包下载下来，我把对应的软件包下载下来，下载完之后我要去刷机，就是刷环境。把环境都升级到我们对应的版本，因为像我们这边的话是可能是两个人用一个台架。

1. U盘升级：简单快捷，方便，直接插到公司服务器，电脑上进入下载网页地址就可以一键下载，插入车机USB口，会弹出是否升级，点击是。直接升级。

• 测试点：升级是否正常完成，升级过程中是否会中断升级，升级过后系统是否正常开机运行，升级前是否插上U盘弹出是或升级字样。

2. 线刷E2升级：最复杂的升级方式，需要从公司内网，下载SOC，和MCU升级包到电脑上，MCU版本线刷升级需要把MCU软件包拉到上位机里面，通过E2烧录器，烧录到主机里面，之后soc直接把软件拉到soc上位机里可以直接烧录，刷写完完成后重启。

• 测试点：烧录是否正常，版本中间是否中断，烧录成功后是否正常开机。

SOC：跑系统，管上层软件界面

MCU：管底层硬件电路，电源、CAN、外设

4.13.3.2 面试题：你们集成如何测试，有哪些流程？

面试题：你们集成如何测试，有哪些流程？

集成测试一天基本是一个版本包出来验证，有时候会出两个包验证，验证类型，信号类验证，和非信号类验证，只针对功能验证，人员安排，一个版本正常两个人验证，一个验证信号类，一个验证非信号类，人员缺少的情况下一个人验证一个版本，熟练情况下两个人验证一个版本，一人一个多小时就验证完成，验证完成后还需要验证回归问题，解决版本是哪天的版本包，我们要去验证新版本中缺陷是否已经解决，如果解决了，则关闭BUG，如果没解决，继续转给开发解决。

4.13.3.3 回归 BUG 难点

集成冒烟测试工作中遇到很多问题：回归BUG。

回归BUG为何难测？比如遇到开发修复后的BUG，这个BUG是开发修复后流传过来的，提票的人是专项测试部提的，开发根据提的票修复的，开发修复后的所有BUG都必须先流转到对应车型集成测试，因为集成人员没有测试这专项内容，会遇到很多不会测试的点，需要去找开发或者提票人员去沟通。或者去需求里面搜索（寻找对应的需求）（系统测试是否也这样测回归呢？不需要）。

4.13.3.4 你只做过台架测试吗？

如果你写的专项语音测试，主要在实车8层台架2层。空调座椅测试实车5台架5。
如果你写座舱集成测试：实车验证1层台架9层。

实车验证前：必须台架本地升级一下。
新主板必须线刷升级，新的主板线刷升级是因为要验证PDID，和VIN是否正常刷写成功。

实车验证之前：

• 第一步：必需台架升级
• 第二步：台架升级后必须在台架验证本地升级，正常升级后才能去实车验证（因为有的版本系统升级有问题，直接升级车机后会造成汽车无法再次升级），第二次升级是在屏幕设置里面直接点击升级，第一次升级可以是U盘升级或线刷升级。

4.13.3.5 你们在企业如何拉包？

企业U盘拉包网址：U盘插到服务器电脑主机上面，在我们自己办公电脑上面打开下面对应网址，内网下，会出现下图中界面，从BUILD WITH PARAMETERS里面下载对应安装包，安装包大小1.6个G，下载时间大概4-5分钟一个，一个人有时候下载两个版本，要接近10分钟，早上上班第一时间把U盘放在上面去排队，之后再打免费咖啡，如果先去打印咖啡，后果很严重，打完咖啡回来后你会发现排队7-8个U盘来，正常7-8个U盘要等30-40分钟的，下载到U盘后，拔插到自己CDC主机上买，进入中控工程模式下，进行升级。

4.13.3.6 为何线刷：与 U 盘升级对比

座舱集成冒烟测试每天一个版本，系统测试每周一个版本，集成冒烟线刷升级正常规定每周线刷一次，为的在新版本上验证PDID正常刷写，或者VIN码正常刷写，其他几天是用U盘升级（U盘插入公司服务器下载一个全量包含SOC和MCU）直接插到CDC主机USB上面，进入工程模式里面进行，点击升级就自动识别到了，识别后自动升级，升级结束后自动重启。

集成测试每周发一个版本给系统测试，在发版本前要去实车验证。
系统测试不需要用线刷，直接U盘刷写，他们不进行线刷。

有时候要等版本，为什么等版本。或者有时间一天两个版本，为什么，因为开发处原因，版本在开发时候出现重大问题，开发会延时发送新版本，也是等版本时期，这个时期我们看看日报，喝喝咖啡，摸摸鱼，这是正常的，有时候早上出来版本后，下午还会出一个版本，这个时候就是比较紧急时候，如果你自己感觉测试部过来，要找领导招人，加班到人就是自己多多加班。

集成测试一天一个版本，系统测试一周一个版本，每天200条左右测试任务，200条十包括信号和非信号，只是非信号测试300-400左右，每天工作量。

快速测试方案：只针对有经验者，想要快速测试，就十凭经验测试，之后打开用例核对结果看是否有漏测。
新手测试，要一条一条用例测试，因为不熟悉。

4.13.4 用例维护与编写

4.13.4.1 车型高中低配差异

可以在工程模式配置字里面配置对应的高中低配置。

4.13.4.2 用例维护

什么时候需要维护，需求变更后，用例如果不在适用，就需要维护用例，及时更改测试用例，这一点很重要，用例有错误时，也需要及时更改用例，公司制度管理很重要。

4.13.4.3 什么时候写用例

当出现新需求时，比如应用中心增加了日历表，组长通知我们要写一份日历表测试用例，我们要借鉴其他模块去效仿写对应测试用例。

项目初期，还没有用例，需要根据经验去验证，同时要写出对应用例，如果公司有其他车型用例，也可以申请一份作为写用例借鉴。

4.13.4.4 写用例方式1

首先我们会根据我们的产品提出的需求，然后根据需求去编写我们的测试用例，而且测试用例要覆盖我们的需求，比如我们平时会根据边界值分析，有效等价无效等价，流程法，以及我们用户平时用到的一些场景法来写。

我就说一条语音唤醒的用例吧，在编写用例时，我会写上用例ID，比如ID为语料01。
之后有所属模块，我会写上语音交互模块，还有用例等级，唤醒我们定为1级。
之后有用例标题：标题设置为语音助手的唤醒。
之后是执行步骤：唤醒语料为：你好酷酷。asr(字体识别)同步显示。
预期结果：出现语音弹框，并有语音提示（语音反馈：就是TTS）。成功唤醒语音助手。
下一步是适用环境：比如我们要写上台架环境，还是实车环境，什么环境下测试的，比如我们是台架测试，环境我就会写台架。
还有实际的结果：测试通过为pass，不通过为fail，还有一种是block阻塞，阻塞我们分为两种，一种是环境阻塞，一种是BUG阻塞。

什么时候需要写 / 维护用例（思维导图整合）：

1. 全新项目没有测试用例 → 无平台化用例，自己部门全写
2. 全新项目有平台化用例 → 根据平台化用例差异项修改维护一套该项目用例
3. 根据自身测试经验，将容易发现问题的模块及对应操作转换成测试用例
4. 将 BUG 转换成测试用例（常规操作出现较多的 BUG）
5. 需求变更后需要更改用例；测试过程中发现需求更改或用例不符（写得不对）时，需要修改测试用例
6. 无此功能（NA）的用例可更改或删除

测试用例结果判定（思维导图：设备名称）：

• PASS：用例通过
• FAIL：用例失败
• BLOCK：环境阻塞 —— 需求不确定、DBC 不满足、测试条件比较苛刻无法满足等，或 BUG 阻塞
• NA：无此功能 —— 用例可更改或删除

我们还会写上执行人：测试的版本，以及日期这些。大概这就是我写用例的详细情况吧。

4.14 每日工作流程与测试前提✓

4.14.1 企业测试过程中的需求

• 实车验证：比如动态测试，静态测试
• 台架验证：仿真验证，以及系统验证
• 空中升级是OTA升级，本地升级是U盘升级，线刷烧录

4.14.2 集成测试每周发布一个版本给系统测试验证

重点，发布版本前要去实车验证一下集成所有功能。因为系统测试有一半时间在实车验证，我们集成测试在台架验证结果通过，实车不一定全部通过，因为测试环境不同，所以每周发布版本前，必须要去实车验证，版本无异常，发布周版本。这个时间大概2-3小时。

实车测试流程：核心逻辑，集成每周发布版本前，要去实车验证，台架测试功能OK后为何要去实车验证，因为台架测试和实车测试环境不同，台架测试通过未必在实车验证中同样通过，所以每周版本发布前必须去实车验证（点检）一下全功能。

自由测试：就是我们测试人员测试完自己用例后，1个BUG没找到，就开始超越测试，测试其他人的模块，随意测试，无规则测试，根据经验测试，目的也是尽量找到产品缺陷，或者给我们自己找到一些KPI。

测试环境 vs 生产环境（思维导图：设备名称）：

• 测试环境（测试 / 演示环境）：项目前中期的车辆处于测试环境中，用于测试
• 生产环境：用户的实际使用环境

4.14.3 工作中要求严谨

严重的BUG我们要在群里通报，并且@对应主管，以及负责人。
如果主功能进不了，我们要尽早找开发确认，提票，群里@对应主管，并且找到对应开发，让负责这个模块的开发同事过来现场观察问题，影响版本问题当天就要修复后，再出新版本重新验证，出新版本后测试要完成版本验证，给出版本验证结果。

4.14.4 测试人员每天流程

每天验证版本去公司当天测试表格中看，表格中有对应日期以及版本升级路径，根据路径下载当天测试版本号，用U盘插入服务器主机上排队下载，一个包2.5G左右，下载一个要4分钟前后，9点上班，快的时候会在半小时下载介绍，慢的时候会在一小时内下载介绍，早上上班免费咖啡先来一杯雀巢，版本下来后，给中控主机CDC进行版本升级，升级需要20分钟左右，喝咖啡。

4.14.5 集成冒烟测试模块

多媒体，蓝牙电话，用户中心，消息中心，车设车控，语音交互，地图导航，空调，座椅，仪表，天气，全局搜索，输入法，日程日历，图库管理，安全优化，主交互，音频策略，情景模式，工程模式，本地升级，多屏互动，无线充电，DVR（行车记录仪），DMS疲劳检测，AVM（全景影像），CarPlay（苹果手机互联车机），电子手册，系统设置，电源管理，我的壁纸。

4.14.6 信号类与非信号类

信号类：车设车控，空调，座椅，仪表，情景模式，无线充电，DVR，DMS，AVM。
非信号类：多媒体，蓝牙电话，用户中心，消息中心，语音交互，地图导航，天气，全局搜索，输入法，日程日历，图库管理，安全优化，主交互，音频策略，工程模式，本地升级，多屏互动，CarPlay（苹果手机互联车机），电子手册，系统设置，电源管理，我的壁纸。

4.14.7 工作流程（早上9点钟上班）

我们会在8.50左右到公司钉钉打卡，到公司后先是打开车机以及电脑，我们是一天一个版本，早上我们会排队用U盘下载版本，我们有一个主机，把U盘插入到主机里，从公司内Jkenis网址中存放版本位置，把版本下载到U盘中，大概3分钟左右把，（或下载到电脑本地后U盘连接到车机后电脑通过connect+ip连接车机后通过adb push命令推送到U盘里面-非正规操作容易泄露机密需要权限仅限了解）之后把u盘插入我们台架车机上，中控会识别到新版本提示是否升级，我们直接升级，这个过程大概半个小时左右吧，升级完成后，我们就根据我们的测试用例进行测试，上午一般测试信号类，下午一般测试非信号类，测试过程中我们会有测试用例进行全面测试覆盖，在测试过程中我们会在缺陷管理平台jira上提票，如果用例测试没有测出bug版本相对稳定，之后有时间我们会进行adb monkey稳定性测试，或者信号类报文信号性能压测用canoe或者tsmaster循环进行信号类压测。在测试过程中遇到bug我们会及时打手机记录下来发生的现场情况，记录下来时间作为提票依据，我们先把主机和电脑通，之后我们会用公司一键抓取车机日志提票到jira平台的时候作为附件，下午有时间我们会去查看下开发进展到哪里了，追踪一下bug状态。接近下班时候我们会根据当天测试内容把结果发群里，并且把当天测试内容一邮件格式发给对应的负责人。

4.14.8 领导负责人

集成人员（12个测试人员，3个测试SF5海外版本，4个测试HM5海外版本，4个测试HM7海外版），小组长（协助我们的），主管（他有自己的事，平时不沟通），软件开发主管（负责开发工作的，遇到软件A级bug要在群里@他，他要第一时间知道并且跟踪），项目经理（负责整个项目的进度）。

集成部门：12个测试人员，1个管理人员（负责项目人员安排其它杂货），3个项目的集成工程师共3人（职责就是负责软件版本集成，通知测试测试，和项目经理与软件经理沟通版本情况），1个科室主任（职责负责这个部门的统筹管理）。

4.14.9 测试前提条件

电脑，台架装备或者实车，测试用例，DBC文件，通信矩阵表，can盒子以及软件，台架针脚定义图，网络拓扑图，公司人员架构表。

根据公司配置的任务正常是组长发放：比如测试问界m5项目，智能座舱验证集成项目，一天一个集成版本验证。

组长会下发对应，台架装备或者实车，测试用例，DBC文件，通信矩阵表，can盒子。

我们拿到相关集成资料后，开始搭建台架，调通。

开始自我安排测试任务：每天验证一个版本。

之后，我们就开始从公司下载升级包到U盘，给主机升级到最新版本。

之后开始根据用例跑用例。

4.14.9.1 用例分为两种

一种是信号类复杂测试，需要加载很多前置条件，比如，空调，座椅，仪表，设置车身车况（车辆控制），辅助驾驶，能量管理，车辆模式，场景辅助。

二种是非信号类测试，就是点点点，验证能否实现，比如多媒体，蓝牙，地图，APP软件，T-BOX。

4.15 升级方式与版本管理✓

我们升级方式分为3种：
升级包分为SOC和MCU。
整包包括上面两种：用于U盘升级。
线刷升级要分开线刷升级，分包也可以U盘升级。

4.15.1 线刷升级

最前端测试：集成开发合成包后，第一个测试流程团队，就是最前端，取名叫做：集成测试（冒烟测试），要测试线刷升级，我们每周发布一个周版本给系统测试，这个版本必须要经过我们线刷验证，目的也是测试线刷是否能成功，每周验证一次。（上周外发的周版本→升级到本周需要外发的周版本）--原因是U盘升级没有问题，线刷后版本出现无法使用的情况。

比较复杂的点是：线刷要单刷SOC包，和MCU包，线刷包要从公司平台拉到自己电脑上，见下图。

线刷之前：要拉包，从哪拉？公司平台，见下图1，每天日报中也会有下载包的地址，见下图2。

线刷升级：要把CDC和MCU版本单独从公司内网平台下载网址处下载到电脑上：然后用E1和E2烧录

器单独烧录MCU（见下图1），SOC线刷直接用双头USB通过上位机直接刷机（见下图2）

以下是MCU上位机（下图4）

在刷MCU在上位机之前，要先进行连接，怎么个连接法？要用E1或者E2硬件连接到电脑和对应的主

机上面

刷MCU流程：

• 第一条，主机要根据下面图5接上跳帽线，形成主版短路
• 第二条，图3要接到主版上后面，形成和E1对接刷写接口
• 第三条，用E1和图3接出来的接口进行连接
• 第四条，用电脑上打开图4上位机，把电脑上下载的MCU包拉进去，进行刷写

以下是CDC上位机

刷CDC流程：

1. 用双头USB线连接到车机CDC智能座舱主机和电脑（上图2）
2. 打开下图中上位机软件（上位机只是一个统称而已，车企自研上位机主要是方便企业，快速刷机，或者智驾过程中看到想要的一些数据）把电脑上已经下载到的CDC数据包拉到上位机里面，进行烧录刷写。

刷写时候，经常会遇到刷写失败。失败原因，更多是流程步骤没搞对，也有软件版本有问题，底层开发写的代码接口不对

4.15.2 U盘升级

整包升级（包裹CDC和MCU），最常用刷机方式，早上把U盘放在服务器旁边排队，下载当天要测试的版本包，升级时候流程：插入带有版本包的U盘到CDC主机，进入车机IVI工程模式，会出现弹窗，弹窗信息：检测到最新版本，是否要升级，点击升级后进入升级模式。

U盘升级前提条件：先进入工程模式，才有U盘升级，也就是本地升级。

进入工程模式条件：每家不同，M5设置左边功能栏目最下面，系统点击10次进入工程模式。

U盘升级流程：插入带有最新版本包的U盘，在工程模式中，系统会自动检测U盘中新版本，会弹出新版本立即安装的弹框，见上图。

4.15.3 OTA升级

实车时，系统已经非常完善，才有这个功能，台架没有OTA升级，只有实车。
要进入OTA升级阶段的车：才能OTA升级。

U盘升级是整包升级，整包包含了MCU和CDC，u盘直接插入车机USB，工程模式中会弹出提示：是否升级，跟手机一样。

台架上面放置的ECU就是：华为智能座舱主机叫做CDC。

CDC主机内部有两个板子，一个主板是骁龙8155芯片的CDC系统升级到这个芯片内。
这个芯片内的升级版本就是取名CDC。
还有一个就是MCU板子：负责一些车灯雨刮之类小模块的。

CDC包名和MCU企业包名：

• CDC版本：CDC_7901301-RA19_SW2.12.B_240930_2435_03
• MCU版本：MCU_7901301-RA19_SW2.12.B_240930_2435_00

下面图片是拉包地址：

4.15.4 Jenkins拉包

下图中是企业服务器拉包的网址：U盘插入服务器电脑上，下3

图中：是进入公司拉包网址，找到当天主线版本，点击开始构建，3-4分钟下载到U盘中，大小2.5G左右。

U盘下载的包是整包：包裹CDC和MCU。

jenkins链接操作步骤：

1. 点击 build with parameters
2. 输入要查询的版本号，支持模糊匹配
3. 点击空白处，展示搜索结果

4.15.5 工程模式与配置

4.15.5.1 工程模式

问界M5点击设置中左边栏目最后：系统10下进入工程模式。

工程模式所有的后台都在这里操作：
工程模式中有：

• 本地升级
• 系统信息
• DMS离线激活
• 功能测试
• ADB模式
• DEVELOPER

下图中有配置字可以配置车型的高中低配置。

一切后台都可以在工程模式进行。

本地升级：U盘升级前提条件在工程模式中。
点击本地升级，会检测到升级包，点击就自动会升级。

工程模式其他功能：

1. PDID，VIN手动输入
2. 时间窗口设置
3. Crash设置开关：在工程模式中有这个开关，打开后遇到APP或者其他系统崩溃错误会直接报错误见下图一。

以下是软件崩溃错误，会跳出来的提示。

1. 修改配置字：车辆高中低配置，在线刷之后，全部调成高配置。
2. 配置安全证书：配置后才能登录账户。

4.15.6 PDID/VIN写入

4.15.6.1 PDID 未录入的处理

PDID = Product Device ID，产品设备唯一标识号。

车机/T-BOX 有序列号，每一台整车/车机硬件有独立 PDID，用于车联网 TSP 平台鉴权、设备认证、激活联网服务。

报错含义：
PDID未录入，请录入后重试：车机本地存储里没有写入合法 PDID 序列号，TSP 后台识别不到本机设备，网络服务、账号登录、车联网功能直接拦截，弹出该提示。

发生场景：

1. 新整机产线出厂：产线诊断工具没有把 PDID 烧写到车机存储，工厂漏烧录；
2. 维修更换车机主机：更换全新 HU 主机，维修工位未重新刷入原车 PDID；
3. 刷机、恢复出厂、烧写镜像：全量刷写固件把 PDID 分区清空；
4. 存储分区异常，PDID 数据丢失；
5. T-BOX 与 HU 车机 PDID 不匹配。

4.15.6.2 线刷升级后的校验

要在工程模式中配置对应的PDID，以及VIN码。

一、账号的测试

1. vin\pdid的写入：

• VIN码（车架号：在车窗前挡风左下角、外面观看（主驾前面））：LM8C7C594RAS00068
• PDID码：SKEV0005000102202402200220000551（手动输入）：0x53 0x4b 0x45 0x56 0x30 0x30 0x30 0x35 0x30 0x30 0x30 0x31 0x30 0x32 0x32 0x30 0x32 0x30 0x32 0x34 0x30 0x32 0x32 0x30 0x32 0x30 0x32 0x30 0x30 0x35 0x35 0x31

线刷升级后：系统重置了，必须要进行写入，VIN码和PDID，不然登录不了账户，登录不了账户很多东西测试不了，DMS和账户都无法验证。

线刷升级后，必须要重新配置：配置字，见上图。

VIN码PDID如何写入：

1. 使用canoe诊断写入，或者从工程模式手动输入，我都是手动输入（不用借设备）
2. 进入工程模式-->Developer-->点击修改VIN/PDID-->修改后点击确认
3. 写入后：断电重启主机

下面黄色了解就好：

输入完后，还需要以下步骤配置安全信息配置：
进入工程模式-->Developer-->安全证书配置-->点击导入海外PROD CA-->点击生成P10-->点击申请证书（成功）-->点击测试TSP连接（连接成功）

注意：第一次申请证书一般会失败，这个时候只需要点击注销证书，再重新生成P10。申请证书就能申请成功：申请成功后就能登录账户了，以及测试账号类东西。

1. 点击头像，同意授权，找SF5的测试负责人拿红米手机，使用SERES软件登录写入VIN和PDID的账号，用手机号扫码登录。

手机登录账号：13882259103，验证码：666666。

在台架测试阶段，用户账户都是公司后台平台人员加入得 身份信息，需要拿到对应工作手机进行扫码登录。

4.16 日志管理与 BUG 提票✓

三种日志导出方法。

4.16.1 U盘导出日志

在工程模式中，关闭ADB开关。
插入U盘可以直接点击导出日志，导出的日志和一键抓取的日志一样。

日志可以几种形式导出：1. U盘在工程模式下导出，IVI或者CDC系统日志，TBOX日志。

4.16.2 脚本一键抓取日志

连接好ADB后，脚本一键抓取日志：（组长同事哪里获取），遇到BUG后，我们一键抓取日志后，我们要一键清空下日志，内部日志一直在录制，2小时大概能达到500M-1G。

4.16.3 adb logcat

adb logcat > 桌面路径。

抓日志的 4 种方式（思维导图：设备名称）：

1. U 盘导日志
2. adb 脚本导日志
3. adb logcat 导日志
4. 使用工具（CANoe、周立功等）抓报文

总线日志录制方式对比（思维导图：总线日志的录制）：

4.16.4 BUG提票模板

4.16.4.1 BUG 提票时机与流程

找到BUG就提票到缺陷管理平台。
有的公司用，禅道，jira，和一些不知名的软件，以及自研。

详细内容见禅道缺陷管理平台。

规格如下：提票需要有公司人员模块表（找对应开发）。

一：提BUG模板（核心）

标题：【集成】【wifi】链接wifi失败
版本信息：主线NS阀：刷机时候刷那个版本，提票时候版本信息就写那个版本
SOC版本：CDC_7901301-RA19_SW2.12.B_220930_2435_03
MCU版本：MCU_7901301-RA19_SW2.12.B_220930_2435_00
硬件版本：
c样件
环境信息：
台架
预置条件：
1.KL15 ON
2.空调界面已展开
3.空调处于打开状态AC_ctrlFeedback: ac_systemOnOffSts =0x1: ON
4.自动模式处于关闭状态AC_ctrlFeedback: ac_autoStatus=0x0:OFF
操作步骤：
点击自动按钮
实际结果：
未下发信号
预期结果：
IVI发送3帧信号"ivi_hvacAutoModeReq =0x1: KEY_PRESS"，然后周期发送ivi_hvacAutoModeReq =0x0: INVALID
出现概率：
失败率30%左右
问题时间：
2025/5/28 09:34:28
备注：无
log/及附件【图片，视频】：

关BUG模板：

BUG关闭标准
【验证版本】
SOC版本：CDC_7901301-RA19_SW2.12.B_240909_2435_00
MCU版本：MCU_7901301-RA19_SW2.12.B_240909_2435_00
【验证环境】
台架
【验证结果】
Pass
【处理结果】
关闭
【验证次数】
10次
【备注】
无

激活bug模板：

【验证版本】
SOC版本：CDC_7901301-RA19_SW2.12.B_240909_2435_00
MCU版本：MCU_7901301-RA19_SW2.12.B_240909_2435_00
【验证环境】
台架
【验证结果】
Fail
【处理结果】
激活（打开）
【验证次数】
根据bug偶现还是必现写，必现就1次，偶现5-10次
【备注】
log/及附件【图片，视频】：
无

提票时候：那个模块的BUG就提给那个负责人。

测试结束后，要有测试数据。

4.16.4.2 JIRA 提 BUG 流程（ECARX-JIRA）

该长截图包含 JIRA 登录页、创建问题表单、缺陷详情页、问题跟踪及关闭界面、BUG 管理流程图等，建议在下方标注【图】的位置手动插入对应截图片段。

参考视频：【软件测试】jira 的使用教程（B 站）。

一、账号登录

• 需要公司申请 JIRA 账号（ECARX-JIRA）
• 登录 ECARX-JIRA 后选择对应项目进入

二、建票（创建问题）

创建问题表单关键字段：

描述内容规范：

bug 标题：【项目名称】【模块】问题具体的简要描述
例如：【H11】【设置】HUD按钮回弹

bug 具体描述：【前提条件】+【测试步骤】+【实际结果】+【预期结果】+【出现概率】+【问题发生时间】+【测试版本】+【复归操作】

bug 具体描述示例（蓝牙通讯录同步问题）：

【前提条件】
1. UsageMode=Driving, CarMode=Normal
2. 手机已与车机配对连接，手机端已授权通讯录权限
（需要加入一个实际存在的网络，不能实际都没有这个网络，那弹出的就是无法找到网络）

【测试步骤】
1. 反复打开/关闭手机或车机蓝牙开关

【实际结果】
无法正常同步

【预期结果】
1. 能正常自动同步联系人和通话记录

【出现概率】
100%（5/5）

【问题发生时间】
11:40（问题发生时车机端的时间）

【测试版本】（车机系统的版本，从工程模式可查看）
AP: unknown 20821
VP: unknown 01600
Visteon: unknown GER3808

【复归操作】
针对黑屏，卡死等问题

缺陷详情页：包含类型、标签、经办人、报告人、安全级别（Suppliers and Responsible projects members 等）、General Information（Responsible Project、Affected Projects、Platform、ECU、Function）、Test Information、创建日期 / 已更新等。附件区需上传 log（如 log_2026-02-12_15，255.28 MB）与视频（如 video(46).mp4）。

提票原则：哪个模块的 BUG 就提给哪个负责人。

三、问题跟踪及关闭

1. 查看待处理问题：通过“分配给我尚未完成的”筛选待处理问题
2. 确认问题状态：问题状态为 resolved（已解决，暂未切换状态到测试）和 ready for test（已解决，已切换状态到测试）的问题安排验证关闭
3. 支持导出 CSV（当前显示的字段）等

四、BUG 管理流程（状态流转）

状态流转总览：

1. NEW（新建 bug）：测试人员提交 bug，进入 NEW 状态，流转到Analysis（待分析），由开发 / 负责人评估问题。
2. Analysis（问题分析）
3. 判断不是 bug：流转Rejected（开发拒绝），可进一步取消Cancelled；
4. 需要再核实：流转Under observation（待观察）；
5. 需要供应商处理：流转Supplier inbox→Supplier in progress供应商开发处理；
6. 内部修复：进入Solution identified确定修复方案。
7. 修复阶段：方案确定后，bug 修复完成，进入Solved（已解决）。
8. 回归测试：Solved 流转到Ready for test（待回归测试），测试做验证：
9. ✅验证通过：流转Closed（关闭），bug 闭环；
10. ❌回归不通过：流转Reopened（重新打开），退回重新分析修复；
11. 缺少测试条件：进入Testing on hold（测试暂停）；
12. 判定为 bug 但暂不修复：标记维持现状。
13. Reopened 重开：回归失败激活 bug，可以退回分析、供应商、待观察、拒绝等各个前置环节，重新走处理流程。
14. 终态：Closed关闭、Cancelled取消、维持现状，三种为 bug 最终结束状态。

状态转换操作明细表（责任人 / 时限 / 条件 / 操作动作）：

原则：

• 测试人员每天需关注自己名下处于 3/4 阶段的问题，如果无法验证 / 无法流转，需要备注清楚
• Testing On Hold：主要针对不满足测试条件，或偶发问题已有兜底方案但需持续观察（测试样件或测试环境不满足）
• 维持现状：实际该问题已经在项目内部经过决策不整改、偏离接受，且已有会议纪要

五、BUG 处理原则

1. 偶发问题关闭压力测试次数要求：按照问题发现时的发现概率，执行双倍次数测试。

2. 偶发问题解决供应商压力测试次数要求：根据供应商内部分析概率，执行双倍次数测试。

3. Rejected 问题关闭（cancel）流程约束：

对于 rejected 的问题，只有以下两类可以走 cancel 流程关闭：

• ① 确定是重复且非第一个提出的问题
• 注：如果与该问题重复的是一个已经关闭的问题，且问题仍然存在，则需判断原关闭问题是否已经过项目和质量偏离：如已偏离则 cancel 此问题；如未偏离则保留此问题
• ② 确定是非有效问题的问题

针对其他如 log 不全问题、偶发问题、需求偏离接收的问题、让步接收的问题，均按照 close 流程关闭。从 rejected 状态切换到 cancel 状态时，需要按照实际情况选择 cancel reason。后续 cancel 率统计将以非有效问题的 cancel 问题进行统计，所以需要准确填写。

4. CID 类问题：如果测试与开发不能达成一致意见，可以通过参考标杆项目的表现来确定是否可以关闭（close 或 cancel）。如果标杆项目（重点项目，且累计销量已超 10W）的表现与问题中的描述一致，且没有此类问题的投诉，那么可以关闭此问题。

5. 系统不整改关闭类（R1/R2）问题管理要求：

4.16.5 邮件与群发布

4.16.5.1 邮件发布

邮件下面发邮件格式：

【SE OS 智能座舱软件平台项目】【集成测试】【2025/08/25】Daily 集成测试结果

Hi all
【SE OS 智能座舱软件平台项目】【集成测试】结果如下，附件为本次版本2025/08/25 集成测试结果，请查收

1.版本信息：（如下例）
CDC版本：CDC_7901301-RA19_SW2.12.B_250825_2435_03
MCU版本：MCU_7901301-RA19_SW2.12.B_250825_2435_00

测试结果：

邮件发完后，也要把对应的当天测试结果图片发微信群里面。

4.16.5.2 群发布测试结果

集成测试09/29daily版本测试结果

（同上面的测试结果汇总表格截图）