# 测试用例设计打法

## 目标

把需求、页面、接口或缺陷描述，转换成更适合模型直接执行的结构化测试用例。重点不是“写得像测试文档”，而是“让后续自动化代理能稳定执行”。

## 输入材料到用例的转换顺序

### 1. 先识别测试对象

优先识别以下信息：

- 是 Web 页面、API、混合流程还是桌面/移动端
- 入口地址、接口路径、关键按钮、关键字段和成功标记是什么
- 哪些数据是前置依赖，哪些数据需要运行时提取
- 哪些路径属于核心业务闭环

### 2. 再识别风险

优先覆盖这些高价值风险：

- 核心主流程不可用
- 关键输入校验缺失
- 权限控制失效
- 业务规则被绕过
- 状态切换或跳转错误
- 接口返回成功但页面未真正完成动作

### 3. 最后决定用例粒度

按“一个用例验证一个清晰目标”的原则拆分。不要把多个不相关目标硬塞进同一个用例里，也不要把一次简单验证拆成过多碎片步骤。

## 默认覆盖矩阵

如果用户只说“生成测试用例”，默认至少产出以下类别：

- `smoke`：验证主流程可走通
- `happy-path`：验证正常业务路径
- `negative`：验证错误输入或业务拒绝
- `permission`：验证未登录、越权或角色限制
- `boundary`：验证边界值或状态边界

如果材料明显不足以支撑全部类别，就优先保留 `smoke`、`happy-path` 和最关键的一个 `negative` 用例。

## 设计动作时的规则

- 把页面进入、点击、填写、选择、等待、断言写成独立动作，不要把多个动作揉成一句话。
- 把 API 请求写成 `request` 动作，并把方法、URL、请求体放进结构化字段。
- 把跨步骤复用的数据通过 `extract` 提取成 `{{var.xxx}}`，不要靠自然语言描述“记住这个值”。
- 把“登录后出现首页标识”“请求返回 code=0”“订单状态变为 paid”这类稳定结果写成断言。
- 把“页面看起来正常”“数据似乎已刷新”这类模糊结果改写成结构化断言，改不了就不要写。

## 设计断言时的规则

优先写这些稳定断言：

- 页面 URL 或路由变化
- 元素可见性
- 元素文本或输入框值
- 状态码
- JSON Path 字段存在或字段值匹配
- 关键业务状态字段

避免把以下内容作为主断言：

- 时间戳
- 随机 ID
- 排序不稳定的列表全量内容
- 经常变化的营销文案
- 无法稳定定位的 toast 文本

## 数据策略

- 把账号、密码、token、验证码、密钥写成 `{{env.xxx}}` 或 `{{secret.xxx}}`
- 把创建接口返回的资源 ID、订单号、token 写成 `{{var.xxx}}`
- 把示例值限制在后续模型真正执行所需的最低范围，不要生成大量无效样例数据

## 风险升级规则

遇到以下场景时，不要直接生成可执行破坏动作，先标记风险或默认禁用：

- 生产环境地址
- 删除、支付、退款、结算、发货
- 不可逆状态变更
- 大批量导入或批处理

这种场景下优先：

- 写入 `assumptions`
- 把用例设为 `enabled: false`
- 明确说明需要额外确认

## 输出质量标准

交付前确认：

- 用例可直接被其他模型读取和执行
- 字段命名统一，没有同义字段混用
- 每个步骤都有明确动作和明确断言
- 每个断言都能落到可执行对象、可执行路径或可执行字段
- 不依赖上下文猜测就能理解步骤含义