测试用例设计的目标，是产出一份他人能独立执行、并能追溯到需求或风险的用例集。做法上，从需求与风险出发确定测试点，再用等价类、边界值、场景法等方法展开为具体用例，写明前置条件、操作步骤、预期结果和优先级，最后通过自检与同行评审控制质量。本文按设计前输入、五步流程、字段模板、角色分工、完整示例和完成检查的顺序展开，适用于单个需求或版本的用例设计。
要点总览（TL;DR）
- 设计前先收集需求文档、原型、接口说明和历史缺陷，并用两句话写清本次覆盖与不覆盖的范围，完成标准是每条用例可独立执行、可追溯、关键风险有覆盖。
- 按五步推进：拆解需求列测试点、按风险排优先级、用等价类/边界值/场景法/状态迁移展开用例、补齐字段、自检与同行评审。
- 字段模板的核心是前置条件、具体测试数据、编号步骤与可观察的预期结果一一对应，一条用例只验证一个明确目标。
- 设计者出初稿，需求与开发角色确认规则和约束，同行评审检查覆盖与可执行性，原设计者通常兼任变更后的维护责任人。
- 提交评审前按覆盖、可执行、预期结果、优先级与数据、一致性、变更同步六项清单自检，全部通过再进入执行。
测试用例设计先定什么：输入、范围与完成标准
开始写用例之前，先把材料收集齐、把边界划清楚。否则容易出现两种情况：一是漏掉某份接口说明里的异常分支，二是把不属于本次范围的兼容性测试也写进来，导致用例集臃肿且无法验收。
设计输入清单
以下材料按优先级排列，能拿到的尽量拿到，缺失的要在范围说明中标注并说明替代依据：
- 需求文档与验收标准：确定业务规则、输入约束和正常流程。
- 原型或设计稿：确定界面元素、交互反馈和提示文案，用于写可观察的预期结果。
- 接口说明：确定参数取值范围、必填项、错误码，是边界值和异常用例的主要来源。
- 历史缺陷记录：同类功能过去出过的问题，往往对应高风险测试点。
- 业务规则与配置说明：如锁定策略、权限规则、限额规则，决定状态迁移和组合场景。
范围说明怎么写
范围说明用两句话即可：本次覆盖哪些功能模块、哪些测试类型（功能、异常、边界、状态流转）；本次不覆盖哪些内容（如性能压测、跨浏览器兼容、历史数据迁移），并注明由谁在哪个阶段负责。把“不测范围”写出来，比只写“测什么”更能减少后续争议。
完成标准
用例设计完成的判定可以归纳为三条：每条用例可被未参与设计的同事按步骤独立执行；每条用例能关联到具体需求条目或已识别的风险点；关键风险均有对应用例，且优先级标注完整。这三条同时成立，才进入评审环节。
从测试点到用例：五步设计流程
五步流程的作用是把“读需求”变成“可交付的用例集”，每一步都有明确输入和输出，便于判断进度。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 拆解需求，列出测试点 | 需求文档、原型、接口说明 | 按功能模块逐条阅读，把每条业务规则转成一个可验证的测试点，标注来源 | 测试点清单 | 每条需求至少对应一个测试点，无来源不明的测试点 |
| 2. 排优先级 | 测试点清单、历史缺陷、业务影响 | 按“出错后果严重程度×发生可能性”排序，标记高、中、低 | 带优先级的测试点清单 | 核心流程与高风险点均为高优先级 |
| 3. 选方法展开用例 | 带优先级的测试点 | 对输入域用等价类与边界值，对业务流程用场景法，对多状态对象用状态迁移法 | 用例草稿 | 每个测试点至少展开一条用例，边界与异常分支有覆盖 |
| 4. 编写字段 | 用例草稿、测试数据 | 补齐前置条件、步骤、预期结果、测试数据、优先级 | 完整用例条目 | 字段无空缺，预期结果可观察 |
| 5. 自检与评审 | 完整用例条目 | 先按检查清单自检，再提交同行评审，记录修改意见并闭环 | 评审通过的用例集 | 评审意见全部处理完毕 |
第三步的方法选择需要说明：等价类用于把大量输入归并为有效类和无效类，每类取代表值；边界值针对取值范围的两端及临界点，如长度上限、金额下限；场景法按用户实际操作路径串联多个功能点，覆盖基本流与备选流；状态迁移法适用于订单、账号、审批单这类有明确状态的对象，重点覆盖合法迁移与非法迁移。一个测试点可以用一种方法展开，也可以组合使用，例如“密码错误”既可用等价类取一个错误值，也可用边界值测试连续错误次数。
用例字段怎么写：模板与填写要点
字段结构决定了用例能否被独立执行。下面是一份可直接套用的字段模板，按此结构填写即可满足大多数功能测试场景。
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 用例编号 | 按模块加序号，保持唯一，便于引用和缺陷关联 | 编号重复或随意变更 |
| 用例标题 | 一句话说明“在什么条件下验证什么”，包含对象与动作 | 只写“登录测试”，无法区分场景 |
| 关联需求/风险 | 填写需求条目编号或风险点描述 | 留空，导致覆盖情况无法核对 |
| 优先级 | 高：核心流程与高风险；中：常用分支；低：边缘场景 | 全部标为高，失去排序意义 |
| 前置条件 | 执行前必须存在的状态，如账号已注册、余额为指定值、处于某状态 | 把操作步骤写进前置条件 |
| 测试数据 | 给出具体值或取值规则，如“密码为 8 位含字母数字” | 写“输入合法密码”，执行者无法判断 |
| 操作步骤 | 按执行顺序编号，每步一个动作 | 一步包含多个操作，失败时难以定位 |
| 预期结果 | 与步骤对应，描述可观察的界面反馈、数据变化或提示信息 | 写“系统正常处理”，无法判定通过与否 |
关于粒度，一条用例验证一个明确目标。把“登录成功”和“登录失败提示”拆成两条，失败时能直接定位问题；合并成一条则只能知道“登录有问题”。预期结果要写到可判定的程度，例如“页面跳转至首页，右上角显示当前用户名”，而不是“登录成功”。测试数据尽量具体，涉及金额、日期、长度的，直接给出数值。
角色与交付物：谁设计、谁评审、谁维护
职责不清是用例质量波动的常见原因。设计、评审、维护三个环节各自有明确的责任人和交付物，可以用一张表固定下来。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试设计者 | 拆解需求、列测试点、展开用例、完成自检 | 用例初稿、测试点清单 |
| 需求角色（产品/业务） | 确认业务规则、验收标准与异常处理口径 | 规则确认结论、需求澄清记录 |
| 开发角色 | 确认技术约束、接口参数范围与错误码 | 接口与约束说明补充 |
| 评审人（同行测试） | 检查覆盖完整性、步骤可执行性、预期结果可判定性 | 评审意见清单 |
| 维护责任人 | 需求变更后更新受影响用例，标记失效用例 | 更新后的用例集、变更记录 |
小团队中需求确认和评审可能由同一人承担，此时仍建议把“规则确认”和“覆盖检查”分开记录，避免自己确认自己评审。维护责任人通常由原设计者担任，需求变更时由需求角色触发通知，维护责任人判断影响范围并更新用例。
当用例需要与需求条目、研发任务保持关联，并让评审意见在测试与研发之间流转时，可以把这些管理动作放到研发管理工具中承载。ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例属性可自定义，用例库中的属性支持筛选，便于按需求或优先级定位待评审的用例。具体字段与关联范围以实际版本配置为准。
示例：一条登录用例从测试点到可执行用例
以下为演示情景，用于说明从测试点展开到完整用例的过程，不代表任何真实项目。
需求要点：用户使用账号密码登录；连续输错 5 次锁定账号 30 分钟；锁定期间正确密码也不可登录。据此列出三个测试点：账号密码正确、密码错误、账号锁定。
| 用例编号 | 标题 | 前置条件 | 测试数据 | 操作步骤 | 预期结果 | 优先级 |
|---|---|---|---|---|---|---|
| LOGIN-001 | 正确账号密码登录成功 | 账号已注册且未锁定 | 账号 test01，密码 Abc12345 | 1. 打开登录页；2. 输入账号密码；3. 点击登录 | 跳转至首页，右上角显示 test01 | 高 |
| LOGIN-002 | 密码错误时提示且不登录 | 账号已注册且未锁定 | 账号 test01，密码 Abc1234（少一位） | 1. 打开登录页；2. 输入账号与错误密码；3. 点击登录 | 停留登录页，提示“账号或密码错误”，错误次数变为 1 | 高 |
| LOGIN-003 | 连续 5 次密码错误后账号锁定 | 账号已注册，错误次数为 4 | 账号 test01，错误密码 | 1. 输入错误密码并登录；2. 再次输入正确密码登录 | 第 5 次错误后提示账号已锁定；随后正确密码登录被拒绝并提示锁定剩余时间 | 高 |
拆分理由：LOGIN-001 验证基本流，作为冒烟用例；LOGIN-002 用等价类取无效输入的代表值，同时验证错误计数这一可观察结果；LOGIN-003 覆盖边界（第 5 次）与状态迁移（正常→锁定），并把“锁定期间正确密码也失败”作为预期结果写入，避免执行者误判。三条用例的前置条件逐条递进，执行者不需要额外推断。
完成检查：用例质量的自检与评审清单
提交评审前先自检，评审时按同一份清单核对，可以减少来回修改。以下清单可逐项打勾，全部通过即视为本次设计完成。
- 覆盖检查：每条需求条目和每个已识别风险都有对应用例；异常分支与边界值有覆盖；无关联需求的用例已说明来源。
- 可执行检查：未参与设计的同事按步骤能独立执行，不需要口头补充信息；前置条件与测试数据足以复现场景。
- 预期结果检查：每条预期结果描述的是可观察的界面反馈、数据变化或提示信息，能明确判定通过或失败。
- 优先级与数据检查：高优先级用例覆盖核心流程与高风险点；测试数据为具体值或明确取值规则。
- 一致性检查：用例标题与步骤描述同一目标；步骤与预期结果一一对应，无遗漏步骤。
- 变更同步检查：需求变更后，受影响的用例已更新，失效用例已标记或移除，并留有变更记录。
评审意见处理完毕后，用例集即可作为本次设计的交付物进入执行阶段。执行中发现的用例缺陷（如步骤缺失、预期结果错误）应回写到用例本身，使用例集在后续版本中持续可用。
常见问题
需求文档写得很粗，只有一句话描述，用例还能设计吗？
可以，但需要先把这句话拆成可验证的规则。做法是列出这句话隐含的输入、处理、输出和异常：输入有哪些字段、取值范围是什么、成功后系统状态如何变化、失败时给什么提示。拿不准的部分向产品或业务角色确认，把确认结论记录在需求澄清记录里，再转成测试点。
如果关键规则始终无法确认，不要用猜测填满用例，而是在范围说明中标注该部分待定，并写明依据哪一版理解设计、后续由谁补充。这样评审时能明确知道哪些用例需要复核。
用例评审应该什么时候做，是全部写完再评审还是分批评审？
建议分两批。第一批在测试点清单完成后评审，重点看覆盖是否完整、优先级排序是否合理，此时修改成本最低。第二批在用例字段填写完成后评审，重点看步骤可执行性和预期结果可判定性。
需求较大时，可以按功能模块分批提交第二批评审，每个模块的用例写完即评审，避免全部堆到最后集中返工。评审意见要逐条记录处理结论，未闭环的意见不作为通过依据。
需求在用例写完后发生变更，已经写好的用例怎么处理？
由需求角色发出变更通知，维护责任人判断影响范围，分三类处理：受影响的用例直接更新步骤与预期结果；不再适用的用例标记失效或移除，保留变更记录；新增规则补充新用例，并关联到对应需求条目。
更新后要重新核对覆盖情况，确认变更引入的异常分支也有用例。变更记录建议保留原用例编号，便于追溯某个缺陷对应的是哪一版用例。
用例数量多少算合适，是不是越多覆盖越全？
用例数量由测试点和风险决定，不由指标决定。判断标准是每条需求条目和每个已识别风险都有对应用例，异常分支与边界值有覆盖，同时没有重复验证同一条件的冗余条目。
如果发现大量用例只在测试数据上不同，可以用等价类合并为一条并注明取值规则；如果一条用例包含多个验证目标，则应拆开。数量本身不构成质量结论，覆盖是否完整、能否独立执行才是判定依据。
用例设计和评审的成果，怎么和需求、缺陷保持关联？
通用做法是在用例条目上填写关联需求编号或风险点描述，执行失败时从用例直接创建缺陷并保留来源用例编号。这样需求变更时能反查受影响用例，缺陷复盘时也能看到对应用例是否缺失。
当这类关联和评审流转需要跨测试与研发协同管理时，可以放到研发管理工具中承载。ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性可自定义且用例库属性支持筛选，便于按需求或优先级定位待评审的用例；具体字段与关联范围以实际版本配置为准。
