3、测试用例设计基础：等价类划分法、边界值分析法、因果图法、场景法在MIL中的应用
做MIL测试这么多年，我见过太多工程师一上来就对着模型瞎点。点完发现覆盖率不够，又回头补用例。说白了，测试用例设计不是拍脑袋的事。它需要方法，需要套路。
今天聊的这四种方法，是我个人在MIL项目中最常用的。它们不是理论空谈，每一个我都踩过坑，也填过坑。
3.1 等价类划分法：别做无用功
等价类划分，说白了就是把输入域分成几个“同类”的区间。你只要从每个区间里挑一个值测试，就能代表整个区间。
为什么MIL里特别管用？
因为模型里的输入信号，很多都是连续值。比如车速0-300km/h，你不可能每个速度都测一遍。那得测到猴年马月去。
核心原则：
- 有效等价类：符合需求规格的输入。比如车速0-300km/h，这个区间内的值都是有效的。
- 无效等价类：不符合需求规格的输入。比如车速小于0，或者大于300。
我记得有一次，测试一个电池SOC（荷电状态）的估算模型。需求写的是SOC范围0%-100%。我偷懒，只测了50%这一个点。结果呢？模型在SOC接近0%时，估算误差突然变大。因为那个区间有个非线性补偿算法，我根本没覆盖到。
避坑指南：
我曾经犯过一个错：把无效等价类想得太简单。比如车速输入，你以为小于0就是无效。但模型内部可能对负值有特殊处理（比如取绝对值）。所以无效等价类也要测，而且要测出边界。
MIL中的实践步骤：
- 识别输入条件（比如车速、油门开度、制动压力）。
- 划分有效和无效等价类。
- 每个等价类至少选一个代表值。
- 生成测试用例。
3.2 边界值分析法：Bug最爱藏在边边上
等价类划分解决了“测哪些区间”的问题。但边界值分析法解决的是“区间边界怎么测”。
你想想看，开发写代码时，最容易出错的地方是哪？就是那些判断条件。比如 if (speed >= 0 && speed <= 300)，这个 >= 和 <= 的边界，稍微写错一个符号，模型行为就全变了。
边界值分析法的要点：
- 取边界上的值（比如0和300）。
- 取边界两侧的值（比如-1和301）。
- 取边界内侧的值（比如1和299）。
我的习惯：在MIL测试中，我通常把边界值分析法跟等价类划分法结合着用。先划分等价类，再在边界上多测几个点。这样覆盖率基本不会差。
举个例子，测试一个“车速超过120km/h时报警”的功能。边界值用例可以这样设计：
| 测试输入（车速） | 预期输出（报警状态） | 说明 |
|---|---|---|
| 119 km/h | 不报警 | 边界内侧 |
| 120 km/h | 报警 | 边界值 |
| 121 km/h | 报警 | 边界外侧 |
嗯，这里要注意：边界值不光是数值边界。时间边界、状态边界也一样。比如一个延时5秒的动作，第4.9秒和第5.1秒就是边界。
3.3 因果图法：理清逻辑关系
等价类和边界值，主要针对单个输入。但模型里很多功能是多个输入组合决定的。这时候因果图法就派上用场了。
因果图法的本质：把“原因”（输入条件）和“结果”（输出行为）之间的逻辑关系画出来。然后根据这个图生成测试用例。
常见的逻辑关系有：
- 恒等：原因A成立，结果B就成立。
- 非：原因A不成立，结果B才成立。
- 与：多个原因同时成立，结果才成立。
- 或：多个原因中只要有一个成立，结果就成立。
我在项目中遇到过这样一个案例：一个“自动紧急制动（AEB）”模型。它的触发条件是：车速大于30km/h 且 前车距离小于10米 且 驾驶员未踩制动。三个条件缺一不可。
如果用等价类划分，你可能只测了“三个条件都满足”和“都不满足”。但因果图法会告诉你：
- 条件1满足，条件2不满足，条件3满足 → 结果？
- 条件1不满足，条件2满足，条件3满足 → 结果？
- ……
一共2^3=8种组合。你想想看，如果漏掉其中一种，模型在那种组合下可能做出错误决策。后果是什么？可能是追尾。
因果图法的步骤：
- 分析需求，找出所有原因和结果。
- 画出因果图（逻辑关系图）。
- 根据因果图生成决策表。
- 从决策表导出测试用例。
3.4 场景法：模拟真实驾驶
前面三种方法，都是从“输入”角度出发的。但场景法不一样。它从“用户故事”或“驾驶场景”出发。
为什么需要场景法？
因为很多Bug，不是单个输入错了，而是多个事件按特定顺序发生时，模型处理不过来。比如：
- 先急加速，再急减速，再急加速。
- 先进入弯道，再触发AEB，再退出弯道。
这些场景，用等价类或边界值很难构造出来。但场景法可以。
场景法的核心：
- 基本流：正常、无异常的流程。比如“驾驶员正常加速到60km/h，然后匀速行驶”。
- 备选流：出现异常或分支的流程。比如“加速过程中，前车突然急刹”。
- 异常流：系统无法处理的流程。比如“传感器突然失效”。
我个人习惯，在MIL测试中，场景法通常用来做“集成测试”或“系统测试”级别的用例设计。因为单元测试用等价类和边界值就够了。但到了模型集成阶段，场景法能帮你发现那些“意想不到”的交互问题。
避坑指南：我曾经设计过一个“高速公路跟车”场景。基本流是“前车匀速，后车跟车”。备选流是“前车减速，后车减速”。看起来没问题。但实际测试时，模型在“前车减速后又加速”这个场景下，出现了跟车距离过大的问题。因为模型对“减速后恢复”的响应太慢了。这个场景，如果不用场景法，我根本想不到去测。
3.5 四种方法的组合使用
说了这么多，你可能会问：到底用哪种？
我的建议是：别只用一种。它们不是互斥的，是互补的。
| 方法 | 适用场景 | MIL中的典型应用 |
|---|---|---|
| 等价类划分法 | 单个输入，连续值 | 车速、温度、压力等模拟量输入 |
| 边界值分析法 | 有明确边界的输入 | 阈值判断、状态切换点 |
| 因果图法 | 多个输入组合决定输出 | 逻辑判断、使能条件、故障处理 |
| 场景法 | 事件序列、用户操作流程 | 驾驶场景、故障注入、模式切换 |
我通常的做法是：
- 先用场景法，梳理出核心的驾驶场景。
- 对每个场景中的关键输入，用等价类划分和边界值分析法细化。
- 对场景中的逻辑判断，用因果图法补充。
这样一套组合拳下来，测试用例的覆盖率基本能到90%以上。剩下的10%，靠经验和对模型的深入理解去补。
最后提醒一句：方法只是工具。别为了用方法而用方法。我见过有人把因果图画得跟电路图一样复杂，结果用例数量爆炸，根本测不完。记住，MIL测试的目的是“用最少的用例，发现最多的Bug”。