测试策略制定：测试范围界定、测试级别选择、测试环境规划
好，咱们接着聊。前面我们把需求理清楚了，用例也画得差不多了。但有个问题摆在你面前：到底测什么？测到什么程度？在哪儿测？
这三个问题，就是测试策略要回答的。我见过不少项目，测试用例写得漂漂亮亮，结果一执行就发现——要么测了不该测的，要么该测的没测到。说白了，就是策略没定好。
今天这一章，我就把这三个核心问题掰开揉碎了讲。你跟着我的思路走一遍，以后做策略就不会跑偏。
一、测试范围界定：别什么都往里装
测试范围，说白了就是划边界。哪些功能要测，哪些不测，测到什么深度。
我刚开始带项目时，总想把所有功能都测一遍。结果呢？项目周期拖了两个月，客户还抱怨关键问题没发现。后来我学乖了——测试范围不是越大越好，而是越准越好。
1.1 基于风险的测试范围界定
我个人习惯用风险矩阵来定范围。把每个功能按两个维度打分：
- 失效后果严重性（1-5分，5分最严重）
- 失效发生概率（1-5分，5分最可能）
然后算风险值 = 严重性 × 概率。我一般这样划分：
| 风险等级 | 风险值范围 | 测试策略 |
|---|---|---|
| 高 | 15-25 | 全覆盖测试，含边界、异常、压力 |
| 中 | 8-14 | 核心功能+典型异常 |
| 低 | 1-7 | 冒烟测试或抽样 |
举个例子。我在做ADAS（高级驾驶辅助系统）项目时，AEB（自动紧急制动）功能的风险值高达25。为什么？失效后果是撞车，概率也不低。那我的策略就是：所有场景全覆盖，包括雨雾天气、夜间、行人鬼探头。
而像车窗一键升降这种功能，风险值顶多6-7分。我就只测基本升降和防夹功能，不会花时间测1000次循环。
核心原则：高风险功能，投入80%的测试资源；低风险功能，20%的资源就够了。别平均用力。
1.2 功能边界与接口边界
范围界定还要考虑功能边界和接口边界。
- 功能边界：比如ESP（电子稳定程序）的介入车速范围是0-120km/h。那0和120就是边界，必须测。
- 接口边界：比如CAN信号的值域是0-255。那0和255就是边界，超范围的值也要测。
我记得有一次，一个同事测BCM（车身控制模块），只测了正常电压范围。结果装车后，电瓶电压偏低时，车窗就失灵了。为什么？因为没测欠压边界。嗯，这个坑我踩过，所以现在特别强调边界。
二、测试级别选择：从单元到系统，层层把关
测试级别，就是在哪个层级测。HIL测试通常涉及三个级别：
- 单元级HIL：测单个ECU（电子控制单元）
- 集成级HIL：测多个ECU的交互
- 系统级HIL：测整车级功能
你可能会问：是不是每个级别都要测？我的答案是：看项目阶段和风险。
2.1 单元级HIL：打地基
单元级HIL，说白了就是把单个ECU拿出来，单独测。这时候，其他ECU用仿真模型代替。
我建议在软件发布早期做单元级HIL。为什么？因为这时候bug最多，而且单个ECU的问题最容易定位。
举个例子。我在做BMS（电池管理系统）项目时，单元级HIL发现了SOC（荷电状态）估算的算法bug。如果等到系统级才发现，排查起来就麻烦了——到底是BMS的问题，还是VCU（整车控制器）的问题？
我的经验：单元级HIL能发现约60%的软件bug。而且修复成本最低。所以别跳过这步。
2.2 集成级HIL：看配合
集成级HIL，测的是多个ECU之间的交互。比如VCU和BMS的通信、ESP和EPS（电动助力转向）的协同。
这个级别，我一般在软件集成测试阶段做。这时候，单个ECU已经测过了，重点看它们能不能好好配合。
我曾经遇到一个案例：VCU发送的扭矩请求，BMS能正确接收。但ESP也同时发送了扭矩请求，VCU就懵了——到底听谁的？这就是集成级HIL才能发现的问题。
2.3 系统级HIL：模拟真车
系统级HIL，是最接近实车的测试。所有ECU都连上，用整车模型跑场景。
我一般在实车测试前做系统级HIL。说白了，就是在实验室里模拟跑一圈。能发现很多实车测试难以复现的问题，比如偶发性的CAN总线冲突。
注意：系统级HIL的模型复杂度高，实时性要求也高。我曾经因为模型步长设置不当，导致仿真结果失真。所以，模型验证是系统级HIL的前提。
三、测试环境规划：工欲善其事，必先利其器
测试环境，就是你用什么工具、什么设备来测。环境规划不好，测试效率会大打折扣。
3.1 硬件环境：选对平台
HIL测试的硬件平台，主流的有：
- dSPACE：功能强大，但贵。适合大型项目。
- NI PXI：灵活性高，性价比不错。我比较常用。
- ETAS LABCAR：集成度高，适合系统级测试。
我个人习惯根据被测对象来选平台。比如测一个简单的BCM，用NI PXI就够了。但测ADAS域控制器，我建议上dSPACE——它的实时性和IO通道数更靠谱。
3.2 软件环境：模型与工具链
软件环境包括：
- 实时模型：比如车辆动力学模型、电池模型、发动机模型。我用过CarSim、ASM、Simulink自建模型。
- 测试管理工具：比如ECU-TEST、TestStand。用来编排测试用例、自动执行、生成报告。
- 总线工具：比如CANoe、PCAN。用来监控和仿真CAN/LIN/以太网。
这里有个坑：模型精度。我见过有人用简化的电池模型测BMS，结果SOC估算误差高达10%。那测试结果还有什么意义？所以，模型精度一定要和测试目标匹配。
我的建议：测试环境规划时，先列一个环境需求清单。包括：IO通道数量、总线类型、实时性要求、模型精度要求。然后根据清单选设备，别拍脑袋。
3.3 环境搭建的避坑指南
我曾经犯过一个低级错误：环境搭建好了，但信号线没做屏蔽。结果测试时，信号干扰导致数据全是毛刺。排查了两天才发现是线缆问题。
所以，环境搭建时要注意：
- 接地：所有设备共地，避免地环路。
- 屏蔽：高速信号线用屏蔽线，且单端接地。
- 标定：传感器和执行器要标定准确。比如油门踏板位置传感器，标定不准，测试结果全错。
嗯，这些细节看似琐碎，但往往决定测试成败。
总结一下
测试策略制定，就是回答三个问题：
- 测什么？——用风险矩阵划范围，别贪多。
- 在哪个级别测？——单元级打基础，集成级看配合，系统级模拟真车。
- 用什么环境测？——硬件选对平台，软件配好模型，搭建时注意细节。
你想想看，如果这三个问题都搞清楚了，测试执行起来是不是就顺畅多了？
下一章，我们聊聊测试用例设计方法——怎么把策略落地成具体的测试步骤。到时候见。