测试用例设计可以按“拆需求—选方法—写用例—评审修订”的顺序推进：先把需求拆成可验证的测试点，再按等价类、边界值、场景法等选择覆盖方式，把每个测试点写成含前置条件、操作步骤、预期结果和优先级的用例，最后经评审与执行反馈修订。完成标志是一份他人能直接执行、可追溯到需求、覆盖关键风险且数量可控的用例集。
要点总览（TL;DR）
- 测试用例设计按“拆需求—选方法—写用例—评审修订”四步推进，每步都有明确输入和输出，前一步的产物直接作为后一步的起点。
- 设计方法按测试点特征选择：单字段校验用等价类与边界值，多条件组合用判定表，有状态对象用状态迁移，端到端流程用场景法。
- 一条可执行的用例至少写清前置条件、操作步骤、预期结果、优先级和关联需求，步骤一条一个动作，预期结果要可观察可判定。
- 用例设计由测试设计人员主笔，产品人员确认验收口径，开发人员提供技术约束，测试负责人组织评审并发布基线。
- 进入执行前按覆盖、可执行、冗余、可维护四类检查逐项核对，全部通过再发布基线版本。
先明确用例设计的输入与完成标准
开始写用例前，先把输入材料收齐，能减少中途反复确认和返工。用例设计阶段的输入通常包括：需求文档或用户故事、验收标准、原型与接口说明、历史缺陷记录、业务规则与数据约束。需求描述模糊时，先向产品人员确认验收口径，再进入拆解，避免把猜测写进预期结果。
完成标准可以从四个角度判断：需求条目都能追溯到对应用例；关键路径与异常路径都有覆盖；每条用例可被他人独立执行；预期结果可观察、可判定。四条同时满足，用例集才具备进入评审和执行的条件。
本篇聚焦用例设计与内容质量。跨项目复用、用例库建设、自动化脚本实现、测试执行与缺陷跟踪的完整流程，属于相邻主题，这里不展开。
用例设计输入清单
| 输入项 | 用途 | 缺失时的处理 |
|---|---|---|
| 需求文档或用户故事 | 提取功能点与验收标准 | 先与产品人员确认，再拆测试点 |
| 验收标准 | 确定预期结果的判定口径 | 补充可判定的验收条件 |
| 原型与接口说明 | 明确页面交互、字段与返回结构 | 向设计或开发人员索取 |
| 历史缺陷记录 | 识别高风险模块与易错场景 | 参考同类功能的历史问题 |
| 业务规则与数据约束 | 支撑边界值、判定表等设计方法 | 由业务方书面确认 |
从需求拆解到测试点的四步操作
四步操作的核心是把“需求语言”逐步转成“可执行用例”。每一步都有明确输入和输出，前一步的输出就是后一步的输入，便于检查遗漏。
第一步：拆需求，输出测试点清单
输入是需求文档与验收标准。动作是逐条识别功能点、业务规则、数据约束和角色权限，把一条需求拆成若干“可验证的判断”。例如“用户可以修改收货地址”可拆为：地址字段的必填与格式校验、默认地址切换、无权限角色不可修改、修改后订单页同步更新。输出是一份测试点清单，每个测试点写清验证对象和判断条件。
第二步：选方法，确定覆盖方式
不同测试点适合不同设计方法，按场景组合使用比套用单一方法更有效。
| 设计方法 | 适用场景 | 产出 |
|---|---|---|
| 等价类划分 | 输入域较大、取值可分组的字段 | 有效与无效等价类各取代表值 |
| 边界值分析 | 有长度、数量、金额上下限的字段 | 上限、下限及临界内外取值 |
| 判定表 | 多个条件组合决定不同结果的业务规则 | 条件与动作的组合表 |
| 状态迁移 | 订单、审批、工单等有状态流转的对象 | 合法与非法状态迁移路径 |
| 场景法 | 跨多个步骤的用户操作流程 | 主流程与异常分支场景 |
选择方法的判断依据是测试点的特征：单字段校验优先用等价类和边界值；多条件组合用判定表；有状态的对象用状态迁移；端到端流程用场景法。一个测试点可以用多种方法交叉覆盖，但要避免同一取值重复设计。
第三步：写用例，按统一字段填写
输入是测试点清单和选定的覆盖方式。动作是按团队统一的字段模板逐条编写，字段至少包含前置条件、操作步骤、预期结果、优先级和关联需求。输出是结构一致的用例集，便于评审、执行和后续维护。
第四步：评审与修订，形成基线
组织同行评审，邀请需求或产品人员确认业务规则与验收口径，开发人员参与接口和技术类用例的评审。评审重点是覆盖遗漏、预期结果不可判定、步骤无法执行三类问题。修订完成后形成基线版本，后续需求变更在此版本上更新并记录变更原因。
用例字段怎么写才可执行
用例写得笼统，执行时就会出现“按理解操作、按感觉判断”的情况。字段级的要求是把验证对象、操作和判断标准都写具体。
关键字段说明
| 字段 | 填写要求 |
|---|---|
| 用例编号 | 唯一且稳定，便于引用和缺陷关联 |
| 标题 | 写清验证对象与条件，如“手机号为空时提交登录” |
| 关联需求 | 填写需求条目编号，保证可追溯 |
| 前置条件 | 执行前必须满足的数据、账号、状态 |
| 操作步骤 | 一条步骤一个动作，按执行顺序编号 |
| 预期结果 | 可观察、可判定的页面表现或数据结果 |
| 优先级 | 按业务影响与发生概率划分，如高、中、低 |
| 用例类型 | 功能、边界、异常、权限等分类标签 |
一条登录场景用例的填写示例
以下为演示情景，用于说明字段写法。
| 字段 | 内容 |
|---|---|
| 用例编号 | TC-LOGIN-012 |
| 标题 | 已注册用户使用正确手机号与密码登录成功 |
| 关联需求 | REQ-LOGIN-03 |
| 前置条件 | 账号已注册且状态正常；登录页可访问 |
| 操作步骤 | 1. 打开登录页；2. 输入已注册手机号；3. 输入正确密码；4. 点击“登录” |
| 预期结果 | 页面跳转至首页；右上角显示当前用户昵称；登录接口返回成功状态 |
| 优先级 | 高 |
| 用例类型 | 功能—主流程 |
常见问题与改法
- 步骤合并：把“输入账号密码并登录”拆成输入账号、输入密码、点击登录三步，执行时才能定位失败环节。
- 预期结果写成“正常显示”：改为具体文案、跳转地址、数据状态或接口返回码，让不同人执行得到一致判断。
- 前置条件缺失：补上账号状态、数据准备和页面入口，避免执行时因环境差异无法复现。
角色分工与交付物
用例设计不是测试人员单独完成的工作，需求确认、技术约束和评审把关分别由不同角色承担。把每个环节的负责人和交付物定清楚，流程才能落到人。
| 角色 | 负责环节 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试设计人员 | 测试点拆解、用例编写与修订 | 测试点清单、用例集 | 评审前提交初稿 |
| 需求或产品人员 | 确认业务规则与验收口径 | 验收标准、规则确认结论 | 拆解需求前、评审时 |
| 开发人员 | 提供接口与实现约束，参与技术类用例评审 | 接口说明、技术约束说明 | 编写用例前、评审时 |
| 测试负责人 | 组织评审、把控覆盖与用例质量 | 评审记录、基线版本 | 评审后、基线发布时 |
用例与需求、缺陷之间的关联需要在协作工具中保持可查。以 ONES 为例，测试用例可以关联需求工作项，评审意见和修订记录随用例留存，执行中发现的缺陷也能回链到对应用例，便于在需求变更时定位受影响的用例范围。这类关联属于管理动作的承载，具体字段和流程可按团队现有规范配置。
设计完成后怎么检查质量
用例集写完不等于设计完成。进入执行前，按覆盖、可执行、冗余、可维护四类检查逐项核对，全部通过再发布基线。
用例设计完成检查清单
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 覆盖检查 | 需求条目是否都有对应用例；异常与边界是否覆盖 | 每条需求至少一条用例可追溯；关键异常路径有对应用例 |
| 可执行检查 | 他人能否按步骤独立执行并得到一致结果 | 抽检用例由未参与编写的人员试执行，结果与预期一致 |
| 冗余检查 | 重复或可合并的用例是否清理 | 同一验证对象与条件不重复出现；用例数量与风险等级匹配 |
| 可维护检查 | 需求变更时能否快速定位受影响用例 | 通过关联需求字段可检索出受影响用例清单 |
检查不通过时按类别处理：覆盖不足则回到测试点清单补充设计；可执行性不足则修订步骤和预期结果；冗余用例合并或删除并记录原因；可维护性不足则补齐关联需求字段。修订后重新抽检，通过后由测试负责人发布基线版本，作为本轮执行的依据。
常见问题
需求文档写得很粗，验收标准也没有，还能开始设计用例吗？
可以先做拆解准备，但预期结果要等验收口径确认后再定稿。具体做法是：先把需求中能确定的功能点、角色权限和数据字段拆成测试点清单，把模糊之处逐条列出，向产品人员确认后再补写预期结果。这样拆解工作不必空等，同时避免把猜测写进用例。若验收标准长期缺失，可先按业务规则和行业惯例提出建议口径，由需求方书面确认后使用。
用例数量是不是越多覆盖越充分？怎么控制规模？
覆盖充分与否看的是关键路径、异常路径和边界是否都有对应用例，数量本身不构成质量指标。控制规模的做法是：同一验证对象与条件的用例只保留一条；等价类中同一类的多个取值取代表值；低风险且实现简单的功能减少重复组合。用例数量应与风险等级匹配，高风险模块多设计，低风险模块保持基本覆盖。冗余检查时把可合并的用例清理掉并记录原因，便于后续追溯。
用例评审应该邀请哪些人，评审重点看什么？
评审通常邀请需求或产品人员确认业务规则与验收口径，开发人员参与接口和技术类用例的评审，测试负责人组织评审并把控覆盖与质量，同组测试人员参与同行评审。评审重点集中在三类问题：需求条目是否有遗漏的测试点；预期结果是否可判定；步骤是否能让未参与编写的人独立执行。评审意见记录后由用例编写人修订，修订完成形成基线版本，后续需求变更在基线之上更新。
需求变更后，之前写好的用例怎么处理？
先通过关联需求字段检索出受影响的用例清单，再逐条判断是修改、新增还是废弃。修改的用例更新步骤和预期结果并记录变更原因；新增的用例补充到基线版本；废弃的用例标注失效原因而不是直接删除，便于回溯历史执行记录。可维护性检查中要求能按关联需求快速定位受影响用例，正是为这一环节做准备。变更后的用例集需要重新抽检，通过后再发布新的基线。
用例设计和自动化脚本是什么关系，本篇为什么不展开脚本实现？
用例设计产出的是可执行的验证逻辑，包括前置条件、操作步骤和预期结果；自动化脚本是把这些逻辑用代码实现。设计质量决定脚本能否稳定运行，但脚本的框架选型、编写规范和持续集成属于实现层面的工作，涉及的技术条件与团队工具链差异较大。本篇聚焦用例本身的内容质量与设计流程，脚本实现和跨项目用例资产复用属于相邻主题，需要时另行查阅对应内容。
