第二篇：测试流程

2.1 需求分析✓

需求定义产品功能以及维度。首先需要了解熟悉业务，分析需求测试点。

确定功能边界：

• 整个业务流程上的功能
• 数据约束条件（比如：6位密码这就是约束条件）
• 权限限制
• 性能约束（比如轮播图需要几秒切换一张这就是性能约束）
• 易用性需求

业务流程：所有功能的连贯性，还需要考虑当前的需求有没有涉及到其他的管理平台。

前台操作系统：用户可以看到的界面。

2.1.1 如何评审需求？

需求通过后：开发根据需求去开发产品功能维度。
测试人员：根据需求写出正向反向用例，以及维度。

2.2 测试计划✓

编写目的：根据需求文档，制定测试策略，预先评估风险，确定测试需要的资源，人员安排以为进度安排，工作量评估。

测试计划7要素：

2.3 测试策略✓

2.4 测试用例✓

根据需求，设计用例。

用例表结构：

2.4.1 座舱测试用例编写核心原则

座舱测试用例编写须遵循以下五项原则，其中"车载特殊性"是区别于互联网测试的关键：

1. 唯一性：一条用例只验证一个测试点，避免多目标混杂导致缺陷定位困难。
2. 可复现：操作步骤清晰、前置条件明确，任何测试工程师按步骤执行均能得到相同结果。
3. 无歧义：预期结果可量化、可判定，明确 Pass / Fail 标准，禁止"显示正常""功能正常"等模糊表述。
4. 全覆盖：正常场景 + 边界场景 + 异常场景 + 反向操作，确保需求无遗漏。
5. 车载特殊性：车载场景贯穿用例全生命周期，不仅体现在前置条件，还影响操作步骤设计与预期结果判定。核心要素包括：行车 / 驻车状态、车速联动阈值、驾驶位权限、行车禁限策略、上下电时序、休眠唤醒。

2.4.2 测试用例标准模板字段定义

座舱测试用例标准模板包含以下字段，企业可根据 ALM 工具（如 Jira / Polarion / TestLink）裁剪：

2.4.3 用例三要素区分

用例的核心三要素为前置条件、操作步骤、实际结果，三者边界必须清晰：

前置条件（测试执行的基础门槛）：正式执行测试操作前，车辆、硬件、软件、网络、环境必须全部满足的初始稳定状态。不满足则测试无效、结果不可信。车载包含4类条件：

1. 整车状态：点火挡位（OFF / ACC / ON / READY）、车速、SOC 电量、高压上电状态、挡位（P / R / N / D）
2. ECU / 软件状态：座舱域控制器、网关、空调 ACM 无故障码，软件版本匹配，无未清除 DTC
3. 硬件工具：CAN 盒（如 PCAN / VN1630）、诊断仪（如 DOIP / VCI）、实车 / 台架环境就绪
4. 前置功能状态：空调默认关闭、语音唤醒功能开启、无故障弹窗、蓝牙已连接等

操作步骤（人为 / 工具执行的有序动作）：测试人员按顺序执行的标准化、可复现操作，是触发被测功能的输入动作流。必须分步、无歧义、可重复执行；只记录人 / 工具做了什么，不写系统反馈。反例："打开音乐并播放歌曲" → 拆分：1. 点击中控桌面【音乐】图标；2. 在歌单中点击第一首歌曲。

实际结果（测试执行完真实发生的现象）：执行完整操作步骤后，车辆、ECU、总线、界面真实表现出的客观现象、报文数据、硬件动作，是实测客观记录。车载需记录多维度信息：界面显示、CAN 报文（信号值 / 周期）、硬件动作（继电器吸合 / 电机运转）、ECU 反馈（诊断响应 / 日志）。预期结果是写用例时根据需求文档预先规定的正确标准表现，实际结果是跑完用例后现场看到的真实客观现象，二者对比不一致则判定测试不通过。

2.4.4 用例编写通用方法论

需求拆解：拿到需求文档、UI 图、交互文档后，按以下维度拆解：入口（桌面图标 / 语音 / 方向盘键 / 自动触发）、操作（用户可执行的操作步骤）、展示（界面元素、状态展示）、联动（跨模块 / 跨域的联动关系）、限制（行车禁限 / 权限限制 / 网络限制）、异常（断网 / 断电 / 冲突调用）、退出（功能退出方式与退出后状态）。

测试场景划分（5大场景库）：

1. 正向正常场景：常规日常使用流程，验证主路径功能正确性。
2. 边界场景：最大值 / 最小值、字数上限、时长上限、设备数量上限。
3. 反向操作场景：频繁点击、快速切换、中途退出、打断操作、非法输入。
4. 异常环境场景：断网、弱网、蓝牙断连、电量低、多应用后台驻留、高温 / 低温。
5. 车载联动场景：车速联动、挡位联动、整车休眠 / 唤醒、上下电时序、整车 OTA、驾驶模式切换。

通用用例设计方法：

2.4.5 座舱模块用例示范

多媒体 - 音乐播放（正向用例）：

• 用例标题：驻车状态下，正常在线音乐播放 / 暂停切换
• 前置条件：车辆 P 挡驻车、网络正常、登录车机账号、音乐 APP 可正常打开
• 测试步骤：1. 点击中控桌面音乐图标，进入音乐播放器；2. 选择任意在线歌曲，点击播放；3. 播放中点击暂停按钮
• 预期结果：1. 正常进入音乐页面，无卡顿、闪退；2. 歌曲正常播放，进度条走动、喇叭出声、播放图标状态切换；3. 音乐暂停，进度条停止，暂停图标反向显示，声音停止

行车限制（车载特色反向用例）：

• 用例标题：车辆行驶中，视频应用自动限制播放
• 前置条件：车辆连接行车模拟器，车速可调节
• 测试步骤：1. 驻车时打开视频 APP 并正常播放视频；2. 控制车速提升至阈值以上
• 预期结果：行车触发限制，视频画面自动黑屏 / 提示行车禁止播放，音频可正常播放（按车企规范）

多屏交互 - 仪表联动：打开导航开始巡航，中控导航信息同步极简展示至仪表，图标、路名、距离、转向箭头显示正常；导航转向时仪表箭头同步刷新，延迟 ≤ 500ms。

2.4.6 常见编写错误与避坑

2.4.7 座舱高频测试点库

• 系统桌面与设置：图标显示、拖拽排序、主题切换（昼夜 / 深色）、壁纸更换、息屏 / 亮屏、恢复出厂设置、多用户切换、系统更新入口。
• 影音娱乐：音乐 / 视频 / 电台、收藏 / 历史、音量调节、静音、音效模式、行车禁播、后台播放、蓝牙音乐切换、音源切换优先级。
• 导航：搜索、路线规划、偏路重算、红绿灯 / 测速提示、仪表投屏、HUD 联动、离线地图、弱网导航、账号同步收藏点。
• 连接类：蓝牙电话、蓝牙音乐、WiFi、热点、CarPlay / HiCar / CarLife、设备配对 / 断连 / 自动重连、多设备切换、USB 连接。
• 语音交互：唤醒 / 打断、连续对话、座舱控制（空调 / 灯光 / 门窗 / 座椅）、静音识别、无网络语音能力、可见即可说、多音区识别、唤醒词自定义。
• 整车联动：上电 / 下电、休眠唤醒、挡位切换、车速限制、低压欠压、整车故障弹窗、驾驶模式切换、充电状态联动、迎宾 / 送客模式。
• 稳定性与性能：冷启动时间、APP 打开帧率、长时间驻留、连续切换、内存占用、发热卡顿、Monkey 压力测试、休眠唤醒恢复速度。

2.4.8 用例写出后，需要三方评审

• 产品需求方
• 开发项目方
• 测试组

测试组需要一条一条讲解所写用例，其他方给出评价意见，评审通过存档测试（待提挡测试），评审不通过，重新优化。

评审流程补充（思维导图：网络拓扑、用例编写）：

• 需求评审：需求工程师讲解需求改动 / 描述内容，并解答各方提出的问题；产品核对需求与产品描述是否一致，有出入提出疑问；开发、测试对不理解之处当场提出，由需求工程师解答
• 测试用例评审：其他三方部门对用例不理解或有疑惑的，由测试解答；有问题的用例标注后修改
• 评审组织：项目经理、科室主任参与

2.5 用例执行✓

需要搭建好测试环境——打包最新版本。
提前准备好测试工具，提前下载好软件。
准备好测试用例：根据用例优先级进行执行。

执行流程：冒烟 → 全面测试 → 先测功能在测性能 → 全面回归测试

测试时候遇到BUG：先复现一下

• 复现是需要先拍摄证据，确认偶现还是必现（复现5次）
• 之后拉日志
• 打点：BUG的时间点，出现BUG先打点，时间戳精确到秒，出现哪些问题在视频中都要解说出来
• 之后提票，就是提BUG到缺陷管理平台
• 开发修复后，回归验证，通过关闭，不通过打回，完成测试闭环

2.6 测试报告✓