Cách sử dụng Postman kiểm thử API chuyên nghiệp

Postman là công cụ phổ biến để gửi request tới API, xem phản hồi, tổ chức các request thành bộ sưu tập (collection), viết script kiểm tra tự động và chạy cả bộ kiểm thử trong pipeline CI/CD. Dùng Postman chuyên nghiệp nghĩa là không chỉ bấm Send từng request, mà tổ chức collection theo tài nguyên, tách cấu hình theo môi trường bằng biến, tự động lấy token xác thực, viết assertion cho mỗi request và chạy chúng tự động mỗi lần deploy. Bài hướng dẫn này đi từ thao tác đầu tiên đến quy trình kiểm thử API hoàn chỉnh.

Cài đặt và giao diện

Postman có ứng dụng desktop cho Windows, macOS, Linux và bản web. Cần tài khoản để đồng bộ dữ liệu. Giao diện chính gồm: thanh bên chứa Collections, Environments, History; khu vực soạn request (phương thức, URL, Params, Authorization, Headers, Body, Scripts); khu vực phản hồi (body, mã trạng thái, thời gian, kích thước, headers, kết quả test).

Gửi request đầu tiên

1. Tạo request mới, chọn phương thức GET, nhập URL của endpoint danh sách.
2. Thêm tham số truy vấn ở tab Params (ví dụ page, limit); Postman tự ghép vào URL.
3. Bấm Send, xem mã trạng thái, thời gian phản hồi và body JSON.
4. Với POST, chọn tab Body, kiểu raw JSON, nhập dữ liệu và kiểm tra header Content-Type.

Hiểu ý nghĩa mã trạng thái và cấu trúc tài nguyên giúp kiểm thử có trọng tâm; nguyên tắc thiết kế được trình bày trong bài xây dựng hệ thống API RESTful chuẩn.

Tổ chức collection

Collection là nơi lưu các request liên quan, chia thư mục theo tài nguyên hoặc luồng nghiệp vụ:

• Auth: đăng nhập, làm mới token.
• Users: tạo, xem, sửa, xóa người dùng.
• Orders: tạo đơn, xem đơn, hủy đơn.
• Luồng đầu cuối: đăng nhập, tạo đơn, thanh toán, kiểm tra trạng thái.

Viết mô tả cho collection và từng request (hỗ trợ Markdown) để collection trở thành tài liệu sống cho cả đội. Postman cũng nhập được đặc tả OpenAPI để sinh collection tự động.

Environment và biến

Không gõ cứng địa chỉ máy chủ hay token vào request. Dùng biến với cú pháp hai dấu ngoặc nhọn, ví dụ {{baseUrl}}/orders.

Tạo environment Local, Staging; chuyển môi trường bằng menu thả xuống là toàn bộ collection chạy với máy chủ tương ứng. Hạn chế tối đa việc chạy kiểm thử ghi dữ liệu trên production.

Xác thực tự động

Ở tab Authorization của collection, chọn kiểu (Bearer Token, OAuth 2.0, API Key, Basic) và để request con kế thừa. Một mẫu phổ biến: request Login có script sau phản hồi lưu token vào biến môi trường; các request khác dùng biến token đó. Với OAuth 2.0, Postman có trình hỗ trợ lấy token theo các luồng chuẩn.

Viết test script

Tab Scripts (Post-response) cho phép viết JavaScript chạy sau khi nhận phản hồi, dùng hàm pm.test và thư viện assertion có sẵn. Những kiểm tra nên có:

• Mã trạng thái đúng như mong đợi (200, 201, 404...).
• Thời gian phản hồi dưới ngưỡng chấp nhận.
• Body có đúng trường, đúng kiểu; có thể kiểm tra theo JSON Schema.
• Giá trị nghiệp vụ: đơn vừa tạo có trạng thái "chờ thanh toán", tổng tiền đúng.
• Header quan trọng như Content-Type.

Script trước request (Pre-request) dùng để tạo dữ liệu động: sinh email ngẫu nhiên, tính chữ ký, đặt thời gian. Kết quả request trước có thể lưu vào biến để request sau dùng, ví dụ lưu mã đơn vừa tạo để gọi API xem chi tiết.

Kiểm thử các trường hợp tiêu cực và bảo mật

Kiểm thử chuyên nghiệp không chỉ thử đường đi thuận lợi:

• Thiếu trường bắt buộc, sai kiểu, chuỗi quá dài phải trả 400 với thông báo rõ.
• Không có token hoặc token hết hạn phải trả 401.
• Người dùng A gọi tài nguyên của người dùng B phải bị từ chối (403 hoặc 404).
• Gọi quá nhiều lần phải bị giới hạn (429).
• Phản hồi lỗi không lộ stack trace, câu SQL.

Những kiểm tra này gắn với các rủi ro trong bài bảo mật ứng dụng web theo OWASP Top 10.

Chạy tự động: Collection Runner và Newman

• Collection Runner: chạy cả collection hoặc thư mục theo thứ tự, lặp nhiều lần với dữ liệu từ file CSV/JSON, xem báo cáo pass/fail.
• Newman: công cụ dòng lệnh chạy collection đã xuất ra file, phù hợp tích hợp vào pipeline. Có thể xuất báo cáo dạng JUnit, HTML.
• Postman CLI: công cụ dòng lệnh chính thức mới hơn, gắn với tài khoản Postman.

Đưa bước chạy bộ kiểm thử API vào pipeline sau khi deploy lên staging giúp phát hiện lỗi hồi quy trước khi lên production; xem bài hướng dẫn thiết lập CI/CD pipeline.

Mock server và giám sát

Khi backend chưa xong, đội mobile hoặc frontend vẫn có thể làm việc nhờ mock server: Postman trả về phản hồi mẫu đã lưu trong collection cho từng request, giúp hai bên phát triển song song dựa trên cùng hợp đồng API. Ngược lại, khi API đã chạy thật, tính năng giám sát (monitor) cho phép chạy collection theo lịch từ cloud và cảnh báo khi test thất bại hoặc phản hồi chậm, như một lớp kiểm tra sức khỏe đơn giản cho các endpoint quan trọng.

Làm việc nhóm và giữ an toàn thông tin

• Dùng workspace nhóm, phân quyền xem và sửa.
• Lưu token, mật khẩu trong biến kiểu secret hoặc Postman Vault, không để trong collection chia sẻ; chú ý giá trị "initial" của biến được đồng bộ lên cloud, còn giá trị "current" thì không.
• Không đặt workspace chứa thông tin nội bộ ở chế độ công khai; đã có nhiều trường hợp khóa API bị lộ qua workspace công khai.
• Xuất collection vào kho mã (Git) để quản lý phiên bản cùng mã nguồn.

Công cụ thay thế đáng biết

Insomnia, Bruno (lưu collection dạng file văn bản trong kho mã, không cần tài khoản cloud), Hoppscotch (mã nguồn mở, chạy trên web), tiện ích REST Client và Thunder Client trong VS Code. Với kiểm thử tự động thuần code, các thư viện như REST Assured (Java), pytest kết hợp requests (Python), supertest (Node.js) phù hợp hơn khi bộ test lớn.