Postman là một trong những công cụ được sử dụng rộng rãi nhất để gửi các yêu cầu HTTP và kiểm tra cách một API hoạt động. Nó bắt đầu như một tiện ích mở rộng của trình duyệt và phát triển thành một ứng dụng desktop đầy đủ, xử lý mọi thứ từ một yêu cầu GET nhanh chóng đến các bộ kiểm thử được lập trình chạy trong CI. Nếu bạn xây dựng hoặc sử dụng API, bạn gần như chắc chắn sẽ gặp nó.
Hướng dẫn này sẽ đi sâu vào việc kiểm thử một API trong Postman theo cách bạn sẽ làm hàng ngày. Bạn sẽ gửi một yêu cầu, kiểm tra phản hồi, viết các xác nhận trong tab Tests, thiết lập môi trường để bạn có thể chuyển đổi giữa môi trường thử nghiệm (staging) và sản phẩm (production), và chạy toàn bộ một collection cùng lúc với Collection Runner. Các ví dụ sử dụng một API công khai để bạn có thể làm theo mà không cần thiết lập bất cứ điều gì trước.
Thiết lập Postman và gửi yêu cầu đầu tiên của bạn
Tải Postman từ trang chính thức và cài đặt ứng dụng desktop. Bạn có thể sử dụng nó mà không cần tài khoản cho công việc cục bộ, mặc dù việc đăng nhập sẽ đồng bộ hóa các collection của bạn trên các thiết bị. Mở ứng dụng và nhấp vào nút New, sau đó chọn HTTP Request.
Một yêu cầu cần tối thiểu ba thứ: một phương thức, một URL và đôi khi là một body. Chọn GET từ danh sách thả xuống phương thức và nhập một endpoint thực tế. Dịch vụ JSONPlaceholder rất tiện lợi để thực hành:
GET https://jsonplaceholder.typicode.com/users/1
Nhấp vào Send. Bảng phản hồi sẽ hiển thị body, mã trạng thái (200 OK), thời gian phản hồi và kích thước. Chuyển đổi chế độ xem body giữa Pretty, Raw và Preview để xem JSON được định dạng hoặc như máy chủ đã gửi.
Đối với một yêu cầu POST, thay đổi phương thức, mở tab Body, chọn raw, và chọn JSON từ danh sách thả xuống định dạng. Dán một payload như thế này:
{
"name": "Maria Chen",
"email": "maria.chen@example.com"
}
Các Headers như Content-Type: application/json được tự động thêm vào khi bạn chọn kiểu body JSON. Tab Headers cho phép bạn thêm bất kỳ thứ gì khác mà API cần, như một header Authorization. Nếu bạn mới làm quen với các mã phản hồi cần mong đợi, hướng dẫn về các mã trạng thái HTTP mà REST API nên sử dụng là một tài liệu tham khảo hữu ích.
Sắp xếp các yêu cầu vào collections
Một yêu cầu đơn lẻ là đủ cho một lần kiểm tra nhanh. Kiểm thử thực sự có nghĩa là nhiều yêu cầu thuộc về nhau: tạo người dùng, lấy người dùng đó, cập nhật họ, xóa họ. Postman nhóm những yêu cầu này thành collections.
Nhấp vào Collections ở thanh bên, sau đó nhấp vào biểu tượng + để tạo một collection mới. Đặt tên cho nó thật cụ thể như “User API smoke tests”. Lưu mỗi yêu cầu vào collection bằng Ctrl/Cmd + S và đặt cho nó một tên rõ ràng. Bạn có thể lồng các thư mục bên trong một collection để tách biệt, ví dụ, các yêu cầu xác thực khỏi các yêu cầu tài nguyên.
Collections cũng là đơn vị bạn chia sẻ. Xuất một collection dưới dạng tệp JSON, hoặc chia sẻ một liên kết nếu bạn đồng bộ hóa lên đám mây. Đồng đội sẽ nhập nó và có chính xác các yêu cầu như bạn. Đây là nền tảng cho mọi thứ khác, bởi vì Collection Runner và các kiểm thử tự động đều hoạt động trên collections thay vì các yêu cầu rời rạc.
Một collection cũng có thể mang theo hành vi được chia sẻ. Postman cho phép bạn gắn các script ở cấp độ collection hoặc thư mục, chứ không chỉ trên một yêu cầu duy nhất. Một pre-request script trên collection sẽ chạy trước mỗi yêu cầu bên trong nó, điều này hữu ích cho việc làm mới một token hoặc đóng dấu một timestamp. Một test script ở cấp độ collection sẽ chạy sau mỗi yêu cầu, điều này tiện lợi cho một xác nhận bạn muốn ở mọi nơi, chẳng hạn như “thời gian phản hồi là hợp lý.” Việc định nghĩa những điều này một lần giúp các yêu cầu riêng lẻ của bạn tập trung vào những gì độc đáo của chúng.
Viết kiểm thử trong tab Tests
Gửi một yêu cầu cho bạn biết điều gì đã được trả về. Một kiểm thử cho bạn biết liệu những gì được trả về có đúng hay không, một cách tự động, mỗi lần. Postman chạy JavaScript trong khu vực Scripts của một yêu cầu (các phiên bản cũ hơn gọi đây là tab Tests) sau khi phản hồi đến.
Postman cung cấp một đối tượng pm để viết các xác nhận. Mẫu cốt lõi là pm.test(name, callback), trong đó callback sẽ báo lỗi nếu một kỳ vọng không thành công. Đây là những xác nhận bạn sẽ sử dụng liên tục:
// Kiểm tra mã trạng thái
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
// Kiểm tra thời gian phản hồi
pm.test("Response is under 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Kiểm tra một trường trong JSON body
pm.test("User has the expected email", function () {
const body = pm.response.json();
pm.expect(body.email).to.eql("maria.chen@example.com");
});
// Kiểm tra một header
pm.test("Content-Type is JSON", function () {
pm.expect(pm.response.headers.get("Content-Type"))
.to.include("application/json");
});
Cú pháp xác nhận đến từ Chai, vì vậy pm.expect hỗ trợ .to.eql, .to.include, .to.be.above, và các cú pháp khác. Nhấp vào Send và kết quả sẽ hiển thị trong tab Test Results, mỗi kiểm thử có màu xanh lá cây hoặc đỏ.
Một vài thói quen giúp các bài kiểm thử hữu ích. Đặt tên cho mỗi khối pm.test theo hành vi mà nó kiểm tra, chứ không phải endpoint, để thông báo lỗi có thể đọc như một câu. Kiểm tra những điều thực sự có thể làm hỏng một người dùng API: mã trạng thái, hình dạng của body, và các trường mà một client phụ thuộc. Tránh xác nhận các giá trị bạn không kiểm soát, chẳng hạn như timestamp do máy chủ tạo, vì những giá trị đó tạo ra các lỗi không đáng tin cậy khiến mọi người bỏ qua màu đỏ. Postman cũng đi kèm với một bảng Snippets bên cạnh trình chỉnh sửa với các xác nhận sẵn có mà bạn có thể nhấp để chèn, đây là cách nhanh nhất để tìm hiểu API pm. Nếu bạn muốn tìm hiểu sâu hơn về thiết kế xác nhận, hãy xem phân tích về các xác nhận API và cách viết chúng tốt. Đối với ý tưởng rộng hơn về việc cấu trúc các kiểm tra thành các trường hợp được đặt tên, hướng dẫn ví dụ về trường hợp kiểm thử API rất đáng đọc cùng với bài này.
Sử dụng môi trường và biến
Việc hardcoding https://api.staging.example.com vào mỗi yêu cầu sẽ gây khó khăn ngay khi bạn cần trỏ đến môi trường sản phẩm. Environments (Môi trường) giải quyết vấn đề này. Một môi trường là một tập hợp các biến được đặt tên.
Nhấp vào biểu tượng môi trường ở thanh bên và tạo một môi trường có tên “Staging”. Thêm một biến base_url với giá trị https://jsonplaceholder.typicode.com. Tạo một môi trường thứ hai có tên “Production” với một base_url khác. Bây giờ, hãy tham chiếu biến trong các yêu cầu của bạn bằng cách sử dụng dấu ngoặc nhọn kép:
GET {{base_url}}/users/1
Chọn môi trường đang hoạt động từ danh sách thả xuống ở góc trên bên phải, và mọi yêu cầu sử dụng {{base_url}} sẽ chuyển đổi theo nó.
Các biến cũng mang dữ liệu giữa các yêu cầu. Một yêu cầu đăng nhập có thể lấy một token từ phản hồi của nó và lưu trữ nó để các yêu cầu sau sử dụng:
pm.test("Save the auth token", function () {
const token = pm.response.json().token;
pm.environment.set("auth_token", token);
});
Bất kỳ yêu cầu sau này nào cũng có thể gửi Authorization: Bearer {{auth_token}}. Chuỗi này là cách bạn kiểm thử các luồng phụ thuộc vào trạng thái, chẳng hạn như tạo một tài nguyên và sau đó xác minh nó tồn tại.
Postman có hai phạm vi biến liên quan đáng biết. Environment variables (Biến môi trường) thuộc về môi trường được chọn và thay đổi khi bạn chuyển đổi môi trường. Collection variables (Biến collection) thuộc về một collection bất kể môi trường nào, phù hợp với các giá trị không đổi cho API đó. Ngoài ra còn có global variables (biến toàn cục), áp dụng ở mọi nơi, và local variables (biến cục bộ) có thời gian tồn tại ngắn chỉ tồn tại trong một lần chạy. Việc chọn đúng phạm vi sẽ giữ một giá trị ở đúng nơi của nó và tránh những bất ngờ khi bạn chuyển đổi mục tiêu.
Chạy toàn bộ một collection với Collection Runner
Việc nhấp vào nút Send trên mỗi yêu cầu sẽ nhanh chóng trở nên nhàm chán. Collection Runner thực thi mọi yêu cầu trong một collection theo thứ tự, chạy tất cả các bài kiểm thử của chúng và cung cấp cho bạn một bản tóm tắt đậu/rớt.
Mở một collection, nhấp vào nút Run (hoặc menu ba chấm, sau đó Run collection). Runner hiển thị các yêu cầu của bạn theo trình tự. Chọn môi trường, đặt số lần lặp để chạy, và tùy chọn đính kèm một tệp dữ liệu. Nhấp vào Run và Postman sẽ thực hiện mọi yêu cầu, từ trên xuống dưới, thực thi các bài kiểm thử của mỗi yêu cầu.
Trang kết quả liệt kê mọi xác nhận trên mọi yêu cầu, với tổng số lượt đậu và rớt. Đây là kiểm tra hồi quy của bạn. Chạy nó sau khi triển khai và bạn sẽ biết trong vài giây liệu API có còn hoạt động bình thường hay không. Runner cũng giữ lịch sử các lần chạy trước, vì vậy bạn có thể so sánh kết quả hôm nay với ngày hôm qua và phát hiện khi nào một bộ kiểm thử trước đây đang xanh bắt đầu gặp lỗi.
Thứ tự rất quan trọng trong runner. Bởi vì các yêu cầu chạy từ trên xuống dưới, bạn có thể đặt một yêu cầu đăng nhập lên đầu để nó điền vào một auth_token, sau đó cho phép mọi yêu cầu bên dưới sử dụng token đó. Điều tương tự cũng áp dụng cho thiết lập và dọn dẹp: tạo một tài nguyên gần đầu, thực hiện nó ở giữa, xóa nó ở cuối. Một collection được sắp xếp tốt sẽ tự động tạo một kịch bản hành trình người dùng hoàn chỉnh.
Để kiểm thử theo hướng dữ liệu, đính kèm tệp CSV hoặc JSON trong runner. Mỗi hàng trở thành một lần lặp, và bạn tham chiếu các cột như các biến như {{username}}. Điều này cho phép một yêu cầu kiểm thử hàng chục kết hợp đầu vào mà không cần nhân đôi yêu cầu. Ví dụ, một endpoint đăng nhập có thể được truy cập bằng một hàng thông tin đăng nhập hợp lệ và một số hàng thông tin đăng nhập không hợp lệ, mỗi hàng xác nhận mã trạng thái mà nó mong đợi. Bài viết về kiểm thử API theo hướng dữ liệu với CSV và JSON mô tả chi tiết mẫu này. Để chạy cùng một collection trong CI mà không cần giao diện người dùng đồ họa, Postman cung cấp công cụ dòng lệnh Newman, được mô tả trong bài so sánh Newman và Postman.
Khi Postman trở nên nặng nề, và những điều cần cân nhắc
Postman rất xuất sắc cho việc kiểm thử thăm dò và các bộ kiểm thử nhỏ đến trung bình. Hai điểm khó khăn xuất hiện khi các dự án phát triển. Thứ nhất, các xác nhận nằm trong JavaScript, vì vậy những người không phải nhà phát triển và những người QA thích cách tiếp cận trực quan sẽ có một đường cong học hỏi. Thứ hai, Postman giữ thiết kế API, kiểm thử, mocking và tài liệu ở các nơi riêng biệt, điều này có nghĩa là dữ liệu kiểm thử và hợp đồng API của bạn có thể bị lệch nhau.
Apidog là một nền tảng API tất cả trong một giải quyết cả hai vấn đề. Nó nhập các collection Postman trực tiếp, vì vậy việc chuyển đổi không phải là viết lại. Các xác nhận có thể được xây dựng trực quan mà không cần mã, đồng thời vẫn cho phép các script khi bạn cần chúng. Bởi vì thiết kế, gỡ lỗi, mocking, kiểm thử và tài liệu chia sẻ một nguồn thông tin duy nhất, các bài kiểm thử của bạn vẫn được căn chỉnh với đặc tả API thực tế. Nếu bạn đang cân nhắc các lựa chọn, tổng hợp các lựa chọn thay thế Postman tốt nhất để kiểm thử API sẽ trình bày các ưu nhược điểm. Bạn có thể tải Apidog và nhập một collection hiện có để so sánh trực tiếp.
Không có điều nào trong số này có nghĩa là bạn nên loại bỏ Postman. Nó vẫn là một lựa chọn vững chắc, đặc biệt cho các kiểm tra nhanh và các nhóm đã đầu tư vào nó. Vấn đề là phải biết mỗi công cụ phù hợp ở đâu.
Các câu hỏi thường gặp
Tôi có cần viết mã để kiểm thử API trong Postman không?
Để gửi yêu cầu và đọc phản hồi thì không. Đối với các xác nhận tự động thì có, ít nhất là một chút. Tab Tests của Postman chạy JavaScript và sử dụng đối tượng pm. Các mẫu đơn giản và bạn có thể sao chép chúng từ bảng mã mẫu (snippets) tích hợp sẵn của Postman, nhưng nó vẫn là JavaScript. Nếu bạn muốn một công cụ xây dựng xác nhận trực quan không cần mã, một nền tảng chuyên dụng như Apidog sẽ xử lý điều đó.
Sự khác biệt giữa Postman collection và environment là gì?
Một collection là một tập hợp các yêu cầu được nhóm lại với nhau, thường đi kèm với các bài kiểm thử của chúng. Một environment là một tập hợp các biến được đặt tên, như base_url hoặc auth_token. Collections chứa những gì bạn gửi. Environments chứa các giá trị thay đổi giữa môi trường staging, production và cục bộ. Bạn trỏ một collection vào các environments khác nhau để kiểm thử cùng một yêu cầu đối với các máy chủ khác nhau.
Làm cách nào để tôi chạy các kiểm thử Postman tự động trong CI?
Sử dụng Newman, trình chạy dòng lệnh của Postman. Xuất collection và environment của bạn, sau đó chạy newman run collection.json -e environment.json. Newman sẽ thoát với mã khác không nếu bất kỳ kiểm thử nào thất bại, đó là điều mà pipeline CI của bạn kiểm tra. Hướng dẫn về tự động hóa các kiểm thử API trong CI/CD sẽ hướng dẫn bạn cách kết nối điều này vào một pipeline.
Postman có thể kiểm thử nhiều hơn các REST API không?
Có. Postman hiện đại hỗ trợ các yêu cầu GraphQL, gRPC, WebSocket và SOAP ngoài HTTP và REST thuần túy. Tab Tests và các xác nhận hoạt động trên hầu hết các giao thức này, mặc dù việc thiết lập yêu cầu chính xác khác nhau tùy theo giao thức.
Một yêu cầu nên có bao nhiêu xác nhận?
Đủ để xác nhận phản hồi là đúng, không quá nhiều đến mức một thay đổi nhỏ làm hỏng hàng tá bài kiểm thử. Một tiêu chuẩn chung là mã trạng thái, thời gian phản hồi và hai hoặc ba trường quan trọng đối với endpoint đó. Giữ mỗi khối pm.test tập trung vào một kỳ vọng để một lỗi cho bạn biết chính xác điều gì đã hỏng.