测试用例编写可以按六个步骤推进：确认输入与范围、把需求拆成可验证点、选择设计方法生成用例、按统一字段填写、组织评审与修订、依据执行反馈迭代。核心产物是一份字段完整、他人可照做的用例集，每条用例写清前置条件、操作步骤、测试数据、预期结果和优先级。下面按这六步说明具体做法，并给出字段模板、角色分工、改写示例和评审检查表。
要点总览（TL;DR）
- 测试用例编写按六步推进：确认输入与范围、拆解需求为可验证点、选择设计方法、按统一字段填写、评审修订、依据执行反馈迭代。
- 动笔前先列输入清单并写明测什么、测哪个版本、不测什么，关键路径与风险点优先分配用例。
- 字段模板包含编号、标题、前置条件、步骤、测试数据、预期结果、优先级；单条用例只验证一个目标，步骤写到他人可照做。
- 评审安排在初稿完成、执行之前，按覆盖度、可执行性、可维护性、优先级四项核对，全部问题关闭后才标记可交付。
- 用例定稿后仍需随需求变更和执行反馈修订并保留版本记录，逐步沉淀为回归测试的基础。
先定范围：写用例前要确认哪些输入
动笔前先把输入凑齐，能避免写到一半回头猜需求。建议在用例编写启动时列一份输入清单，逐项确认是否拿到、版本是否与本次测试对象一致。缺少某项输入时，先记录缺口和影响范围，再决定是否推迟该部分用例的编写。
常见输入包括：需求文档或用户故事、交互原型与视觉稿、接口说明与字段定义、数据字典与业务规则、上下游系统依赖说明、历史缺陷与线上问题记录、本次版本变更清单。输入不必求全，但涉及本次测试对象的关键规则必须有出处，不能靠个人记忆补全。
范围说明要写清三件事：测什么、测哪个版本、不测什么。例如“本次覆盖订单提交与支付回调，基于 3.2 版本需求，不覆盖退款流程与后台对账”。把不测范围写明，评审时才能判断遗漏是刻意取舍还是疏忽。
在范围内再标出关键业务路径与风险点，作为后续覆盖的依据。判断风险可以看几个信号：资金与权限相关逻辑、本次改动集中的模块、历史上缺陷多的功能、依赖外部系统的环节、用户高频使用的路径。这些位置应分配更多用例和更高优先级。
本步的交付物是一份输入清单加范围说明，完成标志是：每项输入标注了来源与版本，测什么与不测什么都已写明，关键路径与风险点已列出并得到测试负责人确认。
从需求到可验证点：拆解与设计方法
需求条目通常是一段描述，不能直接当用例写。拆解的目标是把它变成若干“可观察、可判定”的验证点：执行某个操作后，能在界面上看到、在接口返回中读到或在数据里查到明确结果。拆完后建议形成一张需求—验证点对照表，左侧是需求条目编号，右侧是验证点及其判定方式，便于检查覆盖是否有缺口。
拆解时逐条问三个问题：这条需求约束了哪些输入和状态？每种输入下系统应表现为什么？哪些情况应当被拒绝或提示？以“手机号登录”为例，可拆出：合法手机号加正确验证码可登录、验证码错误有提示、验证码过期有提示、未注册手机号的处理、频繁获取验证码的限制、账号被锁定时的提示。每个验证点都对应一个可判定的结果。
设计方法按场景选用，不必每条需求都用全套方法：
| 方法 | 适用场合 | 产出 |
|---|---|---|
| 等价类划分 | 输入取值范围大、无法逐一枚举，如金额、长度、枚举状态 | 有效类与无效类各若干，每类取代表值 |
| 边界值分析 | 存在上下限的数值、日期、字符长度 | 取最小值、最大值及其相邻值 |
| 场景法 | 多步骤业务流程，如下单、审批、支付 | 主成功场景与各分支场景的步骤序列 |
| 判定表 | 多个条件组合决定不同结果，如优惠叠加、权限组合 | 条件与动作的对应组合，避免遗漏 |
覆盖思路按四个方向铺开：正向路径验证主流程能走通；异常与边界验证错误输入、极限值和失败分支被正确处理；权限与角色验证不同身份看到和能做的范围；状态流转验证对象在各状态间的迁移与非法迁移的拦截。四个方向不必等量，按风险分配比重，资金、权限、数据一致性相关的位置优先写细。
本步完成标志是：每条需求至少对应一个验证点，关键需求的正向、异常、边界、权限分支均有覆盖，方法选用理由能说清。
用例字段怎么写：模板与填写规范
字段统一，用例才能被他人执行和评审。下表是一份可直接套用的字段结构：
| 字段 | 填写要求 |
|---|---|
| 用例编号 | 按模块或需求编号加序号，全局唯一，便于引用与追溯 |
| 标题 | 一句话说明验证什么，包含对象、条件和预期方向，如“验证码错误时登录被拒绝并提示” |
| 前置条件 | 执行前必须存在的状态与数据，如账号已注册、余额为 100 元、处于待支付状态 |
| 操作步骤 | 按顺序编号，每步一个动作，写清在哪个页面、对哪个对象、输入什么 |
| 测试数据 | 步骤中用到的具体值，如手机号、金额、文件类型，避免写“输入合法数据” |
| 预期结果 | 可观察、可判定的结果，写清界面提示、数据变化、状态迁移 |
| 优先级 | 按业务重要性与风险分级，高优先级覆盖主流程与关键风险 |
标题与步骤的写法有三条要求。第一，单条用例只验证一个目标，把“登录并修改密码”拆成两条，失败时才能定位问题。第二，步骤要可执行，写到他人不看需求文档也能照做的程度，避免“正常登录”“输入正确信息”这类笼统表述。第三，步骤与预期结果一一对应，每一步或每组步骤后写明应看到什么。
预期结果的判定标准要具体。写“提示验证码错误”比写“提示错误”好；写“订单状态变为已支付，支付时间记录为当前时间”比写“支付成功”好。涉及数据变化时，说明在哪里查看、看到什么值；涉及提示时，写明提示文案或提示位置；涉及不应发生的行为时，明确写出“不生成订单”“不发送短信”等可核对的结论。
本步完成标志是：用例集字段齐全无空缺，标题能独立说明验证目标，步骤与预期结果可被未参与编写的人直接执行。
角色分工与交付物：谁写、谁审、谁维护
用例编写涉及多个角色，职责分清可以减少返工。下表给出常见分工，团队规模小时一人可兼多职，但评审与编写尽量分开，避免自己审自己。
| 角色 | 主要职责 |
|---|---|
| 用例作者 | 按规范编写用例，维护自己负责模块的用例内容 |
| 评审人（测试同事） | 检查覆盖度、步骤可执行性与预期结果判定标准 |
| 测试负责人 | 确认范围与优先级，组织评审，判定用例集是否可交付 |
| 开发 | 确认技术实现相关的边界与异常处理，参与接口类用例评审 |
| 产品 | 确认业务规则与预期结果是否符合需求意图 |
各阶段交付物对应如下：启动阶段交输入清单与范围说明；设计阶段交需求—验证点对照表；编写阶段交用例集初稿；评审阶段交评审记录与问题清单；修订后交定稿用例集与版本号。交付物不必是独立文档，关键是每项都有明确归属和存放位置。
用例变更的责任归属要提前约定：需求变更时由用例作者同步修订，测试负责人确认影响范围；执行中发现用例错误，由发现人记录、作者修订；定稿后的每次修改保留版本记录，说明改了什么、为什么改。这样在回归测试和交接时能查到用例的演变过程。
当用例需要与需求条目关联、评审意见需要流转和留痕时，可以借助研发管理工具承载这些管理动作。例如在 ONES 中，测试用例可与需求工作项建立关联，评审意见在用例记录上流转，修订后保留版本，测试负责人据此确认用例集状态。工具承担的是关联、流转与留痕，用例内容质量仍取决于前面的拆解与填写规范。
示例：一条登录用例从草稿到定稿
下面用一条登录用例演示改写过程。草稿是常见写法：
- 标题：登录测试
- 前置条件：无
- 步骤：打开登录页，输入手机号和验证码，点击登录
- 预期结果：登录成功
这条草稿有三个问题：标题没有说明验证什么，无法与“验证码错误”等用例区分；步骤笼统，“手机号”和“验证码”没有具体数据，执行人不知道输入什么；预期结果只写“登录成功”，没有说明登录后应看到什么、数据应如何变化。此外它把正常登录与异常情况混在一个验证目标下，失败时难以定位。
按规范改写后：
- 用例编号：LOGIN-001
- 标题：已注册手机号输入正确验证码后可登录并进入首页
- 前置条件：账号 13800000000 已注册且状态正常；该账号当前未登录；验证码有效期为 5 分钟
- 步骤：1. 打开登录页；2. 在手机号输入框输入 13800000000；3. 点击获取验证码；4. 输入收到的 6 位验证码；5. 点击登录
- 测试数据：手机号 13800000000，验证码为本次获取的有效验证码
- 预期结果：步骤 3 后提示验证码已发送，手机收到 6 位数字验证码；步骤 5 后页面跳转至首页，右上角显示该账号昵称，登录状态在刷新页面后保持
- 优先级：高
改写前后的差异集中在四点：标题从“登录测试”变为可判定的验证目标；前置条件补上了账号状态与验证码有效期；步骤与测试数据写到可直接照做的程度；预期结果拆到具体步骤并给出可观察的现象。异常情况另立用例，如“验证码错误时登录被拒绝并提示验证码错误”，与正常登录分开维护。
评审与完成检查：用例集能否交付
评审建议安排在用例初稿完成、尚未进入执行之前，参与人包括用例作者、测试同事、测试负责人，涉及业务规则时请产品参加，涉及接口与异常处理时请开发参加。评审重点看四件事：覆盖是否与需求—验证点对照表一致；步骤能否被他人直接执行；预期结果是否可判定；优先级分配是否与风险匹配。
下面是一份可逐项核对的检查表：
| 检查维度 | 核对项 | 通过标准 |
|---|---|---|
| 覆盖度 | 需求条目是否都有对应用例；正向、异常、边界、权限分支是否覆盖 | 对照表无未覆盖条目，关键风险点有用例 |
| 可执行性 | 前置条件是否完整；步骤是否有具体数据；预期结果是否可观察 | 未参与编写的人可独立执行并判定结果 |
| 可维护性 | 编号是否唯一；单条用例是否单一验证目标；是否便于后续修订 | 修改一条用例不影响其他用例的判定 |
| 优先级 | 高优先级是否覆盖主流程与关键风险 | 执行资源受限时可据此裁剪 |
未通过项的关闭条件要写清：每条问题记录问题描述、责任人和修订要求，作者修订后由提出人确认关闭；涉及范围或预期结果争议的，由测试负责人或产品确认后关闭。全部问题关闭、检查表各项通过，用例集才标记为可交付执行。
用例定稿不等于结束。执行阶段发现的遗漏和错误应回流到用例集，按前面约定的变更责任修订并记录版本。经过一轮执行反馈迭代后，用例集才逐步稳定，成为后续回归测试可复用的基础。
常见问题
需求文档写得很粗，用例编写还能开始吗？
可以先写已明确的部分，同时把不明确处整理成问题清单，向产品确认后再补。做法是：先按现有描述拆出可判定的验证点，对无法判定的条目标注待确认，并在范围说明里写明这部分用例暂不覆盖。等确认结果回来再补齐，避免凭个人理解写出与需求意图不符的预期结果。
用例写到什么颗粒度合适，太细会不会维护成本太高？
颗粒度以“他人能独立执行并判定结果”为准。步骤写到具体页面、对象和输入值即可，不必细到每次点击的坐标。单条用例只验证一个目标，把正常流程与异常分支分开，这样失败时能定位问题，修改一条也不影响其他用例的判定。过度拆分会增加维护量，判断标准是这条用例是否对应一个独立的验证点。
用例评审时产品和开发必须参加吗？
按评审内容决定。涉及业务规则、预期结果是否符合需求意图时，请产品参加；涉及接口边界、异常处理和状态流转时，请开发参加。纯属步骤表述和字段规范的问题，测试同事之间评审即可。测试负责人负责确认范围与优先级并判定用例集是否可交付。
执行阶段发现用例写错了或漏了场景，怎么处理？
由发现人记录问题，用例作者修订，涉及范围变化的由测试负责人确认影响范围。修订后保留版本记录，说明改了什么、为什么改。执行反馈回流是用例集逐步稳定的正常环节，定稿不等于不再变动，关键是每次修改可追溯，回归测试时能查到用例的演变过程。
用例需要和需求条目关联吗，用什么方式管理比较合适？
建议关联。需求变更时能快速定位受影响的用例，评审时也能对照检查覆盖是否有缺口。可以用需求—验证点对照表人工维护，也可以在研发管理工具中建立关联。例如 ONES 的测试用例可与需求工作项关联，评审意见在用例记录上流转并保留版本，测试负责人据此确认用例集状态；用例内容质量仍取决于拆解与填写规范。
