背景

AI 生成测试用例时，操作步骤通常很完整，预期结果却容易停留在 “操作成功”“功能正常”“系统正确处理”。

这类表达的问题不是不够专业，而是无法稳定执行。不同测试人员会用不同证据判断通过；页面提示和真实对象状态不一致时，也很难确定该记录哪一个结果。

本文使用一个脱敏的密码重置场景，演示如何把模糊预期改成可观察断言。示例不连接真实业务系统，也不代表任何具体产品的密码或会话规则。

演示输入与环境

• 场景：通过验证码重置账号密码。
• 原始用例：输入验证码和新密码，提交后验证密码重置成功。
• 输入材料：模糊旧用例、页面设计和接口约定的占位说明。
• 演示环境：文档评审，不执行真实页面、接口或数据库操作。
• 目标：输出可供项目人员补充真实规则的断言结构。

原始预期如下：

预期结果：密码重置成功，功能正常。

它没有说明观察位置、具体变化和观察时间，因此不能直接作为执行判定。

可观察断言模型

我会把预期结果拆成五类观察点：

观察层	要回答的问题	可用证据示例
页面	用户立即看到什么	提示、按钮、跳转、字段状态
接口	请求被怎样处理	状态码、业务码、关键响应字段
对象状态	核心数据是否改变	新密码可用、旧密码失效
关联行为	下游是否同步变化	会话、通知、安全记录
失败恢复	失败后是否保持一致	原密码仍可用、账号状态未异常

其中 “证据示例” 只说明观察方式，不代表项目中的最终业务规则。正式断言必须以需求、接口文档或确认记录为准。

改写步骤

1. 明确测试目标

先区分本用例要验证的是页面交互、重置接口，还是完整密码重置链路。目标不同，需要覆盖的观察层也不同。

2. 找出状态变化

密码重置本质上是一次值替换：新值进入有效状态，旧值退出有效状态。只验证成功提示，无法证明这次状态转换真的发生。

3. 为每个结果补三个字段

每条预期至少回答：

在哪里观察？
观察到什么？
在什么时间或动作之后观察？

例如 “提交后页面显示与设计一致的成功提示” 比 “页面正常” 更容易执行；“重新登录时新密码可用” 比 “密码修改成功” 更接近业务证据。

4. 把未知规则移出正式断言

其他设备是否强制退出、是否发送安全通知、错误次数是否触发锁定，都可能因产品而异。输入材料没有说明时，应放进 “待确认规则”，不能让 AI 按常见产品逻辑补齐。

5. 补失败分支

验证码错误、验证码过期、新密码不符合规则或服务异常时，不只要检查错误提示，还要检查原密码和账号状态有没有被意外改变。

改写后的结构示例

用例目标：验证使用有效验证码重置密码后的账号凭据状态。

前置条件：
- 测试账号处于允许登录的状态；
- 已准备可用的验证码或等效测试条件；
- 密码规则来自已确认的需求或接口约定。

操作步骤：
1. 输入验证码和符合规则的新密码；
2. 提交重置请求；
3. 记录页面提示和接口响应；
4. 退出当前流程，分别使用新、旧密码登录；
5. 按已确认规则检查关联会话或通知。

可观察结果：
- 页面展示与设计一致的处理结果；
- 接口响应符合已确认的接口约定；
- 新密码可以完成登录；
- 旧密码登录失败，失败表现符合已确认规则；
- 关联会话和通知按需求断言；未明确的部分列为待确认；
- 用例执行后恢复或隔离测试账号，避免影响后续执行。

本次方法演示的实际产物

本次没有连接真实系统，因此不能给出 “密码重置功能通过” 的执行结论。得到的是一份结构化评审产物：

• 从一句模糊预期中识别出页面、接口、对象、关联和失败恢复五类观察点。
• 明确新密码和旧密码需要分别验证。
• 将会话失效、通知等未确认内容保留为待确认规则。
• 增加测试账号的清理或隔离要求。

这份产物可以进入用例评审，但补齐真实规则并实际执行之前，不能当作测试结果。

可直接使用的提示词

请评审下面的测试用例，不要把“成功、正常、正确处理”作为最终预期。

1. 先识别页面、接口、对象状态、关联行为、失败恢复五类观察点；
2. 为每条预期写明“在哪里观察、观察到什么、何时观察”；
3. 只使用输入材料中已确认的规则；
4. 没有依据的内容单独列为“待确认规则”；
5. 最后输出仍然缺失的证据和无法执行的断言。

原始用例：
{粘贴用例}

已确认材料：
{粘贴需求、接口文档或评审结论}

评审检查表

1. 页面结果是否具体到提示、跳转或字段状态。
2. 接口断言是否包含业务状态，而不只检查 HTTP 200。
3. 核心对象的前后状态是否都被验证。
4. 新值生效和旧值失效是否分别检查。
5. 关联行为是否有真实规则依据。
6. 失败后原数据是否保持一致。
7. 异步结果是否有来源明确的观察窗口。
8. 每条断言能否由执行人重复取得证据。

常见坑

• 把页面成功提示当成完整业务结果。
• 只检查新值，没有检查旧值是否失效。
• 为了让用例显得完整，让 AI 自行补出会话和通知规则。
• 异步场景随意写固定等待时间，没有系统依据。
• 失败用例只看错误提示，不检查数据是否被部分修改。
• 文档评审没有真实执行，却把结构化产物写成 “验证通过”。

适用边界

这套方法适合功能、接口和端到端用例的预期结果评审。涉及资金、权限、合规或安全策略时，还需要结合正式规则、审计要求和实际环境进行专项验证。

可观察不等于只看页面。真正可执行的预期结果，应该让测试人员知道去哪里取证、用什么规则判断，以及哪些内容目前还不能判断。