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 container CI không có màn hình, trên máy chủ staging chỉ truy cập qua SSH, và dưới sự điều khiển của tác nhân AI chỉ giao tiếp bằng shell. Trong cả ba trường hợp, terminal là nơi một bài kiểm thử thành công hoặc thất bại mà không cần con người theo dõi.

Dùng thử Apidog ngay hôm nay

Bài viết này xếp hạng các công cụ thực hiện kiểm thử trực tiếp từ lời nhắc shell. “Dựa trên terminal” nghĩa là toàn bộ vòng lặp chạy trong shell: cài đặt từ trình quản lý gói, chạy một lệnh và đọc mã thoát. Các tiêu chí gồm khẳng định tích hợp sẵn, luồng đa bước, báo cáo phù hợp CI và trạng thái bảo trì.

Các client thủ công như curl vẫn có vị trí trong danh sách vì nhiều quy trình terminal dựa vào chúng giữa các lần chạy kiểm thử. Nếu cần khảo sát rộng hơn, bao gồm GUI và công cụ được lưu trữ, xem các công cụ kiểm thử API miễn phí tốt nhất.

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

Một client terminal gửi yêu cầu và hiển thị phản hồi. Một công cụ kiểm thử terminal đánh giá phản hồi, sau đó báo cáo kết quả bằng mã thoát để pipeline có thể hành động.

Một công cụ kiểm thử terminal cần có bốn đặc điểm:

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

Dưới đây là 10 công cụ đáng cân nhắc cho kiểm thử API từ terminal năm 2026.

1. Apidog CLI: tạo trực quan, chạy không giao diện ở mọi nơi

Apidog là nền tảng API tất cả trong một gồm thiết kế, kiểm thử, mocking và tài liệu. Apidog CLI (apidog-cli trên npm) là thành phần dành cho terminal.

Bạn tạo kịch bản trong trình chỉnh sửa trực quan, bao gồm yêu cầu nối tiếp, biến trích xuất và khẳng định. Sau đó, dùng apidog run để thực thi cùng kịch bản từ bất kỳ shell nào.

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
apidog run -t <scenario_id> -e <env_id> -r cli

Cách triển khai trong CI

1. Mở kịch bản trong Apidog.
2. Chuyển đến tab CI/CD.
3. Sao chép lệnh được tạo sẵn.
4. Lưu token vào secret của hệ thống CI.
5. Chạy apidog run trong job CI.

Apidog CLI hỗ trợ các trình báo cáo cli, html, json và junit. Báo cáo được ghi vào apidog-reports/, phù hợp để tải lên làm CI artifact.

Các lần chạy theo hướng dữ liệu có thể lấy dữ liệu lặp từ tệp CSV hoặc JSON. Đầu ra JSON có cấu trúc chứa agentHints.nextSteps, giúp tác nhân AI chạy bộ kiểm thử và quyết định bước tiếp theo mà không cần đọc giao diện màn hình.

Yêu cầu: Node.js 16 trở lên.

Tốt nhất cho: Nhóm muốn tạo luồng kiểm thử phức tạp, đa bước trong trình chỉnh sửa và chạy giống nhau trên máy tính cá nhân, CI và tác nhân tự động.

Hạn chế thực tế: Không phải mã nguồn mở và không phải công cụ gửi yêu cầu ad-hoc. Kịch bản nằm trong dự án Apidog, nên đây là lựa chọn nền tảng tích hợp thay vì một HTTP client đơn thuần.

Xem thêm hướng dẫn hoàn chỉnh về Apidog CLI.

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

Hurl chạy yêu cầu HTTP được viết bằng định dạng văn bản thuần túy và thực hiện khẳng định trên phản hồi. Công cụ được xây dựng bằng Rust trên nền libcurl, cung cấp dưới dạng một tệp nhị phân duy nhất nên không cần cài runtime.

Một bài kiểm thử Hurl gần giống HTTP thô, dễ đọc và dễ review trong pull request.

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

Lệnh hurl --test trả về mã khác 0 nếu một khẳng định thất bại, nên có thể dùng trực tiếp làm CI gate.

Ví dụ CI tối thiểu

hurl --test tests/*.hurl

Tốt nhất cho: Kiểm tra smoke test và contract test được lưu trong Git dưới dạng tệp văn bản dễ đọc.

Hạn chế thực tế: Tập trung vào HTTP; không dùng để điều khiển gRPC hoặc tạo tải. Logic phức tạp thường dẫn đến nhiều tệp .hurl thay vì một ngôn ngữ kịch bản đầy đủ.

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

Newman là trình chạy dòng lệnh mã nguồn mở cho collection Postman, sử dụng giấy phép Apache-2.0.

Nếu nhóm đã có collection và test script trong Postman, bạn có thể xuất collection cùng environment dưới dạng JSON, rồi chạy chúng trong CI bằng Newman.

npm install -g newman

newman run collection.json -e staging.json

Cách dùng trong pipeline

newman run collection.json \
  -e staging.json \
  --reporters cli,junit \
  --reporter-junit-export newman-results.xml

Newman trả về mã khác 0 khi một bài kiểm thử thất bại, nên CI có thể chặn merge hoặc deployment.

Tốt nhất cho: Nhóm đã đầu tư vào Postman và muốn chạy collection hiện có trong pipeline mà không cần GUI.

Hạn chế thực tế: Chỉ chạy collection định dạng Postman. Việc tạo và chỉnh sửa collection vẫn diễn ra trong GUI Postman; Newman thực thi bài kiểm thử nhưng 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

Postman CLI là trình chạy mã nguồn đóng của Postman. Không giống Newman, nó đăng nhập vào tài khoản Postman và có thể chạy collection bằng ID trực tiếp từ workspace.

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

postman collection run <collection_id> -e <environment_id>

Khi nên dùng

Dùng Postman CLI khi bạn muốn:

• Chạy collection trực tiếp từ Postman workspace.
• Liên kết kết quả chạy với Postman cloud.
• Không cần xuất collection và environment thành tệp JSON.

Tốt nhất cho: Nhóm Postman muốn các lần chạy liên kết đám mây.

Hạn chế thực tế: Mã nguồn đóng, phụ thuộc tài khoản Postman và có thể gây nhầm lẫn với Newman vì cả hai đều là trình chạy chính thức.

Xem chi tiết trong bài so sánh Postman CLI vs Newman.

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

Bruno lưu collection dưới dạng tệp văn bản .bru trong thư mục thông thường. Điều này cho phép bạn đặt request, assertion và script trong cùng repository với source code.

CLI của Bruno là @usebruno/cli, chạy collection bằng lệnh bru mà không yêu cầu 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

Ví dụ xuất báo cáo cho CI

bru run --env staging --reporter-junit output.xml

Bruno có thể ghi báo cáo JSON, JUnit và HTML để dùng trong CI.

Tốt nhất cho: Nhóm muốn collection được review qua pull request, chạy ngoại tuyến và nằm hoàn toàn trong Git.

Hạn chế thực tế: Cách tạo tệp văn bản phù hợp hơn với lập trình viên so với nhóm hỗn hợp. Hệ sinh thái cũng còn non trẻ hơn Postman.

Xem Bruno CLI vs Apidog CLI để so sánh hai cách tiếp cận.

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

Schemathesis đọc lược đồ OpenAPI hoặc GraphQL và tự động tạo hàng nghìn trường hợp kiểm thử. Nó dùng kiểm thử dựa trên thuộc tính, xây dựng trên Hypothesis của Python.

Thay vì viết từng trường hợp, bạn để Schemathesis fuzz đầu vào nhằm phát hiện:

• Lỗi HTTP 500.
• Vi phạm lược đồ.
• Phản hồi không đúng hợp đồng API.
• Trường hợp góc không được bao phủ bởi test thủ công.

pip install schemathesis

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

Dùng trong quy trình phát hành

schemathesis run https://api.example.com/openapi.json \
  --base-url https://staging.example.com

Tốt nhất cho: Phát hiện lỗi edge case trước khi phát hành, đặc biệt khi bạn có lược đồ OpenAPI đáng tin cậy.

Hạn chế thực tế: Cần một lược đồ thực sự để hoạt động. API lớn có thể tạo nhiều kết quả cần lọc bằng hook và tùy chọn cấu hình.

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

Step CI mô tả quy trình API bằng một tệp YAML duy nhất gồm các bước, giá trị thu thập và kiểm tra.

Công cụ hỗ trợ REST, GraphQL, gRPC, tRPC và SOAP trong cùng một workflow. Nó cũng có thể xác thực dựa trên lược đồ OpenAPI.

npm install -g stepci

stepci run workflow.yml

Trường hợp phù hợp

Dùng Step CI khi bạn cần mô tả luồng như:

1. Đăng nhập.
2. Trích xuất access token.
3. Gọi API cần xác thực.
4. Kiểm tra phản hồi cuối cùng.

Tốt nhất cho: Luồng đăng nhập-sau đó-dùng-token được mô tả khai báo thay vì viết script.

Hạn chế thực tế: Cần runtime Node.js. Tần suất phát hành đã chậm lại, vì vậy nên kiểm tra hoạt động gần đây của repository trước khi xây dựng pipeline phụ thuộc vào nó.

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

curl có sẵn trên macOS, phần lớn bản phân phối Linux và Windows hiện tại. Đây là lựa chọn nhẹ nhất khi môi trường CI hoặc máy chủ bị khóa không cho cài thêm công cụ.

curl là HTTP client tham chiếu. Với -w và shell script, 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}'

Biến curl thành kiểm tra CI đơn giản

status=$(
  curl -s -o /dev/null -w "%{http_code}" \
    https://api.example.com/health
)

test "$status" = "200"

Trong ví dụ này, test sẽ trả về mã khác 0 nếu API không trả về 200.

Tốt nhất cho: Request một lần, script nhỏ và môi trường không thể cài thêm dependency.

Hạn chế thực tế: Mọi assertion đều phải tự làm. Bạn phải dùng jq, tự so sánh giá trị và tự quản lý mã thoát. curl gửi và hiển thị phản hồi; nó không phải test runner hoàn chỉnh.

Xem các lựa chọn thay thế curl cho kiểm thử REST API khi shell glue bắt đầu trở nên khó bảo trì.

9. HTTPie và xh: request thủ công dễ đọc

HTTPie giúp request terminal dễ đọc hơn. Lệnh là http, trường JSON được viết dưới dạng key=value, phản hồi được định dạng và tô màu.

xh triển khai lại cú pháp tương tự bằng Rust, đóng gói thành một tệp nhị phân tĩnh duy nhất. Nó khởi động nhanh hơn và có cờ --curl để in 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

Chuyển request xh sang curl

xh --curl POST api.example.com/users name=acme plan=pro

Tốt nhất cho: Khám phá API thủ công trong khi bạn xây dựng bộ kiểm thử thực tế ở công cụ khác.

Hạn chế thực tế: Cả hai đều là client, không phải test runner. HTTPie cần runtime Python; xh đánh đổi một phần tính năng để có tốc độ và binary gọn nhẹ. Cả hai không cung cấp assertion phản hồi tích hợp sẵn.

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

k6 trả lời câu hỏi khác với test chức năng: không phải “phản hồi có đúng không?”, mà là “API có chịu được lưu lượng truy cập không?”.

k6 là một binary Go của Grafana, viết kịch bản bằng JavaScript. Các ngưỡng biến bài kiểm thử tải thành CI gate: vượt ngưỡng thì k6 thoát với mã khác 0.

brew install k6

k6 run load.js

Ví dụ load.js tối thiểu:

import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 10,
  duration: "30s",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  const response = http.get("https://api.example.com/health");

  check(response, {
    "trả về 200": (res) => res.status === 200,
  });
}

Tốt nhất cho: Kiểm tra hiệu suất được lưu cùng repository với test chức năng và chạy từ máy cá nhân hoặc pipeline.

Hạn chế thực tế: Đây là công cụ tải dưới AGPL-3.0, không phải HTTP client kiểm thử chức năng. Kịch bản có ý nghĩa đòi hỏi phải học API JavaScript của k6.

Thích công cụ tương tác hơn?

Nếu bạn muốn giao diện giống Postman nhưng không rời shell, hãy xem client TUI như atac và posting. Chúng hiển thị trình chỉnh sửa request đầy đủ ngay trong terminal.

Các công cụ này phù hợp để khám phá API, không phải để chặn pipeline. Xem các client REST API terminal và TUI tốt nhất để tìm hiểu thêm.

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 kịch bản tạo trực quan trong CI	Có	npm i -g apidog-cli	Không, có 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	Chạy collection Postman không giao diện	Có	npm i -g newman	Apache-2.0
Postman CLI	Chạy Postman liên kết đám mây	Có	Trình cài đặt Postman	Không
Bruno CLI	Collection .bru gốc Git	Có	npm i -g @usebruno/cli	MIT
Schemathesis	Fuzzing từ lược đồ	Tự động tạo	pip install schemathesis	MIT
Step CI	Luồng YAML đa bước	Có	npm i -g stepci	MPL-2.0
curl	Request thô, script	Tự làm	Cài sẵn	Có
HTTPie / xh	Request thủ công dễ đọc	Không	brew install httpie / xh	Có
k6	Kiểm thử 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 cần làm, không phải từ công cụ.

• Nếu bài kiểm thử đã ở trong Postman, dùng Newman hoặc Postman CLI để chạy ngay.
• Nếu muốn bài kiểm thử là văn bản có thể review trong Git, chọn Hurl hoặc Bruno CLI.
• Nếu có lược đồ OpenAPI tốt, thêm Schemathesis để tìm lỗi không được dự đoán trước.
• Giữ curl và xh cho nhu cầu request thủ công.
• Dùng k6 khi câu hỏi chuyển từ độ chính xác sang khả năng chịu tải.
• Chọn Apidog CLI khi muốn tạo kịch bản trong trình chỉnh sửa trực quan và chạy chúng ở mọi môi trường khác.

Apidog CLI là lựa chọn trong danh sách này mà cùng một dự án cũng có thể chứa thiết kế API, dữ liệu giả và tài liệu. Xem thêm Apidog CLI: client API sống trong terminal của bạn.

Để hiểu rộng hơn về các lớp kiểm thử, xem chiến lược kiểm thử API.

FAQ

Tôi có thể kiểm thử API hoàn toàn từ terminal không?

Có. Bạn có thể tạo bài kiểm thử dưới dạng tệp như Hurl, Bruno hoặc Step CI; hoặc tạo trong trình chỉnh sửa trực quan như Apidog và Postman, rồi chạy không giao diện bằng CLI tương ứng.

Mọi test runner trong danh sách đều trả về mã thoát, đó là thông tin cốt lõi mà CI cần.

Khác biệt giữa API client terminal và công cụ kiểm thử là gì?

Client như curl, HTTPie và xh gửi request rồi hiển thị phản hồi.

Công cụ kiểm thử như Apidog CLI, Hurl và Newman thực hiện assertion trên phản hồi, đồng thời trả về mã khác 0 khi thất bại. Client dùng để khám phá; test runner dùng để chặn pipeline.

Công cụ nào chạy được trong pipeline CI?

Tất cả các trình chạy sau đều trả về mã khác 0 khi thất bại:

apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run

Xem ví dụ thực tế về chạy kiểm thử Apidog CLI trong GitHub Actions.

Có công cụ nào xử lý kiểm thử tải không?

Có. k6 là công cụ chuyên về kiểm thử tải trong danh sách này. Nó dùng threshold để tạo cổng pass/fail.

Các công cụ khác chủ yếu kiểm tra tính đúng đắn chức năng, không đo khả năng chịu tải. Nhiều nhóm ghép một test runner chức năng với k6.

Tôi có cần đặc tả OpenAPI không?

Chỉ Schemathesis yêu cầu đặc tả vì nó tạo test từ lược đồ.

Với các công cụ khác, OpenAPI vẫn rất hữu ích. Apidog có thể nhập OpenAPI 3.x, Swagger 2.0 và collection Postman. Step CI cũng có thể xác thực phản hồi dựa trên lược đồ.

Mô hình chung của cả 10 công cụ là: việc tạo test cần sự thuận tiện, còn việc chạy test cần shell và mã thoát rõ ràng. Hãy chọn nơi bạn muốn viết test, sau đó đảm bảo runner có thể báo kết quả cho pipeline.

Nếu cần cả trình chỉnh sửa lẫn CLI runner trong cùng nền tảng, hãy tải Apidog, tạo kịch bản trong trình chỉnh sửa và đưa lệnh apidog run vào CI.