API Testing với Postman — Automation Testing Introduction

Mở đầu — vì sao bài này quan trọng

Nếu bạn mới bước chân vào thế giới Automation Testing, có một sự thật mà rất nhiều bạn không được nói cho biết sớm: phần lớn giá trị của automation không nằm ở tầng giao diện (UI), mà nằm ở tầng API. Khi tôi phỏng vấn ứng viên QA cho các đội dự án ở TP.HCM, câu hỏi tôi hay hỏi nhất không phải "bạn viết Selenium thế nào" mà là "bạn hiểu một request HTTP gồm những gì". Vì nếu bạn hiểu API, bạn hiểu được xương sống của hệ thống.

API (Application Programming Interface) là cách các phần mềm nói chuyện với nhau. Khi bạn mở app Shopee và bấm "Thêm vào giỏ hàng", điện thoại của bạn không tự tính toán gì cả — nó gửi một request lên server, server xử lý logic nghiệp vụ (kiểm tra tồn kho, giá, khuyến mãi) rồi trả về kết quả. Toàn bộ "bộ não" của ứng dụng nằm ở đây. Nếu bạn test được lớp API này, bạn đã test được phần cốt lõi nhất mà không cần chờ giao diện hoàn thiện.

Trong bài học đầu tiên này, chúng ta sẽ tập trung vào Postman — công cụ phổ biến nhất, dễ tiếp cận nhất để bắt đầu test API. Đây là điểm khởi đầu lý tưởng vì bạn không cần biết lập trình sâu vẫn có thể test được, nhưng lại đủ mạnh để dùng trong các dự án thực tế. Những bài sau trong khóa sẽ đi sâu vào code (REST Assured, pytest, Newman để tự động hóa), còn bài này giúp bạn xây nền tảng tư duy và thao tác cơ bản.

Khái niệm cốt lõi

Tại sao test API thay vì chỉ test UI?

Hãy hình dung một tình huống quen thuộc. Bạn muốn kiểm tra chức năng "đăng nhập sai mật khẩu 5 lần thì khóa tài khoản". Nếu test qua UI, bạn phải mở trình duyệt, gõ email, gõ mật khẩu, bấm nút, chờ trang load, lặp lại 5 lần — mỗi vòng lặp mất vài giây và dễ gãy nếu ai đó đổi màu nút hay đổi vị trí ô nhập. Nhưng nếu test qua API, bạn chỉ cần gửi 5 request đến endpoint /login và kiểm tra response ở lần thứ 6. Nhanh hơn, ổn định hơn rất nhiều.

Đây là bốn lý do cốt lõi khiến API testing trở nên thiết yếu:

Nhanh hơn UI testing rất nhiều. Một API test thường chạy trong mili-giây, trong khi một UI test có thể mất vài giây đến vài chục giây vì phải render trình duyệt. Trên một bộ test lớn, khác biệt này là hàng giờ đồng hồ.
Ổn định hơn (không phụ thuộc thay đổi UI). Giao diện thay đổi liên tục — đổi màu, đổi layout, đổi text nút. Mỗi lần đổi là UI test có nguy cơ gãy. API thì "hợp đồng" (contract) ít thay đổi hơn nhiều, nên test ít flaky hơn.
Test trực tiếp logic nghiệp vụ. API là nơi chứa business logic thật sự: tính giá, áp mã giảm giá, kiểm tra quyền. Test ở đây là test vào đúng chỗ giá trị nằm.
Thiết yếu cho microservices. Trong kiến trúc microservices — vốn rất phổ biến ở các công ty như Tiki, MoMo, Grab — mỗi service giao tiếp qua API. Nếu không test được API, bạn gần như mù trước cách các service tương tác.

Cấu trúc một HTTP request

Để test API, bạn phải hiểu một request gồm gì. Có bốn thành phần chính:

Method (phương thức): GET để lấy dữ liệu, POST để tạo mới, PUT/PATCH để cập nhật, DELETE để xóa. Ví dụ GET /products/123 nghĩa là "cho tôi thông tin sản phẩm số 123".
URL / Endpoint: địa chỉ của tài nguyên, ví dụ https://api.tiki.vn/v2/products/123.
Headers: thông tin đi kèm, phổ biến nhất là Authorization (token xác thực) và Content-Type (định dạng dữ liệu, thường là application/json).
Body: dữ liệu gửi lên, thường ở dạng JSON, dùng cho POST/PUT. Ví dụ khi tạo đơn hàng, body chứa danh sách sản phẩm và địa chỉ giao.

Cấu trúc một HTTP response

Khi server trả lời, response cũng có các phần bạn cần kiểm tra:

Status code: con số cho biết kết quả. 200 OK là thành công, 201 Created là tạo mới thành công, 400 Bad Request là dữ liệu gửi lên sai, 401 Unauthorized là chưa xác thực, 404 Not Found là không tìm thấy, 500 Internal Server Error là lỗi phía server. Đây là thứ đầu tiên bạn phải kiểm tra trong mọi API test.
Response body: dữ liệu trả về, thường là JSON. Bạn kiểm tra xem đúng giá trị, đúng cấu trúc không.
Response time: thời gian phản hồi. Một API tốt nên trả về trong vài trăm mili-giây.

Postman là gì và nó giải quyết vấn đề gì

Postman là một ứng dụng cho phép bạn soạn, gửi request và xem response một cách trực quan mà không cần viết code. Quan trọng hơn, nó cho phép bạn viết assertion (khẳng định) bằng JavaScript để tự động kiểm tra response, gom nhiều request vào Collection, và dùng Environment để quản lý biến (như URL, token) cho từng môi trường dev/staging/production. Đây chính là bước đệm để tiến tới automation thật sự.

Tình huống thực tế

Ví dụ 1 — Sàn thương mại điện tử phát hiện lỗi giá trước khi ra mắt

Một đội QA tại một sàn TMĐT ở Hà Nội (giả định, quy mô khoảng 40 kỹ sư) chuẩn bị ra mắt tính năng "Flash Sale khung giờ vàng". Yêu cầu: sản phẩm giảm 50% nhưng tối đa 100.000đ. Đội quyết định test qua API endpoint POST /cart/calculate thay vì chờ UI hoàn thiện.

Họ gửi request với một sản phẩm giá 500.000đ. Theo công thức, giảm 50% là 250.000đ, nhưng vì trần là 100.000đ nên giá cuối phải là 400.000đ. Response trả về lại là 250.000đ — server đã bỏ quên logic trần giảm giá. Nhờ test API sớm, họ phát hiện lỗi khi UI còn chưa xây xong, tiết kiệm được cả tuần rework. Bài học: API testing cho phép bạn test business logic ngay khi backend sẵn sàng, không cần chờ frontend — đây là tinh thần "shift-left", phát hiện lỗi càng sớm càng rẻ.

Ví dụ 2 — Fintech và bài toán xác thực token

Một startup fintech ở TP.HCM (giả định) có API chuyển tiền yêu cầu token xác thực trong header Authorization. Bạn QA mới vào test endpoint POST /transfer và luôn nhận 401 Unauthorized dù chắc chắn tài khoản đúng. Sau một hồi loay hoay, bạn phát hiện token bị hết hạn sau 15 phút, mà bạn dùng lại token cũ đã lưu từ hôm trước.

Vấn đề này dạy hai điều. Thứ nhất, phần lớn "lỗi API" của người mới thực ra là lỗi cấu hình request — sai header, sai token, sai Content-Type. Thứ hai, trong Postman bạn nên tự động hóa việc lấy token: dùng một request POST /login để lấy token, rồi lưu vào biến environment bằng script, để các request sau tự động dùng token mới. Bài học: đừng hardcode token; hãy để Postman tự lấy và tái sử dụng token, vừa giống thực tế vừa tránh flaky.

Ví dụ 3 — Đội microservices và regression hàng ngày

Một công ty giao vận ở Đông Nam Á (giả định, giống mô hình Giao Hàng Nhanh) có hơn 20 microservices. Mỗi sáng, service "tính phí ship" gọi sang service "địa chỉ" và service "khuyến mãi". Có lần một lập trình viên đổi tên trường JSON từ fee thành shipping_fee mà không báo ai. UI vẫn hiển thị bình thường ở màn hình cũ nhưng đơn hàng liên tỉnh bị tính sai phí.

Đội QA sau đó dựng một Collection Postman gồm 30 request kiểm tra hợp đồng dữ liệu giữa các service, chạy mỗi sáng. Ngay lần chạy đầu, assertion pm.expect(response.fee).to.exist báo đỏ, chỉ đúng vào chỗ đổi tên trường. Bài học: với microservices, API testing không phải "nên có" mà là "bắt buộc phải có" — nó là tấm lưới an toàn duy nhất bắt được những thay đổi hợp đồng âm thầm giữa các service.

Hướng dẫn từng bước

Chúng ta sẽ đi qua một luồng test API hoàn chỉnh trong Postman. Giả sử ta test một API công khai để luyện tập (bạn có thể dùng https://reqres.in hoặc https://jsonplaceholder.typicode.com).

Bước 1 — Cài đặt và tạo request đầu tiên. Tải Postman từ trang chủ, tạo tài khoản miễn phí. Bấm "New" → "HTTP Request". Chọn method GET, nhập URL https://jsonplaceholder.typicode.com/users/1, bấm Send. Bạn sẽ thấy response JSON chứa thông tin user và status 200 OK ở góc phải.

Bước 2 — Gửi một POST request có body. Đổi method sang POST, URL https://jsonplaceholder.typicode.com/posts. Vào tab Body → chọn raw → chọn JSON. Nhập:

{
  "title": "Bài học API",
  "userId": 1
}

Bấm Send, bạn sẽ nhận 201 Created cùng object vừa tạo. Đây là cách bạn kiểm tra chức năng "tạo mới".

Bước 3 — Viết assertion tự động. Đây là bước biến Postman từ công cụ "gửi tay" thành công cụ test. Vào tab Tests (hoặc Scripts → Post-response ở bản mới) và viết:

pm.test("Status code là 201", function () {
    pm.response.to.have.status(201);
});
pm.test("Response có trả về id", function () {
    const data = pm.response.json();
    pm.expect(data.id).to.exist;
});pm.test("Thời gian phản hồi dưới 1 giây", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Bấm Send, kéo xuống tab Test Results — bạn sẽ thấy 3 dòng xanh PASSED. Từ giờ mỗi lần chạy request, Postman tự kiểm tra thay bạn.

Bước 4 — Dùng Environment và biến. Tạo một Environment tên "Staging", thêm biến base_url = https://jsonplaceholder.typicode.com. Trong request, thay URL cứng bằng {{base_url}}/posts. Giờ khi chuyển sang môi trường production, bạn chỉ đổi giá trị biến, không phải sửa từng request. Đây là cách team thật quản lý dev/staging/prod.

Bước 5 — Lưu và truyền token tự động. Trong request login, ở tab Tests thêm:

const token = pm.response.json().token;
pm.environment.set("auth_token", token);

Ở các request cần xác thực, vào tab Headers, thêm Authorization = Bearer {{auth_token}}. Postman sẽ tự điền token mới nhất.

Bước 6 — Gom vào Collection và chạy hàng loạt. Tạo một Collection, kéo các request vào theo thứ tự (login → tạo → đọc → xóa). Bấm Run Collection, Postman chạy tuần tự tất cả và tổng hợp kết quả pass/fail. Đây chính là "bộ test API" đầu tiên của bạn — nền tảng để sau này chạy tự động bằng Newman trên CI/CD.

Lỗi thường gặp & mẹo

Nhầm giữa "gửi được request" và "test API". Rất nhiều người mới nghĩ bấm Send thấy response là xong. Không — test chỉ thật sự tồn tại khi bạn viết assertion. Không có assertion thì không có test, chỉ là thao tác thủ công.
Quên kiểm tra status code. Đừng chỉ nhìn body. Một API trả 200 với body rỗng, hoặc 500 mà bạn không để ý, đều là lỗi. Luôn khẳng định status code trước tiên.
Chỉ test happy path. Người mới hay chỉ test trường hợp đúng. Hãy test cả trường hợp sai: gửi thiếu trường bắt buộc (mong đợi 400), gửi token sai (mong đợi 401), lấy id không tồn tại (mong đợi 404). Lỗi thật thường nằm ở các đường biên này.
Hardcode dữ liệu và token. Dùng biến environment thay vì gõ cứng URL, token. Vừa dễ chuyển môi trường, vừa tránh test gãy khi token đổi.
Không kiểm tra kiểu và cấu trúc dữ liệu. price trả về là "100" (chuỗi) hay 100 (số)? Sự khác biệt này gây bug nghiêm trọng ở phía client. Hãy assert cả kiểu dữ liệu, không chỉ giá trị.
Mẹo — dùng tab Console của Postman. Khi request lỗi khó hiểu, mở Console (View → Show Postman Console) để xem chính xác request đã gửi đi gồm gì. 90% trường hợp bạn sẽ thấy ngay header hay body sai.
Mẹo — dùng biến động cho dữ liệu unique. Postman có {{$randomEmail}}, {{$timestamp}} để tạo dữ liệu không trùng, tránh lỗi "email đã tồn tại" khi chạy test nhiều lần.

Bài tập thực hành

Hãy dành khoảng 60–90 phút cho bài tập sau, dùng API https://reqres.in (một API giả lập miễn phí cho luyện tập):

Tạo request GET lấy danh sách user: GET https://reqres.in/api/users?page=2. Viết assertion kiểm tra status 200 và kiểm tra mảng data có đúng 6 phần tử.
Tạo request POST tạo user mới với body { "name": "Nguyen Van A", "job": "QA Engineer" }. Assert status 201 và kiểm tra response có trả về id và createdAt.
Test trường hợp lỗi: gọi POST https://reqres.in/api/register chỉ với { "email": "test@test.com" } (thiếu password). Assert status 400 và kiểm tra response chứa thông báo lỗi.
Dùng Environment: tạo biến base_url, thay tất cả URL cứng bằng {{base_url}}.
Gom lại thành Collection tên "Bai tap Bai 1" và bấm Run Collection, chụp lại màn hình kết quả pass/fail.

Câu hỏi tự ngẫm sau khi làm: nếu là dự án thật, bạn còn muốn test thêm những trường hợp nào mà bài tập chưa nhắc tới? (Gợi ý: email trùng, phân trang ngoài giới hạn, thời gian phản hồi.)

Tóm tắt

Trong bài đầu tiên này, bạn đã hiểu vì sao API testing là tầng test có giá trị cao nhất trong automation: nhanh hơn UI, ổn định hơn, test thẳng vào business logic, và bắt buộc phải có với kiến trúc microservices phổ biến ở các công ty Việt Nam. Bạn đã nắm được cấu trúc một HTTP request (method, URL, headers, body) và response (status code, body, response time) — nền tảng bắt buộc trước khi làm bất cứ điều gì với API.

Quan trọng hơn, bạn đã thực hành với Postman: gửi request, viết assertion bằng JavaScript để test tự động, dùng Environment và biến để quản lý môi trường, tự động truyền token, và gom mọi thứ vào Collection để chạy hàng loạt. Ba tình huống thực tế cho thấy API testing giúp bắt lỗi giá sớm, xử lý xác thực đúng cách, và bảo vệ hợp đồng dữ liệu giữa các microservices.

Hãy nhớ nguyên tắc vàng: không có assertion thì không có test. Bấm Send chỉ là thao tác; test thật sự bắt đầu khi bạn khẳng định response phải như thế nào. Ở các bài tiếp theo, chúng ta sẽ mở rộng nền tảng này — từ tự động hóa Postman bằng Newman, đến viết API test bằng code với REST Assured và pytest. Nhưng tư duy cốt lõi bạn xây hôm nay sẽ theo bạn suốt cả hành trình.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi