测试用例设计可以按“分析—设计—编写—评审—维护”五个阶段推进：先从需求、原型和接口说明中拆出功能点、业务规则与风险，形成带优先级的测试点清单；再按输入条件选择等价类、边界值、决策表或状态迁移等方法推导测试点；然后把每个测试点写成有前置条件、操作步骤、测试数据和可判断预期结果的用例；最后经评审、修订和基线化后进入执行。下面按这五个阶段给出具体动作、产物和完成标准。
要点总览（TL;DR）
- 测试用例设计从测试分析开始：收集需求、原型、接口说明，拆出功能点、业务规则和风险点，形成带优先级的测试点清单。
- 设计方法按输入条件选择：单字段取值范围用等价类和边界值，多条件组合用决策表，有生命周期状态的对象用状态迁移，通常组合使用。
- 编写时一条用例对应一个验证目标，写清前置条件、操作步骤、具体测试数据和可判断的预期结果，编号与标题保持唯一。
- 评审关注覆盖度、可执行性、预期明确性和冗余，通过后基线化；后续变更从基线发起，保留版本和变更记录。
- 完成检查清单全部满足后，用例才进入执行阶段，执行中发现的问题回流到用例维护。
先做测试分析：从需求到测试点
用例设计的第一步是测试分析，产物是一份可评审的测试点清单。测试点描述“要验证什么”，暂不展开具体操作步骤。缺少这一步，后续容易按页面或按字段平铺用例，覆盖看似很多，关键规则和异常路径却漏掉。
输入材料通常包括需求文档或用户故事、交互原型、接口说明、数据字典、历史缺陷记录和相关业务规则说明。收集时逐项确认版本和适用范围，把口头补充的规则记录到需求或测试点清单中，避免只存在于个别人记忆里。
拆解按以下顺序进行：
- 识别功能点：把需求拆成用户可感知的功能或系统可处理的能力，例如“提交订单”“计算运费”“修改收货地址”。
- 提取业务规则：记录每个功能点背后的判断条件、计算口径、权限限制和状态约束，例如“满99元包邮”“仅待支付订单可取消”。
- 标注风险点：结合规则复杂度、变更频率、历史缺陷、资金与数据影响，标出容易出错或出错代价高的位置。
- 确定范围与优先级：明确本次测什么、不测什么；按风险等级和业务重要性把测试点分为高、中、低优先级，高优先级测试点优先保证覆盖。
测试点清单建议包含编号、所属功能、测试点描述、来源需求、风险等级、优先级和备注。清单完成后由测试负责人与产品、开发对齐一次，确认没有理解偏差，再进入设计方法选择。
按条件选设计方法：等价类、边界值、决策表与状态迁移
设计方法的选择取决于输入条件的形态：单个字段的取值范围用等价类和边界值，多个条件组合决定不同结果用决策表，业务对象有明确状态和流转规则用状态迁移。实际工作中通常组合使用，先用等价类和边界值处理单字段，再用决策表或状态迁移补齐组合与流程。
| 方法 | 适用条件 | 操作步骤 | 输出 |
|---|---|---|---|
| 等价类划分 | 输入有取值范围或类别，无法穷举 | 划分有效类和无效类，每类取代表值 | 有效、无效输入的代表值集合 |
| 边界值分析 | 输入或输出存在上下限、长度、数量边界 | 取边界点及其两侧邻近值 | 边界及边界附近的测试数据 |
| 决策表 | 多个条件组合对应不同处理结果 | 列出条件桩与动作桩，枚举组合并化简 | 条件组合与预期动作的对应表 |
| 状态迁移 | 对象有明确状态和允许的流转 | 画状态图，列出事件、迁移和非法迁移 | 合法与非法状态迁移的测试点 |
等价类划分时，先确定每个输入项的取值域，再划分有效等价类和无效等价类。有效类覆盖正常业务，无效类覆盖非法输入、空值、超长、类型错误等情况。无效类通常一次只取一个，避免多个错误叠加导致无法判断是哪个条件触发的结果。
边界值在等价类基础上取值，常见取法是上点、下点和内点，例如范围1到100，取0、1、2、99、100、101。长度、金额精度、分页数量、时间区间同样适用。边界值测试点要写清具体数据和预期处理结果。
决策表适合条件组合影响结果的场景。先列出所有条件及其取值，再列出对应动作，枚举组合后合并结果相同的规则，删去不可能出现的组合。化简后的每条规则对应一组测试点，规则数量多时优先保留高风险组合。
状态迁移适合订单、审批、工单等有生命周期对象。绘制状态图时标出状态、触发事件、迁移条件和迁移后的动作，同时补充非法迁移，例如已取消订单再次支付应被拒绝。状态图完成后，每条合法迁移和关键非法迁移都转化为测试点。
组合顺序建议是：先按字段做等价类和边界值，得到基础测试点；再用决策表处理跨字段的条件组合；涉及状态流转的对象补充状态迁移测试点；最后检查测试点之间是否重复，合并可合并的项。
把测试点写成可执行用例：字段与写法
测试点确定后，编写阶段的目标是让不同执行人按同一份用例得到一致结果。一条合格用例应包含用例编号、标题、所属模块、优先级、前置条件、操作步骤、测试数据和预期结果，必要时补充关联需求和备注。
标题写“条件+动作+预期”的核心信息，例如“使用已过期优惠券提交订单，提示优惠券不可用”。前置条件写执行前必须满足的系统状态和数据准备，例如“用户已登录，账户中存在一张已过期优惠券”。步骤按操作顺序编号，每步只做一个动作。测试数据直接写在步骤或独立字段中，给出具体值。预期结果写到可观察、可判断，例如页面提示文案、订单状态、数据库字段值或接口返回码。
拆分原则是一条用例对应一个验证目标。一个测试点包含多个独立判断时，拆成多条用例，便于定位失败原因。步骤之间存在强依赖且无法单独执行时，可以保留在同一条用例中，但要在前置条件中说明依赖关系。
命名与编号建议采用“模块缩写-序号”的规则，例如“ORDER-001”，标题保持唯一，便于评审引用和缺陷关联。修订用例时保留编号，变更内容记录在版本说明中。
常见问题包括：步骤写成“测试登录功能”这类无法执行的动作；预期结果只写“正常显示”；测试数据写“任意手机号”；多条验证目标塞进一条用例。编写完成后按这些点自查一遍，能明显减少评审返工。
用例数量增加后，编写、评审和状态流转需要统一承载。ONES 测试管理支持在测试用例库中按模块组织用例，记录前置条件、步骤和预期结果，并通过评审和版本状态管理用例的修订与基线，使编写规范在团队内保持一致。
角色分工与交付物：谁分析、谁编写、谁评审
用例设计不是测试人员单独完成的工作。分析阶段需要产品和开发提供规则确认，编写阶段由测试人员主导，评审阶段由多方共同把关，基线化由测试负责人确认。明确每个环节的负责人和交付物，可以减少交接遗漏。
| 环节 | 负责人 | 协作角色 | 输入 | 输出 |
|---|---|---|---|---|
| 测试分析 | 测试负责人或资深测试 | 产品、开发 | 需求、原型、接口说明 | 测试点清单、范围与优先级 |
| 用例编写 | 测试人员 | 开发补充技术约束 | 测试点清单、设计方法输出 | 用例初稿 |
| 用例评审 | 测试负责人组织 | 产品、开发、测试 | 用例初稿、需求文档 | 评审记录、修订意见 |
| 基线化 | 测试负责人 | 测试人员 | 修订后的用例 | 基线用例集、变更记录 |
评审中，产品重点确认业务规则和预期结果是否符合需求，开发重点确认技术约束、接口行为和异常处理是否覆盖，测试重点检查覆盖度、可执行性和冗余。用例状态可按“草稿—待评审—已评审—已基线—变更中”流转，每次状态变化记录责任人和时间。
一个完整示例：从规则到用例
以“会员折扣与优惠券叠加”规则为例：订单金额满200元享9折，会员额外减10元，优惠券满100减20，折扣与优惠券不可同时使用。演示过程如下。
第一步拆解输入条件：订单金额、是否会员、是否使用优惠券、优惠券门槛。风险点在于叠加规则和边界金额，优先级定为高。
第二步用等价类和边界值处理订单金额：有效类为0至199.99、200及以上，无效类为负数和非数字；边界取199.99、200、200.01。会员条件取是、否两类。
第三步用决策表处理组合。化简后得到四条规则：金额满200且非会员，打9折；金额满200且为会员，打9折再减10元；使用优惠券且金额满100，减20元且不打折；金额不满100使用优惠券，提示不满足门槛。每条规则对应一组测试点。
第四步写成用例。以“会员订单金额200元不使用优惠券”为例：前置条件为已登录会员，购物车金额200元；步骤为进入结算页、选择不使用优惠券、提交订单；测试数据为订单金额200元；预期结果为应付金额170元（200×0.9−10），订单状态为待支付。再补一条边界用例“非会员订单金额199.99元”，预期不打折，应付199.99元。
这个示例展示了从规则拆解、方法选择到用例成稿的完整路径。实际业务规则更复杂时，按同样顺序扩展条件即可，不必为每条规则重新设计流程。
用例评审与完成检查
评审的目标是判断用例是否达到可执行状态，关注覆盖度、可执行性、预期明确性和冗余四个方面。覆盖度检查测试点清单中的高优先级项是否都有对应用例，业务规则和异常路径是否覆盖；可执行性检查前置条件是否充分、步骤是否可操作、测试数据是否具体；预期明确性检查每条用例的结果是否可观察、可判断；冗余检查是否存在重复或可合并的用例。
评审可采用会议评审或书面评审。会议评审适合规则复杂、跨团队的高优先级用例，书面评审适合常规迭代。评审记录应包含问题条目、责任人、修改意见和处理状态，修订完成后由组织人确认关闭。
评审通过后进入基线化，形成当前版本的基线用例集。后续需求变更时，从基线发起变更，记录变更原因和影响范围，修订后重新评审并更新基线，避免执行时用到过期版本。
完成检查清单：
- 测试点清单已覆盖需求中的功能点、业务规则和主要风险点
- 高优先级测试点均有对应用例，异常和边界路径已覆盖
- 每条用例有唯一编号、清晰标题和可判断的预期结果
- 前置条件和测试数据具体，执行人无需额外询问即可操作
- 无重复用例，一条用例对应一个验证目标
- 评审意见已全部处理并记录
- 用例已基线化，版本和变更记录可追溯
以上检查项全部满足，用例即可进入执行阶段。执行中发现的问题回流到用例维护，形成设计、评审、执行、修订的闭环。
常见问题
需求文档写得很粗，测试分析阶段怎么补足输入？
需求粗糙时，测试分析阶段需要主动补齐三类信息：一是业务规则，向产品确认判断条件、计算口径和权限限制，把口头结论记录到测试点清单；二是技术约束，向开发确认接口行为、异常处理和边界限制；三是历史经验，查看同类功能的历史缺陷记录，找出容易出错的路径。补齐后仍不明确的部分，在测试点清单中标注待确认，并在评审前完成确认，避免带着假设编写用例。
等价类和边界值需要为每个字段都做一遍吗？
不必平均用力。优先处理高风险字段：有明确取值范围、长度限制、金额精度、数量或时间区间的字段，以及历史缺陷集中的字段。取值域简单、业务影响小的字段可以合并处理，用一条用例覆盖多个同类输入。判断依据是风险等级和出错代价，而不是字段数量。高优先级测试点保证覆盖，低优先级测试点可以适当抽样。
用例评审应该多久做一次，哪些用例必须上会评审？
评审频率跟随迭代节奏，常规迭代可采用书面评审，规则复杂、跨团队或涉及资金与核心数据的用例建议会议评审。必须上会评审的通常是高优先级测试点对应的用例、新增业务规则的用例以及变更影响范围较大的用例。评审记录要包含问题条目、责任人、修改意见和处理状态，修订完成后由组织人确认关闭，再进入基线化。
用例基线化之后需求又变了，怎么处理旧用例？
从当前基线发起变更，记录变更原因和影响范围，修订受影响的用例，重新评审后更新基线。未受影响的用例保持原版本，避免整批重写。执行时以最新基线为准，旧版本保留在变更记录中可追溯。如果变更导致部分用例失效，将其标记为废弃并说明原因，不要直接删除，便于后续回溯和缺陷关联。
用例数量很多时，如何保证编写规范在团队内一致？
先统一字段模板和命名编号规则，把标题写法、前置条件、测试数据、预期结果的写法要求固化成团队规范，并给出正反示例。其次在评审检查项中加入规范性检查，让偏差在评审阶段暴露。用例数量增加后，可在测试管理工具中按模块组织用例、记录前置条件与步骤，并通过评审和版本状态管理修订与基线，例如 ONES 测试管理提供用例库组织、评审和版本状态管理能力，帮助规范落地。
