API testing là gì? Hướng dẫn kiểm thử API cho tester từ đầu

API là gì và API testing là gì?

API (Application Programming Interface) là giao diện để các phần mềm trao đổi dữ liệu với nhau. Khi bạn bấm "Đăng nhập" trên trình duyệt, giao diện không tự kiểm tra mật khẩu — nó gửi một request tới API của máy chủ, và máy chủ trả về kết quả.

API testing là kiểm thử trực tiếp ở tầng giao tiếp này: gửi request với dữ liệu do bạn kiểm soát và kiểm chứng response trả về có đúng cấu trúc, đúng giá trị, đúng mã trạng thái và đúng quy tắc nghiệp vụ hay không — bỏ qua hoàn toàn lớp giao diện.

Vì sao nên test API

• Phát hiện lỗi sớm hơn: API thường xong trước giao diện, nên bạn không phải chờ.
• Chính xác hơn: khi test fail, bạn biết ngay lỗi ở tầng dịch vụ chứ không phải đoán giữa giao diện, mạng và máy chủ.
• Nhanh và ổn định hơn: một lời gọi API chạy trong mili-giây và không vỡ vì đổi màu nút bấm.
• Bắt được lớp lỗi mà giao diện che giấu: giao diện có thể chặn nhập dữ liệu xấu, nhưng máy chủ thì sao?

Đọc hiểu một request và response

Trước khi test được API, bạn phải đọc được bốn thành phần của request và ba thành phần của response.

Cấu trúc request

Cấu trúc response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1024,
  "status": "confirmed",
  "quantity": 3,
  "total": 450000,
  "createdAt": "2026-09-07T10:22:31Z"
}

Ba thứ cần kiểm tra ở mỗi response: mã trạng thái (status code), header (đặc biệt là Content-Type và các header bảo mật), và body (cấu trúc, kiểu dữ liệu, giá trị).

Bảng status code tester cần thuộc

Checklist thiết kế test case cho một API

1. Đường đi đúng (Happy path)

• Request hợp lệ trả về đúng status code và đúng dữ liệu.
• Cấu trúc response đúng như tài liệu đặc tả: đủ trường, đúng kiểu dữ liệu.
• Dữ liệu thực sự được ghi vào cơ sở dữ liệu — kiểm chứng bằng truy vấn SQL hoặc một API GET.

2. Dữ liệu không hợp lệ

• Thiếu trường bắt buộc.
• Sai kiểu dữ liệu: gửi chuỗi vào trường số, gửi số âm vào số lượng.
• Giá trị biên: 0, số âm, độ dài tối đa, độ dài tối đa cộng một.
• Body rỗng, body không phải JSON hợp lệ.
• Trường thừa không có trong đặc tả — API nên bỏ qua hay báo lỗi?
• Ký tự đặc biệt, emoji, chuỗi Unicode dài, chuỗi có dấu tiếng Việt.

3. Xác thực và phân quyền

• Gọi API mà không gửi token.
• Gửi token đã hết hạn, token sai định dạng, token của môi trường khác.
• Người dùng A truy cập tài nguyên của người dùng B bằng cách đổi ID trên URL.
• Người dùng thường gọi endpoint dành cho quản trị viên.

4. Trạng thái và nghiệp vụ

• Gọi hành động không hợp lệ với trạng thái hiện tại: huỷ một đơn đã giao xong.
• Gửi cùng một request hai lần — có tạo ra hai bản ghi trùng không?
• Thao tác đồng thời: hai request cùng trừ kho của sản phẩm còn 1 cái.

Công cụ và cách bắt đầu

• DevTools của trình duyệt — tab Network: miễn phí, luôn có sẵn, là nơi tốt nhất để bắt đầu quan sát request thật do chính ứng dụng gửi đi.
• Postman hoặc Insomnia: gửi request thủ công, lưu bộ sưu tập, thiết lập biến môi trường.
• cURL: hữu ích khi cần chia sẻ một lệnh tái hiện lỗi trong bug report.
• Playwright hoặc REST-assured: tự động hoá kiểm thử API trong pipeline.

# Gửi một request POST kèm token — dạng đưa vào bug report rất tiện
curl -X POST https://api.example.com/v1/orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"productId": 88, "quantity": -3}'

# Kỳ vọng: 400 Bad Request kèm thông báo về quantity
# Thực tế:  500 Internal Server Error  <-- bug