测试用例设计与管理可以拆成一条可执行的链路：先明确测试范围与需求来源，再按等价类、边界值、场景法等方法产出用例，统一字段与粒度，经过评审后进入执行与缺陷跟踪，最后建立变更、维护与度量机制。核心产物包括测试范围清单、用例设计规范、用例评审记录、执行结果与维护台账。下面按这条链路逐步展开，并给出可直接套用的模板与检查清单。
要点总览（TL;DR）
- 先产出测试范围清单和覆盖优先级表，明确用例的输入来源与排除项，再开始设计用例。
- 按输入特征选择等价类、边界值、场景法、判定表或状态迁移法，单条用例写清前置条件、分步操作和可观察的预期结果。
- 用统一的字段表和模板约束用例结构，区分必填与选填，并在复盘中调整字段。
- 明确测试、开发、产品、测试负责人在用例生命周期中的职责，评审安排在初稿完成、执行之前，意见逐条闭环。
- 执行记录关联缺陷，需求变更按关联需求定位受影响用例，按周期巡检并归档失效用例，用检查清单验收。
先定范围：测试用例从哪里来、覆盖到什么程度
用例质量的第一道关口在动笔之前。先确定“写什么、覆盖到什么程度”，能避免两类常见问题：一类是遗漏关键需求，另一类是在低风险功能上堆大量重复用例。范围界定的产物是一份测试范围清单和一张覆盖优先级表，后续设计与评审都以它为基准。
输入来源：用例的原始素材
用例内容应当可追溯到明确的输入，常见来源包括：
- 需求文档与用户故事：提供业务目标、功能规则和验收标准，是功能用例的主要来源。
- 设计文档与原型：提供页面跳转、交互状态、字段校验规则，适合推导界面与流程类用例。
- 接口说明：提供入参、出参、错误码和约束条件，适合设计接口级用例。
- 历史缺陷记录：暴露过往的高发问题区域，用于补充回归用例和异常场景。
- 线上问题与用户反馈：补充真实使用中的边界场景。
每一条输入都应标注来源编号，便于后续追溯“这条用例为什么存在”。当需求变更时，也能顺着来源快速定位受影响的用例。
范围清单与覆盖优先级
范围清单按功能模块或需求条目逐项列出，并标注覆盖优先级。优先级划分可参考三个维度：业务影响（失败是否影响核心交易或主流程）、变更频率（近期是否频繁改动）、缺陷历史（是否属于高发区域）。据此形成一张表：
| 模块/需求 | 输入来源 | 业务影响 | 变更频率 | 缺陷历史 | 覆盖优先级 |
|---|---|---|---|---|---|
| 登录与鉴权 | 需求文档 REQ-012 | 高 | 低 | 中 | P0 |
| 订单提交 | 需求文档 REQ-031、历史缺陷 | 高 | 高 | 高 | P0 |
| 个人资料编辑 | 原型、接口说明 | 低 | 中 | 低 | P2 |
P0 模块要求覆盖主流程、关键异常和边界值；P1 覆盖主流程与主要异常；P2 可只覆盖主流程。这样在时间紧张时，团队能明确知道哪些用例必须写、哪些可以后补。
明确不纳入范围的内容
范围清单同时要写清排除项，例如：具体自动化脚本的实现、性能压测的脚本细节、跨项目的用例资产复用、第三方系统的内部逻辑。把这些内容显式排除，可以防止用例文档被无关细节稀释，也避免评审时对边界产生分歧。范围清单在需求评审后定稿，作为用例设计的输入。
用例设计方法：按场景选方法并写出可执行步骤
设计方法的选择取决于输入数据的形态。方法用对了，用例数量可控且覆盖有效；方法混用或只用一种，容易出现漏测或大量冗余。下面按输入类型说明方法选用条件，再给出单条用例的写法要求。
按输入类型选择设计方法
| 输入特征 | 推荐方法 | 适用说明 |
|---|---|---|
| 输入域可划分为若干有效/无效区间 | 等价类划分 | 每个等价类取一个代表值，减少重复用例 |
| 输入有明确的数值或长度上下限 | 边界值分析 | 取边界值、边界内侧与外侧值，常与等价类配合 |
| 业务由多步骤流程构成 | 场景法 | 覆盖主成功路径与关键分支、异常中断 |
| 多个条件组合决定不同结果 | 判定表 | 梳理条件与动作的对应关系，避免组合遗漏 |
| 状态随操作迁移 | 状态迁移法 | 覆盖合法迁移与非法迁移 |
实际工作中通常组合使用：先用场景法梳理主流程，再对流程中的关键输入用等价类和边界值细化，对复杂规则用判定表校验组合覆盖。方法选择应记录在设计规范中，便于评审时判断覆盖是否合理。
前置条件、操作步骤与预期结果的写法
一条可执行的用例，读者应能在不询问作者的情况下独立执行。写法要求如下：
- 前置条件：写清执行前必须满足的数据状态、账号权限、环境配置。例如“已存在一个待支付订单，账户余额充足”。
- 操作步骤：按顺序编号，每步只做一个动作，写明操作对象和输入值。避免“进行相关操作”这类模糊表述。
- 预期结果：与步骤对应，写可观察的结果，包括页面提示、数据变化、状态流转。涉及多条预期时逐条列出。
示例用例（演示情景）：
| 字段 | 内容 |
|---|---|
| 用例编号 | TC-ORDER-014 |
| 标题 | 订单金额等于账户余额时提交订单成功 |
| 前置条件 | 账户余额为 100 元；购物车中有一件 100 元商品 |
| 步骤 | 1. 进入结算页；2. 选择余额支付；3. 点击提交订单 |
| 预期结果 | 1. 结算页显示应付 100 元；2. 提交后订单状态为“已支付”；3. 账户余额变为 0 元 |
用例粒度与命名规范
粒度以“一个用例验证一个明确的检查点”为宜。把多个检查点塞进一条用例，失败时难以定位问题；拆得过细，又会造成维护负担。命名采用“对象+条件+预期”的结构，例如“订单金额等于余额时提交成功”，让标题本身就能说明验证意图。同一模块的用例编号保持连续，便于检索和引用。
用例字段与模板：统一结构才能评审和维护
字段统一是用例可评审、可统计、可维护的前提。字段过多会增加填写负担，过少则无法支撑执行与追溯。建议区分必填与选填，并按团队实际裁剪。
用例字段表
| 字段 | 必填/选填 | 填写要求 |
|---|---|---|
| 用例编号 | 必填 | 按模块前缀+序号，全局唯一 |
| 标题 | 必填 | 对象+条件+预期，一句话说清验证点 |
| 所属模块 | 必填 | 对应范围清单中的模块条目 |
| 关联需求 | 必填 | 填写需求编号，保证可追溯 |
| 优先级 | 必填 | P0/P1/P2，与覆盖优先级表一致 |
| 前置条件 | 必填 | 数据状态、权限、环境 |
| 操作步骤 | 必填 | 编号分步，每步一个动作 |
| 预期结果 | 必填 | 与步骤对应，可观察 |
| 设计方法 | 选填 | 标注等价类、边界值等，便于评审覆盖 |
| 测试数据 | 选填 | 具体输入值或数据构造说明 |
| 备注 | 选填 | 特殊说明、依赖项 |
模板调整与维护方式
模板不是一次定终身。建议在项目复盘时检查字段使用情况：长期空置的选填字段考虑删除，频繁补填的信息考虑转为必填。模板变更需同步更新设计规范，并对存量用例做一次批量补齐，避免新旧字段并存导致统计口径不一致。空白模板可直接以上表为骨架，复制到团队的用例管理工具或表格中启用。
评审与角色分工：谁写、谁审、谁维护
用例是团队协作产物，角色不清会导致“写完没人看、改完没人知”。明确职责与评审机制，能让用例在进入执行前就获得质量保障。
角色职责表
| 角色 | 主要职责 |
|---|---|
| 测试工程师 | 依据范围清单设计用例，维护用例内容，执行并记录结果 |
| 开发工程师 | 评审技术相关用例（接口、异常、数据约束），确认可实现性 |
| 产品经理 | 评审业务规则与验收标准覆盖是否完整，确认优先级 |
| 测试负责人 | 组织评审、把关设计规范执行、维护用例台账 |
小团队可由一人兼多个角色，但评审环节建议保留至少一名非作者参与，避免自写自审。
评审时点与检查项
评审安排在用例初稿完成、进入执行之前。检查项包括：
- 覆盖度：范围清单中的 P0、P1 条目是否都有对应用例，主流程与关键异常是否覆盖。
- 可执行性：前置条件是否充分，步骤是否可独立执行，预期结果是否可观察。
- 一致性：字段是否填全，优先级是否与覆盖表一致，命名是否符合规范。
- 冗余度：是否存在重复验证同一检查点的用例。
评审不通过的处理方式
评审意见逐条记录在评审记录中，标注问题类型（遗漏、描述不清、优先级错误等）和责任人。作者修订后由评审发起人复核，复核通过才进入执行。对存在分歧的用例，以需求文档和验收标准为准，必要时请产品经理确认后更新需求说明，再同步修订用例。
当用例需要与需求、任务关联并在团队间流转时，可以借助 ONES TestCase 承载：它支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例属性可自定义，用例库中的属性支持筛选，便于按模块、优先级快速定位待评审或待执行的用例。
执行、变更与维护：让用例跟得上需求
用例写完只是开始。执行记录、变更响应和定期清理，决定了用例库长期是否可信。
执行结果记录与缺陷关联
每次执行都要记录结果状态（通过、失败、阻塞、未执行）和执行人、执行时间、对应版本。失败的用例应关联缺陷单，缺陷修复后回到原用例复测，形成“用例—缺陷—复测”的闭环。这样在回归时能直接依据历史失败记录确定重点范围。ONES TestCase 中未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，减少手工转录。
需求变更触发的用例更新流程
需求变更时，按以下顺序处理：
- 根据用例的“关联需求”字段定位受影响用例。
- 判断变更类型：新增规则则补充用例，规则调整则修改预期结果，功能下线则标记失效。
- 更新用例后在变更记录中登记变更原因、变更人和日期。
- 同步通知执行人员，避免用旧用例得出错误结论。
定期清理与失效用例处理
建议每个迭代或每个季度做一次用例巡检，处理三类情况：长期未执行且无对应需求的用例标记为失效；重复验证同一检查点的用例合并；描述过时、无法执行的用例修订或删除。失效用例不直接物理删除，先归档保留一段时间，便于追溯历史测试范围。维护台账记录每次清理的范围和结论。
完成检查：用例设计与管理是否到位
以下清单可用于自查或评审验收，逐项核对并保留证据。
| 检查项 | 通过标准 | 证据 |
|---|---|---|
| 范围覆盖 | P0、P1 条目均有对应用例，主流程与关键异常覆盖 | 范围清单与用例关联记录 |
| 可执行性 | 随机抽取用例，执行人无需询问即可完成 | 抽查记录 |
| 字段完整 | 必填字段无空缺，优先级与覆盖表一致 | 用例库字段统计 |
| 评审闭环 | 评审意见均有处理结论和复核记录 | 评审记录 |
| 执行可追溯 | 执行结果有状态、执行人和版本，失败用例关联缺陷 | 执行记录与缺陷单 |
| 变更可追踪 | 需求变更后受影响用例已更新并登记 | 变更记录 |
| 维护有节奏 | 按周期完成巡检，失效用例已归档 | 维护台账 |
出现以下情况应阻断进入下一阶段并返工：P0 条目存在无对应用例的遗漏；必填字段大面积空缺导致无法统计；评审意见未闭环即开始执行；需求变更后仍用旧用例出具测试结论。返工完成后重新核对本清单，确认通过再推进。
常见问题
需求文档写得很粗，用例设计还能开展吗？
可以开展，但需要先补齐输入。做法是把需求文档、原型、接口说明和历史缺陷放在一起对照，对描述不清的规则逐条列出待确认问题，在需求评审或与产品经理确认后再定稿范围清单。确认前可以先写主流程用例，把依赖未定规则的异常场景标记为待补充，避免凭猜测写出错误预期结果。
用例评审时开发和产品参与度不高，怎么处理？
先缩小评审范围，把评审材料从全部用例改为范围清单、P0 用例和涉及业务规则或技术约束的关键用例，降低参与成本。评审前把检查项和待确认问题发给参与者，评审中只处理分歧和遗漏，其余意见书面记录。评审记录中标注每条意见的责任人和处理结论，复核通过后再进入执行，让参与者的投入有明确产出。
用例数量很多，维护成本高，如何控制？
从源头控制冗余：同一检查点只保留一条用例，等价类取代表值，低优先级模块只覆盖主流程。维护阶段按周期巡检，合并重复用例，把长期未执行且无对应需求的用例标记失效并归档。字段层面删掉长期空置的选填项，减少填写负担。用例与需求保持关联，需求变更时能定位受影响范围，避免全量重写。
用例和缺陷、需求之间怎么保持可追溯？
在用例上保留“关联需求”字段，执行失败时关联缺陷单，缺陷修复后回到原用例复测，形成用例、缺陷、复测的闭环。需求变更时通过关联需求字段反查受影响用例，更新后登记变更原因和日期。使用 ONES TestCase 时，用例可与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，减少手工转录。
团队规模小，角色分工和评审流程可以简化吗？
可以简化角色数量，一人可兼测试设计与执行，但评审环节建议保留至少一名非作者参与，避免自写自审。评审范围可压缩到 P0 用例和范围清单，检查项保留覆盖度、可执行性和字段完整性三项。维护节奏可按迭代而非固定季度执行，重点是变更后及时更新用例并留下记录。
