简介：这份《测试用例编写指南》面向测试人员与技术管理团队成员，针对编写用例时凭惯性思考、设计逻辑固定、颗粒度与详细程度不一等痛点，提供一套可循可依的规范方法，帮助统一编写标准、弥补知识空缺并提升测试设计水平。资源包共1个docx文件，约494KB，内容涵盖测试设计依据、编写步骤、编写要素、划分原则、编写要求、测试类型、设计方法及用例维护等章节，并附修订记录与风险建议。其中编写步骤细化为需求分析、业务流程分析、系统设计分析、用例编写与完善五个环节，要素部分则对需求路径、前置条件、操作步骤、预期结果、优先级、用例类型与属性等逐项说明，还介绍了等价类划分、边界值分析、状态迁移等设计方法。已有553人学习，适合需要规范用例模板、补齐设计思路的测试从业者参考。
1. 从“凭感觉写用例”到“有据可依”：一份能直接落地的测试用例编写规范
测试团队里最常见的翻车场景，不是不会点页面，而是两个人对着同一个需求写出来的用例颗粒度差了三倍：一个人写了 8 条，另一个人写了 40 条，评审时谁也说服不了谁。更麻烦的是，用例里只写了“输入正确手机号，登录成功”，却没写清前置条件、后台落表校验和日志检查点，执行的人换一个就漏一片。这份《测试用例编写指南》要解决的就是这件事——把测试设计从个人惯性里拽出来，变成一套可评审、可复用、可交接的规范。它适合正在做测试课程设计的学生、要交测试方案文档的从业者，也适合团队里需要统一用例模板的技术管理角色。关键词用例编写注意点，贯穿的正是“写之前怎么想、写的时候怎么落、写完怎么验”这条主线。
2. 需求与设计依据：五步流程把业务需求翻译成测试检查点
2.1 为什么不能拿到需求文档就直接写用例
很多新人拿到需求说明书的第一反应是打开 Excel 开始填行，结果写到一半发现业务流程里有个“复核退回后重新提交”的分支根本没覆盖，回头再补，用例结构已经乱了。这份指南把编写过程拆成五步：需求分析、业务流程分析、系统设计分析、测试用例编写、测试用例完善。前两步解决“业务上要验什么”，第三步解决“系统实现上会改到什么”，后两步才是落笔和补漏。顺序不能颠倒，因为测试需求的检查点是从业务和设计文档里长出来的，不是拍脑袋列出来的。
测试设计依据通常包括需求说明书、概要设计与详细设计、数据库设计、业务背景沉淀文档，以及与开发组对齐后的需求理解，再加上基本成型的 UI。这里有个血泪经验：只读需求文档写出来的用例，往往漏掉接口入参校验和数据库字段长度约束，而这两类恰恰是生产问题的高发区。所以第三步“系统设计分析”不是可选项，它决定了你的用例能不能覆盖改动点的影响范围。
2.2 五步流程的输入、处理与输出
把五步流程落成一张可执行的表，比空讲方法论有用得多。下面这张表是我一般会直接放进方案文档里的版本，每一步的输入、处理和输出都写死，评审时按列对：
| 步骤 | 输入 | 处理动作 | 输出 |
|---|---|---|---|
| 需求分析 | 业务需求说明书 | 按流程或功能分类，逐条拆需求细节 | 测试需求检查点清单 |
| 业务流程分析 | 业务背景、系统业务流程 | 梳理主流程、备选流程、数据流向、关键判断条件 | 需求未提及但需覆盖的补充检查点 |
| 系统设计分析 | 概要/详细设计、接口设计、数据库设计 | 分析改动点及其影响范围 | 逻辑分支检查点 + 回归范围检查点 |
| 测试用例编写 | 测试需求 | 覆盖生产业务流程与系统逻辑分支，关注边界与异常 | 功能、边界、异常、接口、信息安全等类型用例 |
| 测试用例完善 | 评审意见、变更、执行反馈、生产问题 | 按触发条件更新维护 | 修订后的用例集 |
这张表的价值在于：每一步的输出都是下一步的输入，链条断了就能定位是哪一步偷了懒。比如用例执行时发现某个异常分支没覆盖，回溯一下大概率是第二步业务流程分析没把备选流程列全，而不是写用例的人手懒。
2.3 用例完善不是收尾动作，而是触发式维护
指南里明确列了四类必须触发用例更新的场景：评审发现用例有问题、系统新增功能或需求变更、测试过程中发现设计遗漏、系统出现生产问题且经分析属于测试泄漏。这四条的共性是把“维护”从“想起来才做”变成“条件触发必做”。我一般会在用例管理表里加一列“最近修订触发原因”，填的就是这四类之一，答辩或评审时被问到“这条用例为什么改过”，直接指列就行，不用现场回忆。
3. 用例要素与划分原则：模板字段怎么填、颗粒度怎么定
3.1 测试需求与测试用例的字段清单
统一模板是规范化的第一步。测试需求侧的核心字段包括需求路径、需求名称、需求描述、设计人、关联系统；测试用例侧包括用例路径、测试名称、用例描述、前置条件、操作步骤、预期结果、设计人、优先级、用例类型、用例属性、测试方式、执行次数。字段看着多，但每一个都对应一个评审时会被追问的点。
需求路径的格式是“/项目名称/一级需求/二级需求/……/N 级需求”，用例路径则在需求路径基础上追加需求名称。这个层级设计的好处是导入测试管理平台后能直接按树展开，执行时按目录挂执行集，不会出现用例散落找不到归属的情况。优先级分高、中、低三档：高对应基本功能和关键路径，比如正常流程、页面元素正常输入；中对应功能完善类，比如异常流程、异常输入；低对应体验类和辅助功能，比如页面元素显示。用例类型分流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类；用例属性分正常、异常；测试方式分手动、自动化；执行次数记录实际执行轮次。
3.2 测试需求划分：按对象分类定层级
划分原则的核心是控制颗粒度——太粗会漏测试点，太细维护成本压不住。指南按测试对象分类给出了划分方式，前端功能按“新增菜单/菜单功能修改”走目录层级，业务流程按“全业务流程”走流程名和步骤名，后台功能按“单功能/接口”走接口名和校验类型，批处理按任务名，后台流程按全流程场景或步骤分解，数据埋点按页面，兼容性按测试维度细分。
落到具体操作上，有几条判断规则值得直接抄：同一功能不同入口可以合并成一个需求；一个功能的正常流程对应一个检查点；一个功能含多个正常场景或异常流程，分别列多个检查点；同一功能需要准备多份不同数据时，原则上分别列检查点，但如果一次操作要同时处理多份数据，可以单独列一个组合检查点。这几条规则解决的就是“同一个功能有人写 3 条有人写 30 条”的争议。
3.3 测试用例划分：一个检查点对应一条用例的边界在哪
用例划分的默认规则是“一个测试需求检查点对应一条用例”，但不同对象有各自的合并与拆分口径。前端功能里，页面要素检查、列表查询分页删除、表单输入项检查通常拆开写，输入项多时可按输入项或输入分区酌情拆分。业务流程按检查点一条一条来，比如审批流程的自动核查通过、自动核查拒绝、人工审批通过、人工审批拒绝各一条。后台接口的入参有效性检查这类测试点可以考虑合并成一条用例，但账户不存在、手机号被占用这类业务分支要单独拆。批处理和后台流程基本是一个检查点一条用例。数据埋点每个页面一条。兼容性按维度细分，按操作系统维度就是 iOS、Android 各一条，按机型维度就是每个机型一条。
这里有个容易踩的坑：同一个功能的自动化用例和功能用例要匹配，如果自动化用例不能完全覆盖功能用例，就把两者拆成互补的用例集，而不是让自动化用例“假装”覆盖了全部。评审时看到自动化用例集和功能用例集数量对不上又说不清互补关系，基本会被打回。
3.4 操作步骤与预期结果的对应关系
指南用一张对照表把操作步骤和预期结果的对应关系讲透了，这是整份文档里最值得直接搬进课程设计或方案附录的部分。对应关系分四类：一种操作对应一个预期结果分支、一个预期结果含多个检查点、多种操作对应一个预期结果分支、多种操作对应多个预期结果分支。前两类是推荐写法，后两类里“多种操作对应多个预期结果分支”明确标注不建议使用，应尽量按预期结果分支拆分。
举个具体的：删除测试执行集这条用例，如果执行集里挂的是未执行用例，预期结果要写清“可成功删除执行集，包括分类目录及其下所有用例执行记录；测试用例管理列表的用例数据仍存在且为有效状态”。如果挂的是有效未执行加作废未执行的混合用例，预期结果还要补充“作废用例状态不变”。这种写法把前端提示、后台数据存储、前后端一致性三层检查点都落到了字段级，执行的人照着点就不会漏。
4. 编写要求与设计方法：名称、前置、步骤、预期怎么写才不返工
4.1 四个核心字段的硬性要求
测试名称要简洁到能直接识别测试对象和检查点，不能把操作步骤塞进名称里，比如“放款失败-合同冻结”就是合格写法，“输入合同号点击查询后放款失败并检查合同状态为冻结”就是不合格。前置条件必须完整列出特殊账号权限、数据准备和前置操作，而且用例之间不允许相互依赖——把另一条用例当成本条的前置条件，是评审时最常见的返工点。
操作步骤要写清入口、与测试点相关的输入要素、按钮、运行任务和操作顺序，步骤里不能包含检查结果。预期结果要把检查点完整列出：前端成功或失败要包含页面显示、提示信息、后台数据存储、前后端数据一致性；涉及后台数据变更要明确具体数据表和关键字段取值变化；后台系统测试和信息安全相关的前端操作必须包含输出日志和后台数据存储结果检查。预期结果里也不能反过来包含操作步骤。这两条“不能互相包含”的约束，本质是让步骤和结果各自可独立评审。
4.2 用等价类与边界值把输入项检查写全
设计方法部分列了功能正确性测试、异常测试、边界值测试、等价划分测试、错误推测、因果图分析。落到实际写用例，最常用的是等价类加边界值的组合。下面这段伪代码展示的是我一般用来生成输入项检查点的思路，不是要跑起来，而是把“合法/非法、边界内/边界外”的组合逻辑固化下来，避免手写时漏项：
# 输入项检查点生成思路（伪代码，用于梳理用例检查点，不直接执行） def build_input_checkpoints(field): checkpoints = [] # 1. 正常值：取业务上真实会出现的合法数据 checkpoints.append(f"{field.name}-正常值输入") # 2. 等价类：有效等价类与无效等价类各取代表值 for cls in field.valid_classes: checkpoints.append(f"{field.name}-有效等价类-{cls}") for cls in field.invalid_classes: checkpoints.append(f"{field.name}-无效等价类-{cls}") # 3. 边界值：刚刚小于、等于、刚刚大于边界 for boundary in field.boundaries: checkpoints.append(f"{field.name}-边界值-{boundary}") # 4. 特殊字符与前后空格：前端限制与数据库字段长度不一致的高发区 checkpoints.append(f"{field.name}-特殊字符组合") checkpoints.append(f"{field.name}-首尾及中间空格") return checkpoints这段逻辑对应的参数说明：valid_classes和invalid_classes来自需求与数据库设计文档，boundaries来自字段长度和业务规则（比如利率浮动比例边界值为 0）。指南里特别点出的两个高发场景——前端限制长度与数据库字段长度不一致、金额四舍五入——正好落在特殊字符和边界值这两类检查点上。错误推测则靠经验补位，分页场景的查询分页和文件分页、登录页的验证码与身份信息校验组合，都是历史上出过问题的地方，写用例时按同类验证一遍。
4.3 测试类型清单怎么用在用例属性上
指南列了功能测试、接口间测试、信息安全测试、关联性测试、回归测试、数据库测试、压力测试、操作友好性测试、效率测试、兼容性测试、数据移植测试、安装测试。这份清单不是让你每个需求都全写一遍，而是用来对照用例属性做覆盖度自检：涉及代码改动的功能，关联性测试和回归测试范围要在系统设计分析阶段就圈出来；涉及数据迁移的迭代，数据移植测试要单独列检查点，关注迁移前后数据量一致性、表结构变化和迁移后业务逻辑回归；涉及前端信息安全的操作，预期结果里必须带日志和后台存储检查。把这份清单当成一张勾选表，用例评审时逐项确认“本需求涉及哪几类、哪几类没涉及及原因”，比口头说“都覆盖了”有说服力得多。
5. 避坑与常见问题：评审现场最容易被退回的五种写法
5.1 用例之间相互依赖
现象：B 用例的前置条件写着“执行完 A 用例后”。原因：写用例的人图省事，把上一条用例的执行结果当成了本条的数据准备。解决：前置条件只写账号权限、数据准备和前置操作，数据准备通过独立的造数步骤或脚本完成，保证任意一条用例单独拎出来都能执行。
5.2 操作步骤里夹带检查结果
现象：步骤写成“输入手机号，点击查询，确认列表返回 3 条记录”。原因：写的人把操作和验证混在一句话里，执行时无法区分哪一步是动作、哪一步是判断。解决：步骤只写动作，所有检查点移到预期结果，并按编号与步骤对应。
5.3 预期结果只写“操作成功”
现象：预期结果栏只有“添加成功”四个字。原因：没意识到前端提示、后台落表、前后端一致性是三层独立检查点。解决：按指南要求补齐页面显示、提示信息、后台数据表记录和关键字段取值变化，后台类测试补日志检查。
5.4 颗粒度失控导致用例爆炸或遗漏
现象：一个表单 20 个输入项写了 200 条用例，或者整个审批流程只写 2 条。原因：划分原则没落地，全凭手感。解决：按第 3 章的划分口径先定测试需求层级，再按“一个检查点一条用例”展开，输入项多时按输入分区合并，评审时用检查点清单反查覆盖度。
5.5 生产问题泄漏后不回溯用例
现象：线上出了问题，修完就过，用例库没动。原因：缺少触发式维护机制。解决：把“生产问题经分析为测试泄漏”列为用例更新的强制触发条件，回溯到具体缺失的检查点，补进对应用例并在修订记录里注明原因。
6. 验收与答辩：用一张覆盖矩阵证明你的用例设计站得住
验收这份指南类方案，核心不是看文档写得多厚，而是看能不能用一张矩阵证明“需求检查点—用例—测试类型”三者对得上。我一般会要求做三件事。第一，抽三条代表性用例做走查：一条正常流程、一条异常流程、一条涉及后台数据变更的用例，逐字段核对名称、前置条件、步骤、预期结果是否符合第 4 章的要求，重点看步骤和预期有没有互相包含、预期有没有落到数据表和字段级。第二，做覆盖矩阵：行是测试需求检查点，列是功能正确性、边界、异常、接口、信息安全等测试类型，格子里填对应用例编号，空格必须能解释原因。答辩时评委问“这个需求的异常场景覆盖了吗”，直接指矩阵，比翻文档快得多。
第三，准备一个“划分口径说明”页：同一个功能为什么拆成这几条用例、为什么合并那几条，用第 3 章的规则逐条对应。这一步最容易被忽略，但恰恰是区分“会写用例”和“会设计用例”的地方。下面这张矩阵模板可以直接拿去改：
| 测试需求检查点 | 功能正确性 | 边界 | 异常 | 接口 | 信息安全 | 备注 |
|---|---|---|---|---|---|---|
| 用户注册-正常流程 | TC-001 | TC-002 | TC-003 | TC-004 | TC-005 | 手机号字段长度边界见 TC-002 |
| 审批流程-人工拒绝 | TC-010 | — | TC-011 | — | — | 无边界场景，原因：状态机单向 |
答辩时还有一个高频追问：优先级怎么定的。按指南口径回答——高对应基本功能和关键路径，中对应异常流程和异常输入，低对应体验和辅助功能，并且说明执行顺序按优先级排，时间不够时先保高优先级用例执行完。这个回答背后其实是在证明你懂测试执行的资源分配逻辑，而不是随手标了个高。
最后说个我自己的习惯：每次交方案前，强制拿三条用例走一遍“换人执行”测试——把用例给没参与编写的人看，让他照着步骤点，看他会不会在预期结果之外产生疑问。只要有疑问，就说明前置条件或检查点没写透。这个习惯帮我挡掉过好几次评审返工。从那以后我每次交付用例文档都强制走一遍这个换人执行检查，希望帮到你。
本文还有配套的精品资源，点击获取
