Mở đầu — vì sao bài này quan trọng
Có một cái bẫy mà gần như tester nào cũng rơi vào ít nhất một lần trong đời: sau khi thành thạo Postman, viết được collection đẹp, chạy được Newman, họ bắt đầu tự hỏi — "Postman mạnh thế này, hay là dùng luôn nó để test performance cho tiện, đỡ phải học thêm JMeter hay k6?". Nghe rất hợp lý. Cùng một công cụ, cùng một collection đã có sẵn, chỉ cần bấm thêm nút "chạy nhiều người dùng" là ra kết quả tải, quá tiện.
Từ giữa năm 2024, Postman còn "tiếp tay" cho suy nghĩ này khi ra mắt tính năng Performance Testing ngay trong Collection Runner. Bạn chỉ cần chuột phải vào collection, chọn "Run performance test", đặt số virtual users, thời lượng — và Postman sẽ mô phỏng nhiều người dùng ảo gọi API đồng thời. Từ đó rất nhiều người kết luận: "Vậy là Postman thay được JMeter/k6 rồi!".
Bài này tồn tại để đưa bạn ra khỏi cái bẫy đó một cách tỉnh táo. Tôi sẽ chỉ cho bạn tính năng Performance của Postman làm được gì, làm được đến đâu, và — quan trọng hơn — nó không làm được gì. Hiểu đúng ranh giới này giúp bạn tránh hai sai lầm đắt giá: một là dùng nhầm công cụ rồi báo cáo sai năng lực hệ thống cho sếp; hai là học thừa, ôm đồm khi thực ra Postman đã đủ cho nhu cầu "smoke performance" nhẹ nhàng. Đây là bài về giới hạn và sự phù hợp của công cụ — một kỹ năng phán đoán mà tester giỏi nào cũng phải có.
Khái niệm cốt lõi
Performance testing thực chất là gì
Trước khi bàn công cụ, phải rõ mục tiêu. Performance testing (kiểm thử hiệu năng) là họ các bài test đo cách hệ thống hành xử dưới tải. Nó gồm nhiều nhánh:
- Load test: tải kỳ vọng ở mức bình thường/cao điểm, xem hệ thống có giữ được thời gian phản hồi và tỉ lệ lỗi trong ngưỡng chấp nhận không.
- Stress test: đẩy tải vượt ngưỡng để tìm điểm gãy — hệ thống sập ở đâu, sập như thế nào.
- Spike test: tăng tải đột ngột (ví dụ mở bán vé concert đúng 12h trưa) rồi rút nhanh.
- Soak/endurance test: giữ tải trung bình trong nhiều giờ để phát hiện rò rỉ bộ nhớ, tích tụ connection.
Postman Performance làm được đến đâu
Tính năng Performance của Postman (2024) hoạt động như sau: nó lấy các request trong collection, mô phỏng nhiều virtual user (VU) chạy song song ngay trên máy tính của bạn, theo một trong vài kiểu tải (fixed — số VU cố định; ramp up — tăng dần; spike; peak). Bạn xem được biểu đồ response time trung bình, throughput, error rate theo thời gian, và Postman còn ghi lại một số run để so sánh.
Với nhu cầu nhỏ, đây là công cụ tuyệt vời để làm smoke performance test — kiểm tra nhanh xem một endpoint mới có sập ngay khi có, ví dụ, 20 người dùng đồng thời hay không. Nó tích hợp sẵn, không cần viết code mới, tận dụng đúng collection bạn đã build. Đây chính xác là chủ đề của bài học riêng về "Performance Smoke với Postman" ở phần sau khóa; ở bài này ta chỉ nhìn nó dưới góc độ giới hạn.
Ba giới hạn mang tính bản chất
1. Chạy trên một máy, dùng chung một Node.js event loop. Postman (kể cả Newman) là ứng dụng Node.js chạy trên máy bạn. Toàn bộ VU "ảo" thực ra là các tác vụ bất đồng bộ chia sẻ một tiến trình, một event loop. Khi số VU tăng cao, chính máy tính của bạn (và event loop) trở thành nút thắt cổ chai trước cả server. Bạn nghĩ mình đang đo server, nhưng thực ra đang đo... laptop của mình. JMeter (đa luồng, có distributed mode) và k6 (viết bằng Go, mỗi VU là một goroutine nhẹ) sinh tải cao hơn nhiều lần trên cùng phần cứng.
2. Không có tải phân tán (distributed load). Test tải nghiêm túc cần sinh request từ nhiều máy/nhiều vùng để đạt hàng chục nghìn VU và để mô phỏng người dùng ở nhiều nơi. JMeter có master–slave; k6 có k6 Cloud và chạy được trên nhiều pod Kubernetes. Postman Performance chỉ chạy cục bộ, một máy — trần của nó thấp hơn hẳn.
3. Chỉ số kém sâu và khó tự động hóa theo ngưỡng. k6 cho bạn viết thresholds (ví dụ: p95 < 500ms, error rate < 1%) và tự fail pipeline CI nếu vi phạm — cực kỳ quan trọng cho performance gate tự động. JMeter cho báo cáo percentile chi tiết, assertion theo thời gian đáp ứng, tích hợp Grafana. Postman Performance đưa biểu đồ đẹp để bạn nhìn bằng mắt, nhưng khó đặt ngưỡng pass/fail cứng và khó nhét vào CI như một cổng chất lượng thực thụ.
Vậy ranh giới nằm ở đâu
Hãy ghi nhớ nguyên tắc: Postman/Newman là công cụ functional/integration testing xuất sắc; performance chỉ là tính năng phụ trợ cho smoke test nhẹ. Khi bạn cần con số để ra quyết định về hạ tầng ("hệ thống chịu được bao nhiêu người dùng đồng thời trước Black Friday?"), bạn cần công cụ chuyên dụng: JMeter hoặc k6. Postman giúp bạn phát hiện có vấn đề hay không ở quy mô nhỏ; JMeter/k6 giúp bạn đo chính xác đến đâu ở quy mô thật.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử ở TP.HCM và cú "flash sale 12h trưa"
Một sàn TMĐT tầm trung tại TP.HCM (giả định tên ChợViệt) chuẩn bị cho đợt flash sale 12h trưa ngày đôi 6/6. Team QA có sẵn bộ collection Postman test API giỏ hàng và thanh toán. Một bạn tester quyết định "test performance luôn cho tiện": bấm Run performance test với 50 VU trên chính laptop của mình.
Kết quả: response time trung bình 180ms, không lỗi. Bạn báo cáo lên "API chịu tải tốt". Đến trưa 6/6, khi ~8.000 người bấm mua cùng lúc, endpoint checkout timeout hàng loạt, hàng bán được rớt xuống chỉ vì hệ thống nghẽn ở tầng kết nối database.
Bài học rút ra: 50 VU trên một laptop không nói được gì về 8.000 người dùng thật. Con số "180ms" bị giới hạn bởi chính máy sinh tải, và quy mô test cách quy mô thật tới hai bậc độ lớn. Với kịch bản spike cần hàng nghìn VU từ nhiều máy, đây là địa hạt của k6 Cloud hoặc JMeter distributed — Postman chỉ nên dùng để smoke trước đó nhằm bắt lỗi hiển nhiên.
Ví dụ 2 — Fintech Singapore đặt performance gate trong CI
Một công ty fintech ở Singapore (giả định PayNimbus) có quy định: mọi service mới muốn deploy phải qua performance gate tự động — p95 dưới 400ms và error rate dưới 0,5% ở mức 200 request/giây duy trì trong 5 phút, nếu không pipeline tự chặn.
Ban đầu team thử dùng Newman chạy performance trong GitLab CI, nhưng vấp hai vấn đề: một là runner CI chỉ một node, không sinh nổi 200 req/s ổn định; hai là Postman không cho họ khai báo ngưỡng để pipeline tự fail. Họ chuyển sang k6: viết script với block thresholds: { http_req_duration: ['p(95)<400'], http_req_failed: ['rate<0.005'] }, chạy trên vài pod trong CI. k6 tự trả exit code khác 0 khi vi phạm, GitLab tự chặn merge.
Bài học rút ra: khi performance là một cổng pass/fail tự động với ngưỡng cụ thể, k6 đúng công cụ vì nó sinh ra để làm chuyện đó. Postman vẫn được giữ lại — nhưng cho functional test và smoke check, đúng vai của nó.
Ví dụ 3 — Startup dùng đúng chỗ Postman Performance để tiết kiệm
Một startup SaaS nhỏ (giả định Học Nhanh, ~500 người dùng) mới thêm endpoint xuất báo cáo PDF, nghi ngờ nó nặng. QA không có thời gian dựng JMeter/k6, nên dùng luôn Postman Performance: 15 VU, ramp up 2 phút. Sau 30 giây, response time nhảy từ 300ms lên 9 giây và một số request 500 — lộ ngay chuyện endpoint sinh PDF đồng bộ và không có giới hạn concurrency.
Họ vá lỗi (chuyển sang hàng đợi bất đồng bộ) chỉ trong buổi chiều, hoàn toàn nhờ một smoke performance test 5 phút. Với quy mô 500 user, họ không cần dựng hạ tầng tải phân tán.
Bài học rút ra: dùng đúng chỗ, Postman Performance là món hời — bắt lỗi hiển nhiên nhanh, chi phí gần bằng không. Cái sai không phải là dùng nó, mà là nhầm nó với công cụ đo năng lực hệ thống ở quy mô sản xuất.
Hướng dẫn từng bước
Dưới đây là quy trình phán đoán và thao tác thực tế.
Bước 1 — Xác định bạn thật sự cần loại test gì. Tự hỏi: mình muốn bắt lỗi hiển nhiên khi có vài chục người dùng (smoke) hay đo năng lực chịu tải thật để ra quyết định hạ tầng (load/stress/spike thật)? Câu trả lời quyết định công cụ, không phải sự tiện tay.
Bước 2 — Nếu là smoke ở quy mô nhỏ, dùng Postman Performance. Trong Postman: chuột phải vào collection → chọn Run performance test. Cấu hình:
- Virtual users: bắt đầu nhỏ, ví dụ 10–20.
- Test duration: 1–5 phút.
- Load profile: chọn Fixed để giữ VU cố định, hoặc Ramp up để tăng dần và quan sát điểm gãy.
Bước 3 — Đọc kết quả có phê phán. Luôn tự nhắc: con số này bị chặn trần bởi máy bạn và event loop của Node.js. Nếu error rate tăng vọt hay response time phình lên ở mức VU thấp → đây là tín hiệu tốt, bạn đã bắt được vấn đề. Nếu mọi thứ "xanh mượt" ở 20 VU → đừng kết luận hệ thống chịu được 20.000 người.
Bước 4 — Nếu là load/stress/spike thật, chuyển sang công cụ chuyên dụng.
- Chọn k6 nếu team quen JavaScript, cần thresholds tự fail trong CI, muốn code-based và nhẹ.
- Chọn JMeter nếu cần GUI kéo-thả, distributed master–slave, nhiều protocol (JDBC, JMS...), hệ sinh thái plugin/Grafana phong phú.
Bước 6 — Phân vai rõ ràng trong pipeline. Newman lo functional/regression trong CI; k6/JMeter lo performance gate. Đừng ép một công cụ ôm cả hai vai chỉ vì "cho tiện".
Lỗi thường gặp & mẹo
Lỗi 1 — Báo cáo con số tải từ một laptop như thể là năng lực production. Đây là lỗi nguy hiểm nhất vì nó tạo cảm giác an toàn giả. Mẹo: luôn ghi rõ trong báo cáo "test bằng Postman Performance, N VU, chạy cục bộ trên 1 máy — chỉ mang tính smoke, không phản ánh sức chịu tải thật".
Lỗi 2 — Không hiểu virtual user của Postman khác thread của JMeter/goroutine của k6. VU trong Postman chia sẻ event loop; đẩy VU quá cao thì bạn đo giới hạn của máy sinh tải, không phải server. Mẹo: nếu tăng VU mà throughput không tăng tương ứng và CPU máy bạn cạn kiệt, đó là dấu hiệu công cụ đã tới trần — dừng lại và chuyển công cụ.
Lỗi 3 — Tưởng Postman Performance đặt được ngưỡng pass/fail như k6 thresholds. Nó thiên về quan sát bằng mắt. Mẹo: nếu bạn cần performance gate tự chặn deploy, đó là tín hiệu rõ ràng phải dùng k6 (thresholds) hoặc JMeter (assertion + phân tích percentile).
Lỗi 4 — Bỏ qua yếu tố mạng và vị trí địa lý. Test từ laptop trong văn phòng ở Hà Nội tới server đặt tại Singapore sẽ có độ trễ mạng riêng, không đại diện cho người dùng thật rải khắp nơi. Mẹo: với đo tải nghiêm túc cần đại diện địa lý, dùng dịch vụ cloud (k6 Cloud) sinh tải từ nhiều vùng.
Lỗi 5 — Học thừa vì sợ. Ngược lại của lỗi 1: có bạn dựng cả cụm JMeter chỉ để kiểm tra một endpoint nội bộ 50 người dùng. Mẹo: chọn công cụ tương xứng quy mô. Smoke nhỏ thì Postman là đủ và nhanh nhất.
Mẹo tổng quát: dán một câu lên đầu tài liệu test performance của team: "Postman để biết CÓ vấn đề không; JMeter/k6 để biết CHỊU ĐƯỢC đến đâu." Câu này giải quyết 90% tranh cãi chọn công cụ.
Bài tập thực hành
- Smoke bằng Postman Performance. Lấy một collection có ít nhất một endpoint GET và một endpoint POST. Chạy performance test với 10 VU trong 2 phút ở chế độ Fixed, rồi 20 VU chế độ Ramp up. Ghi lại response time trung bình, throughput, error rate. Quan sát: khi tăng từ 10 lên 20 VU, throughput có tăng gấp đôi không? Nếu không, hãy giải thích tại sao (gợi ý: nghĩ về event loop và máy của bạn).
- Viết bảng phân vai công cụ. Cho 5 kịch bản sau, ghi rõ bạn chọn Postman Performance, JMeter, hay k6 và giải thích một câu: (a) kiểm tra nhanh endpoint mới trước khi merge; (b) đo p99 ở 10.000 VU cho ngày mở bán vé; (c) performance gate tự fail trong CI với p95 < 300ms; (d) soak test 6 giờ tìm rò rỉ bộ nhớ; (e) một dev muốn xem endpoint có sập ở 15 người dùng đồng thời không.
- Nhận diện báo cáo sai. Viết lại đoạn báo cáo giả định này cho đúng và trung thực: "Chúng tôi đã test performance bằng Postman và xác nhận hệ thống chịu được 30.000 người dùng đồng thời." — Chỉ ra sai ở đâu và diễn đạt lại cho chính xác về phạm vi.
- (Nâng cao) Nghiên cứu cú pháp
thresholdscủa k6 và viết ra ba ngưỡng bạn sẽ đặt cho một API thanh toán, kèm lý do vì sao Postman Performance không thay thế được ba ngưỡng đó.
Tóm tắt
- Từ 2024 Postman có tính năng Performance Testing (chuột phải collection → Run performance test), mô phỏng virtual users chạy cục bộ trên một máy với các profile Fixed/Ramp up/Spike/Peak.
- Nó tuyệt vời cho smoke performance ở quy mô nhỏ: tận dụng collection sẵn có, không cần code mới, bắt lỗi hiển nhiên nhanh.
- Nhưng nó không thay được JMeter/k6 vì ba giới hạn bản chất: chạy một máy/một event loop nên trần tải thấp; không có tải phân tán đa vùng; chỉ số kém sâu và khó đặt ngưỡng pass/fail tự động trong CI.
- Nguyên tắc vàng: Postman để biết CÓ vấn đề không; JMeter/k6 để biết CHỊU ĐƯỢC đến đâu. Chọn công cụ theo mục tiêu và quy mô, không theo sự tiện tay.
- Sai lầm đắt nhất là báo cáo con số từ một laptop như thể là năng lực production. Luôn ghi rõ phạm vi và điều kiện test.
- Postman và công cụ tải chuyên dụng bổ trợ nhau: khám phá/mô tả API bằng Postman, đo tải thật bằng k6 (thresholds tự fail CI) hoặc JMeter (distributed, percentile chi tiết) — thậm chí chuyển đổi collection sang script k6 để tái sử dụng công sức.