API Testing Là Gì? Lộ Trình Học Kiểm Thử API

API testing là gì?

API testing (kiểm thử API) là việc kiểm thử trực tiếp ở tầng API — tầng dịch vụ giao tiếp giữa các phần mềm — thay vì thao tác qua giao diện người dùng. Tester gửi request đến endpoint của API rồi kiểm tra response trả về: status code đúng chưa, dữ liệu (JSON) có đúng cấu trúc và giá trị không, API xử lý ca lỗi ra sao.

Nói cách khác, thay vì click chuột trên màn hình, bạn "nói chuyện" thẳng với phần lõi xử lý của ứng dụng. Vì bỏ qua lớp giao diện, API testing nhanh hơn, ổn định hơn và phát hiện được những lỗi mà UI test khó chạm tới — ví dụ một API tạo dữ liệu sai nhưng giao diện vẫn hiển thị bình thường.

Để hiểu sâu hơn "API" và "RESTful" nghĩa là gì trước khi test, bạn nên đọc qua bài API RESTful là gì — nền tảng cho mọi nội dung phía dưới.

Vì sao API testing quan trọng

API testing quan trọng vì nó nằm ở tầng "giữa" của cái mà ngành gọi là kim tự tháp kiểm thử (test pyramid). Mô hình này — do Mike Cohn phổ biến, lưu ý đây không phải thuật ngữ chính thức của ISTQB — gợi ý phân bổ công sức test theo ba tầng: nhiều test ở đáy (unit), vừa phải ở giữa (API/service/integration), và ít test chậm-đắt ở đỉnh (UI/E2E).

Lý do nên đầu tư vào tầng giữa rất thực tế:

• Nhanh: một request API trả về trong mili-giây, không phải chờ trình duyệt load.
• Sớm: API thường xong trước giao diện, nên bạn test được khi UI còn chưa dựng.
• Ổn định: UI đổi nút bấm hay layout là test gãy; API ít thay đổi hợp đồng hơn nhiều.

Trong hệ thống đặt phòng họp nội bộ tôi hay lấy làm ví dụ, một lỗi đặt trùng phòng nằm ở logic xử lý phía API. Bắt nó bằng API test mất vài giây; bắt bằng UI test phải mở trình duyệt, đăng nhập, click qua nhiều màn hình — chậm và dễ trượt.

Kiến thức nền cần có (HTTP, REST, JSON)

Trước khi test API, bạn cần nắm ba khối kiến thức nền. Tin vui là chúng không đòi hỏi biết lập trình giỏi, chỉ cần hiểu khái niệm và đọc được.

• HTTP: giao thức để client và server trao đổi. Bạn cần biết các HTTP method chính (GET đọc, POST tạo, PUT/PATCH cập nhật, DELETE xóa) và ý nghĩa các nhóm status code. Nhớ nhanh: 2xx là thành công, 4xx là lỗi do request gửi sai, 5xx là lỗi do server.
• REST: phong cách kiến trúc phổ biến nhất hiện nay để xây API — dùng URL định danh tài nguyên, dùng HTTP method chuẩn để thao tác.
• JSON: định dạng dữ liệu mà hầu hết API dùng để trao đổi. Bạn cần đọc được JSON, hiểu cấu trúc object/array để kiểm tra response đúng-sai.

Ba khối này gắn chặt nhau: bạn gửi một request HTTP đến endpoint REST, rồi đọc response JSON để đối chiếu kỳ vọng. Nếu thấy mơ hồ chỗ method hay status code, hãy quay lại API RESTful là gì — ở đó tôi có bảng tra method và status code đầy đủ.

Công cụ test API (Postman, Newman, REST Assured)

Có khá nhiều công cụ, nhưng người mới chỉ cần bắt đầu với một cái. Bảng dưới so sánh những công cụ phổ biến nhất để bạn chọn đúng điểm xuất phát:

Lời khuyên thật lòng: cứ bắt đầu bằng Postman. Nó cho bạn "nhìn thấy" request và response một cách trực quan, dễ học mà vẫn đủ mạnh để viết test script. Khi quen tay, bạn dùng Newman để chạy bộ test đó tự động trong CI, rồi mới tính đến REST Assured nếu muốn đi sâu hướng automation bằng code. Bài Postman test API hướng dẫn từng bước gửi request đầu tiên.

Lộ trình học API testing theo bước

Đây là lộ trình API testing tôi vẫn dùng để dẫn dắt học viên đi từ con số 0:

1. Nắm nền tảng web (1–2 tuần): hiểu client–server, request–response, HTTP method và status code.
2. Hiểu REST & JSON: đọc được endpoint, biết cấu trúc một JSON response, phân biệt được dữ liệu đúng/sai.
3. Làm chủ Postman: gửi request GET/POST, đặt biến môi trường, đọc kỹ phần response và header.
4. Học cách thiết kế ca kiểm thử cho API: áp dụng tư duy phủ case hợp lệ/không hợp lệ/biên — y hệt khi viết test case cho giao diện. Xem cách viết test case để áp dụng.
5. Viết test tự động trong Postman: dùng test script kiểm tra status code, kiểm tra field trong JSON.
6. Chạy tự động & vào CI: dùng Newman chạy collection theo lịch hoặc mỗi lần build.
7. (Tùy chọn) Tiến lên code: học REST Assured nếu bạn muốn rẽ sâu sang automation.

Đừng vội nhảy cóc. Phần lớn học viên vấp ở chỗ chưa vững HTTP/JSON đã lao vào viết test tự động — nền không chắc thì lên cao rất chông chênh.

Tester cần kiểm thử gì ở API

Test API không phải chỉ "gọi thử xem có chạy không". Một bộ test API tốt nên phủ đủ các khía cạnh sau — đây cũng là phần lõi thực hành của khóa API Testing:

• Functional: API trả về đúng kết quả nghiệp vụ cho từng tình huống đầu vào.
• Status code: đúng mã cho từng ngữ cảnh — 200 khi lấy thành công, 201 khi tạo mới, 404 khi không tìm thấy, 401 khi thiếu xác thực.
• Schema / response: dữ liệu trả về đúng cấu trúc đã thống nhất (đúng field, đúng kiểu) — sai schema là dễ vỡ tích hợp với frontend.
• Authentication & phân quyền: API có yêu cầu token/quyền đúng không; người không có quyền gọi vào thì bị chặn ra sao.
• Error handling (negative test): gửi dữ liệu sai định dạng, thiếu trường bắt buộc, sai quyền — xem API trả lỗi rõ ràng (4xx) hay vỡ thành 500 chung chung.
• Tính toàn vẹn dữ liệu: sau khi POST/PUT, gọi GET lại để chắc dữ liệu đã lưu đúng.
• Performance cơ bản: thời gian phản hồi ở mức chấp nhận được dưới tải bình thường.

Ví dụ với API tạo lượt đặt trong hệ thống đặt phòng họp nội bộ: bạn cần kiểm tra request hợp lệ trả về 201 và lưu đúng dữ liệu; còn khi đặt trùng giờ, API phải trả lỗi rõ ràng (chẳng hạn 409 Conflict với thông báo dễ hiểu) chứ không phải một lỗi 500 chung chung. Theo ISTQB, các phép kiểm thử này trải dài qua cấp độ integration và system test, gồm cả khía cạnh functional lẫn non-functional (như hiệu năng, bảo mật).