测试用例编写的核心，是把需求转成可执行、可判断的验证条目：先明确被测对象和验收标准，再用等价类、边界值、场景法等方法拆出验证点，按统一字段写清前置条件、操作步骤、测试数据和预期结果，最后经评审与执行反馈修订。本文按设计、字段、分工、示例、检查、协作六个环节展开，适合正在建立或规范用例编写流程的测试与研发团队参考。
要点总览（TL;DR）
- 测试用例编写按五步推进：确认需求与验收标准、选择设计方法拆验证点、按统一字段写用例、评审、执行反馈修订；每步以“下一步能顺利开始”为完成标志。
- 字段模板必备项包括用例编号、标题、所属模块、优先级、前置条件、操作步骤、测试数据、预期结果；预期结果要写可观察现象，步骤与验证动作分开写。
- 设计方法按输入特征选用：取值范围用等价类和边界值，多分支流程用场景法，状态流转用状态迁移法；粒度按风险取舍，高风险功能细化到具体数据。
- 角色分工写清设计者、评审者、执行者、需求方和维护责任人的交付物；评审放在初稿完成、提测之前，变更按模块归属并保留记录。
- 完成标准三条：评审意见逐条处理有结论、检查清单相关项全部通过、用例状态更新为可执行并纳入测试计划；执行发现问题按修订流程回写。
测试用例编写的核心步骤
用例编写可以拆成五个前后衔接的步骤。每一步都有明确的输入、动作和输出，完成标志是下一步能顺利开始，而不是“感觉写得差不多了”。
第一步：确认被测对象、需求范围与验收标准
输入是需求文档、原型、接口说明或用户故事。动作是逐条阅读需求，标出可验证的行为描述，把模糊表述（如“响应要快”“体验流畅”）转成可判断的条件（如“列表页在常规数据量下3秒内返回首屏”）。输出是一份验证点清单，每个验证点对应一条或一组需求条目。完成标志是：每个验证点都能回答“验证什么行为、满足什么条件算通过”。需求本身存在歧义时，先与需求方确认再进入设计，避免把错误理解写进用例。
第二步：选择设计方法并拆出验证点
输入是验证点清单和业务规则。动作是根据输入数据的特征和业务流程的复杂度选择方法：输入有取值范围时用等价类和边界值，业务流程有多个分支时用场景法，对象有明确状态流转时用状态迁移法。输出是一组覆盖正常、异常和边界的验证点。完成标志是：主要业务路径、关键异常路径和典型边界都有对应验证点，且能说明每个验证点由哪种方法得出。
第三步：按统一字段写出用例
输入是验证点。动作是把每个验证点展开成一条完整用例，填写用例编号、标题、优先级、前置条件、操作步骤、测试数据、预期结果等字段。输出是可直接交给执行者的用例条目。完成标志是：一位不熟悉该需求的执行者，仅凭用例内容就能完成操作并判断结果对错。
第四步：评审
输入是用例初稿。动作是由需求方、开发、测试设计者共同检查覆盖是否完整、预期结果是否准确、步骤是否可执行。输出是评审意见和修订后的用例。完成标志是：评审意见逐条处理完毕，遗留问题有明确结论。
第五步：执行反馈与修订
输入是执行过程中发现的用例缺陷，例如步骤缺失、数据不可构造、预期结果与实际业务不符。动作是记录问题、修订用例并同步给相关人员。输出是更新后的用例版本。完成标志是：执行中暴露的用例问题已回写到用例库，后续回归可以直接复用修订后的版本。
用例字段模板与设计方法怎么选
字段模板解决“每条用例写什么”，设计方法解决“验证点从哪来”。两者配合，才能让用例既完整又有针对性。
用例必备字段与选填字段
| 字段 | 类型 | 填写要求 |
|---|---|---|
| 用例编号 | 必备 | 项目内唯一，便于引用和追溯 |
| 用例标题 | 必备 | 一句话说明验证对象和验证条件，如“手机号为空时提交注册” |
| 所属模块 | 必备 | 对应功能模块或需求条目，便于组织和检索 |
| 优先级 | 必备 | 按业务重要性和使用频率分级，核心路径为高 |
| 前置条件 | 必备 | 执行前必须满足的环境、数据、账号状态 |
| 操作步骤 | 必备 | 按顺序编号，每步一个动作，避免一步包含多个操作 |
| 测试数据 | 必备 | 写明具体取值或数据构造方式，不用“任意值”代替 |
| 预期结果 | 必备 | 与步骤对应，写可观察的界面反馈、数据变化或接口返回 |
| 关联需求 | 选填（建议填） | 指向需求条目编号，支撑追溯 |
| 备注 | 选填 | 记录设计依据、特殊环境要求或已知限制 |
字段填写有两个常见问题值得注意。一是预期结果写成“正常显示”“操作成功”这类无法判断的表述，应改为具体现象，例如“页面跳转到首页，顶部显示当前登录用户名”。二是步骤中混入验证动作，应把“点击提交”和“检查提示文案”分开写，让执行和判断各自清晰。
设计方法的适用条件
| 方法 | 适用条件 | 产出特点 |
|---|---|---|
| 等价类划分 | 输入有明确取值范围或类型约束，取值数量多但行为可归类 | 把输入分成有效类和无效类，每类取代表值，减少重复用例 |
| 边界值分析 | 输入或长度存在上下限，如字符数、金额、日期区间 | 重点覆盖最小值、最大值及其相邻值 |
| 场景法 | 业务流程有多个步骤、分支或角色参与 | 按主流程和备选流程组织用例，覆盖用户实际使用路径 |
| 状态迁移法 | 对象有明确状态和允许的流转，如订单、审批单 | 覆盖合法迁移和非法迁移，验证状态约束 |
用例粒度需要结合项目阶段取舍。需求频繁变动、迭代周期短时，用例可以写得概括一些，重点保证核心路径和关键异常有覆盖；涉及资金、权限、数据安全等高风险功能时，应细化到具体数据和判断条件。覆盖度以“主要风险都有对应用例”为判断依据，不必追求每个输入组合都单独成条，等价类合并本身就是控制冗余的手段。
角色分工与交付物
用例质量不只取决于写的人，也取决于评审和维护是否有人负责。小团队可以一人兼多个角色，但职责要写清楚，避免用例写完无人评审、执行发现问题无人回写。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 用例设计者 | 确认验证点、选择设计方法、按模板编写用例、处理评审意见 | 验证点清单、用例初稿、修订后的用例 |
| 评审者（需求方、开发、测试同行） | 检查需求覆盖、预期结果准确性、步骤可执行性 | 评审意见、通过结论 |
| 执行者 | 按用例执行、记录实际结果、反馈用例缺陷 | 执行记录、用例问题清单 |
| 需求方 | 确认验收标准、澄清需求歧义、参与关键用例评审 | 需求澄清结论、验收口径 |
| 用例维护责任人 | 随需求变更更新用例、处理执行反馈、维护用例状态 | 更新后的用例版本、变更记录 |
评审时点建议放在用例初稿完成、开发提测之前。此时需求理解已经稳定，评审意见还能赶在测试执行前落实。参与人至少包括用例设计者和需求方，涉及接口或数据逻辑的用例应邀请开发参加。用例变更的责任归属按模块划分：需求变更引起的用例调整由该模块的用例设计者负责，执行中发现的问题由执行者提交、维护责任人确认后修订。每次变更保留记录，便于回溯某条用例为何调整。
示例：一条登录用例从需求到可执行条目
以下为演示情景，用于说明字段填写和方法落地，非真实项目案例。需求描述为：“用户使用手机号和密码登录，手机号为11位数字，密码为8至20位字符；连续输错密码5次后账号锁定30分钟。”
从需求提取验证点
这段需求包含三类信息：输入约束（手机号11位数字、密码8至20位）、正常流程（正确凭证登录成功）、异常与状态规则（密码错误提示、连续5次错误后锁定）。据此可以拆出正常登录、手机号格式异常、密码长度边界、密码错误、账号锁定等验证点。
按方法拆出用例
手机号用等价类和边界值：11位有效号码为有效类，10位、12位、含字母为无效类。密码用边界值：7位、8位、20位、21位。登录流程用场景法：正确凭证登录、密码错误后重试、连续5次错误触发锁定。锁定规则用状态迁移：正常状态到锁定状态、锁定期间尝试登录、锁定到期后恢复。
完整填写一条用例
| 字段 | 内容 |
|---|---|
| 用例编号 | LOGIN-005 |
| 用例标题 | 连续5次输入错误密码后账号锁定 |
| 所属模块 | 用户登录 |
| 优先级 | 高 |
| 前置条件 | 存在状态正常的测试账号，手机号13800000000，密码已设置为正确值；该账号当前无锁定记录 |
| 操作步骤 | 1. 打开登录页；2. 输入手机号13800000000；3. 输入错误密码Abcd1234；4. 点击登录；5. 重复步骤3至4共5次；6. 第6次输入正确密码并点击登录 |
| 测试数据 | 手机号：13800000000；错误密码：Abcd1234；正确密码：Test12345 |
| 预期结果 | 第1至4次登录提示密码错误，账号仍可继续尝试；第5次登录后提示账号已锁定，并说明锁定时长；第6次使用正确密码登录被拒绝，提示账号处于锁定状态 |
| 关联需求 | 登录需求条目中“连续输错密码5次后账号锁定30分钟” |
| 备注 | 锁定到期后的恢复验证另建用例，避免单条用例跨度过长 |
这条示例体现的取舍是：把“触发锁定”和“锁定到期恢复”拆成两条用例，每条只验证一个状态变化，执行失败时容易定位原因。可迁移的规律是，涉及计数的规则要写清第几次操作发生什么变化，涉及时间的规则要把时间条件写进前置条件或单独建用例。
用例质量检查清单与完成标准
判断用例是否写完，可以用下面的清单逐项核对。全部通过，才算达到可评审、可执行的状态。
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 可执行性 | 前置条件是否完整，步骤是否按顺序可操作，测试数据是否可直接构造 | 执行者无需额外询问即可完成操作 |
| 可判断性 | 预期结果是否具体、可观察 | 每条预期结果都能明确判定通过或失败 |
| 独立性 | 用例之间是否存在必须按顺序执行的隐式依赖 | 单条用例可独立执行，依赖项已写入前置条件 |
| 可追溯性 | 是否关联到需求条目或验证点 | 每个验证点至少有一条用例对应，每条用例能说明来源 |
| 覆盖度 | 正常路径、异常路径、边界条件是否都有覆盖 | 高风险功能的主要分支均有对应用例 |
| 冗余 | 是否存在验证同一条件、数据雷同的重复用例 | 重复条目已合并或说明保留理由 |
| 关联检查 | 用例与需求、后续缺陷的关联字段是否填写 | 关联信息完整，执行失败时能据此创建缺陷并回链 |
完成标准可以概括为三条：评审意见已逐条处理并有结论；检查清单中与本次范围相关的条目全部通过；用例状态更新为可执行，并纳入对应测试计划。执行阶段发现用例本身有问题时，按修订流程更新，不直接在执行记录里绕过。
把用例编写接入研发协作流程
用例写在文档里只是第一步，真正发挥作用要靠它与需求、执行记录、缺陷之间的流转。衔接方式可以按以下四个动作设计。
关联需求条目。每条用例或每组用例关联到对应的需求条目，需求变更时能快速找到受影响的用例。关联粒度以验证点为单位，避免整份需求只挂一条用例导致追溯失效。
记录评审与变更。评审意见、修订结论和变更原因保留在用例条目或评审记录中，形成可查的历史。这样后续接手的人能知道某条用例为什么这样写，而不是只看到最终版本。
执行结果与缺陷回填。执行时记录实际结果，未通过的用例直接创建缺陷任务，并在缺陷中回链用例编号。缺陷修复后，执行者按原用例回归，结果回写到执行记录，形成“用例—执行—缺陷—回归”的闭环。
在协作工具中承载。上述动作如果分散在文档、表格和即时通讯里，追溯成本会明显上升。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例可自定义属性以适配不同业务场景，用例库支持树状结构的多层分类组织；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。团队可以把字段模板落到自定义属性上，把评审结论和变更记录留在用例条目中，让需求、用例、缺陷在同一条链路上可查。具体字段配置和流转规则以项目实际设置为准。
常见问题
需求描述很模糊，比如“响应要快”“体验流畅”，用例该怎么写？
先把模糊表述转成可判断的条件，再写用例。例如把“响应要快”转成“列表页在常规数据量下3秒内返回首屏”，把“体验流畅”转成“连续滑动列表不出现白屏或卡顿超过1秒”。转换时与需求方确认口径，把确认后的条件写进预期结果或验收标准。如果暂时无法量化，可以在用例备注中记录待确认项，并先覆盖可判断的行为部分，避免把主观描述直接写进预期结果。
用例评审应该什么时候做，参与人必须有哪些？
评审建议放在用例初稿完成、开发提测之前。此时需求理解已经稳定，评审意见还能赶在测试执行前落实。参与人至少包括用例设计者和需求方；涉及接口、数据逻辑或状态流转的用例，应邀请开发参加；测试同行可以帮忙检查步骤可执行性和冗余。评审输出评审意见和通过结论，意见逐条处理完毕才算完成。小团队可以合并评审会议，但需求方对验收口径的确认不能省略。
一条用例覆盖多个验证点好，还是拆成多条好？
按失败时能否快速定位原因来取舍。如果多个验证点共享同一前置条件和操作路径，且失败时容易区分是哪个点出问题，可以合在一条用例中；如果涉及不同状态变化、不同数据构造方式或不同判断条件，建议拆开。例如“连续5次错误密码触发锁定”和“锁定到期后恢复登录”应拆成两条，因为后者需要等待时间或调整系统时间，执行条件不同。拆分的代价是用例数量增加，可以用等价类合并来控制冗余。
执行时发现用例本身写错了，应该直接改用例还是先记录问题？
先记录问题，再按修订流程更新用例。执行记录中保留实际结果和问题描述，注明是哪条用例的哪个字段有问题（如步骤缺失、数据不可构造、预期结果与实际业务不符）。由该模块的用例维护责任人确认后修订，保留变更记录，便于回溯调整原因。不建议在执行记录里直接绕过问题，否则后续回归会重复遇到同一处缺陷，追溯时也说不清用例版本为什么变化。
用例和需求、缺陷的关联要做到什么程度才算够用？
关联粒度以验证点为单位，让需求变更时能快速找到受影响的用例，执行失败时能从用例直接创建缺陷并回链。每条用例至少关联到对应的需求条目或验证点；未通过的用例创建缺陷任务时带上用例编号；缺陷修复后按原用例回归，结果回写到执行记录。如果整份需求只挂一条用例，追溯会失效；如果关联字段大量留空，后续统计覆盖度和缺陷来源都会缺依据。关联信息在评审和完成检查时一并核对。
