Top công cụ kiểm thử API dòng lệnh 2026

Kiểm thử API đã vượt ra khỏi giao diện người dùng đồ họa (GUI). Các bài kiểm thử hiện chạy trong các container CI không có màn hình hiển thị, trên các máy chủ staging mà bạn chỉ có thể truy cập qua SSH, và dưới sự điều khiển của các tác nhân AI chỉ giao tiếp bằng shell. Ở cả ba nơi này, terminal là nơi một bài kiểm thử thành công hay thất bại mà không cần con người theo dõi.

Bài tổng hợp này xếp hạng các công cụ thực hiện công việc kiểm thử thực sự từ một lời nhắc shell. "Dựa trên Terminal" ở đây có nghĩa là toàn bộ vòng lặp chạy trong một shell: cài đặt từ trình quản lý gói, chạy một lệnh, đọc mã thoát. Xếp hạng này cân nhắc các khẳng định tích hợp sẵn, các luồng đa bước, báo cáo sẵn sàng cho CI và trạng thái bảo trì. Các client thủ công như curl vẫn có một vị trí gần cuối, vì mọi quy trình làm việc trên terminal đều dựa vào chúng giữa các lần chạy kiểm thử. Để có một khảo sát rộng hơn bao gồm các công cụ GUI và công cụ được lưu trữ, hãy xem bài tổng hợp các công cụ kiểm thử API miễn phí tốt nhất.

button

Điều gì phân biệt một công cụ kiểm thử với một client

Một client terminal gửi một yêu cầu và hiển thị cho bạn phản hồi. Một công cụ kiểm thử terminal đánh giá phản hồi và báo cáo kết quả dưới dạng mã thoát mà quy trình của bạn có thể dựa vào đó. Nhóm thứ hai là trọng tâm của danh sách này, và bốn đặc điểm định nghĩa nó:

Khẳng định được tích hợp sẵn. Kiểm tra trạng thái, tiêu đề và nội dung thuộc về công cụ, không phải trong một đống mã jq.
Mã thoát có ý nghĩa. Bằng 0 khi thành công, khác 0 khi thất bại, để CI tự động dừng bản dựng cho bạn.
Khả năng lặp lại. Các bài kiểm thử nằm trong các tệp hoặc dự án bạn có thể kiểm soát phiên bản và chạy lại, không phải trong lịch sử shell của bạn.
Báo cáo. Đầu ra mà con người có thể đọc trong terminal và một bảng điều khiển có thể phân tích cú pháp dưới dạng JSON, JUnit hoặc HTML.

Với các tiêu chí đã được thiết lập, đây là mười công cụ đáng để bạn dành thời gian vào năm 2026.

1. Apidog CLI: tạo trực quan, chạy không giao diện ở bất cứ đâu

Apidog là một nền tảng API tất cả trong một bao gồm thiết kế, kiểm thử, mocking và tài liệu. Apidog CLI (apidog-cli trên npm) là cánh tay terminal của nó. Bạn xây dựng các kịch bản kiểm thử trong trình chỉnh sửa trực quan, với các yêu cầu nối tiếp, biến được trích xuất và các khẳng định, sau đó apidog run thực thi chúng từ bất kỳ shell nào và cung cấp cho quy trình của bạn một mã thoát rõ ràng.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Sao chép lệnh chính xác từ tab CI/CD của kịch bản của bạn
apidog run -t <scenario_id> -e <env_id> -r cli

Bạn không phải đoán ID. Mở kịch bản trong Apidog, vào tab CI/CD và sao chép lệnh được tạo. Các trình báo cáo bao gồm cli, html, json và junit, được ghi vào apidog-reports/, vì vậy cùng một lần chạy sẽ cung cấp cho một terminal, một bảng điều khiển và một kho lưu trữ artifact. Các lần chạy theo hướng dữ liệu lấy các lần lặp từ tệp CSV hoặc JSON. Đầu ra là JSON có cấu trúc với agentHints.nextSteps, cho phép một tác nhân AI chạy một bộ kiểm thử và quyết định bước tiếp theo mà không cần trích xuất màn hình. Nó cần Node.js 16 trở lên.

Tốt nhất cho: các nhóm muốn các kịch bản phức tạp, đa bước được tạo trong một trình chỉnh sửa và chạy giống hệt nhau trên máy tính xách tay, trong CI và bởi các tác nhân. Hạn chế thực tế: nó không phải mã nguồn mở và nó không phải là một trình gửi ad-hoc. Các kịch bản nằm trong một dự án Apidog, vì vậy đây là tùy chọn nền tảng tích hợp chứ không phải một công cụ HTTP đơn thuần. Hướng dẫn hoàn chỉnh về Apidog CLI bao gồm toàn bộ bộ lệnh.

2. Hurl: kiểm thử văn bản thuần túy trong một tệp nhị phân Rust duy nhất

Hurl chạy các yêu cầu HTTP được viết ở định dạng văn bản thuần túy và khẳng định trên các phản hồi. Nó được xây dựng bằng Rust trên nền libcurl và được cung cấp dưới dạng một tệp nhị phân duy nhất, vì vậy không cần cài đặt môi trường runtime. Các bài kiểm thử gần như đọc giống HTTP thô, giúp dễ dàng xem xét trong một yêu cầu kéo.

brew install hurl   # hoặc: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl   # thoát khác 0 nếu một khẳng định thất bại

Tốt nhất cho: các kiểm tra kiểu hợp đồng và kiểm tra khói mà bạn giữ trong kiểm soát phiên bản dưới dạng văn bản dễ đọc. Cờ --test làm cho nó trở thành một cổng CI tự nhiên. Hạn chế thực tế: nó tập trung vào HTTP, vì vậy nó sẽ không điều khiển gRPC hoặc tạo tải, và logic phức tạp có nghĩa là nhiều tệp .hurl hơn thay vì một ngôn ngữ kịch bản.

3. Newman: chạy các collection Postman không giao diện

Newman là trình chạy dòng lệnh mã nguồn mở cho các collection Postman (Apache-2.0). Nếu nhóm của bạn đã viết các yêu cầu và kiểm thử trong Postman, Newman sẽ chạy chính xác collection đó từ một terminal mà không cần GUI. Bạn xuất collection và môi trường dưới dạng JSON và trỏ Newman đến các tệp đó.

npm install -g newman

newman run collection.json -e staging.json

Tốt nhất cho: các nhóm đầu tư vào Postman muốn các collection hiện có chạy trong một pipeline mà không cần thêm chỗ ngồi. Nó thoát với mã khác 0 khi một bài kiểm thử thất bại, vì vậy cổng CI hoạt động sạch sẽ. Hạn chế thực tế: nó chỉ chạy các collection định dạng Postman, và việc tạo vẫn diễn ra trong GUI của Postman. Nó thực thi các bài kiểm thử; nó không giúp bạn viết chúng.

4. Postman CLI: giải pháp thay thế chính thức cho Newman

The Postman CLI là trình chạy mã nguồn đóng riêng của Postman. Không giống như Newman, nó đăng nhập vào tài khoản Postman của bạn và có thể chạy một collection bằng ID của nó, trực tiếp từ không gian làm việc, với kết quả được báo cáo trở lại đám mây của Postman.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

Tốt nhất cho: các nhóm Postman muốn các lần chạy liên kết đám mây mà không cần xuất tệp JSON. Hạn chế thực tế: nó là mã nguồn đóng và gắn với tài khoản Postman, và việc có hai trình chạy chính thức tạo ra sự nhầm lẫn thực sự về việc nên sử dụng cái nào. So sánh Postman CLI vs Newman làm rõ khi nào mỗi cái có ý nghĩa.

5. Bruno CLI: các collection gốc git, chạy với bru

Bruno lưu trữ các collection dưới dạng tệp văn bản thuần túy .bru trong các thư mục thông thường, vì vậy các yêu cầu nằm trong kho lưu trữ của bạn giống như bất kỳ mã nào khác. CLI của nó, @usebruno/cli, chạy các collection đó từ terminal bằng lệnh bru, không liên quan đến tài khoản đám mây.

npm install -g @usebruno/cli

# Chạy mọi yêu cầu trong thư mục collection hiện tại
bru run --env staging

Tốt nhất cho: các nhóm muốn các collection được xem xét trong các yêu cầu kéo và chạy ngoại tuyến, với các khẳng định và kịch bản được xử lý trong cùng các tệp. Nó ghi các báo cáo JSON, JUnit và HTML cho CI. Hạn chế thực tế: việc tạo bằng văn bản thuần túy phù hợp với các nhà phát triển hơn là các nhóm hỗn hợp, và hệ sinh thái còn non trẻ hơn của Postman. Xem cách nó so sánh với trình chạy của Apidog trong Bruno CLI vs Apidog CLI.

6. Schemathesis: lược đồ của bạn viết các bài kiểm thử

Schemathesis đi theo một con đường khác: nó đọc lược đồ OpenAPI hoặc GraphQL của bạn và tạo hàng nghìn trường hợp kiểm thử từ đó, sử dụng kiểm thử dựa trên thuộc tính được xây dựng trên Hypothesis của Python. Thay vì viết từng trường hợp, bạn để nó làm mờ các đầu vào để tìm các lỗi 500, vi phạm lược đồ và các phản hồi phá vỡ hợp đồng mà tài liệu của bạn hứa hẹn.

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Tốt nhất cho: bắt các lỗi trường hợp góc mà không ai nghĩ đến để viết một bài kiểm thử, đặc biệt là trước khi phát hành. Đây là một trong những lập luận mạnh mẽ nhất để duy trì một lược đồ chính xác. Hạn chế thực tế: nó cần một lược đồ thực sự để hoạt động, và một API lớn có thể tạo ra nhiễu mà bạn sẽ lọc bằng các hook và tùy chọn.

7. Step CI: một tệp YAML cho mỗi luồng đa bước

Step CI mô tả một quy trình làm việc API trong một tệp YAML duy nhất: các bước, giá trị được thu thập và các kiểm tra. Nó bao gồm REST, GraphQL, gRPC, tRPC và SOAP trong một quy trình làm việc và xác thực dựa trên một lược đồ OpenAPI. Cùng một tệp chạy trên máy tính xách tay và trong một pipeline.

npm install -g stepci

stepci run workflow.yml

Tốt nhất cho: các chuỗi đăng nhập-sau đó-sử dụng-token được mô tả một cách khai báo, không cần kịch bản. Hạn chế thực tế: nó mang một runtime Node, và tần suất phát hành đã chậm lại, vì vậy hãy kiểm tra hoạt động gần đây của kho lưu trữ trước khi xây dựng một pipeline trên nó.

8. curl: công cụ cơ bản đã được cài đặt sẵn

curl được tích hợp sẵn với macOS, hầu hết các bản phân phối Linux và Windows hiện tại, vì vậy việc cài đặt nhẹ nhất là không cần cài đặt. Nó là client tham chiếu mà mọi công cụ khác tự so sánh, và với -w và shell glue, nó có thể hoạt động như một bộ kiểm thử tối thiểu.

# Gửi POST JSON và chỉ in mã trạng thái HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

Tốt nhất cho: các yêu cầu một lần, kịch bản và môi trường bị khóa nơi không thể cài đặt bất cứ thứ gì mới. Hạn chế thực tế: các khẳng định hoàn toàn tự làm. Bạn truyền vào jq, tự so sánh giá trị và quản lý mã thoát bằng tay. Nó gửi và hiển thị; nó không kiểm thử. Hướng dẫn các lựa chọn thay thế curl cho kiểm thử REST API bao gồm những gì cần tìm khi điều đó không còn đủ nữa.

9. HTTPie và xh: các yêu cầu dễ đọc bằng tay

HTTPie đã làm cho các yêu cầu terminal trở nên dễ đọc: lệnh là http, các trường JSON là các cặp key=value, và các phản hồi được trả về với màu sắc và định dạng. xh triển khai lại cùng một cú pháp đó trong Rust dưới dạng một tệp nhị phân tĩnh duy nhất, với thời gian khởi động nhanh hơn và một cờ --curl in ra lệnh curl tương đương.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # cùng cú pháp, một tệp nhị phân

Tốt nhất cho: khám phá API bằng tay trong khi bạn xây dựng các bài kiểm thử thực tế ở nơi khác. Hạn chế thực tế: cả hai đều là client, không phải trình chạy. HTTPie mang một runtime Python; xh đổi lấy một bộ tính năng nhỏ hơn để lấy tốc độ. Cả hai đều không khẳng định trên một phản hồi.

10. k6: khi vấn đề là tải

k6 trả lời một câu hỏi khác: không phải "phản hồi này có đúng không" mà là "nó có chịu được lưu lượng truy cập không". Nó là một tệp nhị phân Go duy nhất từ Grafana, được viết kịch bản bằng JavaScript, với các ngưỡng biến một kiểm thử tải thành một cổng pass/fail. Vượt quá ngưỡng và k6 thoát với mã khác 0, mà CI đọc là một thất bại.

brew install k6

k6 run load.js   # vus, duration, và thresholds được định nghĩa trong kịch bản

Tốt nhất cho: các kiểm tra hiệu suất nằm trong cùng một kho lưu trữ với các kiểm thử chức năng và chạy từ máy tính xách tay hoặc một pipeline. Hạn chế thực tế: nó là một công cụ tải dưới AGPL-3.0, không phải một client kiểm thử chức năng, và các kịch bản có ý nghĩa có nghĩa là phải học API JavaScript của nó.

Thích một cái gì đó tương tác hơn?

Nếu bạn muốn một giao diện giống Postman mà không cần rời khỏi shell, đó là một loại riêng biệt: các client TUI như atac và posting vẽ các trình chỉnh sửa yêu cầu đầy đủ bên trong terminal. Chúng khám phá API; chúng không chặn các pipeline. Tổng hợp các client REST API terminal và TUI tốt nhất bao gồm khía cạnh đó một cách chuyên sâu.

Bảng so sánh

Công cụ	Chức năng	Khẳng định tích hợp sẵn	Cài đặt	Mã nguồn mở
Apidog CLI	Chạy các kịch bản được tạo trực quan trong CI	Có	`npm i -g apidog-cli`	Không (phiên bản miễn phí)
Hurl	Kiểm thử HTTP văn bản thuần túy	Có	`brew install hurl`	Apache-2.0
Newman	Các collection Postman không giao diện	Có	`npm i -g newman`	Apache-2.0
Postman CLI	Các lần chạy Postman liên kết đám mây	Có	Trình cài đặt Postman	Không
Bruno CLI	Các collection `.bru` gốc Git	Có	`npm i -g @usebruno/cli`	MIT
Schemathesis	Fuzzing từ một lược đồ	Được tạo tự động	`pip install schemathesis`	MIT
Step CI	Các luồng YAML đa bước	Có	`npm i -g stepci`	MPL-2.0
curl	Các yêu cầu thô, kịch bản	Tự làm	Cài đặt sẵn	Có
HTTPie / xh	Các yêu cầu thủ công dễ đọc	Không	`brew install httpie` / `xh`	Có
k6	Tải với ngưỡng pass/fail	Ngưỡng	`brew install k6`	AGPL-3.0

Cách chọn

Bắt đầu từ công việc, không phải công cụ. Nếu các bài kiểm thử đã tồn tại trong Postman, Newman hoặc Postman CLI sẽ chạy chúng ngay lập tức. Nếu bạn muốn các bài kiểm thử dưới dạng văn bản có thể xem xét trong kho lưu trữ của mình, Hurl và Bruno CLI là những lựa chọn mạnh mẽ nhất. Nếu bạn có một lược đồ OpenAPI vững chắc, hãy thêm Schemathesis và để nó săn tìm những lỗi mà bạn không lường trước được. Giữ curl và xh cho lớp thủ công, và mang k6 vào khi câu hỏi chuyển từ độ chính xác sang năng lực.

Chọn Apidog CLI khi bạn muốn tạo kịch bản trong một trình chỉnh sửa trực quan và chạy chúng ở mọi nơi khác. Đây là một lựa chọn duy nhất ở đây mà cùng một dự án cũng mang theo thiết kế API, dữ liệu giả và tài liệu của bạn, đó là sự đánh đổi được giải thích trong Apidog CLI: client API sống trong terminal của bạn. Để có cái nhìn rộng hơn về kiểm thử đằng sau những lựa chọn này, hướng dẫn chiến lược kiểm thử API vạch ra vị trí của từng lớp.

FAQ

Tôi có thể kiểm thử API hoàn toàn từ terminal không? Có. Tạo các bài kiểm thử dưới dạng tệp (Hurl, Bruno, Step CI) hoặc trong một trình chỉnh sửa trực quan (Apidog, Postman), sau đó chạy chúng không giao diện bằng CLI tương ứng. Mọi trình chạy trong danh sách này đều trả về mã thoát, đó là tất cả những gì CI cần.

Sự khác biệt giữa client API terminal và công cụ kiểm thử là gì? Một client (curl, HTTPie, xh) gửi một yêu cầu và hiển thị phản hồi. Một công cụ kiểm thử (Apidog CLI, Hurl, Newman) khẳng định trên phản hồi và thất bại với mã thoát khác 0. Các client khám phá; các công cụ kiểm thử chặn.

Cái nào trong số này chạy trong các pipeline CI? Tất cả các trình chạy: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run, và k6 run đều thoát với mã khác 0 khi thất bại. Để có ví dụ về pipeline hoạt động, hãy xem cách chạy các kiểm thử Apidog CLI trong GitHub Actions.

Có cái nào trong số này xử lý kiểm thử tải không? k6 là chuyên gia tải ở đây, với các ngưỡng làm cổng pass/fail. Các công cụ khác kiểm tra độ chính xác, không phải năng lực, vì vậy nhiều nhóm ghép một trình chạy chức năng với k6.

Tôi có cần một đặc tả OpenAPI để sử dụng các công cụ này không? Chỉ Schemathesis yêu cầu một đặc tả, vì nó tạo các bài kiểm thử từ lược đồ. Ở mọi nơi khác, một đặc tả có ích hơn là cản trở: Apidog nhập OpenAPI 3.x, Swagger 2.0 và các collection Postman, và Step CI có thể xác thực phản hồi dựa trên lược đồ.

Mô hình trên cả mười công cụ là như nhau: việc tạo muốn sự thoải mái, việc chạy muốn một shell. Chọn nơi bạn muốn viết các bài kiểm thử, sau đó đảm bảo trình chạy cung cấp cho pipeline của bạn một mã thoát. Nếu bạn muốn cả hai phần từ một nền tảng, tải Apidog, xây dựng một kịch bản trong trình chỉnh sửa và thả lệnh apidog run của nó vào CI để hoàn tất vòng lặp.