Công cụ kiểm thử API dòng lệnh miễn phí mã nguồn mở

Hầu hết các hướng dẫn kiểm thử API đều chỉ bạn đến một giao diện người dùng đồ họa (GUI). Nhưng nếu bạn làm việc trong terminal, chạy kiểm thử trong CI, hoặc muốn một công cụ mà bạn có thể đọc mã nguồn của nó, thì dòng lệnh (CLI) là nơi kiểm thử API trở nên thú vị. Các công cụ CLI mã nguồn mở mang lại cho bạn những điều mà một sản phẩm lưu trữ không thể: một giấy phép bạn có thể kiểm tra, một tệp nhị phân bạn có thể tự lưu trữ, và một tệp cấu hình bạn có thể cam kết bên cạnh mã của mình.

Đây là một câu hỏi khác so với “công cụ nào nhanh nhất” hay “tệp nhị phân nào nhỏ nhất.” Ở đây, trọng tâm là cấp phép và quyền kiểm soát. Bạn có thể chạy nó trong mạng nội bộ của mình mà không cần tài khoản không? Mã nguồn có trên GitHub theo giấy phép được OSI chấp thuận thực sự không? Nó có tiếp tục hoạt động nếu nhà cung cấp thay đổi giá vào quý tới không? Đây là những câu hỏi mà danh sách này trả lời.

Dưới đây là tám công cụ CLI miễn phí, có sẵn mã nguồn để kiểm thử REST, GraphQL và HTTP API, mỗi công cụ đều có giấy phép chính xác, lệnh cài đặt thực tế và một lệnh minh họa cách hoạt động. Nếu bạn muốn một khảo sát rộng hơn bao gồm các công 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. Để có một cách tiếp cận thuần túy terminal-first để truy cập các endpoint bằng tay, hướng dẫn các lựa chọn thay thế curl để kiểm thử REST API bao gồm khía cạnh tương tác.

button

Điều gì khiến một công cụ CLI "mã nguồn mở" cho kiểm thử API

Rất nhiều công cụ miễn phí để tải xuống. Điều đó không giống với mã nguồn mở. Đối với danh sách này, một công cụ đủ điều kiện dựa trên ba điểm:

Giấy phép thực sự. Mã nguồn công khai theo giấy phép được OSI chấp thuận (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD). Bạn có thể đọc, fork và biết mình được phép làm gì.
Có thể tự lưu trữ, không cần tài khoản. Bạn có thể chạy toàn bộ công cụ trên máy của mình hoặc trình chạy CI mà không cần đăng ký bất kỳ thứ gì. Không có phí chỗ ngồi, không yêu cầu gọi về máy chủ.
Được duy trì và kiểm tra. Kho lưu trữ nằm trên GitHub với lịch sử commit và các vấn đề hiển thị, vì vậy bạn có thể đánh giá xem nó còn hoạt động không trước khi xây dựng một pipeline dựa trên nó.

Mỗi công cụ dưới đây đều đáp ứng hai điểm đầu tiên. Tôi đã đánh dấu công cụ không còn đáp ứng điểm thứ ba. Việc lựa chọn giấy phép quan trọng hơn vẻ bề ngoài: AGPL-3.0 (k6) có nghĩa vụ copyleft nếu bạn xây dựng một dịch vụ xung quanh nó, trong khi MIT và Apache-2.0 có tính chất dễ dãi hơn. Hãy đọc giấy phép trước khi bạn nhúng một công cụ vào sản phẩm.

Hurl: kiểm thử HTTP dạng văn bản thuần túy, một tệp nhị phân Rust duy nhất

Hurl chạy các yêu cầu HTTP được viết dưới định dạng văn bản thuần túy và xác nhận các phản hồi. Nó được xây dựng bởi Orange-OpenSource bằng Rust, được cung cấp bởi libcurl bên dưới, và được phân phối dưới dạng một tệp nhị phân duy nhất. Các kiểm thử gần như giống với chính các yêu cầu, điều này giúp dễ dàng xem xét chúng trong một pull request.

Giấy phép: Apache-2.0. Mã nguồn: github.com/Orange-OpenSource/hurl.

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

# login.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

Tốt nhất cho: các kiểm tra kiểu hợp đồng và kiểm thử smoke mà bạn muốn giữ trong hệ thống kiểm soát phiên bản dưới dạng văn bản dễ đọc. Giới hạn 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. Đối với bất cứ điều gì ngoài chuỗi xác nhận đơn giản, bạn sẽ viết thêm các tệp .hurl thay vì sử dụng ngôn ngữ script.

Step CI: Các quy trình API YAML được xây dựng cho CI

Step CI là một trình chạy quy trình được cấu hình bằng YAML, được tạo ra cho tích hợp liên tục. Nó bao gồm REST, GraphQL, gRPC, tRPC và SOAP trong một tệp quy trình duy nhất, và nó có thể kiểm thử tải và xác thực dựa trên schema OpenAPI. Trình chạy và CLI miễn phí vĩnh viễn.

Giấy phép: MPL-2.0. Mã nguồn: github.com/stepci/stepci.

npm install -g stepci

# workflow.yml mô tả các bước, kiểm tra và thu thập
stepci run workflow.yml

Tốt nhất cho: các nhóm muốn có một tệp khai báo duy nhất mô tả một luồng API đa bước và chạy nó theo cùng một cách cục bộ và trong CI. Giới hạn thực tế: MPL-2.0 là một giấy phép copyleft yếu, vì vậy nếu bạn sửa đổi các tệp của Step CI, bạn sẽ phải chia sẻ lại những thay đổi đó. Việc sử dụng nó để kiểm thử ứng dụng của bạn không có nghĩa vụ như vậy.

Schemathesis: kiểm thử dựa trên thuộc tính từ schema của bạn

Schemathesis đọc schema OpenAPI hoặc GraphQL của bạn và tạo hàng ngà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 thư viện Hypothesis của Python. Thay vì bạn viết từng trường hợp, nó kiểm tra các đầu vào để tìm lỗi 500, vi phạm schema và các phản hồi không khớp với những gì tài liệu của bạn cam kết.

Giấy phép: MIT. Mã nguồn: github.com/schemathesis/schemathesis.

uv pip install schemathesis   # hoặc: pip install schemathesis

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

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

Dredd: kiểm thử hợp đồng dựa trên mô tả API của bạn

Dredd kiểm tra xem API trực tiếp của bạn có thực sự khớp với tài liệu mô tả của nó hay không. Hãy chỉ nó vào một tệp OpenAPI (hoặc API Blueprint) và một backend đang chạy, và nó sẽ phát lại mọi yêu cầu được tài liệu hóa và so sánh phản hồi thực tế với spec. Nó không phụ thuộc vào ngôn ngữ và hỗ trợ các hook để thiết lập và hủy bỏ.

Giấy phép: MIT. Mã nguồn: github.com/apiaryio/dredd.

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

Tốt nhất cho: chứng minh rằng tài liệu và triển khai của bạn không bị lệch nhau. Giới hạn thực tế, và đây là một giới hạn đáng kể: kho lưu trữ Dredd đã được lưu trữ vào tháng 11 năm 2024 và chỉ đọc. Nó vẫn chạy, nhưng không còn được duy trì, vì vậy hãy coi nó là một công cụ ổn định không có các bản sửa lỗi trong tương lai. Nếu bạn muốn một công cụ kiểm tra dựa trên schema được duy trì tích cực, Schemathesis là lựa chọn an toàn hơn.

k6: kiểm thử tải được viết kịch bản bằng JavaScript

k6 là công cụ kiểm thử tải và hiệu suất của Grafana. Bạn viết kịch bản kiểm thử bằng JavaScript hoặc TypeScript, và một engine Go nhanh chóng điều khiển chúng ở quy mô lớn. Đây là lựa chọn mã nguồn mở hàng đầu khi bạn cần biết API của mình hoạt động như thế nào dưới hàng trăm hoặc hàng ngàn người dùng ảo, không chỉ đơn thuần là liệu một yêu cầu duy nhất có thành công hay không.

Giấy phép: AGPL-3.0. Mã nguồn: github.com/grafana/k6.

brew install k6

k6 new script.js   # tạo một kiểm thử khởi đầu
k6 run script.js

Tốt nhất cho: kiểm thử hiệu suất và độ bền sống trong cùng một repo với các kiểm thử chức năng của bạn. Giới hạn thực tế: AGPL-3.0 là giấy phép copyleft mạnh. Điều này tốt cho việc chạy kiểm thử, nhưng nếu bạn xây dựng và phân phối một dịch vụ xung quanh mã của k6, giấy phép này có những nghĩa vụ thực sự; hãy đọc nó trước. k6 cũng tập trung vào tải, không phải các xác nhận hợp đồng chi tiết.

Newman: chạy các bộ sưu tập Postman mà không cần GUI

Newman là trình chạy bộ sưu tập dòng lệnh của riêng Postman. Nếu nhóm của bạn đã có các yêu cầu và kiểm thử API được lưu dưới dạng bộ sưu tập Postman, Newman sẽ chạy chính xác bộ sưu tập đó từ terminal hoặc trong CI, không cần ứng dụng desktop. Đây là cách tiêu chuẩn để đưa một quy trình Postman vào một pipeline.

Giấy phép: Apache-2.0. Mã nguồn: github.com/postmanlabs/newman.

npm install -g newman

newman run my-collection.json -e staging-environment.json

Tốt nhất cho: các nhóm có bộ sưu tập Postman hiện có muốn chạy CI mà không phải trả thêm phí cho các tài khoản Postman bổ sung. Giới hạn thực tế: nó gắn liền với định dạng bộ sưu tập Postman, vì vậy bạn tạo kiểm thử trong giao diện người dùng của Postman (hoặc JSON của nó) thay vì trong một tệp cấu hình thuần túy. Nó chạy các bộ sưu tập; nó không thiết kế hoặc mock API.

Tavern: kiểm thử API dưới dạng plugin pytest

Tavern là một thư viện Python, CLI và plugin pytest mô tả các kiểm thử API trong YAML. Vì nó tích hợp với pytest, bạn sẽ nhận được toàn bộ hệ sinh thái pytest miễn phí: fixtures, báo cáo, song song hóa và các tích hợp CI mà bạn có thể đã sử dụng. Nó xử lý REST, MQTT và gRPC.

Giấy phép: MIT. Mã nguồn: github.com/taverntesting/tavern.

pip install tavern

# test_login.tavern.yaml nằm cạnh các kiểm thử khác của bạn
pytest test_login.tavern.yaml

Tốt nhất cho: các cửa hàng Python đã chạy pytest và muốn các kiểm thử API nằm ngay cạnh các kiểm thử đơn vị. Giới hạn thực tế: nó giả định bạn đã quen thuộc với việc thiết lập kiểm thử Python. Nếu stack của bạn không phải Python, sự phụ thuộc vào pytest sẽ là một trở ngại hơn là một tính năng.

Venom: kiểm thử tích hợp đa trình điều khiển từ OVHcloud

Venom, từ OVHcloud, chạy kiểm thử tích hợp trên nhiều loại trình điều khiển: yêu cầu HTTP, script shell, IMAP, web, cơ sở dữ liệu và nhiều hơn nữa. Nó được viết bằng Go, sử dụng các bộ kiểm thử YAML và xuất các tệp kết quả xUnit mà các hệ thống CI đọc nguyên bản. Nó tỏa sáng khi một kiểm thử duy nhất cần chạm vào nhiều hơn một endpoint HTTP.

Giấy phép: BSD (đã sửa đổi). Mã nguồn: github.com/ovh/venom.

# tải tệp nhị phân từ các bản phát hành GitHub, sau đó:
venom run testsuite.yml

Tốt nhất cho: các luồng end-to-end kết hợp một cuộc gọi API với kiểm tra cơ sở dữ liệu hoặc một bước script trong một bộ kiểm thử. Giới hạn thực tế: với rất nhiều trình điều khiển, YAML trở nên dài dòng và tài liệu giả định bạn sẽ tự ghép nối các ví dụ từ repo.

Vị trí của Apidog (và một lưu ý chân thành)

Đây là phần chân thành. Apidog không phải là mã nguồn mở. Nó là một sản phẩm thương mại với gói miễn phí, vì vậy nó không thuộc danh sách các công cụ có sẵn mã nguồn. Nhưng đáng để biết đến nó vì một lý do: mỗi công cụ ở trên làm một công việc, và việc kết nối Hurl cộng với Schemathesis cộng với Newman cộng với một máy chủ mock thành một quy trình làm việc mạch lạc là một công việc thực sự mà bạn phải tự duy trì.

Apidog tích hợp thiết kế, kiểm thử, mocking và tài liệu vào một nền tảng duy nhất, và apidog-cli đưa khía cạnh kiểm thử ra terminal. Bạn xây dựng kịch bản kiểm thử một lần, sau đó chạy chúng trong CI chỉ với một lệnh:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # thoát 0 nếu tất cả đều thành công, khác 0 nếu thất bại

Đầu ra là JSON có cấu trúc với agentHints.nextSteps, giúp dễ dàng tạo script hoặc chuyển cho một tác nhân AI. Hướng dẫn apidog-cli đầy đủ sẽ trình bày toàn bộ bộ lệnh. Vì vậy: không phải mã nguồn mở, nhưng gói miễn phí cộng với CLI mang đến cho bạn một giải pháp thay thế tích hợp cho việc kết nối nhiều công cụ đơn lẻ với nhau. Nếu giấy phép có thể kiểm tra là một yêu cầu bắt buộc, hãy chọn một trong tám công cụ ở trên. Nếu một quy trình làm việc tích hợp quan trọng hơn, thì đây là sự đánh đổi.

Cách chọn

Công cụ	Tốt nhất cho	Cài đặt	Mã nguồn mở?	Giấy phép
Hurl	Xác nhận HTTP dạng văn bản thuần túy trong Git	`brew install hurl`	Có	Apache-2.0
Step CI	Quy trình CI khai báo	`npm i -g stepci`	Có	MPL-2.0
Schemathesis	Kiểm tra ngẫu nhiên dựa trên thuộc tính từ schema	`pip install schemathesis`	Có	MIT
Dredd	Kiểm thử hợp đồng tài liệu-vs-triển khai	`npm i -g dredd`	Có (đã lưu trữ)	MIT
k6	Kiểm thử tải và hiệu suất	`brew install k6`	Có	AGPL-3.0
Newman	Chạy các bộ sưu tập Postman trong CI	`npm i -g newman`	Có	Apache-2.0
Tavern	Kiểm thử API bên trong pytest	`pip install tavern`	Có	MIT
Venom	Các bộ tích hợp đa trình điều khiển	Bản phát hành GitHub	Có	BSD
apidog-cli	Quy trình làm việc tích hợp từ thiết kế đến kiểm thử	`npm i -g apidog-cli`	Không (gói miễn phí)	Thương mại

Chọn công cụ phù hợp với công việc. Tìm đến Hurl hoặc Newman khi bạn muốn kiểm tra yêu cầu nhanh chóng, dễ đọc; Schemathesis khi bạn có một schema và muốn tìm lỗi; k6 khi vấn đề là quy mô; Tavern hoặc Venom khi các kiểm thử cần nằm trong một bộ lớn hơn. Nếu bạn đang cân nhắc những điều này so với một quy trình lớn hơn, hướng dẫn chiến lược kiểm thử API bao gồm vị trí của từng loại, và bài viết công cụ kiểm thử API không giao diện người dùng xem xét việc chạy kiểm thử mà không cần giao diện người dùng nào cả.

Tổng kết

Các công cụ CLI mã nguồn mở mang đến cho bạn khả năng kiểm thử API mà bạn có thể đọc, fork và chạy theo cách riêng của mình. Hurl và Newman xử lý các kiểm tra yêu cầu hàng ngày, Schemathesis và Dredd thực thi hợp đồng của bạn, k6 đẩy mạnh hiệu suất, và Tavern cùng Venom tích hợp các kiểm thử API vào các bộ lớn hơn. Hãy chọn theo giấy phép và công việc duy nhất bạn cần thực hiện; không gì ngăn cản bạn chạy hai trong số chúng.

Khi bạn muốn thiết kế, kiểm thử, mock và tài liệu hóa ở một nơi thay vì duy trì một chuỗi công cụ, Apidog bao gồm toàn bộ vòng đời và cung cấp apidog-cli cho CI. Tải Apidog để dùng thử CLI cùng với các công cụ trên và xem sự kết hợp nào phù hợp với pipeline của bạn.