Postman Inspector & Network Debugging

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

Hãy tưởng tượng bạn vừa viết một test script trong Postman, bấm Send, và test báo đỏ (failed). Nhưng bạn không hiểu vì sao. Response trông có vẻ đúng, script cũng đúng, vậy mà nó vẫn fail. Bạn ngồi nhìn màn hình 20 phút, thử đủ mọi cách, thêm console.log() rồi... không thấy gì hiện ra. Cuối cùng bạn gõ tin nhắn cho leader: "Anh ơi, test em không chạy được".

Đây là câu chuyện quen thuộc của gần như mọi người mới học Postman. Và trong 90% trường hợp, nguyên nhân là: bạn chưa biết dùng Postman Console và các công cụ debug đi kèm. Bạn đang test "mù" — chỉ nhìn thấy phần response mà Postman hiển thị đẹp đẽ, còn toàn bộ chuyện xảy ra bên dưới (request thực sự được gửi đi như thế nào, header nào được đính kèm, biến nào được thay thế thành giá trị gì, redirect bao nhiêu lần, cookie nào được set) thì hoàn toàn ẩn.

Postman Console là "hộp đen máy bay" của mọi API tester. Khi mọi thứ hoạt động trơn tru, bạn không cần nó. Nhưng khi có sự cố — mà trong nghề test thì sự cố là chuyện hằng ngày — nó là công cụ đầu tiên và quan trọng nhất để bạn tìm ra sự thật. Một tester biết đọc Console giải quyết bug trong 2 phút; một tester không biết thì mất cả buổi chiều và thường kết thúc bằng việc đổ lỗi cho... backend.

Bài này dạy bạn cách mở, đọc, và khai thác Postman Console cùng các công cụ network debugging đi kèm, để bạn không bao giờ phải test mù nữa.

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

Postman Console là gì

Postman Console là một cửa sổ log riêng, ghi lại mọi hoạt động mạng thực tế mà Postman thực hiện. Điểm khác biệt then chốt bạn phải nắm: phần Response tab mà bạn thấy sau khi Send là phiên bản đã được xử lý và làm đẹp của kết quả cuối cùng. Còn Console cho bạn thấy raw traffic — dữ liệu thô đúng như nó đi qua dây mạng.

Console hiển thị cho mỗi request:

• Request line thực sự: method, URL đầy đủ (đã thay biến), giao thức HTTP.
• Request headers: bao gồm cả những header Postman tự động thêm (như User-Agent, Postman-Token, Content-Length) mà bạn không hề khai báo.
• Request body: nội dung thực gửi đi, sau khi biến đã được thay thế.
• Response status, headers, body: nguyên bản.
• Network timing: DNS lookup, TCP handshake, TLS, thời gian tải.
• Redirect chain: nếu server trả 301/302, Console cho thấy từng chặng.
• Console log từ script: mọi console.log(), console.warn(), console.error() bạn viết trong Pre-request Script hay Tests.

Hai loại "response" bạn cần phân biệt

Đây là điểm gây nhầm lẫn nhiều nhất. Trong Response tab, khi API trả JSON, Postman tự động format cho đẹp, tô màu cú pháp, thậm chí "sửa" một số thứ hiển thị. Còn trong Console, bạn thấy chuỗi byte gốc. Sự khác biệt này quan trọng khi bạn nghi ngờ có ký tự lạ, khoảng trắng thừa, BOM (Byte Order Mark), hay encoding sai — những thứ Response tab che giấu nhưng Console phơi bày.

Console log level

Trong script, bạn có bốn cấp độ log, hiển thị màu khác nhau trong Console giúp lọc nhanh:

• console.log() — thông tin thường (trắng/xám).
• console.info() — thông tin (xanh dương).
• console.warn() — cảnh báo (vàng).
• console.error() — lỗi (đỏ).

Thói quen tốt: dùng console.error() cho những điểm kiểm tra quan trọng để dễ lọc trong một collection chạy hàng trăm request.

Tình huống thực tế

Ví dụ 1 — Biến bị "undefined" ở sàn thương mại điện tử Tiki-style

Chị Hằng, QA tại một công ty thương mại điện tử ở TP.HCM (giả định gọi là ShopViet), viết một chained request: request đầu đăng nhập lấy token, request thứ hai dùng token đó gọi API giỏ hàng. Request thứ hai liên tục trả về 401 Unauthorized. Chị chắc chắn token đúng vì request đăng nhập trả 200.

Chị mở Postman Console (View → Show Postman Console), chạy lại cả luồng, và nhìn vào request thứ hai. Console phơi bày sự thật ngay trong Request Headers:

Authorization: Bearer {{access_token}}

Token không được thay thế — nó vẫn là chuỗi literal {{access_token}}. Response tab không bao giờ cho chị thấy header gửi đi, nên chị đã "test mù" suốt 30 phút. Nguyên nhân: script lưu token viết là pm.environment.set("accessToken", ...) (camelCase) nhưng header dùng {{access_token}} (snake_case). Sai tên biến, Postman gửi nguyên chuỗi placeholder.

Bài học: khi gặp lỗi auth hoặc biến, việc đầu tiên là mở Console và nhìn request headers thực sự gửi đi. Nếu thấy {{...}} còn nguyên, biến của bạn không tồn tại hoặc sai tên/sai scope.

Ví dụ 2 — Redirect ngầm nuốt mất POST body

Anh Dũng làm ở một startup fintech tại Hà Nội, test API tạo giao dịch. Anh gửi POST https://api.startup.vn/transactions với body JSON đầy đủ, nhưng server trả về 400 Bad Request với message "body is empty". Anh copy y hệt request đó vào một request mới, vẫn lỗi.

Mở Console, anh thấy điều bất ngờ: có hai dòng request cho một lần Send. Dòng đầu:

POST http://api.startup.vn/transactions  →  301 Moved Permanently

Dòng sau:

GET https://api.startup.vn/transactions  →  400

Server chuyển hướng từ http sang https (301), và theo chuẩn HTTP, khi follow redirect trình khách đổi POST thành GET, làm mất luôn body. Response tab chỉ cho anh thấy kết quả cuối 400 mà giấu hoàn toàn chặng redirect. Console phơi bày toàn bộ chain. Anh sửa URL thành https:// ngay từ đầu, và giao dịch tạo thành công.

Bài học: Console là công cụ duy nhất cho bạn thấy redirect chain. Khi POST/PUT trả kết quả kỳ lạ như "body rỗng" dù bạn đã gửi body, hãy nghi ngờ redirect và xác nhận trong Console. Có thể tắt tự động follow redirect trong Settings để kiểm soát.

Ví dụ 3 — Ký tự tiếng Việt hỏng vì encoding

Bạn Linh test API tìm kiếm sản phẩm cho một chuỗi siêu thị, gõ từ khóa "cà phê". API trả về 0 kết quả, dù trên web app tìm bình thường. Response tab hiển thị request URL là ?q=cà phê — trông đúng. Nhưng trong Console, cùng URL đó hiện raw:

GET https://api.market.vn/search?q=c%C3%A0%20ph%C3%AA

Đây là URL-encoding đúng của UTF-8. Vấn đề nằm ở response: Console cho thấy Content-Type: text/html; charset=ISO-8859-1 thay vì charset=UTF-8, và body chứa cà phê — dấu hiệu kinh điển của mojibake (lỗi giải mã ký tự). Nhờ Console, Linh xác định lỗi thuộc về backend cấu hình sai charset, chứ không phải test script của cô. Cô báo bug kèm ảnh chụp Console làm bằng chứng — dev không thể chối.

Bài học: với dữ liệu tiếng Việt, Console là nơi duy nhất bạn thấy được raw bytes và charset header thật, giúp phân định lỗi thuộc test hay thuộc hệ thống.

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

Bước 1 — Mở Postman Console. Có ba cách:

• Menu: View → Show Postman Console.
• Phím tắt: Cmd + Option + C (macOS) hoặc Ctrl + Alt + C (Windows/Linux).
• Biểu tượng console nhỏ ở góc dưới bên trái cửa sổ Postman (icon > _).

Console mở ra trong một cửa sổ riêng. Nên đặt nó cạnh cửa sổ chính để vừa Send vừa quan sát.

Bước 2 — Xóa log cũ trước khi test. Bấm nút thùng rác (Clear) trong Console. Việc này cực kỳ quan trọng: khi debug, bạn chỉ muốn thấy log của lần chạy hiện tại, không lẫn với hàng trăm dòng cũ.

Bước 3 — Gửi request và đọc từ trên xuống. Sau khi Send, mở entry request tương ứng trong Console. Mỗi entry có thể bung ra (expand) để xem Request Headers, Request Body, Response Headers, Response Body và Network info. Kiểm tra theo thứ tự:

• URL và method đã đúng chưa (biến đã thay thế chưa).
• Request headers — đặc biệt Authorization, Content-Type.
• Request body — đúng nội dung, đúng format chưa.
• Response status và body thô.

Bước 4 — Rải console.log() chiến lược trong script. Trong Pre-request hoặc Tests, in ra các giá trị bạn nghi ngờ:

const token = pm.environment.get("accessToken");
console.log("Token đang dùng:", token);
const body = pm.response.json();
console.log("Response body:", body);
pm.test("Status is 200", function () {
    console.log("Status thực tế:", pm.response.code);
    pm.response.to.have.status(200);
});

Những dòng này hiện trong Console, cho bạn thấy chính xác giá trị tại thời điểm chạy — thứ bạn không thể đoán bằng mắt.

Bước 5 — Dùng bộ lọc (filter). Console có ô search và bộ lọc theo log level. Trong một collection lớn, gõ tên endpoint hoặc lọc theo error để nhảy thẳng đến request có vấn đề.

Bước 6 — Đọc Network timing khi nghi ngờ chậm. Bung mục network của một entry, bạn thấy phân rã thời gian: DNS, Connect (TCP), TLS, và thời gian nhận response. Nếu một request chậm bất thường, timing chỉ cho bạn nút thắt nằm ở đâu — DNS chậm khác hoàn toàn với server xử lý chậm.

Bước 7 — Bật/tắt cấu hình liên quan. Trong Settings → General, các tùy chọn ảnh hưởng debug: "Automatically follow redirects" (tắt để tự kiểm soát redirect), "Send anonymous usage data", "SSL certificate verification" (tắt khi test server nội bộ dùng self-signed cert — Console sẽ báo lỗi TLS nếu bật).

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

Không thấy console.log() hiện ra. Nguyên nhân phổ biến nhất: bạn viết console.log() ở nhầm chỗ, hoặc script có lỗi cú pháp khiến dòng log không bao giờ chạy tới. Kiểm tra tab Tests/Pre-request có báo lỗi đỏ không. Ngoài ra, đảm bảo bạn đang mở đúng Postman Console chứ không phải DevTools của trình duyệt — hai thứ khác nhau hoàn toàn.

Nhầm Console với Response tab. Nhớ nguyên tắc: Response tab để xem kết quả đã làm đẹp; Console để xem sự thật thô. Khi hai bên có vẻ mâu thuẫn, Console luôn đúng.

Quên clear log, đọc nhầm request cũ. Rất nhiều người debug một lỗi đã sửa xong nhưng vẫn thấy "fail" vì đang đọc entry của lần chạy trước. Luôn Clear trước mỗi lần debug.

Log ra object mà chỉ thấy [object Object]. Khi cần xem cấu trúc, dùng console.log(JSON.stringify(obj, null, 2)) để in đẹp, dễ đọc hơn nhiều so với in object trực tiếp trong một số phiên bản.

Bỏ sót header Postman tự thêm. Postman âm thầm thêm Postman-Token, User-Agent, Accept-Encoding: gzip, deflate, br. Nếu API của bạn kỳ thị header lạ hoặc bạn cần request "sạch" giống production, hãy nhìn Console để biết chính xác cái gì được gửi, rồi tắt bớt trong Settings.

Mẹo dọn log tự động: ở đầu Pre-request Script của collection, thêm console.clear() để mỗi lần chạy collection log tự sạch — hữu ích khi chạy bằng Collection Runner.

Mẹo phân biệt lỗi mạng vs lỗi ứng dụng: nếu Console báo Error: getaddrinfo ENOTFOUND → DNS/URL sai. ECONNREFUSED → server không chạy hoặc sai port. ETIMEDOUT → firewall/mạng. Còn nếu có status code trả về (4xx/5xx) → đã kết nối được, lỗi nằm ở tầng ứng dụng.

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

• Bắt biến chưa thay thế. Tạo một request với header Authorization: Bearer {{token}} nhưng cố tình không set biến token. Send, mở Console, và tìm dòng header cho thấy {{token}} còn nguyên. Chụp lại làm quen với cách Console phơi bày biến hỏng.

• Quan sát redirect chain. Gửi một GET http://github.com (chú ý dùng http). Trong Console, đếm xem có bao nhiêu chặng redirect trước khi tới https://github.com và mỗi chặng trả status gì.

• Log có cấu trúc. Viết một Tests script gọi API bất kỳ trả JSON, dùng console.info(), console.warn(), console.error() để in ba loại thông tin khác nhau. Quan sát màu sắc và dùng bộ lọc log level để chỉ hiện dòng error.

• So sánh raw vs formatted. Gọi một API trả JSON, so sánh body trong Response tab (đã format) với body trong Console (thô). Ghi lại điểm khác biệt về khoảng trắng, thứ tự, ký tự.

• Debug timing. Gọi cùng một endpoint 5 lần, đọc network timing trong Console mỗi lần, ghi lại DNS/Connect/TLS/Total. Nhận xét vì sao lần đầu thường chậm hơn (do chưa cache DNS/kết nối).

Tóm tắt

Postman Console là công cụ debug tích hợp mạnh nhất và bị bỏ quên nhiều nhất. Nó là ranh giới giữa một tester "test mù" và một tester chuyên nghiệp. Ba điều cần khắc cốt:

• Response tab cho bạn kết quả đã làm đẹp; Console cho bạn sự thật thô. Khi có nghi ngờ, tin Console.
• Mở Console (Cmd/Ctrl + Alt + C), Clear trước khi test, đọc từ trên xuống: URL → request headers → request body → response. Đây là quy trình phản xạ khi gặp bất kỳ lỗi nào.
• Rải console.log() chiến lược để nhìn thấy giá trị biến, token, body tại thời điểm chạy — đừng bao giờ đoán.

Console phơi bày những thứ Response tab che giấu: biến chưa thay thế, redirect chain nuốt body, header Postman tự thêm, charset sai làm hỏng tiếng Việt, và network timing. Từ giờ, mỗi khi một test báo đỏ mà bạn không hiểu vì sao, phản xạ đầu tiên phải là: mở Console lên đã. Đó là dấu hiệu bạn đã trưởng thành trong nghề API testing.