Postman Flows — visual API workflow

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

Nếu bạn đã đi qua các bài trước về Collection, Environment, Pre-request Scripts và Chained Requests, bạn hẳn đã quen với cách xâu chuỗi các request bằng cách viết JavaScript trong tab Tests: gọi pm.sendRequest, lưu biến, set pm.execution.setNextRequest, rồi chạy toàn bộ bằng Collection Runner. Cách này mạnh, nhưng có một điểm yếu mà bất kỳ ai từng bàn giao bộ test cho đồng đội đều thấm: logic workflow bị "chôn" trong code, nằm rải rác ở nhiều request, rất khó nhìn thấy toàn cảnh. Khi một bạn QA mới vào nhóm mở collection ra, họ thấy 15 request nhưng không hiểu request nào gọi trước, request nào phụ thuộc dữ liệu của request nào, và điều gì xảy ra nếu một bước thất bại.

Đây chính là khoảng trống mà Postman Flows ra đời để lấp. Flows là một trình soạn thảo trực quan (visual editor) cho phép bạn kéo-thả các khối (block) để mô tả một luồng API: request nào chạy trước, dữ liệu chảy từ đâu sang đâu, rẽ nhánh theo điều kiện nào, lặp qua danh sách ra sao — tất cả hiển thị dưới dạng sơ đồ node-and-edge (nút và đường nối) giống như một flowchart sống động. Thay vì đọc code để đoán luồng, bạn nhìn thấy luồng.

Bài này sẽ giúp bạn hiểu Flows là gì, khi nào nên dùng nó thay cho Collection Runner truyền thống, và quan trọng hơn — khi nào không nên dùng. Là một tester chuyên nghiệp, biết chọn đúng công cụ cho đúng bài toán còn quan trọng hơn biết dùng một công cụ hào nhoáng.

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

Flows là gì

Postman Flows là một canvas (khung vẽ) nơi bạn xây dựng workflow bằng cách nối các block lại với nhau. Mỗi block làm một việc: gửi một request, đánh giá một điều kiện, lặp qua một mảng, biến đổi dữ liệu, hoặc hiển thị kết quả. Dữ liệu di chuyển giữa các block qua các đường nối (connection), và bạn có thể "nhìn" thấy giá trị chảy qua từng chặng khi chạy.

Điểm khác biệt cốt lõi so với Collection Runner: Collection Runner chạy các request theo thứ tự tuyến tính (từ trên xuống dưới, có thể bẻ hướng bằng setNextRequest), còn Flows chạy theo mô hình dữ liệu (data-flow) — một block chỉ thực thi khi dữ liệu đầu vào của nó đã sẵn sàng. Điều này khiến việc rẽ nhánh, chạy song song và xử lý có điều kiện trở nên tự nhiên hơn nhiều.

So sánh Flows với Collection Runner

Bảng trên là kim chỉ nam. Ghi nhớ dòng cuối cùng: Flows chưa chạy được bằng Newman. Nếu quy trình CI/CD của bạn dựa trên Newman (mà đa số các bài sau trong khóa này sẽ dạy), thì Flows chưa thay thế được Collection Runner cho phần automation trên pipeline. Flows mạnh nhất ở giai đoạn thiết kế, khám phá và trình bày workflow.

Các block quan trọng bạn sẽ gặp

• Start: điểm khởi đầu của flow, nơi bạn bấm chạy.
• Send Request: gọi một request (thường lấy từ collection có sẵn). Đây là block xương sống.
• Evaluate / Condition (If): kiểm tra một biểu thức, rẽ luồng theo nhánh true/false.
• For Each / Loop: lặp qua một mảng, gửi request cho từng phần tử.
• Select / Transform: trích và biến đổi dữ liệu bằng một ngôn ngữ truy vấn nhẹ (Postman gọi là FQL — Flows Query Language, cú pháp gần giống truy vấn JSON).
• Delay: chờ một khoảng thời gian giữa các bước — hữu ích khi test hệ thống bất đồng bộ.
• Output / Log: hiển thị kết quả cuối để quan sát.

FQL — ngôn ngữ trích dữ liệu trong Flows

Trong Flows, thay vì viết pm.response.json().data.token, bạn dùng FQL để trích giá trị, ví dụ $.body.data.token. Nó gọn, dễ đọc, và cho phép người không phải lập trình viên vẫn nối được dữ liệu. Đây là một trong những lý do Flows được yêu thích ở các nhóm có nhiều tester nghiêng về manual/khám phá hơn là code.

Tình huống thực tế

Ví dụ 1 — Tiki: trình bày luồng "đặt hàng" cho cả nhóm QA

Một nhóm QA giả định tại một sàn thương mại điện tử kiểu Tiki cần test luồng đặt hàng gồm 6 bước: đăng nhập → lấy giỏ hàng → thêm sản phẩm → tính phí ship → tạo đơn → xác nhận thanh toán. Trước đây họ viết toàn bộ trong 6 request với các script pm.setNextRequest, và mỗi lần có bạn mới vào nhóm, người lead phải ngồi giải thích 30 phút "request này lấy token từ request kia".

Khi chuyển sang Flows, người lead dựng một sơ đồ: block Send Request "Login" nối sang "Get Cart", từ đó tách một nhánh sang "Calculate Shipping" và một nhánh sang "Add Item", rồi cả hai hội tụ về "Create Order". Bạn mới chỉ cần nhìn canvas 2 phút là hiểu ngay thứ tự và sự phụ thuộc. Bài học: giá trị lớn nhất của Flows ở đây không phải "chạy nhanh hơn" mà là khả năng truyền đạt (communication) — biến kiến thức ngầm trong đầu người lead thành sơ đồ ai cũng đọc được.

Ví dụ 2 — Fintech ở TP.HCM: rẽ nhánh theo trạng thái KYC

Một startup fintech tại TP.HCM có API xác thực người dùng (KYC) trả về một trong ba trạng thái: pending, verified, rejected. Với mỗi trạng thái, luồng test tiếp theo khác nhau: nếu verified thì test luồng mở ví; nếu pending thì poll (hỏi lại) sau 5 giây tối đa 3 lần; nếu rejected thì kiểm tra thông báo lỗi hiển thị đúng.

Nếu viết bằng script, bạn sẽ có một mớ if/else lồng nhau trong tab Tests rất khó theo dõi. Trong Flows, họ dùng một block Condition rẽ ba nhánh rõ ràng, nhánh pending nối vào một vòng lặp có block Delay 5 giây. Khi demo cho trưởng nhóm compliance — người không biết code — anh này vẫn hiểu và góp ý được rằng "nhánh rejected cần kiểm tra thêm mã lỗi 4xx". Bài học: Flows tỏa sáng khi logic có nhiều nhánh điều kiện và khi bạn cần cộng tác với người không đọc code.

Ví dụ 3 — Agency dịch vụ: khi Flows lại là lựa chọn sai

Một agency ở Hà Nội nhận hợp đồng chạy regression 400 test case mỗi đêm cho khách hàng, kết quả phải xuất ra JUnit để hiển thị trên Jenkins. Một bạn junior hào hứng dựng toàn bộ bằng Flows vì thấy "đẹp và trực quan". Đến khi tích hợp CI/CD thì tắc: Flows không chạy được bằng Newman, không xuất được báo cáo JUnit cho pipeline, và không nhận file CSV dữ liệu 400 dòng một cách tiện lợi như Collection Runner.

Cuối cùng nhóm phải làm lại bằng Collection + Newman + reporter JUnit (đúng như các bài 13–17 của khóa này dạy). Bài học: Flows không phải công cụ automation cho CI/CD. Với data-driven testing quy mô lớn và chạy tự động trên máy chủ, Collection Runner và Newman vẫn là chuẩn. Đừng chọn công cụ vì nó đẹp; chọn vì nó khớp với ràng buộc của pipeline.

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

Hãy dựng một flow đơn giản: đăng nhập lấy token, rồi dùng token đó gọi một endpoint được bảo vệ, và rẽ nhánh kiểm tra kết quả.

• Chuẩn bị request trong collection. Flows lấy request từ collection có sẵn, nên trước tiên hãy tạo hai request: POST /login và GET /me (cần Authorization header). Lưu chúng vào một collection.

• Mở Flows. Trong workspace, ở thanh bên trái tìm mục Flows và bấm tạo flow mới. Bạn sẽ thấy một canvas trống với block Start.

• Kéo block Send Request đầu tiên. Nối từ Start sang một block Send Request, chọn request POST /login của bạn. Nếu login cần body (username/password), điền hoặc gắn biến environment ngay trong block.

• Trích token bằng FQL. Kéo một block Select (hoặc dùng ô trích dữ liệu ngay trên đường nối). Viết biểu thức FQL để lấy token, ví dụ $.body.data.access_token. Bây giờ token đã trở thành một luồng dữ liệu đi tiếp.

• Nối sang request thứ hai. Kéo block Send Request thứ hai, chọn GET /me. Gắn giá trị token vừa trích vào ô Authorization (dạng Bearer {token}) bằng cách nối đường dữ liệu từ block Select sang.

• Thêm rẽ nhánh kiểm tra. Kéo block Condition sau GET /me. Đặt điều kiện như $.status == 200. Nhánh true nối sang một block Output ghi "PASS"; nhánh false nối sang Output ghi "FAIL — token không hợp lệ".

• Chạy và quan sát. Bấm Run. Flows sẽ tô sáng từng block khi thực thi và hiển thị dữ liệu chảy qua từng đường nối. Bạn có thể bấm vào từng đường để xem giá trị thực tế — đây là tính năng debug cực kỳ trực quan.

• Lưu và chia sẻ. Flow được lưu trong workspace và đồng bộ với nhóm. Đồng đội mở ra là thấy ngay sơ đồ, không cần bạn giải thích.

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

• Kỳ vọng Flows chạy trên CI/CD bằng Newman. Đây là hiểu lầm phổ biến nhất. Newman chạy collection, không chạy flow. Nếu cần automation trên pipeline, giữ logic ở collection; dùng Flows cho thiết kế và demo.

• Đưa data-driven quy mô lớn vào Flows. Với hàng trăm dòng CSV, Collection Runner với file dữ liệu vẫn tiện và nhanh hơn. Flows lặp tốt với mảng nhỏ đến trung bình, không phải bộ dữ liệu khổng lồ.

• Quên rằng Flows còn đang phát triển. Đây là tính năng tương đối mới của Postman, giao diện và tên block có thể thay đổi giữa các phiên bản. Đừng ngạc nhiên nếu vị trí menu khác với ảnh chụp cũ trên mạng — hãy tra tài liệu chính thức mới nhất.

• Trích sai đường dẫn FQL. Lỗi hay gặp là quên tiền tố $.body. Response trong Flows được bọc trong một cấu trúc có body, headers, status — nên $.body.data.token mới đúng, không phải $.data.token. Khi bí, bấm vào đường nối để xem cấu trúc thực tế của dữ liệu tại điểm đó.

• Nối dữ liệu lộn xộn thành "mì spaghetti". Flow đẹp là flow đọc được. Đặt tên block rõ ràng, sắp xếp trái-sang-phải theo thứ tự thời gian, gom nhánh liên quan gần nhau. Một flow rối mắt còn khó bảo trì hơn code.

• Mẹo debug: khi một nhánh không chạy như mong đợi, đừng đoán — bấm vào từng đường nối để soi giá trị thực. Flows cho bạn "nhìn xuyên" vào dữ liệu, hãy tận dụng thay vì thêm block Log khắp nơi.

• Mẹo cộng tác: khi trình bày cho stakeholder không rành kỹ thuật (như ví dụ compliance ở trên), hãy ẩn bớt chi tiết header và chỉ để lộ các block chính. Flow lúc này là một công cụ kể chuyện, không phải bản thiết kế kỹ thuật đầy đủ.

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

• Dựng flow login + gọi endpoint bảo vệ đúng theo 8 bước ở trên, với một API công khai bất kỳ (ví dụ reqres.in hoặc API nội bộ của bạn). Trích token bằng FQL và nối sang request thứ hai. Xác nhận nhánh Condition tô sáng đúng khi thành công.

• Thêm nhánh rẽ ba cho một trạng thái giả định status = active / pending / blocked, mỗi nhánh dẫn tới một Output khác nhau. Mô phỏng lại tình huống KYC của startup fintech.

• So sánh có chủ đích. Lấy một luồng bạn đã từng viết bằng script + Collection Runner ở các bài trước, dựng lại bằng Flows. Ghi ra 3 điều dễ hơn và 3 điều khó hơn. Bài tập này rèn cho bạn tư duy chọn đúng công cụ.

• Kiểm tra ranh giới. Thử tưởng tượng (hoặc thử thật) đưa flow của bạn vào một pipeline chạy Newman. Ghi lại vì sao nó không chạy được, và viết một đoạn ngắn giải thích cho một đồng nghiệp junior lý do nên giữ collection cho CI/CD.

Tóm tắt

Postman Flows là trình soạn thảo trực quan để xâu chuỗi request thành workflow bằng cách kéo-thả block, với mô hình chạy theo dữ liệu (data-flow) thay vì tuyến tính. Sức mạnh lớn nhất của nó không nằm ở tốc độ mà ở khả năng truyền đạt và cộng tác: nó biến logic workflow ẩn trong code thành một sơ đồ ai cũng đọc được, đặc biệt hữu ích khi luồng có nhiều nhánh điều kiện hoặc khi bạn làm việc với người không đọc code. FQL giúp trích và nối dữ liệu gọn gàng, và tính năng "nhìn xuyên" giá trị trên từng đường nối khiến việc debug rất trực quan.

Nhưng hãy nhớ ranh giới rõ ràng: Flows chưa chạy được bằng Newman, không phải công cụ cho data-driven quy mô lớn, và còn đang trong giai đoạn phát triển. Với automation trên CI/CD và regression hàng trăm case, Collection Runner cùng Newman vẫn là lựa chọn đúng. Một tester giỏi dùng Flows để thiết kế, khám phá và trình bày, và dùng Collection + Newman để tự động hóa trên pipeline. Chọn đúng công cụ cho đúng bài toán — đó mới là dấu hiệu của sự chuyên nghiệp.