4、测试策略制定：测试范围界定、测试深度与广度、回归测试策略
好，咱们接着聊。前面我们把需求拆成了一个个可测的点，也把HIL环境搭起来了。但有个问题摆在你面前：测什么？测多深？改完代码后要不要全重来？
这就是测试策略要干的事。说白了，就是给你一张作战地图。我见过不少项目，上来就闷头写用例，结果测了一堆无关紧要的，真正有风险的反而漏了。嗯，咱们今天就把这事掰扯清楚。
4.1 测试范围界定：别什么都往里装
测试范围，就是划个圈。圈里的必须测，圈外的暂时不管。怎么划？我个人习惯从三个维度下手：
- 功能维度：哪些功能是核心的？比如ACC（自适应巡航）的跟车、刹停、起步，这些是必测的。而氛围灯颜色切换，优先级就低一些。
- 接口维度：哪些信号是关键的？比如CAN总线上的车速、方向盘转角、制动压力。这些信号错了，车可能直接失控。
- 场景维度：哪些工况是高频的？比如城市拥堵、高速巡航、紧急切入。这些场景覆盖了用户90%的使用时间。
核心原则：测试范围 = 功能重要性 × 失效风险 × 用户使用频率。
三者都高的，必须纳入。有一个低的，可以酌情裁剪。
我在项目中遇到过一件事：某次做BMS（电池管理系统）测试，团队把SOC（荷电状态）校准这种低频维护功能也纳入了HIL测试范围，结果占用了大量资源。后来我建议他们只测核心充放电策略和故障保护，把校准留给实车标定。测试效率直接翻倍。
4.2 测试深度与广度：别太浅，也别太深
测试深度和广度，是一对矛盾。广度大了，深度必然浅。深度够了，广度就受限。怎么平衡？
4.2.1 测试广度：覆盖多少条路？
广度，就是你的测试用例覆盖了多少种输入组合和场景。我一般用等价类划分和边界值分析来定。
举个例子，一个车速信号，范围是0-250 km/h。你不需要测1、2、3……每个值。你只需要测：
- 有效等价类：30 km/h（正常行驶）、100 km/h（高速）
- 边界值：0 km/h、250 km/h、251 km/h（超界）
- 特殊值：-1 km/h（无效信号）
这样，用5个用例就覆盖了所有可能。这就是广度控制的精髓。
4.2.2 测试深度：每条路走多远？
深度，就是每个测试点要测到什么程度。是只测功能通不通，还是连异常、边界、压力都测？
我建议按风险等级来定深度：
| 风险等级 | 定义 | 测试深度要求 |
|---|---|---|
| P0（致命） | 功能失效会导致安全事故 | 全深度：功能、异常、边界、压力、长时间运行 |
| P1（严重） | 功能失效影响驾驶体验 | 中深度：功能、异常、边界 |
| P2（一般） | 功能失效不影响安全 | 浅深度：功能测试即可 |
我的经验：P0级别的测试，我通常会额外加一条「长时间压力测试」。比如让ACC连续工作8小时，看会不会出现内存泄漏或看门狗复位。你想想看，用户可能开长途，系统不能中途掉链子。
4.3 回归测试策略：改完代码后怎么办？
这是最让人头疼的。代码一改，到底要重测多少？全测吧，时间不够。不测吧，心里没底。
我曾经在一个项目中吃过亏。当时只改了仪表盘的一个显示bug，觉得影响不大，就只测了显示相关的用例。结果这个改动影响了底层CAN信号的解析，导致车速显示全部偏移。嗯，从那以后，我定了一套回归策略。
4.3.1 回归测试的三种类型
- 全量回归：所有用例都跑一遍。适用于大版本升级、架构重构。
- 增量回归：只跑受影响的模块和关联模块。适用于小功能修改。
- 冒烟回归：只跑核心功能的几个关键用例。适用于紧急hotfix。
4.3.2 如何确定影响范围？
我建议用信号依赖图来分析。比如你改了制动灯信号，那所有依赖制动灯信号的模块（比如ACC、AEB、ESC）都要回归。
具体做法：
- 列出所有被修改的输入/输出信号。
- 在HIL测试矩阵中，搜索所有用到这些信号的用例。
- 把这些用例标记为「必回归」。
- 再额外加10%的随机用例，防止遗漏。
注意：千万不要只依赖「感觉」。我见过有人觉得「这个改动很小，不用回归」，结果上线后出了大问题。回归策略一定要有数据支撑，而不是拍脑袋。
4.4 实战：一个完整的测试策略示例
假设我们要测试一个自动紧急制动（AEB）功能。我会这样制定策略：
| 维度 | 内容 |
|---|---|
| 测试范围 | 核心功能：前向碰撞预警、自动制动、制动释放。接口：雷达信号、车速、制动压力。场景：前车静止、前车减速、行人横穿。 |
| 测试深度 | P0级（安全相关）：全深度，包括功能、异常（雷达遮挡）、边界（车速0-80 km/h）、压力（连续触发10次）。 |
| 测试广度 | 等价类：车速（10、30、60 km/h）、目标距离（5、20、50米）。边界值：0 km/h、80 km/h、81 km/h。 |
| 回归策略 | 每次修改后，先跑冒烟回归（3个核心场景）。如果通过，再跑增量回归（所有涉及雷达信号的用例）。大版本升级时，全量回归。 |
一句话总结：测试策略不是一成不变的。它应该随着项目阶段、风险变化、资源情况动态调整。你想想看，项目初期和交付前一周，策略能一样吗？
好了，这一章就到这里。下一章我们聊聊测试用例设计的具体方法，包括等价类、边界值、判定表这些实战技巧。到时候我会拿几个真实的HIL项目案例来拆解，保证你听完就能用。