4、需求分析驱动：如何从需求文档提取测试点、需求颗粒度对覆盖度的影响、需求变更管理
做HIL测试这么多年，我越来越觉得：测试用例的质量，七分靠需求，三分靠执行。你想想看，如果需求本身就有问题，后面再怎么折腾也是白搭。今天咱们就聊聊怎么从需求文档里挖出测试点，以及需求颗粒度这个老生常谈但又总被忽视的问题。
4.1 如何从需求文档提取测试点
说实话，我刚入行那会儿，拿到需求文档就是从头读到尾，然后凭感觉写用例。结果呢？漏测率居高不下。后来我总结了一套方法，分享给你。
4.1.1 需求拆解三步法
我个人习惯把需求拆解成三个层次：
- 功能需求：系统要做什么？比如“当车速超过120km/h时，发出报警”。
- 性能需求：做到什么程度？比如“报警响应时间小于100ms”。
- 约束条件：在什么条件下做？比如“仅当发动机运转时有效”。
每个层次都能提取出不同的测试点。举个例子：
原始需求：当车速超过120km/h时，仪表盘显示超速报警图标，并发出蜂鸣声。
提取的测试点：
- 功能：车速从119→121km/h，图标是否显示？蜂鸣是否响起？
- 性能：从超速到报警输出，延迟是否小于100ms？
- 约束：车速超过120但发动机未启动，是否报警？
4.1.2 关键词映射法
我在项目中遇到过很多模糊的需求描述，比如“适当”、“尽快”、“必要时”这类词。嗯，这里要注意——这些词就是测试点的雷区。
我的做法是建立一张关键词映射表：
| 需求中的关键词 | 对应的测试点 | 示例 |
|---|---|---|
| “当...时” | 边界值测试、触发条件测试 | 当车速>120时 → 测试119、120、121 |
| “在...范围内” | 等价类划分、边界值 | 电压在9V~16V范围内 → 测试8.9、9.0、12.5、16.0、16.1 |
| “同时” | 时序测试、并发测试 | 同时按下两个按钮 → 测试先后顺序、同时按下 |
| “如果...则” | 条件组合测试 | 如果车速>120且安全带未系 → 测试4种组合 |
4.1.3 场景串联法
单个测试点容易写，但真实场景往往是多个功能交织在一起的。我建议你把提取出的测试点串联成场景。
比如，一个ACC自适应巡航的需求，可以串联成这样的场景：
- 场景1：前车减速 → 本车跟随减速 → 前车加速 → 本车恢复设定速度
- 场景2：前车切入 → 本车识别新目标 → 调整跟车距离
- 场景3：目标丢失 → 本车保持当前速度 → 重新识别目标
说白了，场景串联就是模拟真实驾驶中的连续操作，而不是孤立的测试点。
4.2 需求颗粒度对覆盖度的影响
这个问题我踩过坑。有一次，需求文档写得特别粗，就一句话：“实现自动泊车功能”。你猜怎么着？我写了20个用例，自认为覆盖得不错。结果测试时发现，泊车过程中方向盘回正时机不对，需求里根本没提这个细节。
避坑指南：我曾经因为需求颗粒度太粗，导致漏测了3个关键场景，项目延期两周。从那以后，我要求所有需求必须细化到可测试的粒度。
4.2.1 颗粒度的三个层次
我把需求颗粒度分为三个层次：
| 层次 | 描述 | 示例 | 覆盖度影响 |
|---|---|---|---|
| 粗粒度 | 一句话描述功能 | “实现自动泊车” | 覆盖度低，漏测风险高 |
| 中粒度 | 描述主要场景 | “支持垂直泊车和平行泊车” | 覆盖度中等，边界场景易遗漏 |
| 细粒度 | 描述具体行为 | “泊车过程中，方向盘转角误差不超过±2°，车速控制在5km/h以内” | 覆盖度高，可测试性强 |
4.2.2 如何判断颗粒度是否合适
我有个简单的判断标准：一个需求点，能不能写出至少3个测试用例？如果写不出来，说明颗粒度太粗了。
举个例子：
- “车门上锁后，车内灯熄灭” → 可以写3个用例：上锁后立即熄灭、上锁后延迟熄灭、解锁后点亮。OK，颗粒度合适。
- “实现车门控制功能” → 写不出3个具体用例。太粗了，需要细化。
4.2.3 颗粒度与覆盖度的平衡
你可能会问：是不是颗粒度越细越好？也不是。太细了会导致需求文档变成天书，维护成本极高。
我个人建议：
- 核心安全功能（ASIL B/C/D）：必须细粒度，每个条件、每个时序都要明确
- 舒适性功能：中粒度即可，边界场景通过评审补充
- 信息娱乐功能：粗粒度也行，靠探索性测试覆盖
4.3 需求变更管理
做HIL测试，最怕的就是需求变更。我记得有个项目，三个月内需求变更了17次，测试用例也跟着改了17次。最后测试报告出来，谁都不敢信。
4.3.1 变更对覆盖度的影响
需求变更不只是改几个字那么简单。它可能带来连锁反应：
- 新增需求：需要补充测试用例，覆盖新功能
- 修改需求：原有用例可能失效，需要重新设计
- 删除需求：关联的测试用例需要废弃，但要注意是否有副作用
小技巧：我习惯在测试用例管理工具里给每个用例打上“需求ID”标签。这样需求变更时，一键筛选出所有关联用例，效率提升不少。
4.3.2 变更影响分析矩阵
我设计了一个简单的矩阵，用来分析变更的影响范围：
| 变更类型 | 影响范围 | 应对措施 | 覆盖度影响 |
|---|---|---|---|
| 参数调整 | 仅该参数相关用例 | 更新阈值，重新执行 | 局部影响 |
| 逻辑修改 | 该功能所有用例 | 重新设计测试场景 | 较大影响 |
| 架构变更 | 多个功能模块 | 回归测试+新增用例 | 全局影响 |
| 接口变更 | 所有依赖该接口的用例 | 更新信号映射 | 中等影响 |
4.3.3 变更后的覆盖度评估
需求变更后，怎么快速评估覆盖度是否达标？我一般用三步法：
- 增量覆盖：新需求是否都有对应的测试用例？
- 回归覆盖：未变更的功能，原有用例是否仍然有效？
- 交叉覆盖：变更是否影响了其他功能的边界条件？
举个例子，假设需求从“车速超过120报警”改为“车速超过130报警”：
- 增量覆盖：新增130边界测试（通过）
- 回归覆盖：120不再报警，原有用例需要更新（注意）
- 交叉覆盖：如果之前有“120~130之间不报警”的用例，现在需要改为“130以下不报警”（容易遗漏）
特别提醒：我曾经遇到过一个变更，只改了需求文档里的一句话，但影响了3个ECU的交互逻辑。结果测试时发现，变更后的功能在某个特定时序下会触发看门狗复位。所以，变更后的交叉覆盖测试一定不能省。
4.3.4 变更管理的几个实用建议
最后，分享几个我在项目中总结的经验：
- 建立变更基线：每次变更前，锁定当前版本的需求和用例
- 变更评审必须参加：测试人员一定要参与变更评审，别等变更完了才知道
- 变更后立即更新用例：别拖，拖久了就忘了哪些用例需要改
- 保留变更历史：方便追溯，也方便分析变更趋势
好了，关于需求分析驱动的内容就聊到这儿。说白了，测试覆盖度的根基在需求。需求搞清楚了，测试用例自然水到渠成。下一章咱们聊聊如何用形式化方法提升覆盖度，敬请期待。