测试用例编写指南：五步法与检查点颗粒度控制

简介：《测试用例编写指南》是一份面向测试设计人员、技术管理团队成员及需要规范用例编写流程的从业者的docx文档，针对凭惯性设计、颗粒度不一、可读性和覆盖度不足等问题，提供可循的编写依据。压缩包共1个docx文件，约494KB，篇幅精炼，便于检索和团队内共享。已有553人学习。文档从目的、适用范围和测试设计依据讲起，依次梳理需求分析、业务流程分析、系统设计分析、用例编写与完善五个步骤，并说明用例路径、前置条件、操作步骤、预期结果、优先级、用例类型、属性和测试方式等要素。内容还涉及测试需求与用例划分原则、编写要求、常见测试类型、等价类划分、边界值分析、状态迁移等设计方法，以及用例维护和生产问题回溯思路。读者可据此统一模板与粒度，补充异常、边界和回归检查点，提升测试设计的规范性与投产质量。

1. 一份测试用例编写指南能补上什么：从“凭惯性思考”到末级检查点

上一轮迭代的用例评审，两个测试同学为一条用例该不该拆争了二十分钟，最后发现争的不是拆法，是各自心里那套用例编写注意点根本不一样：一个人按页面拆，一个人按检查点拆。这类分歧在小团队里很常见，落到投产就是覆盖不全、回归跑不动、缺陷复盘时说不清是漏测还是没写。测试用例编写指南这类文档的价值就在这里——它不教你怎么想，它把需求分析到用例完善切成固定几步，把用例要素的字段口径固定下来，再用一张对照表告诉你不同测试对象该拆到什么颗粒度。下面按文档骨架走一遍，重点放在能直接搬进项目的那部分，适合测试负责人和刚接手用例设计的新人照抄。

2. 五步法拆开看：需求分析到用例完善各自的输入输出

文档把编写过程切成五步，每一步都明确写了输入、处理、输出三段。这个写法本身就值钱——它迫使你在每一步结束时交出一个可检查的产物，而不是“我感觉想清楚了”。很多团队的用例质量问题，追到根上不是写得不细，是中间步骤没有产物，直接从需求文档跳到了用例表格，跳过了业务流程和系统设计两层分析，结果用例只覆盖了需求文档字面上写了的那部分。

先把五步的骨架摆出来，后面几节逐条展开。

这张表我一般会打印出来贴在工位上，写完一批用例回头看一眼，哪一步的产物是空的，基本就能定位到漏测出在哪一层。下面是每一步的实际做法。

2.1 需求分析：把业务需求拆成可数的检查点

这一步的产出不是用例，是检查点清单。常见做法是把需求文档里带“应当”“可以”“支持”“不允许”的句子逐句圈出来，一句至少对应一个检查点候选。举个虚构的例子：某跨平台系统的“消息发送”需求，文档一句话里含单条发送、批量创建、定时任务三种形态，那就至少拆出三个一级需求，每个下面再挂检查点。

分类维度只有两条：按流程分，按功能分。按流程适用于一条业务链路跨多个功能模块的情况，比如从任务创建到审批到执行；按功能适用于单个菜单或单个接口的情况。分类做完，需求路径基本就定下来了，形如“/项目名称/一级需求/二级需求/……/N级需求”。这一步别急着写用例描述，先把需求名称和检查点列全，因为后面所有用例都挂在这棵树下面，树歪了后面全歪。

有个容易忽略的点：需求分析阶段的输出是“测试需求”，不是“测试用例”，两者在文档里是分开定义的。测试需求只回答“要验什么”，用例才回答“怎么验”。把这两件事混在一步做，写出来的东西往往描述含糊，因为脑子里同时在处理“验什么”和“怎么验”两个问题。

2.2 业务流程分析：补需求文档没写的那部分

需求文档写的是系统应该做什么，不写用户实际会怎么走。业务流程分析这一步就是补这个缺口。输入是业务背景知识和被测系统/模块的业务流程，处理时要把主流程、备选流程、数据流向、关键判断条件，以及完成该操作的（非）必要条件全部整理出来。

主流程和备选流程的差别，在实际项目里非常具体。拿一个虚构的审批场景说，需求文档只写了“审批通过/拒绝”两种结果，业务流程分析会补出“支行经办-分行审核拒绝”“支行经办-分行审核通过-总行审核通过”这类组合路径，以及每条路径上审批人角色不同带来的权限差异。这些组合在需求文档里通常不会逐条列，但不测就是漏。

数据流向决定你要准备几份数据。完成某个操作的必要条件里，往往藏着前置数据的要求，比如账户状态必须先处于某个值、某张关联表必须先有记录。把这些整理出来，前置条件字段就有内容可写了。非必要条件指的是缺了它流程也能走通、但结果会不同的东西，比如某开关打开和关闭走的是两条分支，这类也必须作为检查点列出来。

这一步的输出形态是“补充检查点”，明确标注它不属于需求文档原文。这样做的好处是评审时能分清哪些是需求本身要求的、哪些是测试自己补的，需求变更时回填也有依据。

2.3 系统设计分析：改动点与影响范围怎么圈

系统设计分析是用例最容易漏的一步，也是新人最不愿意做的一步，因为要读设计文档。输入是系统设计、接口设计及数据库设计文档，处理时针对系统为实现业务需求所做的主要改动点和影响范围做全面分析。

我的习惯是拿两份东西对照：设计文档里的改动清单，和数据库变更脚本。逐个改动点问一句“谁调用了它”。改一个字段类型，可能牵动三张表、两个对外接口、一个报表统计口径；改一个接口的返回结构，可能让上游三个调用方全部受影响。这些调用关系不会自己出现在需求文档里，只能从设计文档和代码依赖里挖。

这一步的输出有两类检查点：一是改动功能支持的全部逻辑分支，二是影响范围的回归检查点。第二类最容易被砍，因为看上去跟本次需求无关，但恰恰是生产事故的高发区。关联性测试和回归测试的检查点，基本都从这一步产生。项目时间紧的时候可以砍执行轮次，但不建议砍这一层的检查点设计，砍设计等于把风险藏起来了。

2.4 用例编写与完善：五个必须回头的触发条件

用例编写这一步的输入是测试需求，处理要求是尽量覆盖生产上所有业务流程场景和系统逻辑分支，正向之外加强对边界、异常的覆盖。输出覆盖功能正确性、边界、异常、接口、信息安全等类型。

注意这里的措辞是“生产上的所有业务流程场景”，不是“需求文档里的所有场景”。这两者的差距就是前面两步补出来的内容。很多用例集看上去条数不少，但一跑生产就出问题，原因往往是用例是照着需求文档逐句翻译的，没有业务流程和系统设计两层输入。

用例完善这一步写的是触发条件，一共五条：评审过程中发现用例存在问题；系统新增功能或需求变更；测试过程中发现设计时考虑不周、存在遗漏点；系统出现生产问题，经分析判定为测试泄漏。第四条最值钱，也最少被真正执行。

多数团队处理生产问题的流程是：定位、修复、验证、关闭。用例库不动。结果同一个位置第二次出问题，还是同一批人重新想一遍。我的做法是每出一条生产缺陷，先在用例库里按模块搜有没有对应用例：有，就补操作步骤或补预期结果的检查点；没有，就新建一条并把缺陷编号记在备注里。这条规则坚持两个迭代，用例库才会随着系统一起变厚，而不是每次迭代都从零开始。

3. 用例要素与字段定义：一张表管住路径、步骤与预期结果

要素这块，文档给了两份清单：测试需求五个字段，测试用例十二个字段。字段本身不难，难在几个字段的填写口径会直接决定用例能不能被复用、能不能被自动化脚本接、能不能在半年后还有人看得懂。这一章把字段逐个过一遍，重点讲口径而不是定义。

3.1 路径字段：用例库的索引怎么定

需求路径指的是需求所属的结构目录，形式是“/项目名称/一级需求/二级需求/……/N级需求”。用例路径是在需求路径基础上再加一层需求名称，即“/项目名称/一级需求/……/N级需求/需求名称/”。两条规则看着简单，实际填的时候有几种常见分歧。

第一种，路径里要不要带版本号。我的建议是不带。版本用其他字段区分，路径只管层级。路径一旦掺进版本，跨版本统计覆盖率就没法做了，因为同一个功能在不同版本下路径不同，聚合时报表全是散的。

第二种，同一功能多个入口怎么处理。文档给的做法是合并编写一个需求，路径只到功能层，入口差异放在用例的操作步骤里体现。比如某功能既有列表页入口又有详情页入口，需求层面是一个，用例层面可以按入口拆成两条，但路径相同。

第三种，层级多深合适。我一般控制在五级以内。超过五级说明这个需求本身该拆了，而不是继续往路径里加层。路径过深的直接后果是筛选和统计变麻烦，间接后果是没人愿意维护这棵目录树，最后变成一堆平铺的需求名。

3.2 名称、前置条件、步骤、预期结果的写法口径

这四个字段是评审时被挑毛病最多的地方，也是最能体现编写水平的地方。文档对每个字段都给了明确的正反要求，整理成下表更好对照。

关于预期结果还有几条细化要求值得单独说。前端操作成功或失败，检查点要覆盖页面显示、提示信息、后台数据存储、前后端数据一致性四层，只写“提示成功”是不够的，提示文案的关键内容也要写明。涉及后台数据存储或变更的，要明确具体数据表和关键字段的取值变化，写“数据正确保存”等于没写，因为执行的人不知道去哪张表看哪个字段。

后台系统测试和涉及信息安全的前端操作测试，必须包含输出日志、后台数据存储结果的检查。这一条在实操中经常被简化掉，理由是查日志麻烦。但恰恰是这类检查点，在出问题时提供了唯一可回溯的证据，少了它，缺陷复盘就只能靠猜。

提示信息要明确关键检查内容，比如“系统提示分类名称已存在，添加失败”，而不是“系统提示错误”。文案在迭代中会改，写成关键内容而不是逐字照抄，可以降低维护成本，但关键语义不能丢。

3.3 步骤与预期结果的三种映射关系

文档花了较大篇幅讲操作步骤和预期结果分支的对应关系，因为这是实际编写中最容易写乱的地方。三种关系如下。

一对一最干净，写起来也最快。多对一的典型场景是几种不同操作都能触发同一个结果，比如删除一级分类目录、删除多级分类根目录、删除多级分类子目录，三种操作都指向“可成功删除未挂用例的测试执行集”，那就并列三步、共用一个预期结果。多对多在文档里的态度是明确的：不建议使用，尽量按预期结果分支拆开。实在拆不开时，用编号把步骤和预期结果一一挂钩，比如步骤标 1、2、3，预期结果也标 1、2、3。

另外两条硬规则要记住：操作步骤和预期结果分支原则上不允许出现一对多；一个预期结果分支如果含多个步骤，可以先把步骤按序列出，再把检查点和它的前置依赖步骤通过编号关联。这两条规则看起来是格式问题，实际影响的是执行效率——执行人照着写不清的映射关系跑，很容易漏掉某个分支。

3.4 优先级与其他四个字段

优先级的划分方式，文档是按执行顺序分的，不是按业务重要性分的，这一点要在团队里说清楚，否则新人会把用户最关心的功能全标成高。

剩下的字段里，用例类型分为流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类；用例属性分正常、异常；测试方式分手动、自动化；执行次数记录该用例被执行过的次数。执行次数这个字段最容易被当成摆设，实际上它是回归轮次统计的依据，也是判断一条用例是否还有存在价值的参考——连续多个版本执行次数为零的用例，要么是覆盖了废弃功能，要么是被人为跳过了，两种都该处理。

4. 划分原则落地：颗粒度控制到“一条用例一个检查点”

颗粒度是评审会上最容易吵起来的话题。粗了漏测，细了维护成本高，而且不同人对“粗”和“细”的直觉差异很大。文档给的做法是先按测试对象分类，每一类给出明确的划分依据和划分方式，再用示例锚定。这一章按这个思路把七类对象过一遍。

4.1 测试需求划分：七类对象的划分依据

测试需求这一层的划分，核心是按层级往下走：一级需求、二级需求、三级需求逐层细化。不同测试对象的划分路径不一样，对照表如下。

举两个示例帮助理解。前端功能类，路径大概是“公共设置/系统设置/用户管理/用户注册”，一级是上级目录，二级是菜单，三级是功能点。流程类，路径是“贷后业务流程/合同登记”这种形态，一级是流程名，二级是步骤名。后台接口类，路径是“登陆接口/入参校验”或“登陆接口/系统逻辑检查”，一级是接口名，二级是校验类型。

划分依据统一之后，需求树的结构就稳定了，后面做覆盖率统计、做需求追溯都能按同一套维度聚合。

4.2 需求描述的检查点写法

需求描述这个字段要列出针对末级需求的所有检查点，不是写一段说明文字。文档给了六条补充规则，实操价值都很高。

同一项目需要区分多系统或多需求测试时，把系统名称或需求名称作为一级需求，上面那套划分方式作为它的子需求。这条规则解决的是一棵树上挂多个系统的冲突问题。

检查点数量较多时，把末级需求做进一步细分，而不是在一个需求描述里堆一长串检查点。堆在一起的后果是执行和统计都没法按检查点追踪。

同一功能不同入口，合并编写一个需求。入口差异在用例层面处理，需求层面不拆。

一个功能的正常流程，对应一个检查点。这条是基准线，不是上限。

一个功能中包含多个正常场景或异常流程，分别列出多个检查点。比如某操作既有成功路径又有三种失败原因，那就是四个检查点，不是一个。

同一功能需要准备多份不同数据时，原则上分别列出多个检查点；如果是针对同一操作需要同时对多份数据进行处理，可以单独列一个组合检查点。这个区分很细，但会影响后面用例的拆分方式。

4.3 测试用例划分：按对象给对照

用例层面的划分原则是“一个测试需求检查点对应一条用例”，但不同测试对象有各自的调整方式。

前端功能类的调整最灵活：页面要素检查一条，列表查询、分页、删除功能各一条，表单新增或修改的输入项检查视表单输入项数量而定，可以按输入项或输入分区拆。输入项超过十个的表单，全塞一条用例里执行时会很难受，因为任何一项出错都要重新走一遍。

业务流程类坚持一条检查点一条用例，全流程和工作流分别列。全流程是端到端的完整路径，工作流是审批环节的组合，两者的失败模式不一样。

后台功能类给了合并空间：原则上一个检查点一条用例，但入参有效性检查这类可以合并成一条，把多个非法输入放在同一条用例的不同步骤里。这样处理的前提是预期结果足够清晰，每个非法输入对应的提示要写明白。

批处理、后台流程、数据埋点都是严格的一检查点一用例。数据埋点类按页面划分，每个页面对应一条用例。

兼容性类的划分按维度走：按移动端操作系统维度，可以分成两条；按机型维度，机型有多少种就有多少条；按浏览器维度同理。维度选哪个取决于项目实际的风险面，不是都测一遍才叫全。

还有一条容易忽略的说明：同一个功能的自自动化用例和功能用例应当匹配，如果自动化用例不能完全覆盖功能用例，就把两者拆成互补的用例集。这条规则避免的是重复覆盖和覆盖空档同时存在——自动化跑的那些，手工再跑一遍是浪费；自动化没覆盖的，手工也没写，就是漏洞。

4.4 合并与拆分的三条界线

颗粒度控制到最后，落到三个判断上。

同一个需求检查点对应多种操作步骤时，可以合并编写一条用例，用例里详细列出所有操作步骤。判断依据是这些操作指向的预期结果是否相同。

同一个预期结果含多个检查点、且这些检查点由多个不同操作产生时，不建议合并，尽量按预期结果分支拆开。多个预期结果中含多个检查点的组合，是最难执行也最难维护的形态。

一组操作对应一个预期结果、且需要重复验证的场景，可以写成一条用例，但要在前置条件和预期结果里写清楚每次验证的共同判定标准。

5. 常见问题排查：五类翻车现场与修法

规范写在文档里是一回事，落到每个人的手上是另一回事。下面这五类问题在我见过的用例集里出现频率最高，按现象、原因、解决三段写，对照着改比较快。

5.1 前置条件写成相互依赖链

现象：用例 A 的前置条件写“先执行用例 B”，用例 B 又写“依赖用例 C”，单独抽一条出来跑不了，回归时想删又不敢删。

原因：把“系统当前应处于什么状态”写成了“前一步做什么操作”。前者是状态描述，后者是流程描述，混在一起就形成了依赖。

解决：前置条件只写状态、权限和数据准备。比如“指定用户具备所选项目的测试负责人权限；指定项目的测试执行集中有已创建的测试轮次和分类目录，其中含未挂用例的分类目录”。状态怎么来的，交给环境初始化或数据准备，不写进用例。这条改完之后，用例之间就能任意组合成执行集，回归时可以按风险挑着跑。

5.2 操作步骤里混进检查结果

现象：步骤里写“点击删除，检查提示删除成功”，预期结果里又写一遍“提示删除成功”。执行时不知道该在哪一步做判断。

原因：边写边验的习惯带到了文档里。写的时候手上有环境，顺手就验了，顺手就记在步骤里了。

解决：步骤只写动作和输入，判断全部留在预期结果。自查方法很简单，把每条步骤读一遍，凡出现“检查”“确认”“验证”“查看”字样，一律挪到预期结果。这个动作花不了几分钟，但能显著降低执行时的歧义。反过来，预期结果里出现“点击某按钮”“输入某值”这类动作描述，也要挪回步骤。

5.3 颗粒度两极化

现象：一条用例覆盖一个模块的所有输入框，执行一次要半小时；另一条用例只写“页面显示正常”，执行时全靠执行人自己发挥。

原因：没有对照划分原则，按个人手感写。写的人觉得细的那条太啰嗦，粗的那条反正也不会出错。

解决：先按测试对象分类确定用哪套划分方式，再按类里的规则落。前端功能按页面要素、列表查询分页删除、表单输入项三个区拆；表单输入项多的时候按输入项或输入分区再拆。下限是一条用例一个检查点，上限是执行一条用例不超过十分钟。超过上限就说明该拆了，低于下限说明检查点没列全。

5.4 设计方法用成摆设

现象：文档列了功能正确性、异常、边界值、等价划分、错误推测、因果图六种设计方法，实际用例集里只有正向流程，异常和边界几乎为零。

原因：方法只出现在培训里，没有落到字段上。写用例时脑子里想的是功能怎么用，不是数据怎么坏。

解决：让用例属性字段和设计方法对应起来，标“异常”的用例必须能说出用的是哪种方法。异常测试的标准动作是模拟一名不了解产品的客户执行任意操作，把所有输入框按条件位输入特殊字符、超长字符串，重点检查前端限制长度与数据库字段长度不一致的情况，这个不一致是历史缺陷的高发点。边界值取刚刚小于、稍小于、等于、刚刚大于、稍大于五个点，不要只取等于。错误推测拿历史缺陷清单对照，同类系统出过的问题在本次系统上重验一遍。因果图适合输入条件有组合约束的场景，比如登录页的验证码、身份证姓名密码联合校验，条件组合多且互相约束时，用因果图能把组合情况列全。

5.5 用例写完就冻结

现象：需求变更后用例没动，执行时临时改步骤，改完不写回用例库。下一轮回归还是老样子。

原因：维护没有触发条件，靠自觉。而自觉在排期紧的时候最先被牺牲。

解决：把五条触发条件写进流程节点——评审发现问题、新增功能或需求变更、测试过程发现设计遗漏、生产问题判定为测试泄漏。前三条好执行，第四条要变成硬规则：每条生产缺陷关闭前，必须确认用例库里有对应覆盖，没有就补。这条规则真正落地的团队不多，但落地的那些，下一轮同类问题的复发率会明显下降。

6. 用例集反向自检：三个能在半小时内跑完的验证动作

用例写完不等于覆盖到位。我习惯在提交评审前做三轮反向自检，不增加用例条数，只查已有用例集的窟窿，通常半小时内能跑完。

第一轮查缺陷库。把近两个版本的生产缺陷按模块过一遍，逐条问：当前用例集里有没有一条用例能在测试阶段抓到它。抓得到但当时没执行，是执行策略问题；抓不到，是用例设计问题，当场补检查点。这个动作的价值在于它用的是真实故障分布，比任何设计方法都贴近实际风险。虚拟项目里我做过一次统计，三十条缺陷里有九条在用例集里找不到对应覆盖，补完之后下一个版本的同类问题降了一半。

第二轮查设计文档改动清单。把本次迭代的接口变更、表结构变更逐条列出来，每条问两个问题：改动功能自身的逻辑分支覆盖了没有，调用它的上游受影响的功能有没有回归检查点。第二问最容易被跳过，因为上游功能的用例看上去跟本次需求无关，但它们挂在同一棵需求树上，改动一碰就出事。

第三轮查字段长度和边界值的交叉一致性。前端限制长度、接口校验长度、数据库字段长度这三个值在多数系统里并不一致，而不一致的位置就是边界测试该落的地方。具体做法是把表单类用例里涉及输入项的字段拉一张表，三列分别是前端限制、接口校验、数据库长度，逐个比对，取最小值作为有效边界、取三者的边界分别作为测试点。

这三轮里，第一轮最容易被省略，因为缺陷已经修完了，感觉事情结束了。但用例库的厚度就是靠这一轮一轮垫起来的。从那以后我每次提交用例评审前，都会强制走一遍缺陷库反查和边界交叉核对，哪怕只花二十分钟，也比我事后在生产上解释为什么没测到要轻松得多。希望帮到你。

本文还有配套的精品资源，点击获取