测试项分析研究：先想清楚为什么测

测试项写得越多，不代表验证得越充分。真正困难的不是列出用例，而是回答一个问题：如果这里错了，我们能不能知道？

一、从功能到测试项，拆三步

第一步看功能意图：这个功能在整车里解决什么问题，用户能感知到什么。

第二步找可观测行为：总线上有没有报文，执行器有没有动作，模型里有没有可以测量的物理量。

第三步定判定依据：用什么指标、什么容差、在多长时间内完成，才算通过。

这三步缺任何一步，用例就会变成“点一下看看有没有反应”。这种测试也许能发现明显的缺陷，但发现不了边界上的问题。

二、测试设计的四个维度

我通常从四个维度展开：正常、边界、异常、时序。

正常场景验证主路径；边界场景验证参数在临界值附近的行为；异常场景验证传感器失效、通信丢失、执行器卡滞时的降级策略；时序场景验证状态切换、超时恢复和并发冲突。

再叠加三类覆盖：状态机覆盖、接口覆盖、故障模式覆盖。状态机的每个迁移至少走一次，每个外部接口至少有一次异常输入，FMEA 里高风险的失效模式都要有对应用例。

三、一个具体的例子：电动车窗防夹

防夹功能看起来简单，实际上是一个典型的多物理量耦合问题。

边界条件至少包括夹持力阈值、玻璃上升速度、环境温度、供电电压。低温下橡胶变硬，电压低时电机转速下降，同样的障碍物可能产生完全不同的夹持力曲线。

异常条件包括霍尔传感器失效、电机堵转、LIN 通信丢失。每一条都要明确系统的反应：是停止、反转，还是进入降级模式。

判定依据不能只写“应能防夹”。要写清楚在什么位置、以什么速度、夹持多大直径的障碍物时，峰值力不超过多少，反转响应时间不超过多少，反转行程至少多少。

只有写到这个粒度，测试结果才可复现，缺陷才可比较。

四、优先级：风险乘以频度

不是所有测试项都值得投入同样的资源。我习惯用三个因子排序：失效后果的严重度、场景发生的频度、问题被发现的可探测性。

后果严重且高频的场景优先做自动化回归；后果严重但低频的场景，至少要保证手动验证的覆盖；后果轻微又难复现的场景，可以放在探索性测试里。

这个排序不是为了偷懒，而是为了让有限的台架时间用在最值得的地方。

五、预期结果怎么写

好的预期结果有三个特征：可测量、可复现、有容差。

“功能正常”不是预期结果，“在 25 摄氏度、13.5 伏供电下，夹持直径 50 毫米的柔性障碍物，峰值夹持力小于 100 牛，200 毫秒内开始反转”才是。

容差不是含糊，它是对测量不确定性的尊重。传感器精度、采样率、环境波动都会影响结果，把容差写清楚，争议就会少很多。

六、几个反模式

为了覆盖率而覆盖率，会把用例写成互相复制的模板；预期结果照抄需求原文，遇到歧义时无法判定；只测正常路径，把异常留给实车；用例没有版本，改了需求却没人更新。

这些问题的共同点是：测试看起来很忙，但没有回答“为什么测”。

测试项的价值，不在于数量，而在于每一条都能对应一个真实的风险，并且能在失败时给出足够清晰的证据。