测试用例设计从需求分析开始：先把需求拆成可测的输入条件、业务规则和状态变化，再按场景选择等价类划分、边界值分析、决策表或状态迁移等方法生成用例，补齐前置条件、步骤、预期结果和优先级，最后经过同行评审与需求追溯确认覆盖完整。本文按设计流程展开方法选择、用例编写、评审、维护和交付前核对，帮助你把零散的操作记录整理成一份可执行、可评审、可追溯的用例集。
要点总览（TL;DR）
- 设计起点是需求分析：把需求拆成输入域、业务规则、状态流转和异常分支，形成带来源与优先级的可测条件清单。
- 方法按条件形态选：取值范围用等价类与边界值，多条件组合用决策表，有状态流转用状态迁移，组合使用并控制用例数量。
- 一条用例要写清编号、标题、前置条件、步骤、预期结果、优先级和分类标签，步骤与预期结果逐条对应，预期写具体值。
- 评审由设计者、需求方、开发和测试负责人参与，以覆盖完整性、可执行性、预期明确性、冗余和追溯为检查项，阻断项清零才通过。
- 交付前核对覆盖与追溯、字段完整性、可执行性、评审记录和版本责任人，确认后进入执行，执行中发现的问题按维护规则回流。
测试用例设计先做什么：从需求到可测条件
动手写用例之前，先完成需求分析。设计者需要把需求文档、原型、接口说明和业务规则放在一起读，找出哪些内容可以被验证，哪些内容还存在歧义。这一步的产物是一份可测条件清单，它决定了后续选用哪些设计方法，也决定了用例集能否覆盖真正的风险点。
拆解需求时，可以按四个维度逐条过一遍：
- 输入域：每个输入字段的取值范围、类型、长度、是否必填、是否允许为空，以及多个输入之间的关联。
- 业务规则：金额计算、权限判断、审批流转、优惠叠加等有明确判断逻辑的规则，逐条列出条件与结果。
- 状态与流转：业务对象有哪些状态，什么事件触发状态变化，哪些状态之间不允许跳转。
- 异常分支：超时、重复提交、并发操作、数据不存在、外部依赖失败等非正常路径。
识别出的每条可测条件都应标注来源（需求条目编号或原型位置）、优先级和待确认项。优先级可以按业务影响和发生概率划分：核心交易路径、资金与权限相关规则列为高优先级；提示文案、非关键展示列为低优先级。待确认项单独记录，例如需求未说明某个字段为空时的处理方式，这类问题应在设计前向需求方澄清，避免把猜测写进预期结果。
同时要明确不测范围和依赖前提。不测范围包括本期需求未涉及的旧功能、明确由其他系统保证的能力；依赖前提包括测试环境、测试数据、账号权限、外部接口是否可用。把这些写清楚，评审时才能判断用例集边界是否合理。完成标志是：每条需求都能对应到至少一条可测条件，且没有来源不明的条件。
按场景选择设计方法：等价类、边界值、决策表与状态迁移
不同需求片段适合不同的设计方法。选方法的依据是可测条件的形态：取值范围用等价类和边界值，多条件组合用决策表，有状态流转的用状态迁移。实际项目中通常组合使用，先用等价类划分缩小取值空间，再对关键边界补充用例，最后用决策表或状态迁移覆盖规则和流程。
| 方法 | 适用场景 | 设计动作 | 覆盖目标 |
|---|---|---|---|
| 等价类划分 | 输入有明确取值范围或类型约束，如年龄、金额、文件格式 | 把输入划分为有效类和无效类，每类选取代表性取值 | 每个有效类和无效类至少一条用例 |
| 边界值分析 | 取值存在上下限、长度限制、数量阈值 | 取边界点、边界内侧、边界外侧的值，关注临界组合 | 最小值、最大值、刚超出边界的值均被覆盖 |
| 决策表 | 多个条件共同决定结果，如折扣规则、权限组合、审批条件 | 列出条件桩与动作桩，枚举条件组合并标注对应结果 | 每条有效规则至少一条用例，冲突组合有明确处理 |
| 状态迁移 | 业务对象有明确状态和事件驱动，如订单、工单、审批单 | 画出状态与事件，标注合法迁移和非法迁移 | 合法迁移全部覆盖，关键非法迁移有校验用例 |
方法组合时要控制用例数量。等价类划分后，无效类往往只需少量代表值；边界值只对高风险字段展开，不必对所有数值字段都做完整边界组合。决策表中条件过多时，可以合并对结果无影响的组合，保留能区分结果的规则。状态迁移图完成后，优先覆盖主流程和回退路径，再补充异常事件。判断用例数量是否合理的标准是：每条用例都能说明它验证了哪条可测条件，删掉后会出现覆盖缺口。
以一个订单折扣需求为例：订单金额满减属于边界值场景，会员等级与优惠券叠加属于决策表场景，订单从待支付到已支付、已取消属于状态迁移场景。三类方法分别产出用例，再统一编号归入同一用例集，避免重复设计同一条件。
用例编写：字段、步骤与预期结果的写法
一条合格的测试用例应当让不了解需求背景的执行者也能独立操作并判断结果。字段齐全、步骤与预期结果一一对应，是用例可执行的基本要求。
| 字段 | 填写要求 |
|---|---|
| 用例编号 | 按模块或需求编号加序号，保持全局唯一，便于追溯和引用 |
| 标题 | 用“操作对象＋操作＋预期结果”的结构描述，避免“测试登录”这类笼统写法 |
| 前置条件 | 执行前必须满足的数据、账号、环境、状态，写具体值而非“已登录” |
| 测试步骤 | 按执行顺序编号，每步一个动作，包含输入数据 |
| 预期结果 | 与步骤对应，写可观察的界面、数据或状态变化 |
| 优先级 | 高、中、低，与可测条件的优先级保持一致 |
| 分类标签 | 模块、用例类型（功能、异常、权限）、关联需求编号 |
步骤与预期结果建议逐条对应：第几步操作，就写该步完成后应看到什么。对于需要多步才能产生结果的流程，可以在关键步骤后写中间预期，最后一步写最终预期。预期结果要写具体值，例如“订单状态变为已支付，支付时间显示为当前时间”，避免“显示正常”“操作成功”这类无法判定的表述。
数据准备和环境写在执行前说明中：需要哪些测试账号、初始数据处于什么状态、是否依赖外部接口。数据尽量写成可直接使用的具体值，例如“账号 A 余额 100 元，优惠券 B 满 100 减 20，有效期至本月底”。标题命名统一结构后，分类标签用于筛选和统计，标签体系在项目内保持一致，不要同一模块出现多种叫法。
填写示例：编号 TC-ORDER-012，标题“订单金额为 100 元时使用满 100 减 20 优惠券，应付金额为 80 元”，前置条件“账号 A 已登录，购物车含一件 100 元商品，账户持有一张满 100 减 20 优惠券”，步骤为“1. 进入结算页；2. 选择该优惠券；3. 提交订单”，预期结果为“1. 结算页显示优惠 20 元；2. 应付金额显示 80 元；3. 订单创建成功，状态为待支付，优惠金额记录为 20 元”。
用例评审与质量检查：谁参与、查什么、怎么判通过
用例评审的目标是在执行前发现覆盖缺口和表述问题，降低返工成本。评审应由设计者发起，需求方、开发和测试负责人共同参与：需求方确认业务规则和预期结果是否符合原意，开发确认技术实现路径和异常处理是否被覆盖，测试负责人检查设计方法和覆盖完整性。
评审检查项可以固化为一张检查表：
- 覆盖完整性：每条可测条件是否有对应用例，有效类、无效类、边界、规则组合和状态迁移是否覆盖。
- 可执行性：前置条件是否具体，步骤是否可独立操作，数据是否可直接使用。
- 预期结果明确性：是否写具体值或可观察状态，是否存在“正常”“正确”等模糊表述。
- 重复与冗余：是否存在验证同一条件、步骤高度相似的用例，能否合并。
- 追溯关系：用例是否关联需求编号，未覆盖的需求是否有说明。
评审记录要落到具体条目：问题描述、涉及用例编号、提出人、修改责任人和关闭状态。修改完成后由提出人确认关闭，形成闭环。通过标准可以设为：高优先级可测条件全部有用例覆盖，阻断项为零，遗留问题已记录并约定处理时间。阻断项通常包括核心流程无用例、预期结果无法判定、需求歧义未澄清；存在阻断项时评审不通过，修改后重新确认。
当用例数量较多、参与角色分散时，评审记录和修改状态容易散落在聊天工具里。ONES 的测试管理支持将用例与需求关联，评审意见可以记录在工作项中并跟踪到关闭，版本变化也能在系统中留痕，便于测试负责人统一确认通过状态。
用例维护与版本：变更时如何同步更新
用例集在首次评审通过后进入维护阶段。需求变更、缺陷修复和回归测试都会带来更新，维护动作要有触发条件和责任人，避免用例逐渐与系统实际行为脱节。
需求变更触发更新时，先由需求方或产品负责人标记变更影响的需求条目，测试设计者据此定位关联用例，判断是修改预期结果、增加新用例还是标记失效。变更完成后更新用例版本，并在变更记录中写明变更原因、影响范围和修改人。缺陷回归后补充用例的规则是：缺陷属于已有用例未覆盖的场景时，新增用例并关联缺陷编号；缺陷属于用例预期结果写错时，修正原用例并记录修正原因。两类情况都应进入下一轮回归范围。
版本管理建议以基线为单位：每个发布版本对应一个用例基线，基线内的用例编号和内容冻结，后续修改产生新版本。失效用例不直接删除，标记为失效并注明原因和替代用例，归档保留以便追溯历史版本的测试范围。用例变更记录表至少包含变更日期、用例编号、变更类型、变更说明、关联需求或缺陷、修改人和确认人。
完成检查：用例集交付前的核对清单
用例集交付前，按以下清单逐项核对，全部满足后再进入执行或移交环节。
- 覆盖与追溯：每条可测条件都有对应用例；高优先级条件无遗漏；用例与需求编号的关联完整；未覆盖项有书面说明。
- 字段完整性：编号、标题、前置条件、步骤、预期结果、优先级、分类标签均已填写；步骤与预期结果逐条对应；无模糊表述。
- 可执行性：测试数据具体可用；环境与依赖前提已说明；执行者无需额外询问即可操作。
- 评审记录：评审已开展，参与角色齐全；阻断项已清零；遗留问题有责任人和处理时间。
- 版本与责任人：用例集版本号与基线一致；变更记录完整；用例集负责人和评审确认人已明确。
核对完成后，由测试负责人确认交付，用例集进入执行阶段。执行中发现的新问题按维护规则回流到用例集，形成设计、评审、执行、维护的循环。
常见问题
需求文档写得很粗，可测条件拆不出来怎么办？
先把需求拆到能判断对错的粒度，再谈设计方法。具体做法是把需求条目逐条转成“输入—规则—结果”的描述，遇到缺失的处理方式单独列为待确认项，向需求方或产品负责人澄清后再写入预期结果。对于原型和接口说明能补充的部分，以这些材料为准交叉核对。可测条件清单允许存在待确认项，但每条都要有来源和责任人，避免把猜测当成需求事实。
用例数量太多执行不完，应该优先保留哪些？
按风险取舍，而不是按方法数量取舍。高优先级可测条件——核心交易路径、资金与权限规则、关键状态流转——必须保留对应用例；低优先级的提示文案、非关键展示可以合并或抽样。等价类划分后无效类保留代表值即可，边界值只对高风险字段展开完整组合。判断标准是每条用例能说明它验证了哪条可测条件，删掉后是否出现覆盖缺口；有缺口的用例不能删，只能调整执行批次。
评审时需求方和开发意见不一致，以谁为准？
以需求原意为准，由需求方对业务规则和预期结果做最终确认；开发的意见用于判断技术实现路径和异常处理是否被覆盖，属于补充而非替代。出现分歧时，把争议点写成具体条目：涉及哪条可测条件、双方各自的理解、影响哪些用例，然后回到需求文档或原型找依据。文档也无法判定的，记录为待确认项并约定澄清时间，在澄清前不把任何一方的理解写成确定预期。
需求变更后，旧用例是直接删除还是保留？
建议标记失效并归档，不直接删除。删除会丢失历史版本的测试范围，后续追溯“某个版本测了什么”时无从查起。做法是把失效用例标记状态、注明失效原因和替代用例编号，保留在原基线中；新用例进入新版本基线。这样版本对比时能看出哪些用例被替换、哪些是新增，回归范围也更容易界定。
用例评审记录和修改状态用什么方式管理比较稳妥？
关键是让每条意见都能追到关闭状态。记录至少包含问题描述、涉及用例编号、提出人、修改责任人和关闭状态，修改完成后由提出人确认关闭。参与角色分散、用例数量较多时，可以把评审意见和用例关联起来统一跟踪，避免散落在聊天工具里。ONES 的测试管理支持用例与需求关联，评审意见可记录在工作项中跟踪到关闭，版本变化在系统中留痕，便于测试负责人确认通过状态。
