Postman cho người mới: Collection, environment và cách test API cơ bản

3 tháng trước · 9 phút đọc

Postman là gì và tại sao tester cần biết?

Mình nhớ lần đầu nghe dev nói "gọi API", mình ngơ ngác không hiểu gì. API testing nghe có vẻ phức tạp, nhưng thực ra với Postman, bạn không cần viết một dòng code nào vẫn test được.

Postman là công cụ giúp bạn gửi request tới server và xem response trả về - nôm na là bạn "nói chuyện" với backend mà không cần giao diện. Thay vì bấm nút trên app, bạn gõ trực tiếp lệnh vào Postman và kiểm tra xem server có trả về đúng không.

344941 (Postman - công cụ test API phổ biến nhất hiện nay)

Tại sao tester cần Postman? Vì có những lỗi backend không bao giờ thấy được qua giao diện. Dev fix bug phía server nhưng chưa cập nhật UI - bạn cần Postman để kiểm tra xem logic backend đã đúng chưa. Phần lớn job description QA/tester hiện nay yêu cầu kinh nghiệm API testing, nên đây là kỹ năng gần như bắt buộc nếu bạn muốn ứng tuyển.

Thêm nữa: Postman giúp bạn kiểm tra API độc lập với UI. Bug là ở frontend hay backend? Postman giúp bạn phân biệt rõ ngay.

Cài Postman và gửi request đầu tiên

Cài Postman đơn giản: tải về từ trang chủ, cài như phần mềm bình thường. Có thể dùng bản web (app.getpostman.com) mà không cần cài gì cả.

Sau khi mở lên, bạn sẽ thấy giao diện với thanh URL ở giữa. Đây là nơi bạn gõ địa chỉ API cần test.

344942 (Màn hình Postman với 4 vùng chính cần nhớ)

4 vùng cần biết trong Postman:

Method selector: Dropdown chọn GET, POST, PUT, DELETE - loại request bạn muốn gửi
URL bar: Địa chỉ API endpoint cần test
Request tabs: Params, Headers, Body, Auth - nơi thêm thông tin đính kèm
Response panel: Phía dưới, hiển thị kết quả server trả về

Thử ngay với một API công khai - không cần tài khoản, không cần xin ai:

Chọn method GET
Gõ URL: https://jsonplaceholder.typicode.com/posts/1
Nhấn nút Send màu cam

Bạn sẽ thấy ngay một đoạn JSON hiện ra ở phần Response. Đó là dữ liệu server trả về. Nếu thấy được đến đây - bạn vừa gửi API request đầu tiên thành công.

Không có gì phức tạp hơn vậy ở bước này. Mình nói thật: 90% công việc test API manual chỉ là thay đổi URL, method và xem response có đúng không.

Hiểu status code - đọc được kết quả test

Status code là con số 3 chữ số server trả về, cho bạn biết request thành công hay thất bại. Đây là thứ tester nhìn vào đầu tiên sau khi nhấn Send.

344943 (Status code - "tín hiệu" đầu tiên cần đọc sau mỗi lần gửi request)

Không cần nhớ hết 50+ status code. Chỉ cần nhớ 5 nhóm này:

Nhóm	Ý nghĩa	Ví dụ gặp thường
2xx	Thành công	200 OK, 201 Created
3xx	Chuyển hướng	301 Moved Permanently
4xx	Lỗi từ phía client	400 Bad Request, 401 Unauthorized, 404 Not Found
5xx	Lỗi từ phía server	500 Internal Server Error

Những code bạn sẽ gặp hàng ngày:

200: Mọi thứ ổn, đọc response bình thường
201: Tạo dữ liệu thành công (ví dụ: đăng ký user mới)
400: Request sai format - kiểm tra lại body bạn gửi
401: Chưa đăng nhập hoặc token hết hạn - cần xem lại phần Auth
403: Đã đăng nhập nhưng không có quyền - kiểm tra phân quyền
404: Endpoint không tồn tại - kiểm tra lại URL
422: Dữ liệu sai validation (ví dụ: email sai format, bỏ trống field bắt buộc)
500: Lỗi server - báo ngay cho dev, không phải lỗi bạn gây ra

Mẹo thực tế: Khi test một tính năng, mình không chỉ test happy path (gửi đúng, nhận 200). Mình còn cố tình gửi sai để xem server có trả về 400/422 đúng không. Nếu gửi email sai format mà server vẫn trả 200 - đó là bug.

Headers, body và auth - ba thứ gửi kèm request

Ngoài URL và method, mỗi request thường có thêm 3 phần đính kèm. Không hiểu 3 phần này thì test API không được.

Headers là thông tin meta đi kèm request. Thứ phổ biến nhất bạn sẽ gặp:

Content-Type: application/json
Authorization: Bearer eyJhbGci...
Accept: application/json

Content-Type: application/json nghĩa là bạn đang gửi dữ liệu dạng JSON. Thiếu dòng này, nhiều server sẽ không đọc được body và trả về 400. Mình từng mất 30 phút debug rồi mới phát hiện thiếu mỗi cái header này.

344944 (Headers, Body, Auth - 3 tab cần kiểm tra kỹ trước khi nhấn Send)

Body là dữ liệu bạn gửi lên server - chỉ có với POST, PUT, PATCH. Trong Postman, chọn tab Body → chọn raw → chọn JSON ở dropdown. Ví dụ tạo user mới:

{
  "name": "Nguyen Van A",
  "email": "[email protected]",
  "password": "Test@123"
}

Kiểm tra kỹ: tên field có khớp với API doc không? email hay Email? user_name hay username? Sai một ký tự là 400 ngay.

Auth (Authentication) là phần xác thực danh tính. Có vài cách phổ biến:

No Auth: API public, ai gọi cũng được
Bearer Token: Phổ biến nhất. Đăng nhập xong lấy token, gắn vào mọi request tiếp theo
Basic Auth: Username + password mã hóa base64, ít gặp hơn
API Key: Gắn key vào header hoặc URL param

Thực tế khi test: bạn sẽ test đủ 3 case - gửi request không có token (phải trả 401), gửi token hết hạn (phải trả 401), gửi token đúng (phải trả 200). Thiếu bất kỳ case nào là bug có thể bị bỏ sót.

Collection và environment - làm việc có tổ chức

Bạn đang test một app có 30 API endpoint. Lưu từng request rời rạc thì loạn ngay. Collection sinh ra để giải quyết chính xác vấn đề đó.

Collection là thư mục nhóm các request liên quan lại. Ví dụ:

📁 User Management
  ├── POST /register
  ├── POST /login
  ├── GET /profile
  └── PUT /update-profile

📁 Product
  ├── GET /products
  ├── POST /products
  └── DELETE /products/:id

344945 (Collection giúp bạn quản lý hàng chục API mà không bị loạn)

Tạo collection: nhấn nút New → chọn Collection → đặt tên → thêm request vào. Mỗi lần gửi request thành công, nhấn Save để lưu vào collection. Chia sẻ collection với team? Export ra file JSON và gửi cho nhau.

Environment giải quyết vấn đề khác: cùng 1 bộ API nhưng có 3 môi trường khác nhau.

Dev: https://dev-api.company.com - môi trường dev đang code
Staging: https://staging-api.company.com - môi trường test trước khi release
Production: https://api.company.com - môi trường thật, người dùng đang dùng

Thay vì sửa URL mỗi lần chuyển môi trường (và dễ nhầm), bạn tạo environment variable:

Tạo environment tên "Staging"
Thêm variable: base_url = https://staging-api.company.com
Trong request URL gõ: {{base_url}}/products
Muốn chuyển sang Dev? Chỉ cần đổi environment ở góc trên phải

Mình từng không dùng environment, cứ copy-paste URL thủ công. Một lần nhầm gửi request xóa dữ liệu lên production thay vì staging - may mắn là data test nên không ảnh hưởng. Từ đó mình không bao giờ bỏ qua bước tạo environment nữa.

Viết test cơ bản trong Postman với Tests tab

Gửi request và nhìn bằng mắt có trả về đúng không - được, nhưng chưa đủ. Postman có tab Tests cho bạn viết kiểm tra tự động ngay trong công cụ.

Không cần sợ từ "viết code". Tests trong Postman là JavaScript đơn giản, Postman đã viết sẵn các snippet - bạn chỉ cần chọn.

344946 (Tab Tests trong Postman - tự động kiểm tra mà không cần nhìn bằng mắt)

Bên phải tab Tests có mục Snippets. Click vào là tự sinh code. Những snippet hay dùng nhất:

Kiểm tra status code:

pm.test("Status code phải là 200", function () {
    pm.response.to.have.status(200);
});

Kiểm tra response time:

pm.test("Response trả về trong 2 giây", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

Kiểm tra giá trị trong response:

pm.test("Có trường email trong response", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.email).to.eql("[email protected]");
});

Sau khi nhấn Send, kết quả test hiện ở tab Test Results phía dưới - xanh là pass, đỏ là fail. Bạn có thể lưu lại kết quả này trong bug report.

Thực ra đây là bước đệm trước khi học automation testing. Nếu bạn muốn hiểu sâu hơn phần backend và API hoạt động như thế nào, khóa Node & ExpressJS giải thích khá chi tiết từ phía server - giúp bạn hiểu API được xây dựng ra sao, từ đó test kỹ hơn.