接口返回 200，就算测试通过？用取消订单检查真正的业务结果

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

让 AI 写接口测试用例，很容易得到这样的预期：

接口返回 200，取消订单成功。

但这里少问了几件事：

取消的是不是这张订单？订单状态有没有更新？之前占用的库存释放了吗？重复取消会不会多释放一次？

接口响应是一份证据，后续业务状态还需要核对。

这篇用一个取消订单的教学案例，演示怎样把一句“取消成功”，改成真正能检查的预期。

一、200 说明了什么？

HTTP 200 表示请求成功，响应内容的含义还与请求方法有关。这是 HTTP 协议层面的语义。参考：RFC 9110，200 OK

具体到业务，仍然要看接口约定：

• 返回的业务结果是什么？
• 哪些操作已经完成？
• 哪些关联操作还在异步处理？

因此，不应该把 200 简化成“只代表网络通了”，也不能仅凭它认定整个业务流程已经完成。

二、先明确这次要验证的规则

假设本项目确认了下面的口径：

这些是本文的教学约定。实际项目的响应字段、完成时间和重复操作结果，需要按自己的接口文档确认。

测试数据使用独立商品，只有这一张订单，没有其他库存操作：

准备好这些数据，才有条件判断取消前后发生了什么。

三、把“取消成功”拆成三个检查点

第一处：响应是不是对应这张订单？

假设接口成功响应为：

{
"code": 0,
"order_id": "O1001",
"status": "CANCELLED"
}

至少核对：

• HTTP 状态是否符合接口约定。
• 业务码是否表示成功。
• order_id 是否等于本次提交的订单。
• 返回状态是否为 CANCELLED。

其中 code=0 只是本例约定，不是所有接口通用的标准。

如果只检查 code，即使接口返回了另一张订单的信息，也可能被判为通过。

第二处：查询到的订单状态有没有变化？

取消响应结束后，通过订单查询接口或后台，重新查询 O1001。

这里需要拿到另一份证据：

订单 O1001 的当前状态为 CANCELLED。

取消接口返回“已取消”，查询接口仍显示“待支付”，就是需要继续调查的差异。

按照本例同步更新状态的约定，不能用“可能还没同步”直接解释过去。

第三处：这张订单占用的库存释放了吗？

在约定时间内，通过只读查询检查：

O1001 的库存占用记录已解除。
对应的有效释放操作只发生一次。

独立测试商品还可以核对可售库存是否恢复到 10、占用库存是否归零。

如果使用共享商品，就不能只看库存总数。其他订单可能同时下单或取消，总数恢复了，也不一定是这一单释放的。

优先用订单编号关联占用记录和释放记录。

四、异步操作别查一次就结束

本例允许库存释放耗时最多 5 秒。

取消后立即查到库存还没恢复，不能马上判失败；但一直等到恢复，也不能忽略时间要求。

可以按这个流程操作：

记录订单编号和服务端取消成功时间
↓
在约定窗口内重复查询库存占用状态
↓
释放完成：记录完成时间和证据
超过窗口仍未释放：记录超时差异
查询报错或没有查询权限：记录验证受阻

起点应使用约定的服务端时间。取不到时，需要先确认取证方式，不能随便拿页面提示出现的时间代替。

这里反复执行的是只读查询，不要通过反复调用取消接口来等待库存恢复，否则会混入重复操作的影响。

即使第 8 秒库存恢复了，也仍然没有满足本例“5 秒内完成”的要求。

五、补一条重复取消，检查有没有多做事

等第一次库存释放完成，再取消同一订单。

按本例规则，重点检查：

重复请求返回“已取消”还是其他业务提示，按接口文档核对。

但无论提示怎么写，都不能重复增加库存。

注意，这条只验证了完成后的顺序重复请求，还没有验证并发取消、处理中重复请求和故障重试，不能把它们一起标成通过。

六、让 AI 按业务变化补充预期

把需求、接口文档和已有用例贴进去，可以使用下面的提示词：

请评审下面的接口测试用例，
重点检查是否只验证了响应，没有验证业务状态变化。

逐条补充：

1. 前置数据及初始业务状态。
2. HTTP 状态和业务响应的检查项。
3. 请求对象与返回对象是否一致。
4. 操作后的业务状态，以及核对入口。
5. 关联数据是否按需求变化，怎样关联到本次操作。
6. 如果异步完成，明确等待起点、最长时间和查询方式。
7. 重复操作可能产生哪些额外副作用。

要求：
– 字段、状态值、完成时限都必须有文档依据。
– 没有依据的内容列为待确认，不自行补充。
– 查不到证据时，不要直接判为通过。
– 区分业务结果不符和验证受阻。

输出：
原用例｜遗漏的检查｜补充预期｜核对入口｜待确认问题

需求与接口文档：
【粘贴内容】

已有用例：
【粘贴内容】

最终的用例，不应只剩“返回 200，操作成功”。

对于取消订单，更有用的结论是：

取消响应与订单编号一致，订单状态已更新，该订单占用的库存按约定释放，重复取消没有再次释放。

每一部分都能指出核对位置，测试结论才有依据。

本文讨论的是教学场景的测试设计，没有对真实系统执行验证。