Postman & Newman — automation cho non-coder — Automation Testing Introduction

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

Trong hầu hết các đội QA ở Việt Nam mà tôi từng làm việc, có một sự thật hơi phũ phàng: phần lớn tester không phải là developer. Nhiều bạn xuất thân từ chuyên ngành khác, giỏi phân tích nghiệp vụ, giỏi tư duy test case, nhưng khi nghe đến "viết code Java để automation API" thì rào cản tâm lý dựng lên ngay. Kết quả là toàn bộ việc automation API bị dồn hết cho một hai bạn biết code, còn lại thì mãi test tay.

Đây chính là chỗ Postman và Newman toả sáng. Postman cho bạn một giao diện đồ hoạ để gọi API, tổ chức request, gắn assertion (kiểm chứng) mà gần như không cần biết lập trình bài bản. Newman là công cụ dòng lệnh giúp chạy lại toàn bộ những gì bạn đã tạo trong Postman một cách tự động — nghĩa là bạn có thể đưa chúng vào lịch chạy hằng đêm hoặc vào pipeline mà không cần mở tay.

Bài này tập trung đúng một chủ đề: biến Postman thành một bộ automation API thực thụ cho người "không code", và dùng Newman để chạy nó ngoài giao diện. Chúng ta sẽ không đi vào REST Assured hay pytest (đó là các bài riêng), mà khai thác tối đa sức mạnh của bộ đôi Postman + Newman — thứ mà một tester Việt Nam có thể làm chủ trong vài ngày.

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

Collection — trái tim của mọi thứ

Một Collection là một nhóm các request API liên quan được gom lại. Hãy hình dung nó như một thư mục chứa toàn bộ kịch bản test cho một tính năng. Ví dụ, với hệ thống bán hàng, bạn có thể có collection "Order Flow" chứa các request: đăng nhập, thêm sản phẩm vào giỏ, tạo đơn hàng, xem chi tiết đơn, huỷ đơn.

Trong collection, bạn tổ chức request theo folder để phản ánh luồng nghiệp vụ. Điều tuyệt vời là collection có thể export ra một file JSON duy nhất — chính file này là thứ Newman sẽ đọc để chạy tự động. Nói cách khác, mọi công sức bạn bỏ vào Postman đều "đóng gói" được và tái sử dụng ở nơi khác.

Environment và Variable — tách dữ liệu khỏi request

Đây là khái niệm phân biệt người dùng Postman nghiệp dư với người dùng chuyên nghiệp. Thay vì hardcode https://api.shop.vn/v1/orders trong từng request, bạn tạo biến {{base_url}} và định nghĩa giá trị của nó trong Environment.

Postman có nhiều tầng biến:

Environment variable: khác nhau giữa các môi trường. Bạn tạo environment "Staging" với base_url = https://staging-api.shop.vn và environment "Production" với base_url = https://api.shop.vn. Chỉ cần đổi environment ở góc phải là toàn bộ collection trỏ sang môi trường khác.
Collection variable: dùng chung cho cả collection, không phụ thuộc môi trường (ví dụ một hằng số nghiệp vụ).
Global variable: dùng chung mọi nơi — hạn chế dùng vì dễ gây rối.
Local/data variable: sinh ra trong lúc chạy, ví dụ từ file dữ liệu CSV (sẽ nói ở phần sau).

Cú pháp gọi biến ở bất cứ đâu là hai cặp ngoặc nhọn: {{ten_bien}}. Bạn dùng được trong URL, header, body, thậm chí trong script.

Pre-request Script — chạy TRƯỚC khi gửi request

Đây là đoạn JavaScript nhỏ chạy ngay trước khi request được gửi đi. Đừng sợ chữ "script" — bạn không cần biết lập trình sâu, chỉ cần vài dòng mẫu. Công dụng phổ biến nhất:

Sinh dữ liệu động: ví dụ tạo một email ngẫu nhiên để đăng ký, tránh trùng.
Tạo timestamp, chữ ký (signature) cho các API cần ký request — rất hay gặp với cổng thanh toán.

Ví dụ đơn giản, đặt vào tab Pre-request Script:

// Sinh email ngẫu nhiên và lưu vào biến để body dùng
const random = Date.now();
pm.environment.set("test_email", "user" + random + "@test.vn");

Sau đó trong body request, bạn viết "email": "{{test_email}}". Mỗi lần chạy sẽ có email khác nhau.

Test Script — chạy SAU khi có response

Đây là phần biến Postman từ "công cụ gọi API" thành "công cụ automation". Sau khi response trả về, đoạn Test Script (tab Tests, hoặc "Scripts > Post-response" ở bản Postman mới) sẽ kiểm chứng response có đúng như kỳ vọng không. Postman cung cấp thư viện pm với cú pháp gần như tiếng Anh:

// Kiểm tra mã trạng thái là 200
pm.test("Status code la 200", function () {
    pm.response.to.have.status(200);
});
// Kiểm tra response có trường order_id
pm.test("Co order_id trong response", function () {
    const json = pm.response.json();
    pm.expect(json.order_id).to.exist;
});// Kiểm tra thời gian phản hoi duoi 800ms
pm.test("Phan hoi nhanh", function () {
    pm.expect(pm.response.responseTime).to.be.below(800);
});

Mỗi pm.test(...) là một assertion. Khi chạy, Postman và Newman sẽ báo PASS/FAIL cho từng cái. Đây chính là "test case tự động" của bạn.

Chaining request — nối các request thành luồng

Một điểm mạnh nữa: bạn có thể lấy dữ liệu từ response của request trước để dùng cho request sau. Ví dụ, request "Đăng nhập" trả về token, bạn lưu nó:

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

Rồi trong header của các request tiếp theo, bạn đặt Authorization: Bearer {{access_token}}. Nhờ vậy toàn bộ luồng "đăng nhập → tạo đơn → xem đơn" chạy liền mạch mà không cần copy token bằng tay.

Newman — chạy collection ngoài giao diện

Newman là công cụ dòng lệnh (command-line) của Postman, cài qua Node.js. Nó nhận vào file collection (và file environment) rồi chạy tất cả request + test, in kết quả ra terminal hoặc xuất báo cáo. Đây là chiếc cầu nối để đưa bộ test Postman của bạn vào chạy tự động hằng đêm hoặc trong pipeline mà không cần con người bấm nút. Newman chính là thứ biến "test tay có tổ chức" thành "automation thật sự".

Tình huống thực tế

Tình huống 1: Tiki và bài toán regression API cho non-coder

Giả định một đội QA ở một sàn thương mại điện tử lớn như Tiki có 6 tester, trong đó chỉ 1 bạn biết code. Mỗi lần backend release, họ phải kiểm tra lại khoảng 40 API cốt lõi: đăng nhập, danh mục, tìm kiếm, giỏ hàng, đặt hàng, tra cứu đơn. Trước đây làm tay mất gần một ngày công, và hay bỏ sót.

Team leader quyết định để 5 bạn không code cùng xây một collection Postman "Core Regression". Mỗi bạn phụ trách một nhóm API, tự viết request và thêm khoảng 3–4 assertion mỗi request (kiểm status, kiểm trường dữ liệu quan trọng, kiểm thời gian phản hồi). Họ dùng environment "Staging" và "Prod" để tách URL.

Bài học rút ra: chỉ sau hai tuần, 40 API có gần 150 assertion. Việc chia nhỏ theo folder giúp 5 người làm song song mà không giẫm chân nhau. Không ai phải viết một dòng Java nào. Đây là minh chứng rằng automation API không nhất thiết phải bắt đầu từ framework code phức tạp.

Tình huống 2: Một fintech và luồng ký request cho cổng thanh toán

Một công ty fintech ở TP.HCM tích hợp cổng thanh toán, mỗi request gọi sang đối tác đều phải kèm một chữ ký signature được tính từ các tham số + secret key theo thuật toán HMAC. Ban đầu tester phải mở một công cụ online để tính chữ ký bằng tay cho từng bộ tham số — cực kỳ mất thời gian và dễ sai.

Bạn tester phụ trách đã đưa phần tính chữ ký vào Pre-request Script bằng thư viện CryptoJS có sẵn trong Postman:

const params = "amount=50000&orderId=" + pm.environment.get("order_id");
const secret = pm.environment.get("secret_key");
const signature = CryptoJS.HmacSHA256(params, secret).toString();
pm.environment.set("signature", signature);

Sau đó body chỉ cần tham chiếu {{signature}}. Từ chỗ mất 5 phút mỗi request để tính tay, giờ chữ ký được sinh tự động, và bộ test 20 kịch bản thanh toán chạy hết trong chưa đầy một phút bằng Newman.

Bài học rút ra: Pre-request Script không phải thứ xa xỉ dành cho lập trình viên. Với vài dòng mẫu, nó giải quyết đúng những bài toán "khó nhằn" của tester Việt Nam khi làm việc với API cần ký, cần token, cần dữ liệu động.

Tình huống 3: Newman chạy hằng đêm ở một startup SaaS

Một startup SaaS ở Đà Nẵng có API phục vụ khách hàng Đông Nam Á, cần đảm bảo các endpoint quan trọng luôn sống. Họ không có QA automation engineer chuyên trách, nhưng bạn QA lead đã export collection "Smoke Test" (12 request thiết yếu) và đặt một máy chủ nhỏ chạy Newman lúc 6 giờ sáng mỗi ngày qua cron:

newman run smoke.postman_collection.json \
  -e production.postman_environment.json \
  --reporters cli,htmlextra

Nếu có bất kỳ assertion nào FAIL, Newman trả về exit code khác 0, và một script nhỏ sẽ gửi cảnh báo vào nhóm Telegram của team. Có lần lúc 6 giờ sáng, API tìm kiếm trả về lỗi 500 vì một thay đổi database đêm trước — team biết ngay trước khi khách hàng thức dậy và mở app.

Bài học rút ra: giá trị lớn nhất của Newman là biến công sức Postman "một lần" thành giá trị "lặp lại mỗi ngày". Một QA không cần biết Jenkins hay Docker cũng có thể dựng một smoke test tự động bằng cron + Newman + một webhook Telegram.

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

Bước 1 — Tạo Collection và Environment. Trong Postman, tạo collection mới (ví dụ "Order Flow"). Tạo environment "Staging" với biến base_url. Nhớ chọn environment này ở góc trên phải trước khi chạy.

Bước 2 — Xây request đầu tiên với biến. Tạo request POST {{base_url}}/login với body chứa tài khoản test. Đừng hardcode URL — luôn dùng biến để sau này đổi môi trường dễ dàng.

Bước 3 — Thêm Test Script để lưu token. Vào tab Tests, kiểm tra status 200 và lưu token vào environment như ví dụ chaining ở trên. Bấm Send, kiểm tra ở tab "Test Results" xem assertion có PASS không.

Bước 4 — Nối các request phía sau. Với request tạo đơn, đặt header Authorization: Bearer {{access_token}}. Thêm assertion kiểm tra order_id tồn tại và lưu nó lại để request "xem chi tiết đơn" dùng.

Bước 5 — Chạy toàn bộ bằng Collection Runner. Bấm "Run collection" trong Postman để chạy tuần tự tất cả request và xem báo cáo PASS/FAIL tổng hợp ngay trong giao diện. Đây là bước kiểm tra trước khi đưa ra Newman.

Bước 6 — Export. Export collection ra file .json và export environment ra file .json riêng. Lưu ý: KHÔNG export secret thật ra file dùng chung.

Bước 7 — Cài và chạy Newman. Cài Node.js, rồi cài Newman:

npm install -g newman
npm install -g newman-reporter-htmlextra
newman run order-flow.postman_collection.json \
  -e staging.postman_environment.json \
  --reporters cli,htmlextra

Mở file HTML báo cáo được sinh ra để xem chi tiết từng request và assertion.

Bước 8 — Đưa vào lịch chạy tự động. Với cron trên Linux hoặc Task Scheduler trên Windows, đặt lệnh Newman chạy định kỳ. Dùng exit code của Newman để quyết định có gửi cảnh báo hay không.

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

Quên chọn environment. Lỗi phổ biến nhất: chạy request thấy URL thành //login vì {{base_url}} rỗng. Luôn kiểm tra environment đang chọn ở góc phải.
Nhầm Test Script với Pre-request Script. Nhớ nguyên tắc: Pre-request chạy TRƯỚC (chuẩn bị dữ liệu), Tests chạy SAU (kiểm chứng response). Đặt code assertion vào Pre-request thì sẽ không có response để kiểm.
Hardcode dữ liệu nhạy cảm rồi commit lên Git. Đừng bao giờ để secret key, token thật trong file environment rồi đẩy lên repo. Dùng biến môi trường của hệ thống, hoặc file environment riêng không commit.
Test quá lỏng. Nhiều bạn chỉ kiểm status 200 là xong. Hãy kiểm cả nội dung: đúng trường dữ liệu, đúng kiểu, đúng giá trị nghiệp vụ. Một API trả 200 nhưng body rỗng vẫn là lỗi.
Không tách data khỏi test. Nếu cần chạy cùng một request với nhiều bộ dữ liệu, dùng biến {{...}} trong request và một file CSV/JSON làm nguồn dữ liệu, rồi truyền qua -d data.csv cho Newman. Đây là cách "data-driven" nhẹ nhàng ngay trong Postman.
Mẹo môi trường sạch: thêm một request "teardown" ở cuối collection để xoá dữ liệu test đã tạo (ví dụ huỷ đơn hàng test), tránh làm bẩn database staging sau nhiều lần chạy.
Mẹo báo cáo đẹp: reporter htmlextra cho báo cáo trực quan, dễ đính kèm khi báo cáo cho quản lý hoặc lưu bằng chứng test.

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

Tạo một collection "Auth Flow" với 3 request: đăng ký (dùng Pre-request Script sinh email ngẫu nhiên), đăng nhập (lưu token vào environment), và lấy thông tin tài khoản (dùng token đó ở header). Với mỗi request thêm tối thiểu 2 assertion.
Tạo 2 environment "Staging" và "Local" khác nhau về base_url, rồi chạy cùng collection trên cả hai để chứng minh việc tách biến hoạt động.
Export collection và environment, cài Newman, chạy bằng dòng lệnh với reporter htmlextra, và mở file báo cáo HTML. Chụp lại phần kết quả PASS/FAIL.
Nâng cao: chuẩn bị một file users.csv với 3 dòng dữ liệu đăng nhập (2 hợp lệ, 1 sai mật khẩu), chạy Newman với cờ -d users.csv và quan sát assertion PASS/FAIL cho từng dòng.

Tóm tắt

Postman + Newman là con đường ngắn nhất để một tester "không code" bước vào automation API. Bạn tổ chức request thành Collection, tách dữ liệu bằng Environment và biến {{...}}, chuẩn bị dữ liệu động bằng Pre-request Script, và kiểm chứng response bằng Test Script với thư viện pm gần như tiếng Anh. Khi bộ test đã hoàn chỉnh trong giao diện, Newman đưa nó ra dòng lệnh để chạy lặp lại tự động — hằng đêm, theo lịch, hoặc kèm cảnh báo. Ba tình huống thực tế cho thấy bộ đôi này giải quyết được từ regression 40 API, luồng ký request cổng thanh toán, đến smoke test hằng đêm — tất cả mà không cần một framework code phức tạp. Hãy bắt đầu nhỏ với vài request, thêm assertion thật chặt, và bạn sẽ ngạc nhiên về khoảng cách rất ngắn giữa "test tay" và "automation".

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