Top CLI-basierte API-Testing-Tools 2026

API-Tests finden nicht mehr nur in GUIs statt. Tests laufen jetzt in CI-Containern ohne angeschlossenen Bildschirm, auf Staging-Systemen, die man nur über SSH erreicht, und unter KI-Agenten, die nur Shell verstehen. An allen drei Orten ist das Terminal der Ort, an dem ein Test bestanden oder fehlgeschlagen wird, ohne dass ein Mensch zuschaut.

Diese Zusammenstellung bewertet die Tools, die echte Testarbeit von einer Shell-Eingabeaufforderung ausführen. „Terminalbasiert“ bedeutet hier, dass der gesamte Ablauf in einer Shell ausgeführt wird: Installation über einen Paketmanager, Ausführung eines Befehls, Auslesen eines Exit-Codes. Die Rangliste berücksichtigt integrierte Assertions, mehrstufige Abläufe, CI-fähige Berichte und den Wartungsstatus. Manuelle Clients wie curl erhalten immer noch einen Platz am Ende, da jeder Terminal-Workflow zwischen den Testläufen auf sie zurückgreift. Eine breitere Übersicht, die GUI- und gehostete Tools umfasst, finden Sie in der Zusammenstellung der besten kostenlosen API-Test-Tools.

Was einen Testing-Tool von einem Client unterscheidet

Ein Terminal-Client sendet eine Anfrage und zeigt Ihnen die Antwort. Ein Terminal-Test-Tool beurteilt die Antwort und meldet das Ergebnis als Exit-Code, den Ihre Pipeline als Kriterium verwenden kann. Die zweite Gruppe ist das Herzstück dieser Liste, und vier Merkmale definieren sie:

• Integrierte Assertions. Status-, Header- und Body-Prüfungen gehören ins Tool, nicht in einen Haufen von jq-Klebstoff.
• Aussagekräftige Exit-Codes. Null bei Erfolg, ungleich Null bei Fehler, damit CI den Build für Sie fehlschlagen lässt.
• Wiederholbarkeit. Tests leben in Dateien oder Projekten, die Sie versionieren und erneut ausführen können, nicht in Ihrem Shell-Verlauf.
• Berichte. Ausgabe, die ein Mensch im Terminal lesen und ein Dashboard als JSON, JUnit oder HTML parsen kann.

Nachdem die Kriterien festgelegt sind, hier sind die zehn Tools, die im Jahr 2026 Ihre Zeit wert sind.

1. Apidog CLI: visuell erstellen, überall headless ausführen

Apidog ist eine All-in-One-API-Plattform, die Design, Testing, Mocking und Dokumentation umfasst. Die Apidog CLI (`apidog-cli` auf npm) ist ihr Terminal-Zweig. Sie erstellen Testszenarien im visuellen Editor, mit verketteten Anfragen, extrahierten Variablen und Assertions, dann führt apidog run diese von jeder Shell aus und gibt Ihrer Pipeline einen sauberen Exit-Code.

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

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

Sie müssen die IDs nicht erraten. Öffnen Sie das Szenario in Apidog, gehen Sie zum CI/CD-Tab und kopieren Sie den generierten Befehl. Berichterstatter decken `cli`, `html`, `json` und `junit` ab, die in `apidog-reports/` geschrieben werden, sodass derselbe Lauf ein Terminal, ein Dashboard und einen Artefakt-Speicher speist. Datengesteuerte Läufe ziehen Iterationen aus CSV- oder JSON-Dateien. Die Ausgabe ist strukturiertes JSON mit `agentHints.nextSteps`, wodurch ein KI-Code-Agent eine Suite ausführen und seinen nächsten Schritt entscheiden kann, ohne Screen-Scraping zu betreiben. Es benötigt Node.js 16 oder neuer.

Am besten für: Teams, die komplexe, mehrstufige Szenarien in einem Editor erstellen und identisch auf einem Laptop, in CI und von Agenten ausführen möchten. Ehrliche Einschränkung: Es ist nicht Open Source und kein Ad-hoc-Sender. Szenarien leben in einem Apidog-Projekt, daher ist dies die Option der integrierten Plattform und kein bloßes HTTP-Tool. Der vollständige Leitfaden zur Apidog CLI deckt den gesamten Befehlssatz ab.

2. Hurl: Plain-Text-Tests in einer Rust-Binärdatei

Hurl führt HTTP-Anfragen aus, die in einem Klartextformat geschrieben sind, und prüft die Antworten. Es ist in Rust auf Basis von libcurl erstellt und wird als einzelne Binärdatei ausgeliefert, sodass keine Laufzeitumgebung installiert werden muss. Tests lesen sich fast wie rohes HTTP, was die Überprüfung in einem Pull Request erleichtert.

brew install hurl   # or: 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   # non-zero exit if an assertion fails

Am besten für: vertragsbasierte Prüfungen und Smoke-Tests, die Sie als lesbaren Text in der Versionskontrolle speichern. Das `--test`-Flag macht es zu einem natürlichen CI-Gate. Ehrliche Einschränkung: Es ist HTTP-fokussiert, treibt also kein gRPC an oder generiert Last, und komplexe Logik bedeutet mehr `.hurl`-Dateien statt einer Skriptsprache.

3. Newman: Postman-Sammlungen headless ausführen

Newman ist der Open-Source-Kommandozeilen-Runner für Postman-Sammlungen (Apache-2.0). Wenn Ihr Team bereits Anfragen und Tests in Postman erstellt, führt Newman genau diese Sammlung von einem Terminal ohne GUI aus. Sie exportieren die Sammlung und die Umgebung als JSON und verweisen Newman auf die Dateien.

npm install -g newman

newman run collection.json -e staging.json

Am besten für: Teams, die in Postman investiert sind und bestehende Sammlungen in einer Pipeline ohne zusätzliche Lizenzen ausführen möchten. Es beendet sich mit einem Wert ungleich Null, wenn ein Test fehlschlägt, sodass CI sauber abbricht. Ehrliche Einschränkung: Es führt nur Sammlungen im Postman-Format aus, und die Erstellung erfolgt immer noch in der Postman-GUI. Es führt Tests aus; es hilft Ihnen nicht, sie zu schreiben.

4. Postman CLI: die First-Party-Alternative zu Newman

Die Postman CLI ist Postmans eigener Closed-Source-Runner. Im Gegensatz zu Newman meldet sie sich bei Ihrem Postman-Konto an und kann eine Sammlung anhand ihrer ID direkt aus dem Arbeitsbereich ausführen, wobei die Ergebnisse an Postmans Cloud zurückgemeldet werden.

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

postman collection run <collection_id> -e <environment_id>

Am besten für: Postman-Teams, die Cloud-verknüpfte Läufe ohne Export von JSON-Dateien wünschen. Ehrliche Einschränkung: Es ist Closed Source und an ein Postman-Konto gebunden, und das Vorhandensein von zwei offiziellen Runnern führt zu echter Verwirrung darüber, welchen man verwenden soll. Der Vergleich Postman CLI vs. Newman erklärt, wann welche Option sinnvoll ist.

5. Bruno CLI: Git-native Sammlungen, ausgeführt mit bru

Bruno speichert Sammlungen als Klartext-`.bru`-Dateien in gewöhnlichen Ordnern, sodass Anfragen wie jeder andere Code in Ihrem Repository leben. Sein CLI, `@usebruno/cli`, führt diese Sammlungen vom Terminal aus mit dem Befehl `bru` aus, ohne dass ein Cloud-Konto erforderlich ist.

npm install -g @usebruno/cli

# Run every request in the current collection folder
bru run --env staging

Am besten für: Teams, die Sammlungen in Pull Requests überprüfen und offline ausführen möchten, wobei Assertions und Skripte in denselben Dateien behandelt werden. Es schreibt JSON-, JUnit- und HTML-Berichte für CI. Ehrliche Einschränkung: Das Erstellen im Klartext ist eher für Entwickler geeignet als für gemischte Teams, und das Ökosystem ist jünger als das von Postman. Sehen Sie, wie es sich im Vergleich zu Apidogs Runner in Bruno CLI vs. Apidog CLI schlägt.

6. Schemathesis: Ihr Schema schreibt die Tests

Schemathesis geht einen anderen Weg: Es liest Ihr OpenAPI- oder GraphQL-Schema und generiert daraus Tausende von Testfällen, indem es eigenschaftsbasiertes Testen auf Basis von Pythons Hypothesis verwendet. Anstatt jeden Fall selbst zu schreiben, lassen Sie es Eingaben fuzzen, um 500er-Fehler, Schemaverletzungen und Antworten zu finden, die den von Ihren Docs versprochenen Vertrag brechen.

pip install schemathesis

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

Am besten für: das Aufdecken von Edge-Case-Bugs, an die niemand gedacht hat, einen Test zu schreiben, insbesondere vor einer Veröffentlichung. Es ist eines der stärksten Argumente für die Pflege eines genauen Schemas. Ehrliche Einschränkung: Es benötigt ein echtes Schema als Grundlage, und eine große API kann Rauschen erzeugen, das Sie mit Hooks und Optionen filtern müssen.

7. Step CI: Eine YAML-Datei pro mehrstufigem Ablauf

Step CI beschreibt einen API-Workflow in einer einzigen YAML-Datei: Schritte, erfasste Werte und Prüfungen. Es deckt REST, GraphQL, gRPC, tRPC und SOAP in einem Workflow ab und validiert gegen ein OpenAPI-Schema. Dieselbe Datei läuft auf einem Laptop und in einer Pipeline.

npm install -g stepci

stepci run workflow.yml

Am besten für: Anmelde- und anschließende Token-Verwendungssequenzen, deklarativ beschrieben, ohne Skripting. Ehrliche Einschränkung: Es enthält eine Node-Laufzeitumgebung, und die Veröffentlichungsrate hat sich verlangsamt, daher sollten Sie die jüngsten Aktivitäten des Repositorys überprüfen, bevor Sie eine Pipeline darauf aufbauen.

8. curl: Die bereits installierte Referenz

curl wird mit macOS, den meisten Linux-Distributionen und aktuellen Windows-Versionen ausgeliefert, daher ist die leichteste Installation gar keine Installation. Es ist der Referenz-Client, an dem sich jedes andere Tool misst, und mit `-w` und Shell-Verbindungen kann es als minimaler Testharness dienen.

# POST JSON and print only the HTTP status
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}'

Am besten für: einmalige Anfragen, Skripte und gesperrte Umgebungen, in denen nichts Neues installiert werden kann. Ehrliche Einschränkung: Assertions sind komplett DIY (Do It Yourself). Sie leiten in `jq` weiter, vergleichen Werte selbst und verwalten Exit-Codes manuell. Es sendet und zeigt; es testet nicht. Der Leitfaden curl-Alternativen für REST API-Tests behandelt, was zu verwenden ist, wenn das nicht mehr ausreicht.

9. HTTPie und xh: Lesbare Anfragen von Hand

HTTPie machte Terminal-Anfragen lesbar: Der Befehl ist `http`, JSON-Felder sind `key=value`-Paare, und Antworten kommen farbig und formatiert zurück. xh implementiert dieselbe Syntax in Rust als einzelne statische Binärdatei neu, mit schnellerem Start und einem `--curl`-Flag, das den entsprechenden curl-Befehl ausgibt.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # same syntax, one binary

Am besten für: die manuelle Erkundung einer API, während Sie die eigentlichen Tests woanders erstellen. Ehrliche Einschränkung: Beide sind Clients, keine Runner. HTTPie bringt eine Python-Laufzeitumgebung mit; xh tauscht einen kleineren Funktionsumfang gegen Geschwindigkeit ein. Keiner von beiden prüft eine Antwort.

10. k6: Wenn es um Last geht

k6 beantwortet eine andere Frage: nicht „Ist diese Antwort korrekt?“, sondern „Hält sie dem Traffic stand?“ Es ist eine einzelne Go-Binärdatei von Grafana, in JavaScript geskriptet, mit Schwellenwerten, die einen Lasttest zu einem Bestanden/Nicht Bestanden-Gate machen. Wird ein Schwellenwert überschritten, beendet sich k6 mit einem Wert ungleich Null, was CI als Fehler interpretiert.

brew install k6

k6 run load.js   # vus, duration, and thresholds defined in the script

Am besten für: Performance-Prüfungen, die im selben Repository wie funktionale Tests leben und von einem Laptop oder einer Pipeline aus ausgeführt werden. Ehrliche Einschränkung: Es ist ein Lasttool unter AGPL-3.0, kein funktionaler Testclient, und aussagekräftige Szenarien erfordern das Erlernen seiner JavaScript-API.

Bevorzugen Sie etwas Interaktives?

Wenn Sie eine Postman-ähnliche Oberfläche wünschen, ohne die Shell zu verlassen, ist das eine separate Kategorie: TUI-Clients wie atac und posting zeichnen vollständige Anfrage-Editoren im Terminal. Sie erkunden APIs; sie steuern keine Pipelines. Die Zusammenstellung der besten Terminal- und TUI REST API Clients behandelt diese Seite ausführlich.

Vergleichstabelle

Wie wählt man aus

Beginnen Sie bei der Aufgabe, nicht beim Tool. Wenn Tests bereits in Postman existieren, führen Newman oder die Postman CLI sie morgen aus. Wenn Sie Tests als überprüfbaren Text in Ihrem Repository wünschen, sind Hurl und Bruno CLI die stärksten Optionen. Wenn Sie ein solides OpenAPI-Schema haben, fügen Sie Schemathesis hinzu und lassen Sie es die Bugs jagen, die Sie nicht vorhergesehen haben. Behalten Sie curl und xh für die manuelle Ebene und holen Sie k6 hinzu, sobald sich die Frage von Korrektheit zu Kapazität ändert.

Wählen Sie die Apidog CLI, wenn Sie Szenarien lieber in einem visuellen Editor erstellen und sie überall sonst ausführen möchten. Es ist die einzige Option hier, bei der dasselbe Projekt auch Ihr API-Design, Mock-Daten und Dokumentation umfasst, was in Apidog CLI: Der API-Client, der in Ihrem Terminal lebt erklärt wird. Für das breitere Testbild hinter diesen Auswahlmöglichkeiten zeigt der Leitfaden API-Teststrategien, wo jede Ebene passt.

Häufig gestellte Fragen (FAQ)

Kann ich APIs vollständig vom Terminal aus testen? Ja. Erstellen Sie Tests als Dateien (Hurl, Bruno, Step CI) oder in einem visuellen Editor (Apidog, Postman) und führen Sie sie dann headless mit dem entsprechenden CLI aus. Jeder Runner auf dieser Liste gibt einen Exit-Code zurück, was alles ist, was CI benötigt.

Was ist der Unterschied zwischen einem Terminal-API-Client und einem Test-Tool? Ein Client (curl, HTTPie, xh) sendet eine Anfrage und zeigt die Antwort. Ein Test-Tool (Apidog CLI, Hurl, Newman) prüft die Antwort und schlägt mit einem Exit-Code ungleich Null fehl. Clients erkunden; Test-Tools steuern.

Welche davon laufen in CI-Pipelines? Alle Runner: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run und k6 run beenden sich bei Fehler mit einem Wert ungleich Null. Ein funktionierendes Pipeline-Beispiel finden Sie unter Apidog CLI Tests in GitHub Actions ausführen.

Behandeln diese Tools Lasttests? k6 ist hier der Lasttest-Spezialist, mit Schwellenwerten als Bestanden/Nicht bestanden-Gates. Die anderen prüfen die Korrektheit, nicht die Kapazität, daher kombinieren viele Teams einen funktionalen Runner mit k6.

Benötige ich eine OpenAPI-Spezifikation, um diese Tools zu verwenden? Nur Schemathesis benötigt eine, da es Tests aus dem Schema generiert. Überall sonst hilft eine Spezifikation, anstatt zu blockieren: Apidog importiert OpenAPI 3.x, Swagger 2.0 und Postman-Sammlungen, und Step CI kann Antworten gegen ein Schema validieren.

Das Muster bei allen zehn Tools ist dasselbe: Die Erstellung wünscht Komfort, die Ausführung eine Shell. Wählen Sie, wo Sie Tests schreiben möchten, und stellen Sie dann sicher, dass der Runner Ihrer Pipeline einen Exit-Code übergibt. Wenn Sie beide Hälften von einer Plattform wünschen, laden Sie Apidog herunter, erstellen Sie ein Szenario im Editor und fügen Sie den Befehl apidog run in CI ein, um den Kreis zu schließen.