第4章基于需求的测试设计

4、基于需求的测试设计：需求可追溯性、需求覆盖率分析、从需求到用例的映射

好，咱们今天聊点实在的。

前面几章我们讲了各种测试设计模式，但有个问题我一直想强调——你设计的用例再好，如果跟需求对不上号，那等于白干。说白了，测试的终极目标就是验证需求有没有被正确实现。所以这一章，我们来聊聊怎么把需求和测试用例牢牢绑在一起。

什么叫需求可追溯性？我个人的理解是：每一个测试用例，都能找到它对应的需求来源。反过来，每一条需求，也能找到验证它的测试用例。

听起来很简单对吧？但我在项目中遇到过不少次，需求文档更新了，测试用例却没跟着改。结果呢？测试报告显示“全部通过”，但客户验收时发现功能根本不对。嗯，这种锅我背过，所以现在特别重视追溯性。

核心要点：建立需求ID与测试用例ID的映射关系。每条需求至少对应一个测试用例，每个测试用例至少追溯一条需求。

怎么做？我建议用表格来管理。比如这样：

需求ID	需求描述	测试用例ID	测试用例名称
REQ-001	车速超过120km/h时，仪表盘显示红色警告	TC-001	验证超速警告显示
REQ-002	刹车踏板行程超过50%时，制动灯点亮	TC-002	验证制动灯点亮逻辑
REQ-003	系统上电后3秒内完成自检	TC-003	验证上电自检时间

你想想看，有了这个表，需求变更时你就能快速定位受影响的测试用例。我曾经因为没做这个，改了一个需求后漏掉了三个测试用例，结果在回归测试时翻车了。从那以后，追溯表成了我的标配。

覆盖率这个词，大家都不陌生。但需求覆盖率跟代码覆盖率不一样，它关注的是“需求有没有被测试到”，而不是“代码有没有被执行到”。

怎么算需求覆盖率？公式很简单：

需求覆盖率 = (已覆盖的需求数 / 总需求数) × 100%

举个例子，假设系统有50条需求，你设计了测试用例覆盖了45条，那覆盖率就是90%。剩下的10%呢？要么是漏了，要么是需求本身不可测试。

注意：覆盖率不是越高越好。100%覆盖率听起来很美，但有些需求可能无法直接测试（比如“系统应稳定运行”这种模糊描述）。强行覆盖反而会造出无效用例。

我个人习惯把需求分成三类：

对于第一类，必须100%覆盖。第二类，尽量覆盖关键指标。第三类，嗯，我一般会跟产品经理确认，看能不能转化成可验证的条款。

好，现在我们来解决核心问题：怎么把一条需求变成一组测试用例？

我总结了一个三步法，你试试看：

举个例子，需求是“当车速超过120km/h时，仪表盘显示红色警告”。

第一步，拆解：

第二步，设计场景：

第三步，编写用例：

用例ID: TC-001
需求ID: REQ-001
前置条件: 系统上电，仪表盘正常工作
测试步骤:
  1. 模拟车速信号为130km/h
  2. 观察仪表盘显示
预期结果: 仪表盘显示红色警告图标
实际结果: （测试后填写）
状态: 通过/失败

小技巧：我习惯在用例里直接写上需求ID，这样后期追溯时一眼就能看出来。另外，如果一条需求拆出了多个用例，我会在用例名称里加后缀，比如“TC-001-1”、“TC-001-2”。

做需求到用例的映射，看着简单，但坑不少。我分享三个亲身经历：

坑一：需求描述太模糊。比如“系统应响应迅速”，什么叫迅速？没有量化指标。后来我学乖了，遇到这种需求直接找需求方确认，写成“响应时间小于200ms”。
坑二：只测正常路径。我曾经只验证了“车速超过120km/h时显示警告”，但没测“车速降到120km/h以下时警告是否消失”。结果呢？警告一直亮着，客户投诉了。所以边界场景一定要覆盖。
坑三：需求变更后不更新用例。这个前面提过，但值得再说一遍。需求变了，用例必须跟着变。我现在的做法是：每次需求变更，都触发一次用例评审。

嗯，差不多就这些。需求可追溯性、覆盖率分析、映射方法，这三块是测试设计的基石。你想想看，如果连需求都没测全，后面的测试再花哨也没用。

下一章我们聊聊更进阶的内容——基于模型的测试设计。到时候见。