Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Postman cho WebSocket & gRPC

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

Trong suốt khóa học, chúng ta đã dành phần lớn thời gian để test REST API — mô hình request/response quen thuộc: bạn gửi một yêu cầu, server trả về một phản hồi, kết nối đóng lại. Nhưng thực tế sản phẩm hiện đại ở Việt Nam đã đi xa hơn REST rất nhiều. Khi bạn mở app Shopee và thấy tin nhắn chat với shop hiện lên tức thì, khi bạn xem một trận đấu trên FPT Play và tỉ số cập nhật real-time, hay khi Grab hiển thị vị trí tài xế di chuyển từng giây trên bản đồ — đằng sau đó không phải là REST, mà là WebSocket. Còn khi các hệ thống backend nội bộ của các ngân hàng, ví điện tử, hoặc nền tảng logistics giao tiếp với nhau với yêu cầu tốc độ cực cao và định dạng chặt chẽ, họ thường dùng gRPC.

Vấn đề là: rất nhiều QA engineer chỉ quen test REST, và khi gặp một feature dùng WebSocket hay gRPC thì bối rối — không biết cách gửi thử một message, không biết đọc luồng dữ liệu real-time, không biết gRPC là gì ngoài cái tên. Kết quả là những tính năng real-time — vốn là phần "ăn tiền" nhất của sản phẩm — lại bị test hời hợt hoặc bỏ qua.

Tin vui là Postman — công cụ bạn đã thành thạo — hỗ trợ cả WebSocket và gRPC ngay trong giao diện. Bài này sẽ giúp bạn tự tin cầm Postman lên để khám phá, kiểm thử và debug hai giao thức này, mà không cần phải học một tool hoàn toàn mới hay viết code từ đầu.

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

WebSocket là gì và khác REST ra sao

REST hoạt động theo mô hình "hỏi-đáp một lần rồi thôi": client mở kết nối, gửi request, nhận response, đóng kết nối. Muốn dữ liệu mới, client phải hỏi lại (polling). Điều này lãng phí và có độ trễ.

WebSocket thì khác về bản chất. Nó thiết lập một kết nối hai chiều (full-duplex) và duy trì liên tục giữa client và server. Sau khi "bắt tay" (handshake) qua HTTP để nâng cấp lên giao thức WebSocket, kết nối được giữ mở. Từ đó, cả client và server có thể chủ động đẩy message cho nhau bất cứ lúc nào mà không cần request mới. Đây chính là lý do chat, thông báo, tỉ số trực tiếp và theo dõi vị trí đều dùng WebSocket.

URL của WebSocket không bắt đầu bằng http:// hay https:// mà bằng ws:// (không mã hóa) hoặc wss:// (có TLS, tương đương HTTPS). Ví dụ: wss://socket.shopee.vn/chat?token={{token}}.

Postman phân biệt hai loại WebSocket request:

  • Raw WebSocket: kết nối WebSocket thuần, bạn tự gửi text hoặc JSON tùy ý. Dùng cho hầu hết các hệ thống tự xây dựng.
  • Socket.IO: một thư viện phổ biến trên nền WebSocket, thêm khái niệm "event" (tên sự kiện + payload). Nếu backend team của bạn dùng thư viện socket.io (rất phổ biến trong hệ sinh thái Node.js), bạn phải chọn đúng loại này, nếu không sẽ không kết nối được.

gRPC là gì

gRPC là một framework gọi hàm từ xa (Remote Procedure Call) do Google phát triển. Thay vì suy nghĩ theo "resource và URL" như REST, gRPC suy nghĩ theo "gọi một hàm/method trên server". Nó có ba đặc điểm quan trọng bạn cần nắm:

  • Dùng Protocol Buffers (protobuf) thay vì JSON. Đây là định dạng nhị phân, gọn và nhanh hơn JSON nhiều lần. Cấu trúc dữ liệu được định nghĩa trước trong file .proto.
  • Chạy trên HTTP/2, cho phép nhiều luồng dữ liệu song song trên một kết nối.
  • Hỗ trợ streaming: ngoài kiểu gọi thông thường (unary — một request, một response), gRPC còn có server streaming, client streaming và bidirectional streaming — rất giống tinh thần real-time của WebSocket nhưng có cấu trúc chặt chẽ hơn.
Điểm mấu chốt khi test gRPC: bạn cần service definition — tức là biết server có những method nào, mỗi method nhận và trả về dữ liệu gì. Postman lấy thông tin này qua hai cách: server reflection (server tự khai báo, nếu được bật) hoặc bạn import file .proto do dev cung cấp.

Vì sao dùng Postman thay vì tool khác

Trước đây, để test WebSocket người ta phải viết script Node.js, còn gRPC thì phải dùng công cụ dòng lệnh như grpcurl khá khó dùng. Postman gom tất cả vào một giao diện quen thuộc: bạn vẫn dùng environment, vẫn dùng variable {{token}}, vẫn lưu request vào collection để chia sẻ với team. Đó là lợi thế lớn khi làm việc nhóm.

Tình huống thực tế

Ví dụ 1 — Test tính năng chat real-time của một sàn TMĐT

Giả sử bạn là QA tại một sàn thương mại điện tử tương tự Shopee. Team vừa ra tính năng chat giữa người mua và shop, dùng WebSocket. Dev đưa bạn endpoint wss://socket.example-shop.vn/chat và yêu cầu xác thực bằng token trong query string.

Bạn tạo một WebSocket Request trong Postman, đặt URL wss://socket.example-shop.vn/chat?token={{buyer_token}}, với buyer_token lấy từ environment. Bấm Connect — góc phải hiện "Connected" màu xanh. Ở tab Messages, bạn gửi thử một JSON:

{ "type": "send_message", "conversation_id": 88123, "text": "Sản phẩm còn hàng không shop?" }

Gần như tức thì, panel bên dưới hiển thị hai message: một message ack xác nhận server đã nhận, và một message message_delivered khi shop online nhận được. Bạn phát hiện một bug quan trọng: khi gửi text tiếng Việt có dấu như "Sản phẩm còn hàng không shop?", message trả về bị lỗi thành "Sản ph?m còn hàng" — dấu hiệu server chưa xử lý đúng UTF-8. Nếu chỉ test REST, bạn có thể đã bỏ sót.

Bài học rút ra: WebSocket cho phép bạn quan sát luồng message hai chiều theo thời gian thực, và chính khả năng "nhìn thấy" này giúp bắt được các lỗi encoding, thứ tự message, hoặc message trùng lặp mà REST không lộ ra.

Ví dụ 2 — Test hệ thống định vị tài xế bằng gRPC nội bộ

Giả sử bạn làm QA cho một startup giao đồ ăn ở TP.HCM, tương tự mô hình của GrabFood. Backend team dùng gRPC cho service TrackingService để app tài xế đẩy vị trí liên tục về server. Họ cung cấp cho bạn file tracking.proto.

Bạn tạo một gRPC Request trong Postman, nhập địa chỉ grpc-staging.example-food.vn:50051, rồi import file tracking.proto. Ngay lập tức Postman liệt kê các method: SendLocation (client streaming) và SubscribeDriverLocation (server streaming). Bạn chọn SubscribeDriverLocation, điền message request { "driver_id": "DRV-7781" }, bấm Invoke. Postman giữ kết nối mở và bắt đầu nhận về một chuỗi message vị trí, mỗi 3 giây một lần:

{ "lat": 10.7769, "lng": 106.7009, "timestamp": 1719450000 }

Trong quá trình test, bạn phát hiện khi tài xế mất mạng 10 giây rồi kết nối lại, server gửi dồn một loạt vị trí cũ thay vì chỉ vị trí mới nhất — gây "nhảy" trên bản đồ. Đây là một bug logic streaming mà bạn chỉ thấy được nhờ theo dõi luồng gRPC stream.

Bài học rút ra: Với gRPC streaming, giá trị của Postman nằm ở chỗ nó giữ kết nối và hiển thị từng message trong stream, giúp bạn kiểm tra tần suất, thứ tự và hành vi khi mạng chập chờn — những kịch bản rất thực tế ở Việt Nam nơi mạng di động không phải lúc nào cũng ổn định.

Ví dụ 3 — Kiểm thử xác thực và ngắt kết nối trên Socket.IO

Một công ty fintech dùng socket.io để đẩy thông báo biến động số dư cho khách hàng. Bạn cần kiểm tra: nếu token hết hạn, server có ngắt kết nối đúng cách không?

Bạn tạo một Socket.IO request (không phải Raw), kết nối tới wss://notify.example-fin.vn với token hợp lệ, lắng nghe event balance_changed. Kết nối thành công. Sau đó bạn đổi {{token}} sang một token đã hết hạn và kết nối lại. Đúng như kỳ vọng, server gửi event unauthorized rồi đóng kết nối trong vòng 1 giây. Bạn ghi nhận đây là hành vi đạt yêu cầu bảo mật.

Bài học rút ra: Với Socket.IO, việc chọn đúng loại request và biết cách "lắng nghe theo tên event" là chìa khóa. Test các kịch bản tiêu cực (token sai, hết hạn) cũng quan trọng như kịch bản thành công.

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

Tạo và test một WebSocket Request

  • Trong Postman, bấm New → WebSocket Request (hoặc từ menu New chọn WebSocket).
  • Chọn loại kết nối ở góc: Raw cho WebSocket thuần, hoặc Socket.IO nếu backend dùng thư viện đó.
  • Nhập URL, ví dụ: wss://socket.shopee.vn/chat?token={{token}}. Nhớ dùng wss:// cho môi trường production có TLS.
  • (Tùy chọn) Vào tab Headers hoặc Params để thêm thông tin xác thực nếu server yêu cầu qua header thay vì query string.
  • Bấm Connect. Theo dõi trạng thái: "Connecting..." rồi "Connected" nếu thành công.
  • Ở khung soạn message (tab Messages / New Message), chọn định dạng Text hoặc JSON, gõ nội dung message rồi bấm Send.
  • Quan sát panel message log bên dưới: message bạn gửi (mũi tên đi ra) và message server trả về (mũi tên đi vào) được liệt kê theo thời gian, kèm timestamp. Bấm vào từng message để xem chi tiết.
  • Với Socket.IO, ở tab Events bạn khai báo tên các event cần lắng nghe (ví dụ balance_changed), bật listener trước khi gửi.
  • Khi xong, bấm Disconnect để đóng kết nối.

Tạo và test một gRPC Request

  • Bấm New → gRPC Request.
  • Nhập địa chỉ server dạng host:port, ví dụ grpc-staging.example-food.vn:50051. Không thêm http:// phía trước.
  • Cung cấp service definition theo một trong hai cách:
- Using server reflection: nếu server bật reflection, Postman tự lấy danh sách method. - Import a .proto file: bấm để nạp file .proto dev đưa. Có thể cần khai báo cả các file phụ thuộc (import paths).
  • Chọn method cần gọi từ danh sách xổ xuống. Postman hiển thị kiểu của method: Unary, Server streaming, Client streaming hay Bidirectional.
  • Ở tab Message, Postman tự sinh sẵn cấu trúc JSON tương ứng với message request. Điền giá trị các trường. Có thể bấm "Generate Example Message" để lấy mẫu.
  • (Tùy chọn) Thêm Metadata (tương đương header của REST) như authorization: Bearer {{token}}.
  • Bấm Invoke. Với unary, bạn nhận một response. Với streaming, kết nối giữ mở và các message chảy về liên tục — dùng nút End / Cancel để dừng.
  • Đọc Response ở panel bên phải, kèm cả Status code của gRPC (ví dụ 0 OK, 16 UNAUTHENTICATED) và metadata phản hồi.

Đưa vào quy trình test có tổ chức

Sau khi thử nghiệm thủ công, hãy lưu request vào Collection để cả team dùng chung, và tham số hóa mọi thứ nhạy cảm ({{token}}, {{host}}) qua Environment, đúng như cách bạn đã làm với REST. Điều này giúp chuyển nhanh giữa dev, staging, production mà không sửa tay.

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

  • Nhầm ws:// với http://: WebSocket bắt buộc dùng ws:// hoặc wss://. Dán nhầm sẽ báo lỗi kết nối ngay.
  • Chọn sai Raw vs Socket.IO: nếu backend dùng thư viện socket.io mà bạn chọn Raw, kết nối có vẻ mở nhưng không nhận được event nào. Hãy hỏi dev rõ họ dùng loại nào trước khi test.
  • Quên xác thực trong query string: nhiều hệ thống VN gắn token vào URL (?token=...). Nếu quên hoặc token hết hạn, server sẽ đóng kết nối ngay sau handshake — dễ tưởng nhầm là server lỗi.
  • gRPC không có reflection: nếu server tắt reflection và bạn không có file .proto, Postman không biết method nào tồn tại. Luôn xin file .proto từ dev như một phần "hợp đồng" test.
  • Sai import path của proto: một file .proto thường import các file khác. Nếu thiếu, Postman báo lỗi parse. Xin trọn bộ thư mục proto, không chỉ một file lẻ.
  • Bỏ qua kịch bản mạng chập chờn: điểm mạnh của WebSocket/gRPC là real-time, nên hãy chủ động test ngắt mạng, reconnect, gửi dồn message. Đây là nơi bug thật sự ẩn nấp.
  • Mẹo encoding tiếng Việt: luôn test message có dấu tiếng Việt để phát hiện lỗi UTF-8 sớm — một lỗi cực kỳ phổ biến với sản phẩm Việt Nam (chủ đề này sẽ được đào sâu ở bài về Unicode & encoding).
  • Mẹo đọc status gRPC: nhớ một vài mã hay gặp — 0 OK, 3 INVALID_ARGUMENT, 16 UNAUTHENTICATED, 14 UNAVAILABLE (server không phản hồi). Chúng giúp chẩn đoán nhanh nguyên nhân.

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

  • WebSocket cơ bản: Dùng một public echo server như wss://ws.postman-echo.com/raw. Tạo WebSocket Request, kết nối, gửi một message JSON có chứa text tiếng Việt có dấu, và xác nhận server "echo" lại đúng nguyên văn. Ghi lại thời gian round-trip.
  • Quan sát luồng hai chiều: Vẫn với echo server, gửi liên tiếp 5 message trong 5 giây và quan sát thứ tự message log. Thử ngắt kết nối giữa chừng rồi kết nối lại, ghi nhận hành vi.
  • gRPC với reflection: Tìm một public gRPC demo server có bật reflection (ví dụ grpcb.in:9000 hoặc server nội bộ của team bạn). Tạo gRPC Request, dùng server reflection để liệt kê method, gọi thử một method unary và đọc response cùng status code.
  • Tình huống tiêu cực: Với endpoint có xác thực, cố tình gửi token sai hoặc bỏ trống, ghi lại cách server phản ứng (đóng kết nối, trả status UNAUTHENTICATED, hay gửi event lỗi). So sánh với kỳ vọng và ghi thành một test case.
  • Tổ chức hóa: Lưu tất cả request trên vào một Collection mới tên "Realtime Testing", tham số hóa host và token qua một Environment. Viết mô tả ngắn cho từng request để đồng đội hiểu ngay.

Tóm tắt

WebSocket và gRPC là hai giao thức đứng sau những tính năng "real-time" và hiệu năng cao mà sản phẩm Việt Nam ngày càng phụ thuộc — từ chat, thông báo, theo dõi vị trí đến giao tiếp backend tốc độ cao. Khác với REST, cả hai đều xoay quanh kết nối được duy trì và luồng message liên tục, nên cách test cũng phải chuyển từ tư duy "hỏi-đáp một lần" sang "quan sát luồng dữ liệu theo thời gian".

Điều đáng mừng là bạn không cần rời khỏi Postman: dùng WebSocket Request (chọn đúng Raw hay Socket.IO, dùng wss://, gửi text/JSON và đọc message log hai chiều) và gRPC Request (nhập host:port, nạp service definition qua reflection hoặc file .proto, chọn method, Invoke và đọc cả response lẫn status code). Hãy tận dụng environment và collection để làm việc nhóm bài bản, và luôn ưu tiên test các kịch bản thực tế của Việt Nam như tiếng Việt có dấu và mạng chập chờn. Nắm vững bài này, bạn đã mở rộng năng lực test của mình ra khỏi REST — một bước tiến quan trọng trên con đường trở thành một API Tester toàn diệ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