第3章测试需求分析

3、测试需求分析：从需求到测试需求的转化、测试需求分解、测试需求优先级划分

好，咱们进入第三个关键环节——测试需求分析。

说实话，很多刚入行的工程师容易把这一步和“读需求文档”混为一谈。其实差别大了去了。需求文档是产品经理或系统工程师写的，它描述的是“系统应该做什么”。而测试需求，是我们测试工程师要回答的——“我怎么证明它做对了？”

我个人习惯，拿到一份需求文档后，先不急着写用例。我会先做一件事：把每一句话，翻译成测试能验证的语言。这个过程，就是“从需求到测试需求的转化”。

3.1 从需求到测试需求的转化

举个例子。需求文档里写了一句：“车辆在高速行驶时，ACC自适应巡航应能稳定跟随前车。”

这句话看着没问题吧？但作为测试工程师，你脑子里要立刻蹦出几个问题：

“高速行驶”具体是多少？80km/h？120km/h？
“稳定跟随”怎么量化？跟车距离误差在多少米以内算合格？
“前车”是什么工况？匀速？急刹？变道？

你看，需求文档里的一句话，到了我们手里，就得拆成好几个可测量的测试需求。

核心转化原则：

模糊词 → 量化指标：比如“快速响应”变成“响应时间≤200ms”
功能描述 → 边界条件：比如“能识别行人”变成“在光照度>5lux、行人高度>1.2m时识别率≥95%”
系统行为 → 可观测结果：比如“系统报警”变成“仪表盘显示红色图标+蜂鸣器鸣响”

我在项目中遇到过最典型的反面教材：需求里写“系统应具备良好的电磁兼容性”。结果测试时大家吵起来了——什么叫“良好”？最后我们不得不拉上EMC专家，重新定义成“在30V/m场强下，CAN总线误码率不超过0.1%”。

嗯，所以记住：不能量化的需求，就是伪需求。

3.2 测试需求分解

转化完了，下一步就是分解。说白了，就是把一个大需求，拆成一个个能独立测试的小单元。

我习惯用“功能树”的方式来做。比如一个“自动泊车”功能，我会先画出它的功能树：

自动泊车
├── 车位检测
│   ├── 垂直车位检测
│   ├── 平行车位检测
│   └── 斜向车位检测
├── 路径规划
│   ├── 单步路径生成
│   └── 动态路径修正
├── 执行控制
│   ├── 转向控制
│   ├── 速度控制
│   └── 制动控制
└── 人机交互
    ├── 界面显示
    ├── 语音提示
    └── 紧急接管

然后，每个叶子节点，就是一个独立的测试需求。比如“垂直车位检测”可以继续分解为：

车位长度≥车辆长度+1.2m时，检测成功率≥98%
车位宽度≥车辆宽度+0.8m时，检测成功率≥95%
车位两侧有障碍物时，检测时间≤3s

我的分解小技巧：

分解到“一个测试用例能独立验证”为止。如果某个测试需求还需要再拆，说明粒度还不够细。我曾经把一个“雨刮控制”需求拆成了47个测试需求，项目经理说我疯了。结果测试执行时，每个需求对应一个HIL测试用例，覆盖率100%，他闭嘴了。

3.3 测试需求优先级划分

需求分解完了，你会发现——太多了！不可能全部做完。这时候就得排优先级。

我个人常用的方法是“三因素打分法”：

因素	权重	评分标准（1-5分）
安全影响	50%	5分=直接导致人身伤害；3分=功能降级；1分=不影响安全
用户感知	30%	5分=用户每次使用都遇到；3分=偶尔遇到；1分=几乎无感知
实现复杂度	20%	5分=极难实现/新算法；3分=中等；1分=成熟方案

然后算总分：优先级分数 = 安全影响×0.5 + 用户感知×0.3 + 实现复杂度×0.2

分数高的，优先测试。分数低的，可以放到后续迭代或者做冒烟测试。

避坑指南：

我曾经犯过一个错——把所有“安全相关”的需求都排成P0。结果测试资源全被占用了，一些用户体验类的缺陷（比如界面卡顿、提示音延迟）直到量产前才发现。后来我调整了策略：安全类需求必须测，但用户感知类需求也要留出至少30%的测试资源。平衡，才是关键。

你想想看，如果所有需求都是最高优先级，那等于没有优先级。测试的本质是风险管理，不是完美主义。

3.4 一个完整的转化示例

最后，我拿一个真实项目中的例子，把整个流程串一遍。

原始需求：“车辆在倒车时，后方有行人经过，系统应发出警报。”

Step 1：转化为测试需求

倒车速度范围：0-15km/h
行人距离：后方3m范围内
行人移动速度：0-5km/h（慢走）
警报方式：蜂鸣器以2Hz频率鸣响，仪表盘显示红色警示图标
响应时间：从行人进入检测区域到发出警报≤500ms

Step 2：分解测试需求

测试需求1：倒车速度5km/h，行人静止在后方2m处，验证警报触发
测试需求2：倒车速度10km/h，行人以3km/h横向穿过，验证警报触发
测试需求3：倒车速度15km/h，行人以5km/h纵向靠近，验证警报触发
测试需求4：行人距离3.5m（超出范围），验证不触发误报
测试需求5：行人移动速度6km/h（超出范围），验证不触发误报

Step 3：划分优先级

测试需求1：安全影响5分，用户感知4分，复杂度2分 → 总分4.1 → P0
测试需求2：安全影响5分，用户感知4分，复杂度3分 → 总分4.3 → P0
测试需求3：安全影响4分，用户感知3分，复杂度4分 → 总分3.7 → P1
测试需求4：安全影响3分，用户感知2分，复杂度1分 → 总分2.3 → P2
测试需求5：安全影响2分，用户感知1分，复杂度1分 → 总分1.5 → P3

你看，这样排下来，P0的测试需求先执行，P3的可以放到最后甚至不做。资源有限，好钢要用在刀刃上。