Checklist kiểm thử REST API: kiểm tra thực tế, ví dụ và câu trả lời phỏng vấn

1. Biến documentation thành test model

Bắt đầu từ resource, không phải tool. Với POST /orders, xác định ai được gọi, header bắt buộc, request field và constraint, success response, error format và state của order sau khi tạo. Rule chưa rõ phải thành câu hỏi, không lấy current behavior làm expected result.

Tạo decision table cho authenticated/anonymous, cart empty/not empty, stock đủ/không đủ và payment required/not required. Nó tìm combination mà danh sách endpoint phẳng bỏ sót. Ghi environment và API version.

• Nêu business invariant của endpoint.
• Tách documented rule khỏi assumption.
• Ghi version, environment và test-data owner.
• Nối mỗi response với state transition đã hứa.

2. Method, status code, header và content negotiation

HTTP semantics là một phần contract. GET safe; PUT và DELETE được định nghĩa idempotent; POST không tự động idempotent. Hãy test ý nghĩa của repeat trong sản phẩm, không chỉ học thuộc status. 200 kèm error object vẫn có thể sai contract.

Kiểm Content-Type, Location sau create khi contract yêu cầu, cache header và correlation id. Phân biệt 400 syntax, 401 authentication, 403 permission, 404 missing resource, 409 state conflict và 422 semantic validation theo contract thật.

POST /orders HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: order-77-cart-19

{"delivery_address_id": 55}

3. Input validation và test design

Áp dụng equivalence partition và boundary cho từng rule. Quantity 1–10 cần 0, 1, 10, 11, wrong type, missing, NULL và decimal. String cần empty, whitespace, length, encoding và normalization. Không tạo hàng chục random value cùng một partition.

Kiểm cả cross-field và state rule: coupon đúng format có thể expired, address hợp lệ có thể thuộc user khác, product id hợp lệ có thể hết stock. Error phải chỉ ra rule mà không lộ stack trace hay SQL.

valid:   {"quantity": 1}, {"quantity": 10}
invalid: {"quantity": 0}, {"quantity": 11}
type:    {"quantity": "2"}, {"quantity": 2.5}
missing: {}, {"quantity": null}

4. Kiểm schema, value và persisted state

Schema validation xác nhận required field, type và format; nó không chứng minh total đúng hoặc record đã được lưu. Hãy tính business oracle độc lập theo rounding rule đã thống nhất.

Sau write, đọc lại qua interface hỗ trợ. POST trả 1242 nhưng GET trả 1380 gợi ý lỗi persistence/read model. Cả hai trả 1242 nhưng provider charge 1380 thì lỗi downstream. Hai quan sát cần hai báo cáo khác nhau.

pm.test('created', () => pm.response.to.have.status(201));
pm.test('json response', () => pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json'));
const order = pm.response.json();
pm.test('expected total', () => pm.expect(order.total).to.eql(1242));
pm.environment.set('order_id', order.id);

5. Authentication, authorization và ownership

Authentication trả lời caller là ai; authorization trả lời họ được làm gì. Kiểm no token, malformed/expired token, wrong role và truy cập object người khác. Ẩn button trên UI không bảo vệ API.

Tạo hai synthetic user. A tạo order; B thử GET, PATCH, DELETE bằng id của A. Kiểm cả list, search, export và nested resource vì detail endpoint kín vẫn có thể đi cùng search bị leak.

Actor A + order A: GET allow, PATCH allow
Actor B + order A: GET deny,  PATCH deny
Admin   + order A: theo documented role
Anonymous          : deny, không leak data

6. Idempotency, retry, concurrency và pagination

Client retry sau timeout, proxy lặp call và user double-click. Gửi lại request với cùng và khác idempotency key rồi kiểm final business effect. Chạy song song cho coupon, lead conversion hoặc last stock item.

Với pagination, kiểm stable order, không overlap/gap, metadata và page-size boundary. Rate limit cần limit−1, limit, limit+1 cùng header/reset, không chỉ tạo một 429.

• Cùng key và cùng body.
• Cùng key nhưng khác body.
• Timeout trước khi client thấy response.
• Hai request bắt đầu đồng thời.
• Hai phía của rate-limit boundary.

7. Dependency failure và asynchronous processing

API có thể trả trước khi queue consumer, payment provider hoặc email service hoàn tất. Tách accepted work khỏi completed work; định nghĩa status polling, event hoàn tất, eventual-consistency window và deadline.

Mô phỏng timeout, 5xx, malformed response, duplicate/out-of-order event và queue unavailable. Kiểm retry, dead-letter, idempotent consumer và reconciliation. Publish message chưa chứng minh notification đã được gửi.

POST /exports -> 202 + export_id
GET /exports/{id} -> queued | processing | ready | failed
ready -> download URL hoạt động và thuộc requester
failed -> reason an toàn, retry quan sát được

8. Performance, automation và test report hữu ích

Performance check cần workload và threshold: concurrency/RPS, data volume, warm-up, percentile và error budget. “API nhanh” không đo được. Theo dõi p95/p99 cùng error rate và saturation.

Automate check ổn định và có giá trị: contract, critical rule, authorization matrix và regression path. Isolate data, tránh chain dài che failure đầu tiên, và report request id, sanitized request/response, environment, expected state và side effect.

• Fast contract tests cho mỗi change.
• Integration tests cho storage/dependency.
• Critical smoke nhỏ sau deployment.
• Regression theo changed risk.
• Observability cho latency, error và queue.