본문으로 건너뛰기
SDETRole
SDETRole

API 테스트

REST API 테스트 케이스 템플릿

엔드포인트별 REST API 테스트 체크리스트를 구조화해 생성합니다.

브라우저에서만 실행됩니다 회원가입 불필요

Endpoint

Use {id} or :id for path parameters.

Used in titles.

Endpoint characteristics

Test cases · 25

  1. TC-001PositiveP1

    POST order succeeds with valid input

    Steps

    1. Send POST /api/v1/orders with a valid token and a valid request body.
    2. Capture status, headers and body.

    Expected

    201 Created (or 200/202 if documented). Response body matches the documented schema; Content-Type is correct (e.g. application/json).

  2. TC-002PositiveP1

    Created order is persisted and retrievable

    Steps

    1. Send POST /api/v1/orders with a valid body.
    2. Read the Location header or returned id.
    3. GET the created order.

    Expected

    Location (if returned) points to the new order; GET returns the same field values that were sent, plus server-generated fields (id, timestamps).

  3. TC-003NegativeP2

    Unsupported method returns 405

    Steps

    1. Send an HTTP method the endpoint does not support to /api/v1/orders.

    Expected

    405 Method Not Allowed with an Allow header listing the supported methods.

  4. TC-004NegativeP1

    Malformed JSON body is rejected

    Steps

    1. Send POST /api/v1/orders with invalid JSON (e.g. a trailing comma).

    Expected

    400 Bad Request with a clear parse error. Never 500.

  5. TC-005NegativeP2

    Wrong Content-Type is rejected

    Steps

    1. Send POST /api/v1/orders with a valid body but Content-Type: text/plain.

    Expected

    415 Unsupported Media Type (or 400 if documented).

  6. TC-006NegativeP3

    Unacceptable Accept header

    Steps

    1. Send POST /api/v1/orders with Accept: application/xml (if only JSON is supported).

    Expected

    406 Not Acceptable, or JSON returned anyway if the API ignores Accept. Behaviour should be consistent and documented.

  7. TC-007AuthP1

    Missing credentials returns 401

    Steps

    1. Send POST /api/v1/orders without an Authorization header.

    Expected

    401 Unauthorized with a WWW-Authenticate header. No data leaked in the body.

  8. TC-008AuthP1

    Invalid or expired token returns 401

    Steps

    1. Send POST /api/v1/orders with a malformed token, then with an expired token.

    Expected

    401 Unauthorized in both cases.

  9. TC-009AuthP1

    Insufficient permissions return 403

    Steps

    1. Send POST /api/v1/orders as a user without the required role or scope.

    Expected

    403 Forbidden. No side effects (nothing created, changed or deleted).

  10. TC-010ValidationP1

    Each required field is enforced

    Steps

    1. For each required field, send the body with that field removed.

    Expected

    400 Bad Request (or 422) naming the missing field. One case per field.

  11. TC-011ValidationP1

    Wrong data types are rejected

    Steps

    1. For each field, send a value of the wrong type (string for number, number for string, object for array).

    Expected

    400/422 naming the field. Values are not silently coerced unless documented.

  12. TC-012ValidationP2

    Null and empty values

    Steps

    1. Send null, "" and whitespace-only strings for required fields.

    Expected

    400/422 for required fields; optional fields accept null only if documented.

  13. TC-013ValidationP2

    Unknown properties are handled

    Steps

    1. Add an unexpected property to the body.

    Expected

    Either rejected with 400 or ignored, matching the API contract. Never stored or echoed back.

  14. TC-014ValidationP2

    Mass assignment of protected fields

    Steps

    1. Send server-controlled fields such as id, role, isAdmin, createdAt or balance in the body.

    Expected

    Values are ignored or rejected; protected fields keep their server-side values.

  15. TC-015BoundaryP2

    String length limits

    Steps

    1. For each length-limited field, send min-1, min, max and max+1 characters.

    Expected

    min and max accepted; min-1 and max+1 rejected with 400/422.

  16. TC-016BoundaryP2

    Numeric range limits

    Steps

    1. For each numeric field, send minimum-1, minimum, maximum, maximum+1, 0 and a negative value.

    Expected

    Values inside the range accepted; outside rejected with 400/422. No overflow or 500.

  17. TC-017BoundaryP3

    Unicode and special characters

    Steps

    1. Send names containing accents, emoji, RTL text, quotes and <script> tags.

    Expected

    Stored and returned unchanged (correct UTF-8), and never executed or reflected unescaped.

  18. TC-018BoundaryP3

    Oversized payload

    Steps

    1. Send a body larger than the documented limit.

    Expected

    413 Content Too Large, not a timeout or 500.

  19. TC-019IdempotencyP2

    Duplicate submission behaviour

    Steps

    1. Send POST /api/v1/orders twice quickly with the same body.

    Expected

    Behaviour matches the contract: either two records, or a 409 Conflict on a unique field. No partial or corrupted record.

  20. TC-020Rate limitP2

    Exceeding the rate limit returns 429

    Steps

    1. Send POST /api/v1/orders repeatedly until the documented limit is exceeded.

    Expected

    429 Too Many Requests with a Retry-After header; requests succeed again after waiting.

  21. TC-021Rate limitP3

    Rate limit headers are accurate

    Steps

    1. Send POST /api/v1/orders and read the rate limit headers (RateLimit / X-RateLimit-*).

    Expected

    Remaining count decreases by one per request and resets at the advertised time.

  22. TC-022Security headersP2

    Security and cache headers are present

    Steps

    1. Send POST /api/v1/orders with a valid token and inspect response headers.

    Expected

    Strict-Transport-Security and X-Content-Type-Options: nosniff are present; Cache-Control: no-store on authenticated responses; no Server/X-Powered-By version disclosure.

  23. TC-023Security headersP3

    CORS policy is restrictive

    Steps

    1. Send POST /api/v1/orders with Origin: https://evil.example.

    Expected

    Access-Control-Allow-Origin is absent or not reflecting the untrusted origin; never "*" together with credentials.

  24. TC-024Security headersP2

    Errors do not leak internals

    Steps

    1. Trigger a 4xx and (if possible) a 5xx response.

    Expected

    Error bodies contain no stack traces, SQL, file paths or framework versions.

  25. TC-025Performance smokeP3

    Response time within budget

    Steps

    1. Send POST /api/v1/orders 10 times sequentially and record durations.

    Expected

    p95 under the agreed budget (for example 500 ms); no request times out.

도구 소개

대부분의 API 테스트 계획서는 같은 부분을 놓칩니다. 객체 수준 인가, 멱등한 재시도, 페이지네이션 경계, 요청 한도 헤더, 내부 정보를 노출하는 오류 바디입니다. 엔드포인트(메서드, 경로, 인증 필요 여부, 바디 사용 여부, 페이지네이션 여부, Idempotency-Key 지원 여부, 요청 한도 적용 여부)를 설명하면 이 도구가 고정된 규칙을 적용해 케이스마다 우선순위, 단계, 기대 결과를 담은 번호 매긴 체크리스트를 만듭니다. 결과가 결정적이어서 같은 엔드포인트는 항상 같은 ID를 얻으므로, 다시 생성해도 내보낸 테스트 케이스가 안정적으로 유지됩니다. 출발점으로 활용하고, 여러분만 아는 비즈니스 규칙을 추가하세요.

사용 방법

  1. 메서드를 고르고 경로를 입력하세요. 경로 파라미터에 {id}나 :id를 쓰면 not-found 및 접근 제어 케이스가 추가됩니다.
  2. 엔드포인트에 해당하는 특성을 체크하세요.
  3. 체크리스트를 검토하고 필요하면 카테고리로 필터링한 뒤, 테스트 관리 도구용 Markdown 표나 CSV로 복사하거나 다운로드하세요.

REST API 테스트 케이스 템플릿 자주 묻는 질문

BOLA(또는 IDOR)란 무엇이며 왜 P1인가요?

Broken Object Level Authorisation(객체 수준 인가 취약점)은 요청의 ID만 바꿔 다른 사용자의 객체에 접근할 수 있는 문제입니다. 흔하고 악용하기 쉬워 OWASP API Security Top 10의 1위 위험이므로, 경로에 ID가 있는 모든 엔드포인트에는 이 테스트가 있어야 합니다.

PUT이나 DELETE에는 왜 멱등성 키 케이스가 없나요?

RFC 9110은 PUT과 DELETE(그리고 GET)를 멱등한 메서드로 정의하므로, 키 없이도 반복 요청의 효과가 같아야 합니다. 그래서 이 도구는 대신 “repeat the request”(요청 반복) 케이스를 추가합니다. Idempotency-Key는 POST와 PATCH에서 중요합니다.

CSV를 Jira, TestRail, Xray로 가져올 수 있나요?

CSV에는 표준 따옴표 처리가 된 ID, Category, Priority, Title, Steps, Expected result 열이 있어 대부분의 가져오기 마법사가 매핑할 수 있습니다. 가져올 때 각 열을 사용하는 도구의 필드에 매핑해야 합니다.

SDETRole 전체에서 검색할 내용을 입력하세요.

Pagefind 전문 검색 · 브라우저에서 실행됩니다 검색 페이지 열기 →