背景

很多 AI 生成的测试用例，步骤看起来完整，真正执行时却会卡在前置条件上。

典型写法是：

用例：删除默认收货地址
前置条件：用户已登录，系统运行正常
步骤：进入地址列表，删除默认地址
预期：删除成功，功能正常

问题不只是表达模糊。账号下有几条地址、哪条是默认地址、是否被订单引用、删除后如何回退，都会改变预期结果。

本文使用一个脱敏演示，展示如何约束 AI 区分事实、可准备数据、假设和待确认规则。示例不是某个具体模型的横向评测，也没有使用生产数据。

演示条件

• 场景：地址管理中的 “删除默认地址”。
• 输入材料：一条模糊旧用例，以及有限的业务描述。
• 环境：方法演示，不连接真实业务系统。
• 目标：得到一份可执行、可评审的用例结构。
• 验证方式：检查每个前置条件是否有来源，每个预期是否可观察。

第一次输出为什么不能直接用

当输入只有 “删除默认地址” 时，AI 很容易补出如下规则：

前置条件：
1. 用户已登录。
2. 账号下存在多条地址。
3. 当前默认地址未被订单使用。

预期结果：
1. 默认地址删除成功。
2. 系统自动将下一条地址设为默认地址。

第 1 条通常可以由执行人准备，第 2 条需要明确具体数据，第 3 条和 “自动选择下一条” 则可能是 AI 根据常见产品逻辑补出的假设。

如果需求没有这些规则，就不能把它们直接写进正式用例。

将前置条件拆成四类

建议先建立以下结构：

这个分类的作用是避免 AI 把 “合理” 误写成 “真实”。

推荐提示词

请改写以下测试用例。

第一步：把现有信息拆成：
1. 已知事实；
2. 可准备测试数据；
3. 你的假设；
4. 待确认业务规则。

第二步：只有“已知事实”和“可准备测试数据”可以进入前置条件。
没有依据的规则不要补造，单独放入待确认项。

第三步：输出以下字段：
- 用例目标；
- 账号和权限状态；
- 测试数据状态；
- 关联对象状态；
- 操作步骤；
- 页面可观察结果；
- 接口或数据可观察结果；
- 清理与恢复动作；
- 待确认规则。

原始用例：
{粘贴用例}

已确认业务材料：
{粘贴需求、接口或确认记录}

改写后的结构示例

用例目标：验证删除默认地址后的地址状态。

已知事实：
- 已登录用户可以进入地址管理页。
- 地址列表展示默认地址标记。

可准备数据：
- 账号 U1 下创建 A、B 两条地址。
- A 标记为默认地址，B 为非默认地址。

操作步骤：
1. 使用 U1 进入地址管理页。
2. 删除地址 A。
3. 重新查询地址列表。
4. 进入下单页检查默认选中地址。

可观察结果：
- A 不再出现在地址列表中。
- 地址查询接口不再返回 A。
- B 的默认状态根据已确认规则进行断言。
- 删除失败时，A 和 B 的状态保持不变。

待确认规则：
- 删除 A 后，B 是否自动成为默认地址？
- 被未完成订单引用的地址是否允许删除？

这里没有强行补出最终业务答案，但执行条件和证据位置已经明确。规则确认后，只需要补上对应断言。

评审时重点检查什么

1. 前置状态是否可以稳定准备

不要只写 “存在测试数据”。应该说明账号、数据数量、对象状态，以及准备数据的方法。

2. 前置条件是否混入预期结果

“删除后自动选择下一条地址” 是结果规则，不是操作前已经存在的条件。

3. 每条规则是否有依据

可以在用例中记录需求章节、接口字段、评审结论或历史缺陷编号。没有依据的内容进入待确认项。

4. 结果是否可观察

优先使用执行人能获得的证据：页面状态、接口响应、消息记录或允许查询的数据。不要用 “系统正确处理” 代替断言。

5. 是否包含清理和恢复

地址、账号和默认状态如果会被用例修改，需要说明如何恢复，避免影响后续执行。

常见坑

• 让 AI 根据产品常识自动补业务规则。
• 把 “用户已登录” 当成全部前置条件。
• 写了测试数据，但没有说明数据状态。
• 把结果规则写进前置条件，导致逻辑循环。
• 为了显得完整，隐藏了仍未确认的信息。
• 只断言页面提示，没有检查对象状态是否真的变化。

适用边界

这套方法适合评审和改写 AI 生成的功能、接口和场景用例。对于强合规、资金或权限场景，还需要结合正式规则、历史缺陷和系统设计材料。

脱敏演示只能用于说明方法，不能替代真实项目的业务确认和实际执行结果。

前置条件写得越像事实，越应该追问它的来源。AI 可以帮助补结构，但不能替项目补规则。