About api-testing
A skill for API testing work, helping teams develop test plans, cases, and risk analyses across several interface protocols. It emphasizes explicit assumptions, prioritization, and evidence.
Key features
- 01Create API test plans and cases
- 02Analyze and prioritize interface risks
- 03Choose checks by protocol
- 04Separate confirmed facts from assumptions
- 05Check cross-request business outcomes
Use cases
- 01Design tests for REST or GraphQL APIs
- 02Cover gRPC, WebSocket, or SOAP scenarios
- 03Draft an initial plan with stated assumptions
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ naodeng/ awesome-qa-skills --skill api-testingAfter installing, type/api-testingin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
output-formats.mdquick-start.mdREADME.mdagents/openai.yamlevals/eval.yamlevals/cases/basic-success.yamldomain-method-regression.yamledge-incomplete-input.yamledge-risk-priority.yamlevals/fixtures/check_domain_decisions.pycheck-domain-decisions.shdomain-oracle.jsonexamples/postman-rest-api/API-Environment.postman_environment.jsonnewman-run.shREADME.mdUser-API-Tests.postman_collection.jsonexamples/rest-assured-java/pom.xmlREADME.mdexamples/rest-assured-java/src/test/java/com/example/UserApiTest.javaexamples/supertest-nodejs/package.jsonREADME.mdexamples/supertest-nodejs/tests/users.test.jsoutput-templates/template-csv.csvtemplate-excel.tsvtemplate-json.jsontemplate-markdown.mdtemplate-word.mdtemplate-xmind.mdprompts/api-testing.mdreferences/domain-decision-example.mdDetails
From the project READMEAPI 测试(中文版)
英文版: 见对应英文技能。
何时使用
- 需要 API 测试方案、API 用例或 API 风险分析。
- 请求涉及 REST、GraphQL、SOAP、gRPC、WebSocket 或混合接口场景。
执行流程
- 阅读并遵循「按需加载」中的主提示词(覆盖清单、输出结构、质量要求)。
- 只补充真正影响结果的项目上下文:范围、环境、限制、风险、依赖、期望产出。
- 信息不全时先给可用初版,并显式标出假设与信息缺口。
- 默认 Markdown;用户指定其他格式时再切换。
领域执行要点
- 按已确认协议选择分支:REST 校验 method/status/schema/幂等;GraphQL 校验 data 与 errors、null 和字段权限;gRPC 校验 status/metadata/deadline/流终止;WebSocket 校验握手、消息 ID/顺序/重连;SOAP 校验 WSDL、namespace 与 Fault。未使用协议不强行覆盖。
- 将契约检查与跨请求业务后置条件分开:创建/更新→读回→权限视图→重复请求/下游效果;每步保留请求 ID、业务键、版本与证据。
- 状态码正确但读回余额、状态或关联错误仍为业务失败;响应可能异步时按项目一致性窗口等待,不自定窗口。
- 数据由隔离命名空间和唯一业务键准备,清理按依赖逆序执行并记录残留;未知授权或真实副作用限制保持 blocked。
核心约束
- 按风险/业务影响排优先级,不要平均摊铺。
- 把「已确认事实」和「当前假设」分开写。
- 不要编造用户未提供的接口、字段、环境或根因细节。
- 结果必须可执行:场景具体、有优先级、能指导下一步。
按需加载
-
校准领域结果、正确对照或证据缺口时,读取 references/domain-decision-example.md 的脱敏输入、逐项预期与复算依据。
-
产出前必须阅读并遵循
prompts/api-testing.md(最低覆盖清单、输出结构、质量要求)。 -
需要 Excel/CSV/JSON/Word 等格式时:读
output-formats.md,并按用户格式要求输出。 -
需要套用现成模板时:读
output-templates/中匹配的模板,不要自创冲突结构。 -
用户要示例或对标现有资产时:读
examples/中相关样例。 -
需要框架规范、排障、报告 schema 等深资料时:只读
references/里与当前问题相关的文件,不要整目录通读。 -
需要格式转换或辅助校验时:优先使用
scripts/中已有脚本,而不是重写一遍。 -
需要评测/回归本 skill 时:使用
evals/,并用 skill-up 校验与运行。 -
用户只要最短上手路径时:读
quick-start.md。
交付前自检
- 已遵循主提示词的输出结构
- 最低覆盖关注:本次纳入的接口或业务流程、优先级和风险等级、正向场景、异常场景、边界场景、鉴权和权限检查、请求与响应校验、错误处理…(细节以主提示词为准)
- 已覆盖最低清单,或标明为何省略
- 高风险项有明确优先级
- 未编造用户未提供的细节
- 假设与信息缺口已标明
常见误区
- 范围和上下文都不清楚时,不要假装已经完整可用。
- 不要把所有项写成同等重要。
- 不要跳过假设与信息缺口。
- 不要输出大段与当前工具链无关的空泛理论。