第三章：需求分析与覆盖映射

好，咱们进入正题。这一章要聊的，是测试设计里最容易被忽视、却又最致命的一环——如何从需求文档里挖出覆盖点，以及怎么把需求、功能、测试用例这三层东西串起来。

我见过太多团队，拿到需求文档就开始写用例。结果呢？上线后漏测一堆，回头一看，需求里明明写着的东西，测试用例里压根没覆盖到。说白了，就是映射关系没建立好。

3.1 需求文档里的“宝藏”在哪？

需求文档不是小说，不能通读一遍就完事。我个人习惯是，拿到文档先做三件事：

• 划出所有“显性”功能点：比如“用户可上传头像”、“支持登录”。这些是明摆着的。
• 找出所有“隐性”约束：比如“上传图片大小不超过5M”、“登录超时时间为30分钟”。这些往往藏在描述里，容易被忽略。
• 标记所有“异常”场景：比如“网络断开时如何处理”、“输入非法字符会怎样”。需求文档通常不会写这些，但你必须自己推出来。

举个例子。我之前做过一个电商项目，需求里写“用户下单后，系统自动发送确认邮件”。看起来很简单对吧？但如果你只测“正常发送”，那就漏了：邮件发送失败怎么办？用户邮箱填错了怎么办？邮件内容被截断了怎么办？这些，都是覆盖点。

3.2 三层映射：需求 → 功能 → 用例

这是本章的重头戏。我把它叫做“三层映射模型”。你想想看，需求是抽象的，功能是具体的，用例是可执行的。这三者之间，必须有一条清晰的链路。

怎么建这条链路？我习惯用一张表来管理：

需求ID	需求描述	功能点	测试用例ID	测试用例描述
REQ-001	用户可修改昵称	昵称修改功能	TC-001	输入合法昵称，验证修改成功
REQ-001	用户可修改昵称	昵称修改功能	TC-002	输入超长昵称，验证截断或报错
REQ-001	用户可修改昵称	昵称修改功能	TC-003	输入特殊字符，验证过滤或报错
REQ-002	用户可上传头像	头像上传功能	TC-004	上传合法图片，验证显示正常
REQ-002	用户可上传头像	头像上传功能	TC-005	上传超大文件，验证拒绝上传

看到没？一个需求，可以映射到多个功能点（虽然这里一个需求只对应一个功能点，但实际中一个需求可能拆成多个功能）。一个功能点，又可以映射到多个测试用例。这就是一对多、多对多的关系。

3.3 覆盖映射的流程图

光说理论不够，我画了一张图，帮你理解这个映射过程：

这张图的核心逻辑就是：需求不能直接变成用例，中间必须经过功能层。我见过有人试图从需求直接写用例，结果写出来的用例要么太抽象（无法执行），要么太零散（漏了关键点）。

3.4 避坑指南：我曾经踩过的坑

做这行十几年，我在需求分析和覆盖映射上栽过不少跟头。挑几个典型的说说：

• 坑一：需求变更后，用例没同步更新。我曾经负责一个项目，需求改了三次，但测试用例还是最初那一版。结果上线前才发现，有一半的用例已经失效了。从那以后，我强制团队在需求变更时，必须同步更新映射表。
• 坑二：只覆盖了“快乐路径”。很多新手拿到需求，只测“正常情况”。比如“用户登录成功”，但从不测“密码错误”、“账号锁定”、“网络超时”。这些异常场景，需求文档里通常不会写，但你必须自己补上。
• 坑三：映射关系混乱。一个用例对应多个需求，或者一个需求没有对应任何用例。这种混乱，往往是因为没有用工具管理。我建议用Excel或专门的测试管理工具，把映射关系维护好。

3.5 实战：如何快速提取覆盖点

最后，分享一个我常用的方法——“五步提取法”：

1. 通读需求：先快速过一遍，了解整体功能。
2. 逐句分析：每一句话，问自己三个问题——这是什么功能？有什么约束？有什么异常？
3. 列出覆盖点：把分析结果写成列表，每个覆盖点一句话。
4. 建立映射：把覆盖点归类到功能点，再把功能点映射到需求。
5. 评审确认：和产品、开发一起过一遍，确保没有遗漏。

这个方法，我团队用了好几年，效果不错。你试试看，应该能帮你省不少事。