测试用例编写指南：检查点驱动与用例评审落地

简介：这份《测试用例编写指南》以单个 docx 文档交付，面向测试工程师、测试设计人员及需要统一用例规范的项目团队，重点解决用例编写凭经验、颗粒度不一、可读性差和覆盖不足等问题。文档围绕需求分析、业务流程分析、系统设计分析、用例编写与完善展开，并细化测试需求与用例模板要素、需求与用例划分原则、测试类型、等价类划分、边界值分析、状态迁移等设计方法，同时补充用例维护和风险建议。压缩包共 1 个文件，为 docx 格式，大小约 494KB，目录按目的、适用范围、设计依据、编写步骤、要素、划分原则、编写要求等章节组织，便于查阅和团队内复用。已有 551 人学习下载，适合希望建立规范编写流程、补齐知识空缺并提升测试设计质量的读者参考。

1. 一份 docx 能解决什么：把“凭惯性写用例”变成可检查的流程

测试用例写到第三年，最容易出现的不是不会写，而是每个人写得都不一样：有人一个功能拆八条，有人八条并一条；有人前置条件写三行，有人直接留空；有人把“点击登录”当预期结果，有人把整段 SQL 校验塞进操作步骤。评审会上吵半天，最后靠嗓门定稿。这份《测试用例编写指南》.docx 要治的就是这个病——它不谈玄学，把需求分析、流程分析、系统设计分析拆成带输入输出的五步，再把需求路径、优先级、用例类型、用例属性这些字段钉死，让用例变成能被审、能被查、能被复用的资产。适合谁？带两三人测试小组的负责人、刚从执行岗转到设计岗的同学，以及被“测试泄漏”追过责、想给团队立规矩的人。

2. 五步编写链路：每一步的输入、处理与输出

文档最值钱的部分在“4 测试用例编写步骤”，不是因为它列了五条，而是因为它给每一步都定义了输入、处理、输出。没有输出的步骤等于没做，这是判断一份用例到底走没走流程的第一把尺子。

2.1 从需求说明书到测试需求检查点

步骤一的动作是把业务需求按“流程或功能”分类，落成测试需求，并把每个需求细节拆成检查点。注意这里的措辞：输出不是“用例”，是“测试需求 + 检查点”。很多团队翻车就翻在这里，需求评审完直接开写用例，中间那张检查点清单跳过了，结果用例数量看着不少，但需求里的某一条分支根本没人认领。

我在带小团队时会在这一步加个土办法：每份需求文档右侧留一列，逐条标“已转检查点 / 不测（理由）/ 待确认”。转完再统计一遍条数，检查点数应大于等于需求条目数，因为一条需求里常有多个正常场景和异常流程，按文档 6.1 的说明，这类情况必须分别列出多个检查点，而不是合并成一条。

检查点的描述也有讲究。差的写法是“验证用户注册功能正常”；能用的写法是“注册时手机号已被其他账户占用，提交后提示已占用且不生成新用户记录”。区别在于后者自带判定条件，到了用例阶段几乎可以直接翻译成预期结果。

2.2 业务流程分析与系统设计分析的补位作用

步骤二、步骤三常被当成走过场，实际上是补需求文档漏洞的两道闸。业务流程分析的输出是“业务需求未提及、但需要覆盖验证的检查点”，比如主流程走通了，但复核被拒、数据回退、跨节点状态不一致这些备选路径，需求说明书往往一句话带过。系统设计分析的输出则是“改动功能支持的所有逻辑 + 影响范围回归”。

文档把系统设计分析单列一步，指向很明确：接口设计文档和数据库设计文档要读。举个具体场景，某后台功能改了一个状态字段的枚举值，界面看不出任何变化，但依赖这个字段的报表统计、批处理跑批、消息推送全在影响范围内。只看需求文档，这三处一条用例都不会有；读了设计文档，回归检查点自然浮出来。

实操上我会让设计人在这步产出一张影响范围表，三列就够：改动点、调用方、是否需要回归。表格不用进正式文档，但必须挂在用例评审材料里，评审时逐行过。下面这张表是这类分析的常见骨架，字段可按项目裁剪：

2.3 用例编写与完善：把检查点翻译成可执行条目

步骤四的输入是测试需求，输出要覆盖功能正确性、边界、异常、接口、信息安全等类型。文档强调“除正向测试外，加强对边界、异常的关注”，这不是套话，而是对前面检查点质量的兜底——如果检查点里一条异常都没有，说明步骤二没做。

步骤五列了四种必须回写的场景：评审发现问题、需求变更、测试中发现遗漏、生产问题被判定为测试泄漏。第四条最狠，也最有用。测试泄漏意味着有人已经为这个漏洞付过代价，如果不把对应用例补进去，同一个坑会再踩一次。

提示：步骤五不是“有空再维护”。建议在缺陷复盘会上直接定人定时间，把补充用例作为缺陷关闭的前置动作，否则这类维护永远排在做新需求后面。

2.4 需求路径与用例路径的层级约定

文档 5 章给的路径格式值得单独说。需求路径是“/项目名称/一级需求/二级需求/……/N 级需求”，用例路径在需求路径基础上再拼一层需求名称。这个设计的好处是用例天然挂在需求树下，覆盖率一查便知：某条末级需求下没有任何用例，就是覆盖缺口。

实际落地时最容易乱的是层级深浅不统一。同一项目里，有人拆到三级，有人拆到五级，导出的用例清单没法按层汇总。我的做法是先定死最大层级（比如统一不超过四级），再定一条规则：只有需要独立统计覆盖率的对象才单开一级。系统名、模块名、功能名各占一级，到了具体校验点就不再往下拆，改成在同一末级需求下列多个检查点。

3. 用例要素与划分颗粒度：字段怎么写才算合格

这一章是文档里最容易被执行、也最容易被打折扣的部分。要素齐不齐，评审时一眼能看出来；颗粒度合不合理，往往要等执行阶段才暴露。

3.1 十一个字段的填写底线

文档规定测试用例包含用例路径、测试名称、用例描述、前置条件、操作步骤、预期结果、设计人、优先级、用例类型、用例属性、测试方式、执行次数。逐个说几个高频出问题的：

测试名称要“可直接通过名称识别测试对象和检查点，不包含具体操作步骤和逻辑”。文档给的示例是“放款失败-合同冻结”，格式是“现象/检查点-条件”。反面例子是“输入错误密码点击登录验证提示”，把操作写进名称，一旦步骤调整名称就失真。

前置条件必须完整，且用例之间不允许互相依赖。这条是硬约束，血泪经验：一旦允许“先执行用例 A 再执行 B”，只要 A 挂了，后面一串全废，回归时根本分不清是代码问题还是顺序问题。有特殊账号权限、需要造数据的，全部写进前置条件，不要藏在步骤第一步。

操作步骤里不能包含检查结果，预期结果里不能包含操作步骤。这两句看着像文字游戏，实际是防止用例变成流水账。步骤只写“做什么”，结果只写“看到什么、数据变成什么”，一一对应关系用编号绑定。

预期结果的深度是区分新手和老手的地方。文档要求：前端成功/失败要包含页面显示、提示信息、后台数据存储、前后端一致性；涉及后台数据变更要明确具体数据表和关键字段取值；后台系统测试和信息安全相关的前端操作，必须检查输出日志。也就是说，“提示添加成功”只完成了一半，还得去看库里那条记录的关键字段对不对、日志里有没有留痕。

优先级三级划分也要说清：高是基本功能和关键路径（正常流程、页面元素正常输入），中是功能完善（异常流程、异常输入），低是体验类和辅助功能。常见误用是把所有异常用例都标高，结果高优先级用例占了七成，等于没有优先级。合理的分布大致是高占三到四成，剩下的按风险摊。

3.2 测试需求划分：四类对象的不同拆法

文档 6.1 把测试对象分成前端功能、流程类、后台功能、批处理、后台流程、数据埋点、兼容性几类，每类给了划分依据。核心差异在于“按什么切”：

前端功能按菜单层级切，一级是菜单上级目录，二级是菜单名，三级是功能名。比如“公共设置/系统设置/用户管理/用户注册备案”就是典型三层。流程类按“全业务流程-流程名称-步骤名称”切，工作流要按经办、复核节点分开。后台功能按“功能/接口名称-校验类型”切，一个登录接口至少拆出“入参校验”和“系统逻辑检查”两条需求。批处理按节点切，通知转历史任务、利息计提任务各成一条。

文档还给了六条补充说明，其中两条最容易被忽略：同一功能不同入口可以合并成一个需求；同一功能要准备多份不同数据时，原则上分别列检查点，除非是对多份数据做同一次处理，才列组合检查点。

3.3 测试用例划分：一条需求检查点对应一条用例的边界

6.2 的总原则是“一个测试需求检查点对应一条用例”，但给了明确的合并例外。前端功能里，表单输入项多时可以按输入项或输入分区拆用例；后台功能里，入参有效性检查这类可以合并成一条。

最值得抄的是文档给的那个示例结构：单条发送消息的用例拆成三条——页面要素检查（布局、标题文字、栏位显示、弹窗）、查询条件有效性检查、新建任务输入项检查。这个拆法背后是三种不同的验证逻辑：静态展示、查询交互、表单校验。按验证逻辑拆，而不是按页面区域拆，复用性明显更好。

兼容性测试的拆法也给了具体维度：按操作系统、按机型、按浏览器，每种维度下细分项对应一条用例。这里有个隐性成本要提醒：机型维度拆得越细，用例数量线性增长，维护成本跟着涨。我的习惯是只对核心流程做机型矩阵，非核心功能按操作系统两档覆盖即可。

3.4 用表格管理步骤与预期结果的对应关系

文档 7 章末尾用一整组示例讲操作步骤和预期结果的分支对应，这块建议直接照搬成团队模板。核心是三种合法形态：一对一（一种操作对一个结果分支）、多对一（多种操作对一个结果分支）、多对多（用相同编号绑定）。明确不建议的是一对多（一种操作产生多个结果分支）和“多个预期结果含多个检查点”。

举个能直接套用的例子。添加分类的输入有效性检查，一份操作对应五个输入场景（空、空格、特殊字符、前后空格、超长、重复），每个场景一个预期结果，编号一一对应，这是“多种操作对应多个预期结果分支”的标准写法。而“一组操作一个预期结果”的典型是：多次销户再注册后，在服务窗登录检查额度展示与最近一次申请一致——步骤有先后依赖，但最终只验证一个结论。

用 Markdown 或 Excel 管理时，建议加一列“分支编号”，步骤侧写 S1、S2，结果侧写 R1、R2，多对多时在结果单元格里标“S1、S3 → R2”。评审时对着编号过，比读大段文字快得多。

4. 设计方法与测试类型的组合：别把方法当清单打勾

文档 9 章列了功能正确性、异常、边界值、等价划分、错误推测、因果图分析六种方法，8 章列了功能、接口间、信息安全、关联性、回归、数据库、压力、操作友好性、效率、兼容性、数据移植、安装十二种测试类型。方法解决“怎么取数据”，类型解决“测什么维度”，两者是乘法关系，不是并列清单。

4.1 六种设计方法的适用边界

功能正确性测试用真实业务数据验证需求规格，是覆盖率的底盘，任何用例集都必须先保证这条。异常测试的定位很具体：模拟一个不了解产品的客户执行任意操作，输入非法类型、不符合要求的数据、长度溢出数据，看程序是否给提示并妥善处理。文档举的例子很实用——增加按钮的所有输入框，输入特殊字符，或者前端限制长度与数据库字段长度不一致。后一种情况是经典泄漏点：前端限了 20 字符，库里字段是 30，绕过前端直接调接口就写进去了。

边界值测试要求取“刚刚小于、稍小于、等于、刚刚大于、稍大于”，文档给的例子是利率浮动比例边界值 0。这里补一句实操：边界值不是只测数值，字符串长度、日期临界（月末、闰年 2 月 29 日）、分页最后一页的余数条数，都算边界。

等价划分把有效/无效输入分成若干等价类，每类取代表值。错误推测靠经验和直觉，文档点了两个高频区：分页场景（查询分页、文件分页）、金额四舍五入。因果图分析适合输入条件有组合约束的场景，文档举了登录页验证码、身份证姓名密码校验的组合。

实际写用例时，一条用例往往同时用了两三种方法。比如“添加分类-名称为空/空格”既用了等价划分（空和空格归为无效类），又用了边界值（空格数量）。不用在用例里标注用了哪种方法，但设计人心里要有数，否则容易漏掉等价类里没被代表值覆盖的那种。

4.2 关联性测试与数据移植测试的触发条件

十二种类型里，有两种经常被漏。关联性测试针对“不涉及代码改动但与被改动功能有依赖或调用关系的功能”，触发条件就是第 2 章说的影响范围分析，没有那张表就无从下手。数据移植测试针对迭代更新带来的数据迁移，关注三点：迁移前后数据量一致性、数据库表结构变化、迁移后数据的业务逻辑回归。

这两类测试的共同点是没有明确的需求文档支撑，靠设计人对系统的理解补。所以文档把它们放进类型清单而不是方法清单，意思是“你得想到要做”，而不是“照着某份文档做”。

信息安全测试的落地要求也值得单拎：对未经授权的人或外接系统使用内部系统或数据的权限范围进行检测，且后台系统和涉及信息安全的前端操作必须检查输出日志。日志检查不是可选项，很多权限绕过问题只能从日志里看出来。

4.3 一次完整的用例设计推演

拿“用户注册”做一遍。步骤一输出检查点：正常注册、手机号已占用、验证码错误/过期、密码强度不足、必填项缺失。步骤二补业务流程：注册后自动登录失败的回退、同一手机号短时间重复提交。步骤三补系统设计：注册写几张表、发几条消息、有没有风控接口调用。

到编写阶段，正常注册一条（高优先级、功能正确性），手机号占用一条（中、异常），验证码错误和过期建议拆两条（等价类不同，过期涉及时间边界），密码强度用边界值取最小长度前后各一档，重复提交用错误推测补一条并发场景。预期结果侧，每条都要落到具体表的关键字段，比如用户表的新增记录数、状态字段初值、消息表是否生成待发记录。

这套推演下来，一个注册功能大概产出 10 到 15 条用例，其中异常和边界占六成以上。如果你写出来只有三四条且全是正向，基本可以判定步骤二、三没做。

5. 避坑与排查：五条来自评审现场的记录

5.1 用例数量很多但覆盖率上不去

现象：一轮迭代写了三百条用例，执行全通过，投产仍出问题。原因：用例挂在需求树外，或者末级需求下没有对应用例，覆盖率统计失真；也可能是检查点合并过度，一条用例塞了多个检查点，执行时只验证了显眼的那一个。解决：导出“需求-用例”映射表，逐末级需求查是否有用例，缺的补；再把含多个检查点的用例按结果分支拆开，一个预期结果分支只留一个检查点。

5.2 前置条件互相引用导致批量失效

现象：回归执行到一半，前面的用例失败，后面几十条全部阻塞。原因：违反“用例之间不允许相互依赖”，把上一条用例的执行结果当前置条件。解决：把依赖数据写进前置条件的数据准备脚本或造数说明；确实有业务先后顺序的（如销户再注册），合并成一条含多步骤的用例，在步骤内体现顺序，而不是拆成互相引用的两条。

5.3 操作步骤里写满了检查动作

现象：评审时读步骤读到一半不知道在验什么，执行人边点边判断，结果因人而异。原因：把“检查页面提示为 XX”写进了操作步骤，预期结果栏反而空着或只写“成功”。解决：步骤只保留入口、输入、点击、任务触发四类动作；所有判定性描述移到预期结果，并按前端显示、提示信息、后台数据、日志四个层面列全。

5.4 优先级全员标“高”

现象：高优先级用例占七成以上，执行排期时无法取舍，最后按书写顺序执行。原因：把“重要功能”和“关键路径”混为一谈，异常用例也被标高。解决：按文档口径重标——高只留给基本功能和关键路径的正常流程，异常输入和异常流程归中，界面显示和辅助功能归低；重标后高优先级占比控制在三到四成。

5.5 生产问题复盘后用例没回写

现象：同一个模块连续两个版本出同类问题。原因：缺陷复盘只改了代码，没走步骤五的回写动作，用例集里依然没有对应检查点。解决：把“补充或修正用例”设为缺陷关闭的必要条件，复盘会上指定设计人和完成时间；补充的用例在描述里注明关联的缺陷现象，方便后续回归时识别。

6. 把指南变成团队资产：模板化与用例评审的两个抓手

文档本身是静态的，真正让它生效的是两件事：一套锁死的字段模板，和一场能吵出结论的评审。这两件事做完，指南才算落了地。

模板这块，我一般不让团队自由发挥。要素字段固定为 11 列，用例路径由系统按需求树自动拼，设计人默认当前登录账号，执行次数初始为 0 由执行阶段累加。真正需要人工填的是名称、前置条件、步骤、预期结果、优先级、用例类型、用例属性七项。把这七项做成必填校验，缺一项不允许提交评审，能挡掉大半低级问题。

评审的流程建议分两轮，第一轮只看检查点，不看用例。参与人拿着需求文档逐条对，确认每条需求都有检查点认领，异常和边界检查点有明确来源（来自业务流程分析还是设计文档分析）。这一轮通过后，第二轮才看用例本身，重点看三处：步骤和预期结果的编号对应是否成立、预期结果是否落到数据表和关键字段、优先级分布是否合理。

下面这段是给用例集做机械自查的脚本思路，用 Python 遍历导出的 CSV，把几类高频问题先筛一遍，评审时只看筛出来的。字段名按你们模板改，逻辑通用。

import csv from collections import Counter # 导出的用例 CSV，列名按团队模板调整 FIELDS = ["用例路径", "测试名称", "前置条件", "操作步骤", "预期结果", "优先级", "用例类型"] def check(path): rows = list(csv.DictReader(open(path, encoding="utf-8-sig"))) issues = [] # 1. 前置条件为空：有权限或造数要求的用例容易漏 for r in rows: if not r["前置条件"].strip(): issues.append(("缺前置条件", r["测试名称"])) # 2. 步骤里出现判定词，说明检查动作写错了栏位 judge_words = ["检查", "确认", "验证", "查看是否"] for r in rows: if any(w in r["操作步骤"] for w in judge_words): issues.append(("步骤含检查动作", r["测试名称"])) # 3. 预期结果未提到数据表或字段，深度不够 for r in rows: if "表" not in r["预期结果"] and "字段" not in r["预期结果"]: issues.append(("结果未落到数据层", r["测试名称"])) # 4. 优先级分布失衡：高优先级占比超 50% 视为异常 dist = Counter(r["优先级"] for r in rows) total = len(rows) or 1 if dist.get("高", 0) / total > 0.5: issues.append(("高优先级占比过高", f"{dist['高']}/{total}")) # 5. 用例类型单一：只有功能类说明异常、接口、安全维度缺失 types = Counter(r["用例类型"] for r in rows) if len(types) <= 2: issues.append(("用例类型过少", str(dict(types)))) return issues for item in check("cases.csv"): print(item)

这段脚本做的是机械筛查，不判断业务对错。判定词列表按团队习惯增删，“表/字段”的匹配规则也可以换成你们库表的命名前缀，减少误报。跑完输出的是待人工确认的清单，不是结论。优先级那条阈值 0.5 是我踩过坑之后定的，早先按 0.7 放过一次，结果排期时还是分不出主次，后来压到 0.5，逼着设计人重新想清楚哪些是真正的基本功能。

第二个抓手是用例和自动化的匹配关系。文档 6.2 的说明里有一条：同一个功能的自动化用例和功能用例应匹配，自动化覆盖不全时，把两者拆成互补用例集。这条在落地时经常被理解成“自动化另写一套”，结果两套用例各说各话，回归时不知道该信哪套。我的处理是让自动化用例直接引用功能用例的编号，覆盖不到的分支在功能用例上标注“仅手工”，每次迭代同步更新这张对照表。

最后说个我自己的习惯。早些年我也不爱写前置条件，觉得执行时造一下数据就行，直到有次回归换了台环境，权限账号没配全，一整批用例执行结果全是“预期不符”，排查了半天才发现是环境问题。从那以后我每次提交用例前，都强制走一遍上面那段自查脚本，前置条件为空的一条都不放过。这套东西不复杂，难的是每次都走。希望帮到你。

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