4. 测试策略与计划：基于V模型的测试策略、测试计划制定、测试用例设计方法
各位同学，咱们今天聊点实在的。测试策略和计划，说白了就是打仗前的排兵布阵。你想想看，一个车规级项目，几十个ECU，上千万行代码，没有策略就往上冲，那结果只能是——测试覆盖率一塌糊涂，bug漏到路试才发现。
我个人习惯，在项目启动的第一周，就必须把测试策略这张图给画出来。不是画给领导看的，是画给自己团队看的。今天我就把我在几个量产项目里踩过的坑、总结出来的方法，掰开了揉碎了讲给你们听。
4.1 基于V模型的测试策略
V模型大家都熟悉，左边是开发，右边是测试。但很多人把它理解成了“先开发完再测试”，这是大错特错的。V模型的核心思想是：测试活动应该与开发活动并行开展。
我给大家画一张图，看看V模型里测试策略到底长什么样。
这张图我想强调三个关键点：
- 双向验证：左侧每个开发活动，右侧都有对应的测试活动。系统需求分析完了，系统验收测试的用例就要开始写了。
- 测试左移：别等到代码写完了才想怎么测。我在一个项目中吃过亏，需求阶段没参与，结果测试时发现需求本身就有歧义，返工成本高得吓人。
- 分层策略：不同层级关注不同质量属性。单元测试关注逻辑正确性，集成测试关注接口交互，系统测试关注功能和非功能需求。
实战经验：我在做某个ADAS项目时，测试策略里专门加了一层“安全机制验证测试”。因为ISO 26262要求ASIL B以上的功能，必须单独验证安全机制的覆盖率和有效性。这一层放在软件集成测试和系统集成测试之间，专门用来测故障注入后的系统行为。
4.2 测试计划制定
测试计划不是写一份文档就完事了。它是个活的东西，要跟着项目节奏不断调整。我一般把测试计划拆成三个维度来考虑：
| 维度 | 核心内容 | 我的建议 |
|---|---|---|
| 时间维度 | 测试里程碑、迭代周期、关键交付节点 | 每个Sprint结束前2天，必须完成当轮测试报告 |
| 资源维度 | 测试环境（HIL/SIL/MIL）、工具链、人员分工 | HIL台架要提前2周预约，别等到测试前1天才发现没资源 |
| 质量维度 | 测试准入/准出标准、缺陷管理流程、覆盖率目标 | MC/DC覆盖率达不到100%的模块，不允许进入集成测试 |
嗯，这里要注意。测试计划里最容易忽略的是测试环境准备。我记得有一次，测试计划里写了“第8周开始HIL测试”，结果第8周到了，HIL台架还没搭好，因为采购的板卡缺货。从那以后，我要求测试计划里必须包含环境就绪检查点，提前两周确认。
小技巧：用甘特图来管理测试计划。每个测试活动标注前置依赖、持续时长、负责人。我习惯用Excel画一个简单的甘特图，贴在团队共享空间里，每周更新一次进度。
4.3 测试用例设计方法
测试用例设计，是测试工程师的核心手艺。车规级软件对测试用例的要求尤其高——你想想看，一个刹车系统的bug，可能关系到生命安全。所以用例设计必须系统化、可追溯。
今天重点讲两个最基础也最实用的方法：等价类划分和边界值分析。
4.3.1 等价类划分
等价类划分的核心思想是：把输入域分成若干个子集，每个子集里的数据对程序来说“等价”。你只需要从每个等价类里选一个代表值来测，就能覆盖整个子集。
举个例子，一个车速信号处理函数，输入范围是0~250 km/h：
- 有效等价类：0 ≤ 车速 ≤ 250（正常范围）
- 无效等价类：车速 < 0（负值异常）、车速 > 250（超范围异常）
- 特殊等价类：车速 = 0（静止状态）、车速 = 250（最高限速）
我在项目中遇到过一个问题：测试人员只测了有效等价类，忽略了无效等价类。结果在实车路试时，传感器偶发输出一个-1的值，系统直接崩溃了。这就是典型的等价类划分不完整。
避坑指南：我曾经在一个项目中，等价类划分只考虑了功能输入，没考虑环境输入。比如温度、电压、CAN总线负载率这些因素，也会影响系统行为。建议在等价类划分时，把环境变量也纳入考虑。
4.3.2 边界值分析
边界值分析是等价类划分的补充。经验告诉我们，程序在边界处最容易出bug。所以我们要重点测试每个等价类的边界值及其邻域。
还是车速信号的例子：
| 边界类型 | 测试值 | 预期结果 |
|---|---|---|
| 下边界 | 0 | 正常处理 |
| 下边界-1 | -1 | 触发错误处理或默认值 |
| 下边界+1 | 1 | 正常处理 |
| 上边界 | 250 | 正常处理 |
| 上边界-1 | 249 | 正常处理 |
| 上边界+1 | 251 | 触发错误处理或饱和截断 |
你想想看，为什么边界值这么重要？因为程序员写条件判断时，经常写错 <= 和 <。比如本应是 if (speed >= 0 && speed <= 250)，结果写成了 if (speed > 0 && speed < 250)。边界值测试就能抓住这类问题。
4.3.3 组合方法实战
在实际项目中，我通常把等价类划分和边界值分析结合起来用。下面是一个完整的用例设计流程：
- 识别输入变量：列出所有影响系统行为的输入（包括功能输入和环境输入）。
- 划分等价类：对每个输入变量，划分有效等价类和无效等价类。
- 提取边界值：对每个等价类，提取边界值及其邻域。
- 组合测试用例：用正交表或Pairwise方法，把不同变量的等价类和边界值组合起来，减少用例数量。
- 添加异常场景：补充一些特殊场景，比如多个输入同时越界、输入抖动、通信中断等。
实战案例：我在做电池管理系统（BMS）的测试时，有一个功能是“过温保护”。输入变量包括电池温度、电流、SOC。我们用等价类划分把温度分成：低温（< -20°C）、正常（-20~60°C）、高温（60~85°C）、过温（> 85°C）。边界值重点测了-20°C、60°C、85°C这几个点。结果在-20°C边界处发现了一个bug——温度传感器在-20°C时输出值跳变，导致保护逻辑误触发。
4.4 测试用例的追溯性
车规级项目有个硬性要求：每个测试用例都必须能追溯到需求。ISO 26262里明确要求建立需求-测试用例的双向追溯矩阵。
我习惯用表格来管理追溯关系：
| 需求ID | 需求描述 | 测试用例ID | 测试方法 | 覆盖类型 |
|---|---|---|---|---|
| REQ-SPD-001 | 车速信号范围0~250 km/h | TC-SPD-001~006 | 等价类+边界值 | 功能覆盖 |
| REQ-SPD-002 | 超速时触发报警 | TC-SPD-007~009 | 边界值+异常场景 | 功能覆盖+错误覆盖 |
| REQ-SPD-003 | 车速信号丢失时使用默认值0 | TC-SPD-010~012 | 故障注入 | 安全机制覆盖 |
这样做的好处是，当需求变更时，你能快速定位到受影响的测试用例，及时更新。我在一个项目中，需求改了3版，测试用例也跟着迭代了3版，全靠这个追溯矩阵才没漏掉。
工具推荐：如果项目规模大，建议用DOORS或Polarion这类需求管理工具，自动生成追溯矩阵。小团队用Excel也能搞定，但一定要保持更新，别偷懒。
4.5 测试策略的落地检查清单
最后，我给大家一个自检清单。每次制定测试策略和计划时，对照着过一遍：
- ✅ 测试活动是否与开发活动并行启动？
- ✅ 每个测试层级是否有明确的准入/准出标准？
- ✅ 测试环境（HIL/SIL/MIL）是否已就绪？
- ✅ 测试用例是否覆盖了所有等价类和边界值？
- ✅ 无效等价类和异常场景是否已包含？
- ✅ 测试用例是否可追溯到需求？
- ✅ 安全机制验证是否有单独的测试用例？
- ✅ 测试计划中是否预留了回归测试的时间？
嗯，这个清单看起来简单，但每一条背后都有血泪教训。我建议你们把这份清单打印出来，贴在工位上。每次做测试计划时，一条一条核对，能帮你避开80%的坑。