不规则测试

不稳定的测试会对同一段代码给出不同的结果。API 测试中常见的原因包括：时机不当（例如在异步任务完成之前进行断言）、测试之间共享状态、残留的先前运行数据、真实的网络调用、未经初始化的随机数据，以及对当前日期或时区的依赖。

工作原理

故障的诊断方法是：反复运行同一个提交，直到故障重现，然后比较两次运行之间的差异。修复方法是：消除变异源，例如：等待特定条件而非固定时间；为每个测试分配不同的数据；使用随机生成器；冻结时钟；以及用伪造的依赖项或可控的沙箱环境替换实际运行的依赖项。

误解

自动重试机制可以修复不稳定的测试。但重试掩盖了症状，却保留了根本原因；它还会掩盖产品中真正存在的间歇性错误——竞态条件看起来就像不稳定的测试。与其重试后置之不理，不如隔离并修复问题。

点击这里试试

POST /protocol/v1/jobs返回 202，并且每次轮询 GET /protocol/v1/jobs/{id}时任务都会继续执行——这是一个很好的练习，可以练习等待条件满足而不是直接休眠。每次运行之间重置沙箱，以防止状态泄漏。

相关内容

• Testing async jobs and 202 Accepted
• 测试夹具

资料来源

• HTTP semantics — RFC 9110
• OpenAPI Initiative

其他术语

• 测试夹具 — 测试开始时的已知数据和状态，每次运行都以相同的方式设置。
• 模拟 API — 一个可以替代真实 API 的方案，它能够返回逼真的响应，但背后却没有真实的系统支持。
• API 沙箱 — API 的一个独立副本，其中调用不会产生任何实际影响，数据可以重置。
• 赝品、存根和假货 — 三种类型的测试替身——真实依赖项的替代品——它们在执行的操作和检查的内容上有所不同。
• 合同测试 — 测试 API 及其使用者是否在请求和响应的形式上达成一致，而无需同时运行它们。
• 烟雾测试 — 在进行任何更彻底的检查之前，先运行一组简短快速的检查，确保最重要的路径都能正常工作。

阅读英文版

所有术语 · 测试技巧 · 全部 39 个模拟 REST API

最后更新时间 2026年10月16日