测试用例的结构是什么
测试用例的最小可用结构包含四要素：前置条件、操作步骤、测试数据与预期结果；编号、标题、优先级、关联需求等属于管理性字段。粒度以一次可独立执行并得出明确判定为准：过细会让维护量膨胀、执行记录冗长，过粗会让失败定位变难、覆盖点模糊。好的用例不依赖执行者的经验——换一个人照着做，得到的判定结论应当一致。
基本信息
| 基本要素 | 编号、标题、前置条件、步骤、数据、预期结果 |
|---|---|
| 可选要素 | 优先级、关联需求、自动化状态、附件 |
| 粒度标准 | 一次可独立执行并得出明确判定 |
| 标题风格 | 条件加行为加预期，评审不展开步骤即可判断覆盖点 |
| 载体形式 | 用例管理工具、表格文档、自动化脚本内联注释 |
典型使用场景
- 需求评审：把验收标准逐条落到用例，暴露描述含糊的需求条目
- 回归执行：新成员照单执行即可，不依赖口头交接
- 缺陷复现：用最小步骤组合记录复现路径，附环境与数据
- 用例评审：按四要素齐备度检查，快速找出缺失预期的用例
- 自动化移植：步骤与预期边界清晰，才适合改写成自动化脚本
- 执行记录：每条用例留执行人、环境与结果，验收结论可追溯
示例（编排式写法）
示例（编排式写法）
# 用例：账户余额不足时下单应被拒绝
# 前置：用户已登录，账户余额为 0 元，商品库存充足
| 步骤 | 操作 | 预期 |
| 1 | 输入 0 元下单 | 提示金额需大于 0，订单未创建 |
| 2 | 输入 0.01 元下单 | 创建成功，状态为已支付 |
# 数据：账户 A（余额 0）、商品 SKU-A-1（库存 10）四要素检查表
| 要素 | 要写清什么 | 常见缺失表现 |
|---|---|---|
| 前置条件 | 账号状态、数据、环境依赖 | 只写已登录，缺余额与库存状态 |
| 操作步骤 | 可复现的最小操作序列 | 步骤跳跃，隐含未记录的操作 |
| 测试数据 | 具体值而非范围描述 | 写有效金额，不写具体数值 |
| 预期结果 | 可判定的界面与数据表现 | 写页面正常，无法判定通过与否 |
预期结果要覆盖三层：界面提示、接口返回、数据落库；只写界面表现的用例在接口被绕过时没有任何保护力。
用例不是操作手册：步骤只保留导向判定的操作，屏保式记录每个点击会让维护成本失控，也让评审抓不住重点。
粒度调整的经验值：一条用例对应一个可独立判定的验证目标；若失败后需要拆半天才知道坏了哪个点，就是拆得不够；若三条用例的失败永远一起出现，就是该合并。