第2章：测试需求分析——需求文档解读、可测试性分析与优先级划分

大家好，我是老张。今天咱们聊聊测试需求分析。

说实话，很多工程师拿到需求文档，第一反应就是直接写测试用例。我年轻时也这么干过，结果呢？测到一半发现需求根本没法测，或者测完了才发现最重要的功能没覆盖到。嗯，这章就是帮你避开这些坑。

2.1 需求文档解读——别让文字骗了你

需求文档是什么？说白了，就是产品经理或系统工程师的「愿望清单」。但愿望和现实之间，往往隔着一条鸿沟。

我个人习惯，拿到需求文档先做三件事：

1. 通读全文，抓核心功能——别急着看细节，先搞清楚这个ECU到底要干什么。
2. 标记模糊描述——比如「正常响应」「适当延迟」这种词，我见一个标一个。
3. 找隐含假设——需求里没写但实际必须有的东西，比如上电时序、通信超时处理。

举个例子，我之前做过一个项目，需求里写「当车速超过120km/h时，系统发出报警」。听起来很清晰对吧？但仔细一问：

• 车速信号从哪里来？CAN总线还是硬线？
• 报警持续多久？一直响还是响3秒？
• 车速降到120以下后，报警自动消失还是需要手动复位？

你看，一句话能拆出五六个测试点。这就是解读需求的意义。

2.2 需求可测试性分析——能不能测，心里要有数

可测试性分析，说白了就是判断「这个需求能不能用HIL测出来」。我见过太多需求，写得天花乱坠，一到测试台架就傻眼。

为什么会这样？因为有些需求天生就不适合HIL测试。比如：

需求类型	可测试性	说明
功能逻辑类	高	如「按键按下后LED点亮」，直接给信号看输出
时序类	中	如「100ms内响应」，需要高精度计时
环境类	低	如「在-40℃下正常工作」，HIL模拟不了温度
主观感受类	极低	如「报警声音听起来舒适」，这得人耳判断

我建议，拿到需求后先做一次可测试性打分。1分代表完全不可测，5分代表完美可测。低于3分的需求，要么找替代方案，要么跟需求方沟通修改。

曾经有个项目，需求要求「系统在收到故障信号后，应在500ms内进入安全状态」。听起来没问题，但实际测试时发现：故障信号本身就有200ms的抖动。你想想看，这500ms的指标还有意义吗？所以可测试性分析，不仅要看需求本身，还要看测试环境的能力边界。

2.3 需求优先级划分——先测什么，后测什么

测试资源永远有限，时间紧任务重是常态。所以优先级划分不是可选项，而是必选项。

我个人习惯用「三因素法」来定优先级：

1. 功能安全等级——ASIL等级越高，优先级越高。这是硬指标，没得商量。
2. 功能复杂度——越复杂的功能，越容易出问题，应该优先测。
3. 变更频率——经常改的需求，优先测。因为改一次就可能引入新bug。

举个例子，我做过的一个BMS项目，需求优先级划分如下：

需求	安全等级	复杂度	变更频率	优先级
过压保护	ASIL C	高	低	P0（最高）
SOC估算	QM	极高	高	P1
历史数据记录	QM	低	低	P2
UI显示优化	QM	中	高	P3（最低）

另外，我建议把优先级结果写进测试计划里，让项目经理和开发团队都看到。这样万一时间不够，砍掉低优先级的测试项时，大家心里都有数。

2.4 实战案例——一个完整的分析过程

好了，理论说完了，咱们看个真实案例。

需求原文：「当电池温度超过60℃时，BMS应切断充电回路，并在仪表盘显示报警信息。」

第一步：需求解读

• 温度信号来源：NTC传感器，通过ADC采集
• 切断方式：控制充电继电器断开
• 报警显示：通过CAN总线发送报警报文，仪表盘解析显示
• 隐含条件：温度回落到安全范围后，是否自动恢复充电？需求没写，需要确认

第二步：可测试性分析

• 温度模拟：HIL可以模拟NTC电阻值，可测（5分）
• 继电器控制：HIL可以监测继电器驱动信号，可测（5分）
• 报警报文：HIL可以监听CAN总线，可测（5分）
• 仪表盘显示：HIL无法直接验证，需要人工确认（3分）

整体可测试性4分，可以接受。

第三步：优先级划分

• 安全等级：ASIL B（较高）
• 复杂度：中等（涉及温度采集、逻辑判断、执行器控制、通信）
• 变更频率：低（温度保护是标准功能）
• 综合优先级：P1（高优先级）

你看，经过这三步分析，这个需求怎么测、测什么、什么时候测，就清清楚楚了。

下一章，咱们聊聊怎么把需求转化成具体的测试用例。到时候我会分享一些我常用的模板和套路，保证实用。