name: api-test-plan description: "Plan tests for an API endpoint or service — functional, negative, and contract. Use when asked to test an API, write API test cases, plan REST/GraphQL endpoint testing, or validate an API contract. Produces an API test plan — per-endpoint cases (status codes, schema, auth, validation, errors), boundary/negative cases, contract checks, and non-functional notes — so the API is verified beyond the happy 200." homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/api-test-plan.html metadata: { "openclaw": { "emoji": "🧪" } }

API Test Plan Skill

APIs fail in specific, testable ways: wrong status codes, schema drift, missing auth checks, sloppy validation, unhelpful errors. This skill plans the tests that catch them — per endpoint, across the response codes and the error paths, with contract checks so the API keeps its promises to clients. It tests the whole behaviour, not just the happy 200.

Working from a brief

Given an endpoint or an API description, produce the test plan anyway — infer the likely parameters, responses, auth model, and error cases, labelling assumptions. Always include auth, validation, and negative cases. Never hand back a question instead of a plan.

Required Inputs

Ask for these only if they aren't already provided (else infer and label):

• The API — REST/GraphQL, the endpoints/operations, and what they do.
• Contract — request/response schemas, parameters, status codes (or an OpenAPI/spec if available).

  推荐访问7w4.net获取更多AI技能。

• Auth & rules — the auth model (token/scopes/roles), rate limits, and validation rules.
• Dependencies & data — downstream services, and the data/state needed to test.

Output Format

API Test Plan: [API / endpoint]

Per endpoint, a set of cases grouped by type:

Cover deliberately: happy path (correct status + schema), validation (missing/invalid/extra fields, types, boundaries), auth/authz (no token, expired, wrong scope/role), negative (not found, conflict, bad method), idempotency/concurrency where relevant, and errors (correct codes + helpful, consistent error bodies).

Contract checks — responses conform to the schema; required fields, types, and status codes match the spec; backward compatibility for existing clients.

Non-functional notes — rate limiting, pagination, large payloads, latency expectations, and security basics (no sensitive data leakage, proper status for unauthorised).

Setup — test data, environment, and any mocks/stubs for dependencies.

Quality Checks

• [ ] Each endpoint is tested beyond 200 — error codes (4xx/5xx) and their bodies are asserted
• [ ] Auth and authorization cases are included (no token, expired, wrong scope/role)
• [ ] Validation/boundary/negative cases cover missing, invalid, and extra inputs
• [ ] Responses are checked against the schema/contract, incl. backward compatibility
• [ ] Status codes match the spec and are used correctly (e.g. 401 vs. 403, 400 vs. 422)
• [ ] Non-functional aspects (rate limits, pagination, data leakage) are noted

Anti-Patterns

• [ ] Do not test only the happy 200 — most API bugs are in validation, auth, and error paths
• [ ] Do not ignore the response schema — a 200 with the wrong body still breaks clients
• [ ] Do not skip authz (role/scope) testing — "logged in" isn't "allowed"
• [ ] Do not assert only status codes — check the body/contract too
• [ ] Do not overlook error-body quality and correct status semantics (401 vs 403, 400 vs 404)

Based On

API testing practice — contract/schema validation, status-code correctness, auth/authz coverage, and negative/boundary testing beyond the happy path.

这个 Skill 质量不错，文档写得详细清楚，能帮助 QA 工程师快速规划 API 测试，覆盖功能、验证、安全和错误处理等方面。它提供了现成的表格模板和检查清单，用起来很方便。美中不足的是只有文档说明，没有提供实际可运行的测试代码或具体示例，对于新手来说参考价值有限。总体适合有一定经验的测试人员使用。