让 AI 写接口测试用例很容易得到这样的预期接口返回 200取消订单成功。但这里少问了几件事取消的是不是这张订单订单状态有没有更新之前占用的库存释放了吗重复取消会不会多释放一次接口响应是一份证据后续业务状态还需要核对。这篇用一个取消订单的教学案例演示怎样把一句“取消成功”改成真正能检查的预期。一、200 说明了什么HTTP 200 表示请求成功响应内容的含义还与请求方法有关。这是 HTTP 协议层面的语义。参考RFC 9110200 OK具体到业务仍然要看接口约定返回的业务结果是什么哪些操作已经完成哪些关联操作还在异步处理因此不应该把 200 简化成“只代表网络通了”也不能仅凭它认定整个业务流程已经完成。二、先明确这次要验证的规则假设本项目确认了下面的口径未支付订单购买一件商品占用一份库存。取消接口成功后订单状态立即变为CANCELLED。库存在服务端记录取消成功后的 5 秒内异步释放。首次释放完成后再取消同一订单不重复释放库存。这些是本文的教学约定。实际项目的响应字段、完成时间和重复操作结果需要按自己的接口文档确认。测试数据使用独立商品只有这一张订单没有其他库存操作检查项取消前完成释放后订单状态待支付已取消可售库存910占用库存10准备好这些数据才有条件判断取消前后发生了什么。三、把“取消成功”拆成三个检查点第一处响应是不是对应这张订单假设接口成功响应为{code:0,order_id:O1001,status:CANCELLED}至少核对HTTP 状态是否符合接口约定。业务码是否表示成功。order_id是否等于本次提交的订单。返回状态是否为CANCELLED。其中code0只是本例约定不是所有接口通用的标准。如果只检查code即使接口返回了另一张订单的信息也可能被判为通过。第二处查询到的订单状态有没有变化取消响应结束后通过订单查询接口或后台重新查询O1001。这里需要拿到另一份证据订单 O1001 的当前状态为 CANCELLED。取消接口返回“已取消”查询接口仍显示“待支付”就是需要继续调查的差异。按照本例同步更新状态的约定不能用“可能还没同步”直接解释过去。第三处这张订单占用的库存释放了吗在约定时间内通过只读查询检查O1001 的库存占用记录已解除。 对应的有效释放操作只发生一次。独立测试商品还可以核对可售库存是否恢复到 10、占用库存是否归零。如果使用共享商品就不能只看库存总数。其他订单可能同时下单或取消总数恢复了也不一定是这一单释放的。优先用订单编号关联占用记录和释放记录。四、异步操作别查一次就结束本例允许库存释放耗时最多 5 秒。取消后立即查到库存还没恢复不能马上判失败但一直等到恢复也不能忽略时间要求。可以按这个流程操作记录订单编号和服务端取消成功时间 ↓ 在约定窗口内重复查询库存占用状态 ↓ 释放完成记录完成时间和证据 超过窗口仍未释放记录超时差异 查询报错或没有查询权限记录验证受阻起点应使用约定的服务端时间。取不到时需要先确认取证方式不能随便拿页面提示出现的时间代替。这里反复执行的是只读查询不要通过反复调用取消接口来等待库存恢复否则会混入重复操作的影响。即使第 8 秒库存恢复了也仍然没有满足本例“5 秒内完成”的要求。五、补一条重复取消检查有没有多做事等第一次库存释放完成再取消同一订单。按本例规则重点检查检查项预期订单状态仍为已取消库存占用仍为 0独立商品可售库存仍为 10不能变成 11该订单的有效库存释放仍只有一次重复请求返回“已取消”还是其他业务提示按接口文档核对。但无论提示怎么写都不能重复增加库存。注意这条只验证了完成后的顺序重复请求还没有验证并发取消、处理中重复请求和故障重试不能把它们一起标成通过。六、让 AI 按业务变化补充预期把需求、接口文档和已有用例贴进去可以使用下面的提示词请评审下面的接口测试用例 重点检查是否只验证了响应没有验证业务状态变化。 逐条补充 1. 前置数据及初始业务状态。 2. HTTP 状态和业务响应的检查项。 3. 请求对象与返回对象是否一致。 4. 操作后的业务状态以及核对入口。 5. 关联数据是否按需求变化怎样关联到本次操作。 6. 如果异步完成明确等待起点、最长时间和查询方式。 7. 重复操作可能产生哪些额外副作用。 要求 - 字段、状态值、完成时限都必须有文档依据。 - 没有依据的内容列为待确认不自行补充。 - 查不到证据时不要直接判为通过。 - 区分业务结果不符和验证受阻。 输出 原用例遗漏的检查补充预期核对入口待确认问题 需求与接口文档 【粘贴内容】 已有用例 【粘贴内容】最终的用例不应只剩“返回 200操作成功”。对于取消订单更有用的结论是取消响应与订单编号一致订单状态已更新该订单占用的库存按约定释放重复取消没有再次释放。每一部分都能指出核对位置测试结论才有依据。本文讨论的是教学场景的测试设计没有对真实系统执行验证。