Postman Advanced Features — API Testing with Postman Advanced

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

Nếu bạn đang đọc bài này, tôi đoán rằng bạn đã dùng Postman ở mức "cơ bản": mở app, gõ một URL, chọn method GET hoặc POST, bấm Send, rồi nhìn response trả về. Điều đó hoàn toàn ổn khi bạn mới bắt đầu. Nhưng khi bạn bước vào một dự án thật — một API có hàng chục endpoint, chạy trên nhiều môi trường, được nhiều người trong team cùng test — thì cách dùng "gõ tay từng cái" sẽ khiến bạn kiệt sức và mắc lỗi liên tục.

Đây là bài mở màn của cả một khóa học nâng cao. Vai trò của nó không phải dạy bạn một tính năng cụ thể nào đến tận cùng, mà là vẽ ra bức tranh toàn cảnh: Postman ở mức chuyên nghiệp thực chất là một bộ công cụ gồm nhiều mảnh ghép phối hợp với nhau. Bạn cần hiểu các mảnh ghép đó là gì, chúng giải quyết vấn đề nào, và chúng liên kết ra sao — trước khi đào sâu từng mảnh trong các bài sau.

Hãy tưởng tượng bạn là QA tại một công ty fintech ở TP.HCM. Sáng thứ Hai, sếp nhắn: "Team backend vừa deploy version mới lên staging, em test lại toàn bộ luồng thanh toán giúp anh, xong thì chạy lại trên production sau khi release nhé." Nếu bạn phải sửa tay từng URL từ staging sang production, dán lại token đăng nhập vào 20 request, rồi tự mắt so sánh từng response — bạn sẽ mất cả buổi và vẫn có nguy cơ sót lỗi. Postman nâng cao sinh ra chính là để biến buổi sáng đó thành vài cú click. Đó là lý do bài này quan trọng.

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

Ở mức nâng cao, Postman không còn là "công cụ gửi request" mà là một nền tảng test API với các thành phần chính sau. Tôi sẽ giới thiệu tổng quan để bạn nắm được vai trò của từng thứ; mỗi thành phần này sẽ có riêng một hoặc nhiều bài chuyên sâu về sau.

1. Collection — nơi tổ chức các request

Collection là một "thư mục thông minh" chứa nhóm các request liên quan. Thay vì để 50 request rời rạc, bạn gom chúng theo nghiệp vụ: nhóm "Authentication", nhóm "Đơn hàng", nhóm "Thanh toán". Collection cho phép bạn chạy toàn bộ nhóm một lượt (Collection Runner), gắn mô tả tài liệu, và chia sẻ nguyên cụm cho đồng nghiệp chỉ bằng một link. Đây là đơn vị làm việc trung tâm của mọi thứ nâng cao trong Postman.

2. Environment — quản lý cấu hình theo môi trường

Đây là tính năng "đổi đời" đầu tiên bạn cần nắm. Một API thường tồn tại ở nhiều môi trường: dev (máy lập trình viên), staging (môi trường thử nghiệm giống thật), và production (môi trường thật khách hàng dùng). Mỗi môi trường có URL khác nhau, khóa API khác nhau. Environment cho phép bạn khai báo các giá trị này một lần, rồi chỉ cần đổi môi trường trên dropdown là toàn bộ request tự dùng đúng cấu hình.

Ví dụ một Environment "Dev" có thể trông như thế này:

// Dev Environment
{
  "base_url": "http://localhost:3000",
  "api_key": "dev_key_abc123",
  "timeout": "5000"
}

Và Environment "Production":

// Production Environment
{
  "base_url": "https://api.vietnamcos.com",
  "api_key": "prod_key_xyz789",
  "timeout": "3000"
}

Trong request, thay vì gõ URL cứng, bạn viết {{base_url}}/orders. Postman sẽ tự thay {{base_url}} bằng giá trị của môi trường đang được chọn. Đổi từ Dev sang Production = một cú click, và toàn bộ request đổi theo. (Chi tiết cách dựng dev/staging/prod sẽ ở Bài 5.)

3. Variables — biến để tái sử dụng giá trị

Biến (variable) là thứ giúp bạn không phải lặp lại và không phải sửa tay. Có nhiều phạm vi (scope) khác nhau: biến toàn cục (global), biến môi trường (environment), biến collection, và biến cục bộ trong lúc chạy. Ký hiệu chung là dấu ngoặc nhọn kép {{ten_bien}}. Bạn dùng biến để lưu URL gốc, token đăng nhập, ID vừa tạo ra... rồi tái sử dụng ở request khác. (Các loại và phạm vi biến được mổ xẻ ở Bài 6.)

4. Scripting — Postman biết chạy code

Đây là điều khiến người mới ngạc nhiên nhất: Postman chạy được JavaScript. Có hai điểm bạn có thể chèn code:

Pre-request Script: chạy trước khi gửi request — dùng để chuẩn bị dữ liệu, tạo chữ ký, sinh timestamp.
Tests Script: chạy sau khi nhận response — dùng để kiểm tra (assertion) kết quả có đúng không, và lưu giá trị ra biến.

Toàn bộ khả năng tự động hóa nâng cao — kiểm tra status code, validate cấu trúc JSON, nối nhiều request thành một luồng — đều dựa trên scripting này. (Pre-request ở Bài 7, Tests ở Bài 8, toàn bộ API pm.* ở Bài 9.)

5. Collection Runner — chạy hàng loạt

Thay vì bấm Send từng request, Collection Runner chạy cả collection theo thứ tự, tự động, và báo cáo request nào pass/fail. Đây là bước đầu tiên biến việc test thủ công thành test tự động. Kết hợp với dữ liệu từ file CSV/JSON, bạn có thể chạy cùng một request với hàng trăm bộ dữ liệu khác nhau.

6. Các thành phần mở rộng khác

Postman còn có Mock Server (giả lập API khi backend chưa xong), Monitor (chạy collection theo lịch để giám sát), Newman (chạy collection ngoài command line để cắm vào CI/CD), và Flows (workflow trực quan). Bạn chưa cần dùng ngay, nhưng nên biết chúng tồn tại để định hình lộ trình học.

Điểm mấu chốt bạn cần rút ra: các thành phần này không rời rạc mà xâu chuỗi với nhau. Environment cấp giá trị cho Variables → Variables được dùng trong request và trong Script → Script kiểm tra response và lưu biến mới → Collection Runner chạy tất cả → Newman đưa lên CI/CD. Hiểu được sợi dây liên kết này chính là "tư duy nâng cao" mà cả khóa hướng tới.

Tình huống thực tế

Tình huống 1: Cô QA và 20 lần dán token

Lan là QA mới vào một startup giao đồ ăn tại Hà Nội. API của công ty yêu cầu mọi request phải kèm token đăng nhập trong header. Ban đầu, mỗi buổi sáng Lan gọi request /login để lấy token, rồi copy chuỗi token dài loằng ngoằng đó, dán tay vào header của từng request trong số 20 request cô cần test. Token hết hạn sau một giờ, nên đến trưa cô phải làm lại toàn bộ.

Sau khi học về Environment và Tests Script, Lan làm khác: cô thêm một dòng vào phần Tests của request /login:

// Trong Tests của request /login
const token = pm.response.json().access_token;
pm.environment.set("auth_token", token);

Từ đó, mọi request khác chỉ cần đặt header Authorization: Bearer {{auth_token}}. Mỗi sáng Lan bấm /login một lần, token tự động được lưu vào biến môi trường, và cả 20 request dùng chung. Bài học rút ra: sự kết hợp giữa Script (để trích và lưu giá trị) với Variable (để tái sử dụng) loại bỏ hoàn toàn thao tác copy-paste thủ công lặp đi lặp lại — thứ vừa tốn thời gian vừa dễ sai.

Tình huống 2: Fintech và cú suýt gọi nhầm production

Một công ty ví điện tử ở TP.HCM có ba môi trường. Bạn Minh, QA của team, test tính năng hoàn tiền (refund) trên staging. Trước đây, URL được gõ cứng trong từng request kiểu https://staging-api.vidien.vn/refund. Một hôm cần test trên production, Minh sửa tay URL từng request — và ở request thứ 8, anh quên chưa đổi lại về staging cho lần test tiếp theo. Kết quả: một lệnh refund test suýt bắn thẳng vào hệ thống thật.

Sau sự cố, team chuẩn hóa bằng Environment. Mỗi request chỉ dùng {{base_url}}/refund. Muốn test staging thì chọn Environment "Staging" trên dropdown; muốn production thì chọn "Production". Không còn URL cứng, không còn nguy cơ "sửa nửa chừng". Họ còn đặt màu và tên rõ ràng cho Environment production để nhắc nhở "cẩn thận, đây là môi trường thật". Bài học rút ra: gõ cứng cấu hình vào từng request không chỉ tốn công mà còn nguy hiểm. Environment tập trung cấu hình về một chỗ, giảm rủi ro nhầm lẫn giữa các môi trường — cực kỳ quan trọng với hệ thống dính tới tiền.

Tình huống 3: Test một luồng, không phải một request

Tại một sàn thương mại điện tử giả định tên GreenMart, QA cần test luồng đặt hàng: (1) đăng nhập → (2) tạo giỏ hàng → (3) thêm sản phẩm → (4) thanh toán. Bốn bước này phụ thuộc nhau: bước 2 cần token của bước 1, bước 3 cần cart_id của bước 2, bước 4 cần cả hai.

Ở mức cơ bản, người ta chạy tay từng bước, mắt nhìn response, copy cart_id sang bước sau. Ở mức nâng cao, GreenMart gom bốn request vào một Collection theo đúng thứ tự, mỗi request có Tests Script lưu giá trị cần thiết ra biến (pm.environment.set("cart_id", ...)), rồi request sau dùng lại {{cart_id}}. Cuối cùng họ bấm Collection Runner chạy một phát cả bốn bước. Bài học rút ra: Postman nâng cao cho phép bạn test một luồng nghiệp vụ hoàn chỉnh một cách tự động, chứ không chỉ từng request đơn lẻ. Đây chính là nền tảng của "chained requests" mà bạn sẽ học sâu ở Bài 11.

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

Hãy làm quen bằng một bài thực hành nhỏ, đi qua đúng những mảnh ghép cốt lõi. Ta sẽ dùng một API công khai miễn phí để thử: https://jsonplaceholder.typicode.com.

Bước 1 — Tạo một Collection. Ở thanh bên trái, bấm biểu tượng "+" hoặc "New Collection". Đặt tên "API Nâng Cao - Thực Hành". Đây là nơi chứa mọi request bạn sắp tạo.

Bước 2 — Tạo một Environment. Bấm vào biểu tượng con mắt (Environments) hoặc "New Environment". Đặt tên "Demo". Thêm một biến:

base_url với giá trị https://jsonplaceholder.typicode.com

Nhớ bấm Save, rồi chọn "Demo" ở dropdown môi trường góc trên bên phải.

Bước 3 — Tạo request dùng biến. Trong Collection vừa tạo, thêm request mới. Ở ô URL, gõ {{base_url}}/posts/1 với method GET. Chú ý Postman sẽ tô màu {{base_url}} — di chuột vào để xác nhận nó đang trỏ đúng giá trị. Bấm Send. Bạn sẽ nhận về một bài post dạng JSON.

Bước 4 — Thêm Tests Script. Chuyển sang tab "Tests" (hoặc "Scripts" → "Post-response" ở bản Postman mới). Dán đoạn sau:

pm.test("Status code là 200", function () {
    pm.response.to.have.status(200);
});
pm.test("Response có trường title", function () {
    const data = pm.response.json();
    pm.expect(data).to.have.property("title");
});// Lưu userId để request sau dùng lại
pm.environment.set("saved_user_id", pm.response.json().userId);

Bấm Send lại. Mở tab "Test Results" ở khu vực response — bạn sẽ thấy hai dòng màu xanh PASS. Đây là lần đầu bạn để Postman tự kiểm tra thay vì mắt nhìn.

Bước 5 — Tái sử dụng biến vừa lưu. Tạo request thứ hai: GET {{base_url}}/users/{{saved_user_id}}. Bấm Send. Postman tự điền ID mà request trước đã lưu. Bạn vừa nối hai request thành một chuỗi phụ thuộc — nguyên lý cốt lõi của test luồng.

Bước 6 — Chạy cả Collection. Bấm chuột phải vào Collection → "Run collection". Postman mở Collection Runner, liệt kê các request. Bấm "Run" và xem toàn bộ chạy tuần tự, kèm báo cáo pass/fail. Chúc mừng — bạn vừa đi trọn vòng: Environment → Variable → Request → Test → Runner.

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

Quên chọn Environment. Lỗi phổ biến nhất của người mới: viết {{base_url}} nhưng không chọn môi trường nào ở dropdown. Kết quả là biến rỗng, URL biến thành /posts/1 và request lỗi. Mẹo: luôn liếc dropdown môi trường góc trên bên phải trước khi Send. Nếu thấy "No Environment", hãy chọn lại.

Nhầm giữa biến rỗng và biến chưa định nghĩa. Khi di chuột vào {{ten_bien}}, nếu Postman hiện màu đỏ hoặc "unresolved variable", nghĩa là biến đó chưa tồn tại ở phạm vi đang chọn. Kiểm tra xem bạn đã tạo biến đúng nơi chưa (environment vs collection vs global).

Lẫn lộn Pre-request và Tests. Nhiều bạn viết code lưu token vào tab Tests của chính request /login — đúng, vì tab Tests chạy sau khi có response. Nhưng nếu bạn viết code cần chạy trước (ví dụ sinh timestamp cho request hiện tại), phải đặt ở Pre-request. Nhớ quy tắc: Pre-request = trước khi gửi, Tests = sau khi nhận.

Gõ cứng giá trị nhạy cảm vào request. Đừng bao giờ dán thẳng API key hay token vào URL/header rồi lưu collection và chia sẻ — bạn sẽ vô tình lộ bí mật cho cả team hoặc lên Git. Hãy đưa chúng vào biến môi trường (và ở mức cao hơn là Postman Vault, sẽ học ở Bài 21).

Mẹo dùng Console. Postman có Console riêng (menu View → Show Postman Console, hoặc biểu tượng góc dưới trái). Nó cho bạn thấy request thực sự được gửi đi trông ra sao sau khi biến đã được thay thế — cực kỳ hữu ích khi debug biến không như mong đợi. Dùng console.log() trong script để in giá trị ra đây.

Mẹo đặt tên rõ ràng. Đặt tên request và collection theo nghiệp vụ ("Đăng nhập", "Tạo đơn", chứ không phải "request1", "test copy 2"). Khi collection lớn dần, tên rõ ràng cứu bạn khỏi mê cung.

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

Dựng bộ khung riêng. Tạo một Collection tên "Luyện tập cá nhân" và hai Environment: "Local" (base_url = http://localhost:3000) và "Public" (base_url = https://jsonplaceholder.typicode.com). Tạo một request GET {{base_url}}/posts và thử đổi qua lại hai môi trường, quan sát request đổi theo.

Viết assertion đầu tay. Với request trên, thêm Tests kiểm tra: (a) status code là 200, (b) response là một mảng, (c) mảng có nhiều hơn 5 phần tử. Gợi ý: dùng pm.expect(pm.response.json()).to.be.an('array') và .length.

Nối hai request. Tạo request POST {{base_url}}/posts với body JSON bất kỳ. Trong Tests, lưu id trả về vào biến new_post_id. Tạo request thứ hai GET {{base_url}}/posts/{{new_post_id}}. Chạy lần lượt và xác nhận request thứ hai dùng đúng ID.

Suy ngẫm. Viết ra 3-4 câu: trong công việc (hoặc dự án học) của bạn, chỗ nào bạn đang làm thủ công lặp đi lặp lại mà một trong các thành phần vừa học (Environment, Variable, Script, Runner) có thể tự động hóa? Ghi lại để đối chiếu khi học các bài sau.

Tóm tắt

Bài này không dạy bạn một thủ thuật đơn lẻ, mà đặt nền tư duy cho cả khóa: Postman ở mức chuyên nghiệp là một bộ công cụ liên kết, không phải một nút Send. Bạn đã gặp mặt các mảnh ghép cốt lõi — Collection để tổ chức, Environment để quản lý cấu hình dev/staging/prod, Variables để tái sử dụng giá trị, Scripting (Pre-request và Tests) để Postman tự chạy code và tự kiểm tra, và Collection Runner để chạy hàng loạt — cùng các thành phần mở rộng như Mock Server, Monitor, Newman, Flows mà bạn sẽ đào sâu sau.

Điều quan trọng nhất cần mang theo: những thành phần này xâu chuỗi với nhau thành một dây chuyền tự động — Environment cấp biến, biến chảy vào request và script, script kiểm tra rồi lưu biến mới, Runner chạy tất cả. Qua ba tình huống thực tế — cô QA thoát khỏi việc dán token, công ty fintech tránh gọi nhầm production, sàn GreenMart test trọn luồng đặt hàng — bạn đã thấy giá trị thật của tư duy này: nhanh hơn, an toàn hơn, ít sai sót hơn. Ở các bài kế tiếp, ta sẽ mổ xẻ từng mảnh ghép đến tận cùng, bắt đầu từ Advanced Assertions và Mock Servers. Hãy giữ vững bức tranh tổng thể này làm la bàn.

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