API Testing Patterns 是一套面向 API 测试的模式与实践集合，覆盖契约测试、REST 与 GraphQL 测试以及集成测试，并区分测试层级、关键测试场景、可用工具与智能体协作方式。
用途与测试层级 资料给出了三个测试层级：契约测试（provider-consumer 协议、无依赖、速度快）、组件测试（以 mock 隔离 API、速度快）、集成测试（使用真实数据库与服务依赖、速度较慢）。设计 API 测试策略或测试 API 时，需要先确定测试层级。核心主张是：API 就是契约，应从消费者视角测试契约而非实现，并始终测试错误场景而非只测正常路径，同时为 API 测试做版本化以预防破坏性变更。
主要能力与关键场景 资料列出需要重点测试的场景及示例：认证（401/403 处理，如过期 token、错误用户）、输入（400 校验，如缺字段、类型错误）、错误（500 的优雅处理，如数据库不可用、超时）、幂等性（防止重复，如相同幂等键）、并发（竞态条件，如并行下单）。 原文给出了多组代码模式：消费者驱动契约（consumer 定义请求与响应期望，provider 必须满足，并用 schema 校验）、认证与授权（无 token 返回 401、过期 token 返回 401、跨用户访问返回 403）、输入校验（必填字段、类型、范围均返回 400）、幂等性（同一幂等键返回同一 orderId）、并发（并行下单后核对库存数量）、REST CRUD 模式（CREATE 201、READ、UPDATE、DELETE 204 及删除后 404）。
快速模式选择 资料给出的对应关系为：微服务使用消费者驱动契约（Pact）；REST API 测试 CRUD、分页与过滤；GraphQL 测试查询校验与复杂度限制；外部依赖用 mock 做组件测试；性能方面对关键端点做负载测试。
使用方式与工具 可用工具方面：契约测试用 Pact、Spring Cloud Contract；REST 测试用 Supertest、REST-assured、Playwright；负载测试用 k6、Artillery、JMeter。资料还给出智能体协作方式，包括 qe-api-contract-validator（校验契约、检测破坏性变更）、qe-test-generator（根据 OpenAPI 规范生成测试）、qe-performance-tester（端点负载测试）、qe-security-scanner（API 安全测试），并给出调用示例（指定 spec、endpoint、coverage、rps、checks 等参数）以及通过 FleetManager 以 contract-testing 策略、mesh 拓扑协调多个智能体的示例。记忆命名空间为 aqe/api-testing/，下分 contracts、generated-tests、validation、performance。
最佳实践与应避免事项 建议做法：从消费者视角测试、用 schema 校验而非精确值、大量测试错误场景、为 API 测试做版本化、在 CI/CD 中自动化。应避免：测试实现而非契约、忽略 HTTP 语义（状态码）、不做负向测试、断言字段顺序或额外字段、测试过慢（应 mock 外部服务）。另有自动化与生产监控建议：在 CI/CD 中用 schema 校验自动化，并监控生产 API 的契约漂移。
注意事项（Gotchas） 资料列出若干坑：智能体基于文档化 API 而非真实 API 生成测试，应先对运行中的服务做验证；认证 token 会在测试运行间过期，应使用长寿命 token 的 fixture 或每套件前刷新；CI 中的限流会导致间歇性失败，应对 429 响应加带指数退避的重试；生产环境的 GraphQL introspection 可能被禁用，应针对 staging schema 而非生产端点测试；幂等性测试每次运行需要唯一请求 ID，硬编码 ID 会在重试时造成假通过。
适用场景与限制 适用于测试 REST 或 GraphQL API、校验微服务契约、设计 API 测试策略、防止 API 破坏性变更等场景，尤其适合微服务、分布式系统与第三方集成。资料未提供该技能的收费方式、价格、平台限制或具体安装命令，这些信息暂未提供。