4、测试用例设计方法（上）：等价类划分、边界值分析、决策表法在TCU换挡逻辑中的应用
各位工程师，大家好。今天我们聊聊测试用例设计。
说实话，很多刚入行的朋友觉得写测试用例就是「点点点」。但真正做过TCU项目的人都知道，换挡逻辑的测试用例设计，是门手艺活。搞不好，路试的时候就会出洋相。
我个人习惯把测试用例设计方法分成两派：黑盒派和白盒派。今天我们先讲黑盒派的三个核心招式：等价类划分、边界值分析、决策表法。这三个方法，在TCU换挡逻辑测试中，几乎天天用。
4.1 等价类划分：别做无用功
等价类划分，说白了就是「抓典型」。
你想想看，油门开度从10%到90%，难道每个百分比都要测一遍？没必要。因为很多输入值对程序来说，处理逻辑是一样的。我们把它们归为一类，每类挑一个代表测就行了。
核心原则：
- 有效等价类：程序能正常处理的输入
- 无效等价类：程序不能处理的输入（比如负值、超范围值）
我在项目中遇到过这样一个案例：测试换挡点。TCU会根据油门开度和车速决定是否升挡。油门开度范围是0%到100%。
我当时划分的等价类是这样的：
| 输入条件 | 有效等价类 | 无效等价类 |
|---|---|---|
| 油门开度 | 0% ~ 100% | < 0%， > 100% |
| 车速 | 0 km/h ~ 最高车速 | < 0 km/h |
| 挡位信号 | P, R, N, D, S | 其他非法挡位 |
嗯，这里要注意：无效等价类往往比有效等价类更容易发现bug。我曾经因为漏测了「油门开度 > 100%」这个无效类，结果在台架上模拟传感器故障时，TCU直接进入了跛行模式，吓了我一跳。
我的习惯：每个输入条件至少覆盖一个有效等价类和一个无效等价类。别偷懒，无效类往往是隐藏的雷区。
4.2 边界值分析：Bug最爱藏在边界上
等价类划分解决了「测哪些值」的问题。但边界值分析告诉你：边界值才是Bug的老巢。
为什么？因为程序员写判断条件时，最容易在「>=」和「>」之间犯迷糊。你想想看，if (speed >= 20) 和 if (speed > 20)，差一个等号，结果天差地别。
在TCU换挡逻辑中，边界值分析尤其重要。比如升挡点：
- 1挡升2挡：车速边界值 20 km/h
- 2挡升3挡：车速边界值 40 km/h
- 3挡升4挡：车速边界值 60 km/h
边界值分析要求我们测试：边界值本身、边界值-1、边界值+1。
| 边界场景 | 测试值 | 预期结果 |
|---|---|---|
| 1挡升2挡（边界20 km/h） | 19, 20, 21 | 19不升挡，20升挡，21保持2挡 |
| 2挡降1挡（边界15 km/h） | 14, 15, 16 | 14降挡，15保持，16不降挡 |
我记得有一次，测试2挡降1挡的边界。按照设计，车速降到15 km/h时应该降挡。但我用15 km/h测试时，TCU没反应。后来发现，代码里写的是 if (speed < 15)，而不是 if (speed <= 15)。就差一个等号，导致降挡延迟了1秒。这在坡道上可是要出事的。
避坑指南：我曾经因为只测了边界值本身，没测边界值-1，漏掉了一个严重的换挡抖动问题。记住：边界值分析不是只测边界，而是测边界附近的所有敏感点。
4.3 决策表法：复杂逻辑的克星
等价类和边界值解决的是「单个输入」的问题。但TCU换挡逻辑往往是多个条件组合决策。比如：
- 条件1：车速是否达到升挡点？
- 条件2：油门开度是否稳定？
- 条件3：是否处于手动模式？
- 条件4：坡度是否过大？
这么多条件组合起来，靠直觉去测，肯定漏。这时候就需要决策表法。
决策表的结构很简单：
- 条件桩：列出所有输入条件
- 动作桩：列出所有可能的输出动作
- 规则：每个条件组合对应一个动作
我给大家看一个简化版的TCU升挡决策表：
| 条件/动作 | 规则1 | 规则2 | 规则3 | 规则4 |
|---|---|---|---|---|
| 车速 >= 升挡点 | Y | Y | N | N |
| 油门稳定 | Y | N | Y | N |
| 非手动模式 | Y | Y | Y | Y |
| 坡度 < 10% | Y | Y | Y | Y |
| 执行升挡 | √ | × | × | × |
你看，只有规则1（车速达标 + 油门稳定 + 非手动模式 + 坡度小）才会执行升挡。其他情况都不升挡。
我个人习惯用决策表来梳理需求。很多时候，需求文档写得模棱两可，但一画决策表，矛盾就暴露出来了。比如上面这个表，如果需求说「油门不稳定时也升挡」，那规则2就应该打√。但实际中，油门不稳定时升挡会导致换挡冲击，所以设计上通常禁止。
实战技巧：决策表不要画太大。条件超过4个，表格就会爆炸。我一般把复杂逻辑拆成多个小决策表，每个表只处理一个功能点。
4.4 三种方法的组合应用
实际项目中，这三种方法不是孤立的。我通常这样组合：
- 先用等价类划分：确定每个输入参数的取值范围，找出有效类和无效类
- 再用边界值分析：针对每个边界点，补充边界值附近的测试数据
- 最后用决策表：梳理多个条件组合的逻辑，确保覆盖所有关键场景
举个例子，测试「坡道辅助起步」功能：
- 等价类：坡度（0%, 5%, 15%, 30%）、刹车状态（踩下/松开）、挡位（D/R）
- 边界值：坡度边界（5%, 10%——辅助功能激活阈值）
- 决策表：坡度 > 10% + 刹车松开 + D挡 → 保持制动2秒
这样一套组合拳下来，测试覆盖率基本能到90%以上。剩下的10%，靠探索性测试和路试去补。
我的建议：写测试用例前，先花10分钟画个决策表。你会发现，很多隐藏的逻辑漏洞在画表的时候就暴露了。这比跑完测试再改bug划算得多。
4.5 小结
今天讲的三种方法，等价类划分帮你「减量」，边界值分析帮你「聚焦」，决策表法帮你「理清逻辑」。三者结合，TCU换挡逻辑的测试用例设计基本就稳了。
下节课，我们继续讲白盒测试方法：条件覆盖、路径覆盖、MC/DC覆盖在TCU软件中的应用。到时候我会分享一个我踩过的坑——因为路径覆盖不全，导致一个极端工况下的换挡超时问题，直到路试才被发现。
好了，今天就到这里。大家回去可以拿自己项目的换挡逻辑练练手，画个决策表试试。有问题随时交流。