1. 拿到需求别急着开写：用例设计的第一步其实是"读懂系统"
功能测试用例到底该怎么设计？我发现很多刚入行的测试新人，最喜欢干的一件事就是：打开Excel，照着需求文档的字段列表，一个输入框一个输入框地写用例。"输入用户名"一条，"输入密码"一条，"点击登录按钮"一条……写了几十条下来，看着挺充实，一评审就被老测试几句话问住：登录失败之后有提示吗？连续输错五次会锁账号吗？锁了之后什么时候解锁？这些用例你写在哪了？
这其实就是典型的"用例设计思路没建立起来"的表现。测试用例不是需求文档的字段翻译器，它是你对整个系统的一次模拟推演——你得在脑子里先把功能跑一遍，再把"跑法"具象化成一条条用例。所以我不太喜欢直接用"设计思路"这个词来讲这件事，我更愿意把它拆成四个环节：读懂需求、拆解场景、组织表达、持续维护。这篇文章就沿着这条线，把我这些年实际走下来的思路完整过一遍，希望能给正在为"用例写不好、评审总挨批"发愁的朋友一点实在的参考。
1.1 需求澄清阶段：用例设计者应该坐的位置
先说一个我自己的亲身体会：用例设计真正开始的时间，不是需求文档交到你手上那一刻，而是产品经理开始讲需求的那一刻。
我见过太多测试同事，需求宣讲会上从头到尾不吭声，等文档发下来才逐字逐句读。结果读到一半发现一堆模糊地带："这里的列表排序规则是什么？""这个字段必填吗？""超时时间设多少？"——这些问题如果在会上问，一分钟就能得到答案，拖到写用例的时候再回头找产品，往往就得等半天，而且很容易出现"需求变更了但你还在按旧逻辑写"的情况。
所以在需求澄清阶段，我会强迫自己干三件事：
第一，带着问题去听。需求文档没到手之前，先跟产品经理要一页纸的"功能概述"，哪怕是口头说的都行。我要搞清楚三个最基本的问题：这个功能给谁用？解决什么问题？操作路径是什么？这三个问题搞不清楚，后面所有用例都是空中楼阁。
第二，现场把业务规则"顶"清楚。产品经理讲到任何一条规则时，我都会追问它的边界情况。比如"订单超过30分钟未支付自动取消"，我会立刻问：那第29分59秒支付成功了呢？第30分钟整呢？自动取消的同时用户正在支付怎么办？取消之后库存还恢复吗？这些问题不是抬杠，而是把规则从"文字描述"变成"可执行的逻辑"。
第三，把需求当代码一样做"静态走查"。我会在拿到需求文档之后，对照历史功能，列一张"变更影响清单"——这次改了什么、新增了什么、删除了什么、有没有动到之前的老逻辑。很多重大故障都出在"我只是加了一个字段，没想到牵动了旧逻辑"这种地方。
说个真实案例。我们之前做过一个后台的批量导入功能，需求文档里写得很清楚："支持Excel批量导入，单次不超过1000条。"我看完之后问了一句：如果导入的文件里，有50条数据格式正确、30条格式错误、20条重复，系统会怎么处理？产品说：逐条校验，错误的跳过，正确的导入。我又问：那错误和重复的记录要不要给用户反馈？反馈在哪看？要不要生成一个失败清单？产品当场愣了一下，说这个细节他还没想好。结果这个"没想好"的细节，后来成了整个功能最复杂的模块——因为失败清单要展示具体行号、错误原因、并且允许用户下载修正。
测试人员如果在需求阶段不问这一句，等用例写完、开发做完了才发现，返工成本就是十倍百倍。所以别觉得自己只是"写用例的"，你要把自己当成第一个"运行"这套系统的人——你在纸上跑不通的逻辑，开发写完大概率也跑不通。
1.2 业务规则拆解：从"需求描述"翻译成"逻辑清单"
需求澄清做完，接下来这一步非常关键，也是很多测试同学跳过去的：把需求文档里的自然语言，逐条翻译成"如果-那么"的逻辑清单。
为什么要干这件事？因为自然语言是有歧义的。"用户点击提交后，系统将订单状态更新为待审核"——这句话看起来没毛病，但"点击提交"之前发生了什么？表单校验不通过怎么办？网络异常超时怎么办？服务器返回500怎么办？这些在自然语言里全是隐含逻辑，你要做的就是把它们全部显式化。
我常用的做法是画一张"业务规则清单表"，每一行就是一条独立业务规则，列包括：编号、触发条件、系统动作、异常分支、备注。比如拿一个最简单的登录功能来说：
| 编号 | 触发条件 | 系统动作 | 异常分支 |
|---|---|---|---|
| R01 | 用户名和密码均正确 | 登录成功，跳转首页 | 无 |
| R02 | 用户名正确，密码错误 | 提示"密码错误" | 记录失败次数 |
| R03 | 用户名不存在 | 提示"用户名不存在" | 无 |
| R04 | 连续失败5次 | 锁定账号30分钟 | 锁定期间即使密码正确也不放行 |
| R05 | 锁定期满后首次登录 | 解锁并允许登录 | 重置失败计数 |
这套规则清单整理完，你会发现两件重要的事：第一，用例还没开始写，你已经能看出产品逻辑的漏洞了（比如R04和R05之间的竞态条件：第29分59秒用户试了一次错的，算不算锁定期内？）；第二，后面写用例的时候，完全可以"一条规则对应至少两条用例"——一条走正常分支、一条走异常分支，覆盖率和逻辑完备性一下子就上去了。
这块我还有个心得：规则清单要尽量落到"可判定"的程度。什么叫可判定？比如"密码错误"这四个字，你得搞清楚是前端先校验格式，还是发到后端校验？错误提示的文案是什么？输入框要不要标红？光标要不要定位回密码框？这些虽然不是每条都要写进用例，但它们是你的"测试观察点"——没有观察点的用例，执行完你也分不清到底算通过还是算失败。
2. 用例设计的"工具箱"：不是每种方法都要硬套，得知道在什么场景用哪把
功能测试用例设计方法论，市面上讲得很多，等价类划分、边界值分析、场景法、判定表、因果图、正交实验、错误推测……书上都写过，但我在实际项目里发现一个普遍问题：很多测试同学把方法当成了模板，拿到任何功能都从等价类开始套，结果把最简单的东西做复杂了，把最复杂的东西又做简单了。
所以这一节我不打算按教科书的方式把每个方法讲一遍，而是想聊聊我实际使用这些方法时的"选型逻辑"——什么场景下用什么方法最划算，什么情况下可以大胆地把方法组合起来用。
2.1 输入类功能：等价类和边界值谁在先，其实有讲究
等价类划分和边界值分析是测试用例设计的基础中的基础，几乎所有跟输入框、下拉框、日期控件有关的功能都能用上。但这两者谁先谁后，很多人没想过。
我的习惯是：先做等价类划分，再做边界值补充，最后用错误推测来"加菜"。为什么这个顺序？因为等价类解决的是"覆盖面"问题，边界值解决的是"精准度"问题，错误推测解决的是"真实感"问题。你不可能一上来就精确定位某个边界，你得先把大区域分出来，把有效数据和无效数据划清楚，再去看边界上的那两三个值。
举个例子，一个库存管理系统的"入库数量"输入框，要求是：大于0小于等于10000的正整数。等价类怎么划？有效等价类有三个：1到10000之间的整数、大于0的任意整数（这只是理论上说，实际上还是要落到具体值）；无效等价类有一堆：0、负数、小数、非数字字符、超过10000的整数、空值。边界值分析怎么做？就是取边界旁边的值：0和1（下边界两侧）、10000和10001（上边界两侧）。注意，这里有一个新手常犯的错误——边界值不是只取边界本身，而是要把边界两侧的值都取到，而且要结合有效类取一个、无效类取一个。比如1是有效下边界，0是无效下边界，两个都要测。
但是光这样还不够。我还会问一句：这个输入框有没有输入法限制？能不能粘贴？复制粘贴一个"1，000"有没有可能？输入" 1 "（带空格）算不算通过？这些用等价类和边界值划分不出来，因为它们属于"真实用户在操作时可能出现的输入方式"——这就是错误推测法发挥作用的地方了。
错误推测法听起来很玄学，好像全靠个人经验，其实也有套路：基于你过去犯过的错和见过的bug去推测当前系统可能存在的问题。我有个习惯，新项目开始前，会专门去翻一下过往同类模块的缺陷报告，把高频bug列成一张"失效模式清单"——比如：日期格式在不同浏览器解析差异、金额计算浮点精度丢失、大量数据下分页按钮失效、快速双击提交按钮产生重复订单……这些清单，每到一个新功能就拿出来过一遍，能命中不少问题。
2.2 流程类功能：场景法才是主线，别再用"功能点罗列"代替"用户旅程"
输入类功能好处理，真正让很多测试头疼的是流程类功能——用户从开始操作到结束，中间可能跨页面、跨状态、跨数据变更。比如电商下单、审批流、订单退货流程，这类功能光靠等价类和边界值是远远不够的，你需要的是场景法。
场景法的核心思想，是"用基本流和备选流把用户的操作路径走一遍"。但我在工作中看到的普遍现象是，大家用场景法用得特别粗糙：基本流就是需求文档里的happy path，备选流就是"随便挑几个报错场景"——这样下来，整个流程的完整性还是覆盖不到。
我自己的做法，是把场景法和状态转换法结合着用。第一步，先把系统的核心状态画出来，比如一个订单的状态可能有：新建、待支付、已支付、待发货、已发货、已完成、已取消。第二步，画状态之间的合法转换边：新建可以到待支付（发起支付），待支付可以到已支付（支付成功），待支付可以到已取消（用户取消），已支付可以到待发货（支付完成进入备货）……第三步，把"导致状态转换的动作"逐条列出来。第四步，用这些合法转换边推导基本流，用非法转换边和异常情况推导备选流。
这么做的好处是，你会发现有些"虽然流程上合法但产品经理没写清楚"的状态组合。比如：已发货之后还能不能申请取消？如果订单已经出库了，用户取消申请系统是拦截还是走逆向流程？已支付但是支付回调没收到，订单卡在中间态，系统有没有对账机制？这些问题如果等到执行阶段暴露出来，要么是需求漏洞，要么是开发实现没考虑——而你现在在用例设计阶段就发现了，等于提前帮项目排了雷。
场景法写出来的用例，还有个好处就是可读性强。我评审别人的用例时，最怕看到那种"点击A按钮，验证跳转到B页面""点击C按钮，验证D字段显示"的碎片化用例——你根本不知道用户在干什么，也说不清这条用例验证的是哪个业务目标。场景法用例就不一样，它们的名字本身就带着业务含义："用户支付超时后重新发起支付，订单状态最终应为已支付并恢复库存扣减"——评审人一眼就能看出这条用例的业务价值和验证点。
2.3 多条件组合：判定表、因果图、正交试验，到底用哪个
流程类功能处理完，还有一个场景经常让人头大：当一个动作的结果同时受多个条件影响时，用例数量会失控。比如优惠券计算：用户是否登录、是否会员、订单金额是否满足门槛、优惠券是否在有效期内、是否可叠加使用——五个条件两两组合，就是32种情况，全写出来用例数爆炸，不写吧又怕漏掉关键组合。
这种场景下，不同的方法各有适用场景。判定表适合条件个数不多（一般不超过4~6个）且条件和动作都是离散取值的情况。因果图是判定表的图形化表达，适合你在跟别人沟通逻辑时用，实际写用例时还是转化为判定表更直接。正交试验法，我个人觉得是最适合"条件多、组合多、但全测不现实"的场景——它用正交表取有代表性的组合，用最少的用例覆盖两两组合的完整度，很适合参数组合测试。
不过我得给一句忠告：正交试验法在真实项目中的应用没有教科书里那么乐观。因为正交试验假设所有条件之间是相互独立的，而真实业务逻辑里，条件之间往往有强关联——"用户是会员"和"用户未登录"这两个条件不可能同时为真。所以正交试验算出来的用例组合里，经常会有一些"逻辑上不可能"的搭配，你需要人工把这些排除掉。我的建议是：先用判定表把业务规则的核心逻辑理清楚，再用正交试验的思路处理那些"理论上可以组合、但没必要穷举"的次级参数，两者结合，才能既保证核心逻辑覆盖，又控制用例规模。
3. 如何判断用例"够了"：从覆盖维度到优先级排序的完整框架
用例写完了，评审的时候最怕被问一个问题："用例全了吗？"——"全"这个字是没法量化的。你不能拍着胸脯说全覆盖了，你得有一套判断框架。
3.1 功能点之外的"隐形维度"：数据、状态、权限、环境、异常
很多测试同学判断覆盖率的时候，只看"功能点"——需求文档里写了几个功能点，我就写几条用例。这是远远不够的。我在工作里总结了一套"多功能维度检查法"，每次用例评审之前，用这套维度清单做一次自查：
第一个维度是数据维度：同样的操作，不同数据状态下结果是否一致？比如列表页有0条数据、1条数据、1000条数据时的分页展示；比如搜索功能，关键词为空、单字、长文本、带特殊符号时的表现。这些不写用例你心里就没底。
第二个维度是状态维度：上文已经说过，流程类功能一定要画出所有状态和状态转换。很多bug其实就藏在"状态+动作"的矩阵里——比如"已取消订单重新支付"这种操作，需求文档根本没写，但用户真的能到达这个页面（历史订单里点了一个旧链接）。这种"从不该出现的入口进入"的用例，恰恰最能发现问题。
第三个维度是权限维度：同一功能对不同角色、不同数据范围应该有不同的可见性和操作性。前台用户能不能看到后台的"删除"按钮？普通员工能不能看到所有人的薪资？A部门经理能不能修改B部门的数据？权限维度最容易出的是"越权"漏洞，这类用例在安全测试里也是重点。
第四个维度是环境维度：不同浏览器、不同操作系统、不同网络环境下功能表现是否一致？这不仅仅是兼容性测试的事——有些隐藏的js报错、样式错乱、接口超时，只在特定环境下才会触发。我见过一个项目，开发在自己Chrome上测得好好的，用户用Safari打开直接白屏，就是因为有个API在Safari下不被支持。
第五个维度是异常维度：这是我最看重的维度。包括外部接口异常、依赖服务超时、数据库连接失败、消息队列积压等。很多团队把异常测试扔给"联调阶段"去碰运气，但真正的异常场景需要提前设计——比如支付回调延迟2分钟到达，系统怎么处理？第三方短信服务挂了，注册流程是继续还是报错？这些不是联调能碰出来的，得专门写用例去验证。
用这套维度自查完，你会发现"功能点全覆盖"只是一个及格线。真正的好用例，是能让这些"隐形维度"里的深层问题浮到水面上来的。
3.2 优先级排序：高风险、高频次、高影响，三者合一的先测
用例数量永远不可能无限膨胀，所以在用例设计阶段就得学会做减法。我的排序逻辑就一句话：风险高低、使用频次、影响范围，三者综合打分，分数高的优先级就高。这不是什么高深理论，但真正落地的团队不多。
具体怎么操作？我给每条用例标三个维度分，每个维度1到5分：风险维度是"这个功能出错的可能性"——逻辑越复杂、耦合越深、越容易出问题，分越高；频次维度是"用户实际使用这个功能的频率"——高频功能出错，影响面最大；影响维度是"出错后的后果严重程度"——数据不可恢复、资金损失、权限泄露，都是5分级别的。
然后计算综合分（风险乘以频次乘以影响，或者简单相加，看你团队习惯）。分高的用例放在冒烟测试和回归测试的核心集里，分低的放在扩展回归里。这里有个容易被忽视的tip：冒烟测试用例集一定要从高优先级用例里选，而不是从功能点里平均选。因为冒烟测试的目的是"用最少的时间确认系统没崩"，只有把高风险高频的功能覆盖到了，这个目标才成立。
4. 用例表达与文档化：字段怎么设计、步骤怎么写，才算一份"能直接用"的用例
设计好用例思路之后，表达层面的问题就来了。很多团队用例写了不少，一执行才发现：前置条件没写清楚、测试数据没准备好、预期结果模糊不清——执行人员拿到用例根本没法跑。这一节我专门聊聊怎么把脑子里想好的用例，落成一份别人能直接照着执行的文档。
4.1 用例字段设计：从"最小集"到"完整集"，哪些字段必不可少
功能测试用例模板，不同公司差别很大。有些公司一个Excel里就五六个字段：用例编号、模块、标题、步骤、预期结果。有些公司特别讲究，从测试环境、测试阶段、前置条件、测试数据、步骤描述、预期结果、实际结果、缺陷编号、执行人、执行时间、备注，十几个字段一个不少。
我的观点是：字段不是越多越好，但有几个字段绝对不能省。省掉那些字段，用例的可执行性和可追溯性都会大打折扣。
首先是"前置条件"，这个字段重要性极高，但也是被省略得最多的。前置条件写清楚，执行人员才知道这条用例的起点是什么——需要哪些数据已存在、哪个环境已准备好、登录的是哪个账号。我见过很多用例，步骤第一条就写"点击个人中心"，但个人中心入口在哪？需要登录吗？数据是空还是有历史记录？全没写，执行人员只能靠猜。
第二步"测试数据"字段也很关键。比如测试搜索功能，你得写明搜索关键词是什么，期望返回哪些结果；测试转账功能，你得写明转账金额、账户余额、手续费规则。没有明确测试数据的用例，不同人执行可能得出不同结论——你说验证通过，我说数据不对，吵半天最后发现是各自拿的数据不一样。
第三步"预期结果"字段，一定要写到"可观察""可判定"。不要写"系统正常运行"这种废话，要写"页面右上角提示'保存成功'，列表第一行显示新记录，记录状态为'草稿'"。预期结果越具体，用例执行的判定就越容易，即使换一个新人来执行，也不会因为理解偏差而出错。
第四步"用例编号"要有规则。很多项目的用例编号就是流水号，用例多了之后完全没法追溯。我习惯的编号规则是"模块缩写-阶段-序号"，比如"LOGIN-SM-001"代表登录模块冒烟测试第1条、"ORDER-EXT-023"代表订单模块扩展测试第23条。这样做的好处是，从缺陷编号里直接能反查到用例编号，用例编号又能定位到模块和阶段——需求变更的时候，改起来也有索引可循。
4.2 步骤描述：操作、输入、预期逐行对应，一段白话胜过十行术语
用例步骤怎么写，我非常看重"可执行性"。我见过最差的写法是："输入正确账号密码，点击登录，验证页面跳转。"——"正确账号密码"是哪个账号哪个密码？跳转到哪个页面？验证什么？什么都不明确。
我自己的写法偏好是：每个步骤都包含三要素：操作位置、操作动作、输入数据（如有）。每个步骤的预期结果单独成行，紧跟其后。比如登录用例可以这样写：
- 打开登录页，访问地址：https://xxx.com/login（测试环境）
- 输入用户名：test_user01（该账号在测试库中已存在）
- 输入密码：Test@123456
- 点击"登录"按钮
- 预期结果：页面跳转至首页，右上角显示"test_user01"，首页接口请求均返回200
这么写看起来很啰嗦，但一个从没接触过这个项目的执行人员，照着这个步骤就能完成测试。这才是用例该有的样子——用例是给人看的执行手册，不是给自己看的思维导图。另外还有一个细节：用例步骤里应该写"数据"，而不是写"任意有效数据"。因为"任意有效"不知道怎么构造，你说随便填一个，执行的人随手填了个123456，然后发现报错说密码格式不对，白白浪费时间排查是不是环境问题。
4.3 从功能用例到自动化前置：设计阶段就要留的"自动化接口"
随着测试团队逐步引入自动化（比如用Playwright这套工具链做Web端端到端测试），功能用例的设计思路也要跟着升级——最核心的变化是，用例设计阶段就要考虑这条用例将来能不能被自动化复用。
我在日常工作中有一个习惯，每写一条手工用例，都会在脑子里过一遍"如果自动化来做，这条用例的步骤是否可脚本化"。有些用例天生适合自动化：固定的操作路径、明确的输入输出、确定的页面跳转——这些可以按Playwright的Page Object模式来拆解（把页面元素定位和业务操作封装成Page对象，用例脚本只做"点击"和"断言"两层）。有些用例不适合自动化：需要人工视觉判断的样式问题、需要连第三方硬件的场景、大量随机数据驱动的探索性测试——这些留在手工用例里更理智。
所以在用例模板里，我会额外加一列"自动化适配性"（高/中/低/不适用），并在步骤描述中尽量把元素的稳定标识（id、name、data-testid等）记录下来。这样做有一个实际好处：等真正开始搭自动化框架的时候，你手头已经有一批"按自动化标准组织过"的用例了，不用再回头重新梳理需求。我见过太多团队，功能测试用例是一套Excel，自动化脚本是另一套Script，两边各写各的，维护成本翻倍。从一开始就在用例设计阶段对齐，后面能省很多事。
5. 用例评审和维护：好的用例是"改"出来的，不是"写"出来的
用例写完了，评审做完了，是不是就结束了？不是。用例的生命周期是从评审会之后才开始的。我见过太多项目的用例库，版本还停留在半年之前，新需求加了一堆，旧用例没删，改动的逻辑也没同步——这样的用例库，执行价值接近于零。
5.1 评审会看什么：业务正确性、逻辑完备性、表达可执行性
用例评审这个环节，不同团队做法差别很大。有的团队评审就是测试组自己人过一遍，有的团队会叫产品、开发、测试三方一起过——后者才是我觉得靠谱的做法，因为三方看用例的角度完全不同，三个角度合起来才能把问题暴露全。
产品经理看什么？看用例是否真实反映了业务需求——有没有遗漏商业规则，有没有把某种边界情况处理得跟业务预期不符。开发人员看什么？看用例是否符合系统实现——某个功能其实是调了第三方接口的，你的预期结果里得体现异步等待；某个状态其实是定时任务刷新的，你的用例步骤里得留出触发时机。测试人员自己看什么？看表达可执行性——前置条件清不清楚？测试数据有没有给全？预期结果可不可判定？
评审会上我最常问的三个问题是：
第一个：这条用例的"失败"怎么定义？如果预期结果是"页面提示保存成功"，那如果页面没有提示但数据确实存进去了，算通过还是失败？这类判定标准必须在评审时定清楚，否则执行时一定打架。
第二个：这个场景的"数据从哪里来"？很多用例需要特定数据支持，比如"测试用户已购买过该课程"。执行人员要去哪找这个用户？是自己注册一个新账号买一遍，还是测试环境里已经有预置数据？评审的时候不把这个链路走通，执行阶段就开始到处求人。
第三个：这条用例和那条用例之间有无依赖关系？用例的执行顺序有没有讲究？比如"新增用户"这条，必须在"查询用户列表"之前执行。如果有依赖关系，要么在用例里写明前置用例编号，要么在Excel里把用例排好序。移动端的用例尤其依赖执行顺序——你不可能在没有安装App的情况下测试"启动App后的闪屏页"。
评审会的产出，不只是"通过""不通过"的结论，而是一份"修改意见清单"。我把每个意见标记为"阻塞性（必须改）"和"建议性（可以不改）"，阻塞性的比如业务规则理解错误、遗漏关键场景、测试数据不可用，必须当场改完；建议性的比如步骤描述可以更精简、字段顺序调整，会后统一处理。
5.2 变更驱动的用例维护：新增、修改、删除三条线并行
系统上线之后，需求变更不可避免。每一次需求变更，都是用例库的一次"手术"。我建议团队里指定一个用例库"Owner"（维护者），每次变更走一条标准流程：
第一步，需求变更分析。拿到变更需求后先评估影响范围——涉及哪些模块、哪些状态、哪些数据规则。影响分析做得越细，用例改动范围就越准。
第二步，用例新增。新增的特性写成新用例，这部分逻辑跟从0到1设计用例一样，不再赘述。但要注意，新增用例的编号不要插到旧编号中间去，用新模块前缀加新序号，保持编号体系稳定。
第三步，用例修改。这个最容易被偷懒——很多测试同学在旧用例上直接把预期结果改了，也不管步骤描述、前置条件、测试数据是否需要同步调整。我见过一个经典事故：需求把"注册时手机号必填"改成了"注册时手机号可选填"，测试同学只改了预期结果另一条，却不知道"手机号必填"这条用例在另外两个模块（如"忘记密码"模块、"安全设置"模块）里也有同样的断言，三个地方全要同步改——漏改的直接后果就是后面回归测试误报了一堆"bug"，开发查了半天发现根本不存在。
第四步，用例删除。删除旧用例也是学问，不要直接用物理删除，建议在用例状态列标记为"废弃"——保留可追溯性。因为出了问题要回溯时，你可能需要知道"当年这个地方为什么不再测试了"——可能是功能下线了，也可能是策略调整了。
5.3 覆盖率评估：从"点数人头"到"需求-用例映射"
最后聊聊"覆盖率"这个指标。很多人一提覆盖率，第一反应是代码覆盖率——行覆盖率、分支覆盖率多少多少。但这个对功能测试用例来说并不直接适用。功能测试用例设计更关心的，是"需求-用例映射覆盖率"。
我的做法是：每个功能需求点建立一张"需求项-用例编号"映射表。比如需求项"用户注册-手机号校验"，对应用例REG-001、REG-002、REG-003；需求项"用户注册-密码强度校验"，对应REG-004、REG-005。评审时把映射表打开，从上往下逐条打勾，看看哪些需求项还没有对应用例，或者有了用例但没覆盖关键分支。这张表的维护成本不高，但它的价值在于：让你的用例库从"一堆Excel"变成了"一张可审计的网络"——每一个需求点都有据可查，每一条用例都有责任归属。
这套"需求-用例映射"的另一个价值，是在需求变更时快速定位影响面。回头再看5.2节说的同步修改问题，如果你有映射表，一条需求变更过来，直接查表就知道哪些模块下的哪些用例需要看，不用靠记忆去翻Excel。
到这里，我把功能测试用例设计从"读懂需求"到"表达落地"到"持续维护"的完整思路都过了一遍。这一套东西看着挺多，但落到日常工作中，核心就是一句话：用例设计不是写出来的，是"拆"出来的——把需求拆成规则、把规则拆成路径、把路径拆成步骤、把步骤拆成断言。你把这个"拆"字吃透了，用例自然就有血有肉了。
