Hướng Dẫn Kiểm Thử API: Từ Cơ Bản Đến Quy Trình Tự Động Hóa

Developer reviewing API documentation on screen

API là hợp đồng giữa các hệ thống phần mềm. Khi một API bị lỗi, mọi thứ phụ thuộc vào nó đều bị ảnh hưởng. Vậy mà kiểm thử API thường bị xem nhẹ — chỉ được thực hiện thủ công trên trình duyệt ngay trước khi triển khai. Một chiến lược kiểm thử API đúng đắn sẽ phát hiện lỗi sớm, ghi lại hành vi kỳ vọng và giúp bạn tự tin hơn khi phát hành sản phẩm.

Kiểm thử API là gì?

Một bài kiểm thử API gửi một HTTP request và kiểm tra các yếu tố trong response:

Mã trạng thái — Chúng ta nhận được 200 OK hay 404 Not Found?
Body của response — Cấu trúc dữ liệu có đúng không? Các giá trị có chính xác không?
Headers — Content-Type có được thiết lập đúng không? Header xác thực có xuất hiện không?
Thời gian phản hồi — Endpoint có phản hồi trong khoảng thời gian chấp nhận được không?
Xử lý lỗi — Điều gì xảy ra khi đầu vào không hợp lệ? Chúng ta có nhận được thông báo lỗi rõ ràng không?

Các mã trạng thái HTTP cần nắm vững

Mã	Ý nghĩa	Khi nào bạn sẽ gặp
`200`	OK	GET, PUT, PATCH thành công
`201`	Created	POST thành công và tạo ra một tài nguyên
`204`	No Content	DELETE thành công hoặc hành động không có body
`400`	Bad Request	Đầu vào không hợp lệ, JSON sai định dạng, thiếu trường
`401`	Unauthorized	Token xác thực bị thiếu hoặc không hợp lệ
`403`	Forbidden	Đã xác thực nhưng không có quyền truy cập
`404`	Not Found	Tài nguyên không tồn tại
`409`	Conflict	Tài nguyên bị trùng lặp, xung đột phiên bản
`422`	Unprocessable Entity	Lỗi xác thực trên JSON hợp lệ
`429`	Too Many Requests	Vượt quá giới hạn tốc độ
`500`	Internal Server Error	Lỗi phía server
`503`	Service Unavailable	Server ngừng hoạt động hoặc quá tải

401 nghĩa là "bạn là ai?" — 403 nghĩa là "tôi biết bạn là ai, nhưng bạn không được phép làm điều đó."

Kiểm thử thủ công với API Request Builder

Trước khi tự động hóa, hãy tìm hiểu các endpoint của bạn theo cách thủ công. API Request Builder của chúng tôi cho phép bạn:

Thiết lập phương thức HTTP (GET, POST, PUT, PATCH, DELETE)
Thêm headers (Authorization, Content-Type, các header tùy chỉnh)
Xây dựng query parameter mà không cần mã hóa URL thủ công
Viết request body dạng JSON với tính năng tô sáng cú pháp
Kiểm tra toàn bộ response bao gồm headers và thời gian phản hồi

Công cụ này rất hữu ích khi khám phá một API mới, gỡ lỗi một endpoint cụ thể hoặc nhanh chóng xác minh một bản sửa lỗi.

Kiểm thử REST API: chu trình CRUD đầy đủ

Với một API /users giả định, một bộ kiểm thử đầy đủ bao gồm:

Tạo mới (POST)

POST /users
Content-Type: application/json

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor"
}

Kiểm tra:

Trạng thái 201 Created
Body của response chứa người dùng vừa tạo với id được sinh tự động
Header Location trỏ đến tài nguyên mới (ví dụ: /users/42)

Đọc (GET)

GET /users/42
Authorization: Bearer <token>

Kiểm tra:

Trạng thái 200 OK
Body khớp với người dùng đã tạo
id là 42

Cập nhật (PUT / PATCH)

PATCH /users/42
Content-Type: application/json

{ "role": "admin" }

Kiểm tra:

Trạng thái 200 OK
role trong response hiện là "admin"
Các trường khác không thay đổi

Xóa (DELETE)

DELETE /users/42
Authorization: Bearer <token>

Kiểm tra:

Trạng thái 204 No Content
GET /users/42 sau đó trả về 404

Kiểm thử tiêu cực: những bài kiểm thử mà hầu hết mọi người bỏ qua

Kiểm thử tích cực xác minh luồng hoạt động bình thường. Kiểm thử tiêu cực xác minh rằng API xử lý đầu vào không hợp lệ một cách khéo léo:

Thiếu các trường bắt buộc → 400 với thông báo lỗi rõ ràng
Kiểu dữ liệu không hợp lệ ("age": "twenty") → 400
Tài nguyên không tồn tại (GET /users/99999) → 404
Token đã hết hạn → 401
Truy cập dữ liệu của người dùng khác → 403
Gửi payload 10 MB → 413 Payload Too Large
Vượt quá giới hạn tốc độ → 429 kèm header Retry-After

Một API được thiết kế tốt sẽ thất bại một cách có thể dự đoán và cung cấp thông tin hữu ích.

Các mô hình kiểm thử xác thực

Bearer token (JWT)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Các tình huống kiểm thử:

Token hợp lệ → response đúng
Token hết hạn → 401 với thông báo "Token expired"
Token bị giả mạo (thay đổi một ký tự) → 401
Thiếu header → 401
Token dành cho môi trường khác → 401

Sử dụng JWT Decoder của chúng tôi để kiểm tra token và xem thời gian hết hạn trong quá trình kiểm thử thủ công.

API key

X-API-Key: sk_live_abc123

Kiểm thử: key sai, thiếu key, key không đủ quyền.

Luồng OAuth 2.0

OAuth tạo thêm độ phức tạp — hãy kiểm thử các endpoint trao đổi token riêng biệt với các endpoint tài nguyên.

Xác thực body của response

Đừng chỉ kiểm tra mã trạng thái. Hãy xác thực cấu trúc của các response:

// Using Jest + supertest
test("GET /users/:id returns the correct user", async () => {
  const response = await request(app).get("/users/42").set("Authorization", `Bearer ${token}`);

  expect(response.status).toBe(200);
  expect(response.headers["content-type"]).toMatch(/json/);
  expect(response.body).toMatchObject({
    id: 42,
    name: expect.any(String),
    email: expect.stringMatching(/^[^\s@]+@[^\s@]+\.[^\s@]+$/),
    role: expect.oneOf(["admin", "editor", "viewer"]),
  });
});

Với các schema response phức tạp hơn, hãy sử dụng tính năng xác thực JSON Schema với JSON Schema Validator của chúng tôi để định nghĩa cấu trúc kỳ vọng một lần và kiểm thử tất cả các endpoint dựa trên đó.

Kiểm thử hợp đồng

Trong kiến trúc microservices, kiểm thử hợp đồng đảm bảo rằng consumer và provider đồng thuận về cấu trúc API. Consumer định nghĩa những gì họ cần; provider xác minh rằng họ đáp ứng điều đó. Các công cụ như Pact tự động hóa quá trình này.

Điều này đặc biệt có giá trị khi các nhóm quản lý các service khác nhau — một bài kiểm thử hợp đồng sẽ thất bại ngay lập tức khi một trường bị đổi tên hoặc bị xóa, trước khi tích hợp.

Kiểm thử hiệu năng và tải

Kiểm thử chức năng cho bạn biết API có hoạt động hay không. Kiểm thử hiệu năng cho bạn biết nó hoạt động tốt đến mức nào dưới tải:

Baseline — Thời gian phản hồi p50/p95/p99 với một người dùng duy nhất là bao nhiêu?
Kiểm thử tải — Hiệu năng như thế nào ở mức lưu lượng truy cập cao nhất dự kiến?
Kiểm thử căng thẳng — Đến điểm nào thì API bắt đầu thất bại?
Kiểm thử đột biến — Điều gì xảy ra khi lưu lượng đột ngột tăng gấp 10 lần?

Mục tiêu phổ biến: < 200ms cho p95 ở mức tải cao nhất dự kiến.

Danh sách kiểm thử API

Kiểm thử tất cả các thao tác CRUD cho mỗi tài nguyên
Kiểm thử các trường hợp tiêu cực: đầu vào không hợp lệ, thiếu xác thực, không tìm thấy
Xác thực body của response theo schema (không chỉ kiểm tra mã trạng thái)
Kiểm thử các trường hợp ngoại lệ của xác thực: token hết hạn, bị thiếu, bị giả mạo
Xác minh các response lỗi có thông báo hữu ích
Kiểm tra rằng phân trang, lọc và sắp xếp hoạt động đúng
Kiểm thử hành vi giới hạn tốc độ
Xác minh không có dữ liệu nhạy cảm bị rò rỉ trong các response lỗi
Kiểm tra thời gian phản hồi ở mức tải dự kiến

Kiểm thử API tốt là mạng lưới an toàn cho việc tái cấu trúc và là tài liệu tốt nhất bạn có thể có — chúng cho thấy chính xác mỗi endpoint làm gì và mong đợi gì.