第一章：需求文档解读
大家好，我是老张。在汽车电子测试这行摸爬滚打了十几年，今天咱们聊聊一个最基础但也最容易被忽视的话题——怎么读懂需求文档。
你可能觉得这有什么难的？不就是看字吗？
嗯，还真不是。我见过太多测试工程师拿到需求文档就开始写用例，结果写到一半发现需求根本没法测。说白了，需求文档解读是HIL测试的起点，这一步走歪了，后面全是白费功夫。
1.1 需求文档的结构
一份规范的汽车电子需求文档，通常长什么样？我个人习惯把它拆成三个层次：
- 系统级需求：描述整车层面的行为。比如“车辆上电后，仪表盘自检灯点亮3秒后熄灭”。
- 功能级需求：描述某个具体功能的行为。比如“当车速超过120km/h时，仪表盘发出超速报警音”。
- 信号级需求：描述具体的信号交互。比如“BCM通过CAN总线发送0x123报文，Byte0的bit2表示左转向灯状态”。
我在项目中遇到过一种情况：需求文档里只写了系统级需求，没有细化到信号级。结果测试用例写出来全是“验证仪表盘是否正常”，根本没法在HIL台架上执行。你想想看，HIL测试需要精确到哪个引脚、哪个报文、哪个信号，没有这些细节，测试就是空中楼阁。
1.2 功能需求与非功能需求
很多新手容易把这两类需求混在一起。我简单说说区别：
| 类型 | 定义 | 例子 |
|---|---|---|
| 功能需求 | 系统“做什么” | 按下雨刮开关，雨刮器以低速模式运行 |
| 非功能需求 | 系统“做得怎么样” | 雨刮器从接收到指令到开始动作，延迟不超过100ms |
功能需求相对好测，因为它是“有就是有，没有就是没有”。但非功能需求就麻烦了。比如“延迟不超过100ms”，你用什么手段测？用示波器抓信号？还是用CANoe的测量工具？
我记得有一次，需求里写“BCM唤醒时间小于50ms”。我们按常规方法测，发现总是超。后来仔细一看，原来需求文档里没写清楚“从哪个时刻开始计时”——是从CAN报文唤醒信号出现开始？还是从BCM的电源引脚上电开始？
你看，这就是非功能需求容易埋坑的地方。所以我的建议是：遇到非功能需求，一定要追问三个问题：
- 这个指标怎么测量？
- 测量起点和终点是什么？
- 允许多少误差？
1.3 需求的可测试性分析
这是今天最核心的内容。什么叫可测试性？说白了就是：这个需求能不能在HIL台架上被验证？
我总结了一个“三看”原则：
- 一看输入是否可控：测试时，你能不能模拟出需求里描述的条件？比如“当环境温度低于-30℃时”，你的HIL台架能不能产生-30℃的温度信号？如果不能，这个需求就不可测。
- 二看输出是否可观：系统的响应你能不能采集到？比如“仪表盘显示‘请检查发动机’”，你的HIL台架能不能通过摄像头或者CAN信号确认这个显示？
- 三看时序是否明确：需求里有没有明确的时间顺序？比如“先A后B再C”，如果顺序模糊，测试用例就没法写。
举个例子。需求文档里写：“当车辆发生碰撞时，安全气囊控制器应切断燃油泵供电。” 这个需求可测吗？
咱们套用“三看”原则：
- 输入可控吗？可以。HIL台架可以模拟碰撞信号（比如通过硬线触发气囊控制器的碰撞输入引脚）。
- 输出可观吗？可以。通过CAN总线可以读到燃油泵继电器的状态信号。
- 时序明确吗？不明确。是碰撞信号出现后立即切断？还是延迟100ms？还是等气囊点爆后再切断？
你看，前两条都满足，但第三条不明确。这时候就需要跟系统工程师确认时序。我一般会在需求文档旁边批注：“请明确切断燃油泵供电的延迟时间”。
- □ 输入信号是否能在HIL台架上模拟？
- □ 输出信号是否能在HIL台架上采集？
- □ 时序约束是否明确？
- □ 边界条件是否定义清楚？（比如“高温”到底是多少度？）
- □ 异常情况是否有描述？（比如“如果CAN总线断开，系统应如何响应？”）
最后说一句。需求解读这件事，看起来是“读”，实际上是“问”。你问得越细，后面写用例就越顺。我见过太多测试工程师不好意思问，结果测试做到一半才发现需求有歧义，那时候再改就晚了。
嗯，今天就聊到这儿。下一章咱们讲讲怎么把需求转化成具体的测试场景。记住一句话：需求文档不是圣经，它是你跟系统工程师沟通的起点。