DEV Community

Cover image for Top CLI-basierte API-Testing-Tools 2026
Emre Demir
Emre Demir

Posted on Originally published at apidog.com

Top CLI-basierte API-Testing-Tools 2026

API-Tests finden nicht mehr nur in GUIs statt. Sie laufen in CI-Containern ohne Bildschirm, auf Staging-Systemen, die nur per SSH erreichbar sind, und unter KI-Agenten, die ausschließlich Shell-Befehle ausführen. In allen drei Fällen entscheidet das Terminal per Exit-Code, ob ein Test bestanden hat oder nicht.

Apidog noch heute ausprobieren

Diese Übersicht konzentriert sich auf Tools, die API-Tests vollständig in der Shell ausführen: installieren, Befehl starten, Exit-Code auswerten und Reports als Artefakte speichern. Bewertet werden integrierte Assertions, mehrstufige Abläufe, CI-geeignete Berichte und Wartungsstatus. Manuelle Clients wie curl bleiben relevant, weil sie zwischen automatisierten Testläufen für schnelle Diagnosen nützlich sind.

Eine breitere Übersicht mit GUI- und gehosteten Optionen finden Sie in der Zusammenstellung der besten kostenlosen API-Test-Tools.

Was ein Test-Tool von einem Client unterscheidet

Ein Terminal-Client sendet eine Anfrage und zeigt die Antwort. Ein Terminal-Test-Tool bewertet diese Antwort und liefert einen Exit-Code zurück, den Ihre Pipeline als Gate verwenden kann.

Achten Sie bei einem Tool für CI auf diese vier Punkte:

  • Integrierte Assertions: Status, Header und Body werden direkt geprüft, statt Shell-Klebstoff mit jq, grep und eigener Fehlerbehandlung zu bauen.
  • Aussagekräftige Exit-Codes: 0 bei Erfolg, ein Wert ungleich 0 bei Fehlern.
  • Wiederholbarkeit: Tests liegen in versionierbaren Dateien oder Projekten, nicht im Shell-Verlauf.
  • Berichte: Menschen brauchen lesbare CLI-Ausgabe; CI-Systeme brauchen JSON, JUnit oder HTML.

Die folgenden zehn Tools decken unterschiedliche Arbeitsweisen ab: visuelle Szenarien, textbasierte Tests, bestehende Postman-Sammlungen, Schema-Fuzzing und Lasttests.

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

Apidog ist eine API-Plattform für Design, Testing, Mocking und Dokumentation. Die Apidog CLI (apidog-cli auf npm) führt Szenarien aus dem Apidog-Projekt im Terminal aus.

Der typische Ablauf:

  1. Erstellen Sie ein mehrstufiges Szenario im visuellen Editor.
  2. Verketten Sie Anfragen, extrahieren Sie Variablen und definieren Sie Assertions.
  3. Kopieren Sie den generierten CI/CD-Befehl.
  4. Führen Sie das Szenario lokal oder in CI mit apidog run aus.

Apidog CLI-Ausführung

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

# Den exakten Befehl im CI/CD-Tab des Szenarios kopieren
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Sie müssen IDs nicht manuell zusammensuchen: Öffnen Sie das Szenario in Apidog, wechseln Sie zum Tab CI/CD und kopieren Sie den generierten Befehl.

Für automatisierte Pipelines wählen Sie einen passenden Reporter:

# Lesbare Ausgabe im Terminal
apidog run -t <scenario_id> -e <env_id> -r cli

# Report als CI-Artefakt erzeugen
apidog run -t <scenario_id> -e <env_id> -r junit
Enter fullscreen mode Exit fullscreen mode

Unterstützt werden cli, html, json und junit; die Reports werden in apidog-reports/ geschrieben. Datengesteuerte Tests können Iterationen aus CSV- oder JSON-Dateien laden. Die Ausgabe ist strukturiertes JSON mit agentHints.nextSteps, sodass KI-Code-Agenten einen Lauf auswerten können, ohne Terminalausgaben per Screen-Scraping zu analysieren. Voraussetzung ist Node.js 16 oder neuer.

Am besten für: Teams, die komplexe Szenarien visuell erstellen und sie identisch auf Laptop, in CI und durch Agenten ausführen möchten.

Einschränkung: Apidog ist nicht Open Source und kein Ad-hoc-HTTP-Sender. Szenarien leben in einem Apidog-Projekt, daher ist es eine integrierte Plattform und nicht nur ein einzelnes HTTP-Tool.

Der vollständige Leitfaden zur Apidog CLI beschreibt den gesamten Befehlssatz.

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

Hurl führt HTTP-Anfragen aus Klartextdateien aus und prüft die Antworten. Es basiert auf Rust und libcurl und wird als einzelne Binärdatei ausgeliefert. Dadurch benötigen Sie keine separate Laufzeitumgebung.

Ein minimaler Login-Test:

brew install hurl
# Alternative:
# 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
Enter fullscreen mode Exit fullscreen mode

hurl --test beendet sich mit einem Wert ungleich 0, wenn eine Assertion fehlschlägt. Damit können Sie Hurl direkt als CI-Gate einsetzen:

hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

Am besten für: Vertragsprüfungen und Smoke-Tests, die als gut lesbarer Text im Repository liegen sollen.

Einschränkung: Hurl ist HTTP-fokussiert. Es ist kein gRPC-Runner und kein Lasttest-Tool. Komplexe Logik verteilt sich eher auf mehrere .hurl-Dateien als auf eine vollständige Skriptsprache.

3. Newman: Postman-Sammlungen headless ausführen

Newman ist der Open-Source-CLI-Runner für Postman-Sammlungen unter Apache-2.0. Wenn Ihr Team Anfragen und Tests bereits in Postman gepflegt hat, können Sie dieselben Sammlungen ohne GUI ausführen.

Exportieren Sie Sammlung und Umgebung als JSON:

npm install -g newman

newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Für CI sollten Sie zusätzlich einen maschinenlesbaren Report erzeugen:

newman run collection.json \
  -e staging.json \
  -r cli,junit \
  --reporter-junit-export reports/newman.xml
Enter fullscreen mode Exit fullscreen mode

Newman beendet sich mit einem Fehlercode, wenn Tests fehlschlagen.

Am besten für: Teams mit bestehenden Postman-Sammlungen, die diese ohne zusätzliche Lizenzen in Pipelines ausführen möchten.

Einschränkung: Newman führt nur Sammlungen im Postman-Format aus. Das Erstellen der Tests erfolgt weiterhin in der Postman-GUI; Newman ist ein Runner, kein Editor.

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

Die Postman CLI ist Postmans eigener Closed-Source-Runner. Anders als Newman meldet sie sich beim Postman-Konto an, führt Sammlungen direkt per ID aus dem Workspace aus und meldet Ergebnisse an die Postman-Cloud zurück.

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

postman collection run <collection_id> -e <environment_id>
Enter fullscreen mode Exit fullscreen mode

Praktisch ist dieser Ansatz, wenn die Sammlung bereits zentral im Postman-Workspace liegt und Sie keine JSON-Exporte verwalten möchten.

Am besten für: Postman-Teams, die cloudverknüpfte Läufe direkt aus ihrem Workspace benötigen.

Einschränkung: Die CLI ist Closed Source und an ein Postman-Konto gebunden. Die parallele Existenz von Newman und Postman CLI kann bei der Toolwahl verwirrend sein.

Der Vergleich Postman CLI vs. Newman hilft bei der Entscheidung.

5. Bruno CLI: Git-native Sammlungen mit bru

Bruno speichert Sammlungen als Klartext-.bru-Dateien in regulären Ordnern. Anfragen, Assertions und Skripte können damit wie Anwendungscode im Repository liegen und in Pull Requests geprüft werden.

npm install -g @usebruno/cli

# Alle Requests der aktuellen Sammlung mit der Umgebung "staging" ausführen
bru run --env staging
Enter fullscreen mode Exit fullscreen mode

Für CI können Sie Reports erzeugen und als Build-Artefakte speichern:

bru run --env staging --reporter-junit reports/bruno.xml
Enter fullscreen mode Exit fullscreen mode

Bruno unterstützt JSON-, JUnit- und HTML-Reports.

Am besten für: Teams, die API-Sammlungen offline, Git-nativ und reviewbar verwalten möchten.

Einschränkung: Klartextdateien sind besonders entwicklerfreundlich, können für gemischte Teams aber weniger zugänglich sein als ein visueller Editor. Das Ökosystem ist zudem jünger als das von Postman.

Siehe auch: Bruno CLI vs. Apidog CLI.

6. Schemathesis: Ihr Schema schreibt die Tests

Schemathesis liest ein OpenAPI- oder GraphQL-Schema und generiert daraus Testfälle. Das Tool verwendet eigenschaftsbasiertes Testen auf Basis von Python Hypothesis, um ungültige oder ungewöhnliche Eingaben zu erzeugen.

Damit finden Sie beispielsweise:

  • unerwartete 500er-Fehler,
  • Antworten, die nicht dem Schema entsprechen,
  • Edge Cases, für die niemand manuell einen Test geschrieben hat. 
pip install schemathesis

schemathesis run https://api.example.com/openapi.json
Enter fullscreen mode Exit fullscreen mode

Setzen Sie es vor Releases oder in einer separaten Pipeline-Stufe ein, damit Schema-Verletzungen früh sichtbar werden.

Am besten für: APIs mit gepflegtem OpenAPI- oder GraphQL-Schema, bei denen Sie automatisiert Edge Cases und Vertragsverletzungen suchen möchten.

Einschränkung: Ein korrektes Schema ist Voraussetzung. Bei großen APIs kann Fuzzing viele Ergebnisse erzeugen, die Sie mit Hooks und Optionen eingrenzen müssen.

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

Step CI beschreibt API-Workflows in einer YAML-Datei. Ein Workflow kann Schritte, extrahierte Werte und Prüfungen enthalten. Unterstützt werden REST, GraphQL, gRPC, tRPC und SOAP; außerdem kann Step CI gegen ein OpenAPI-Schema validieren.

npm install -g stepci

stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

Ein sinnvoller Anwendungsfall ist ein Login-Ablauf:

  1. Login-Request senden.
  2. Token aus der Antwort speichern.
  3. Token in einem nachfolgenden Request verwenden.
  4. Status und Response-Body prüfen.

Am besten für: Deklarative, mehrstufige Abläufe wie Login-, Token- und Freigabeprozesse ohne umfangreiches Skripting.

Einschränkung: Step CI benötigt Node.js. Prüfen Sie vor dem produktiven Einsatz außerdem die aktuelle Repository-Aktivität, da sich die Veröffentlichungsrate verlangsamt hat.

8. curl: Die bereits installierte Referenz

curl ist auf macOS, den meisten Linux-Distributionen und aktuellen Windows-Versionen verfügbar. Es ist der Referenz-HTTP-Client für schnelle Diagnosen, Skripte und eingeschränkte Umgebungen.

So senden Sie JSON und geben nur den HTTP-Status aus:

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}'
Enter fullscreen mode Exit fullscreen mode

Für ein minimales CI-Gate müssen Sie den Status selbst prüfen:

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

test "$status" = "200"
Enter fullscreen mode Exit fullscreen mode

Am besten für: Einmalige Requests, Shell-Skripte und Systeme, auf denen keine zusätzliche Installation möglich ist.

Einschränkung: Assertions sind komplett DIY. Sie kombinieren curl mit jq, vergleichen Werte selbst und verwalten Fehlercodes manuell. curl sendet Anfragen; es ist kein vollständiger Test-Runner.

Der Leitfaden curl-Alternativen für REST API-Tests zeigt, wann ein dediziertes Test-Tool sinnvoller wird.

9. HTTPie und xh: Lesbare Anfragen von Hand

HTTPie macht manuelle Terminal-Anfragen lesbarer: Der Befehl heißt http, JSON-Felder werden als key=value geschrieben und Antworten formatiert angezeigt.

xh implementiert eine ähnliche Syntax in Rust als einzelne statische Binärdatei. Es startet schnell und kann mit --curl den äquivalenten curl-Befehl ausgeben.

http POST api.example.com/users name=acme plan=pro
xh   POST api.example.com/users name=acme plan=pro
Enter fullscreen mode Exit fullscreen mode

Am besten für: Manuelle API-Erkundung und Debugging, während die eigentlichen Tests in Hurl, Bruno, Postman oder einem anderen Runner liegen.

Einschränkung: HTTPie und xh sind Clients, keine Test-Runner. HTTPie benötigt eine Python-Laufzeitumgebung; xh priorisiert einen kleineren Umfang und schnellen Start. Keines der Tools prüft Antworten mit integrierten Assertions.

10. k6: Wenn es um Last geht

k6 beantwortet eine andere Frage als funktionale Test-Tools: nicht „Ist die Antwort korrekt?“, sondern „Hält der Service unter Traffic stand?“

k6 ist eine Go-Binärdatei von Grafana. Lastszenarien werden in JavaScript beschrieben. Schwellenwerte machen einen Lasttest zu einem Bestanden/Nicht-bestanden-Gate: Wird ein Schwellenwert überschritten, beendet sich k6 mit einem Fehlercode.

brew install k6

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

Definieren Sie virtuelle Nutzer, Dauer und Schwellenwerte direkt im Skript:

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, {
    "Status ist 200": (res) => res.status === 200,
  });
}
Enter fullscreen mode Exit fullscreen mode

Am besten für: Performance-Prüfungen, die im selben Repository wie funktionale Tests liegen und lokal oder in CI laufen sollen.

Einschränkung: k6 ist ein Lasttest-Tool unter AGPL-3.0, kein Ersatz für einen funktionalen API-Test-Runner. Aussagekräftige Szenarien erfordern die Einarbeitung in die JavaScript-API.

Bevorzugen Sie etwas Interaktives?

Wenn Sie eine Postman-ähnliche Oberfläche möchten, ohne die Shell zu verlassen, ist das eine andere Kategorie: TUI-Clients wie atac und posting bieten vollständige Request-Editoren im Terminal.

Sie eignen sich zur API-Erkundung, steuern aber keine Pipelines. Die Übersicht der besten Terminal- und TUI REST API Clients behandelt diese Tools ausführlich.

Vergleichstabelle

Tool Aufgabe Integrierte Assertions Installation Open Source
Apidog CLI Visuell erstellte Szenarien in CI ausführen Ja npm i -g apidog-cli Nein (kostenlose Stufe)
Hurl Klartext-HTTP-Tests Ja brew install hurl Apache-2.0
Newman Postman-Sammlungen headless Ja npm i -g newman Apache-2.0
Postman CLI Cloud-verknüpfte Postman-Läufe Ja Postman-Installer Nein
Bruno CLI Git-native .bru-Sammlungen Ja npm i -g @usebruno/cli MIT
Schemathesis Fuzzing von einem Schema Generiert pip install schemathesis MIT
Step CI Mehrstufige YAML-Abläufe Ja npm i -g stepci MPL-2.0
curl Rohe Anfragen, Skripting DIY vorinstalliert Ja
HTTPie / xh Lesbare manuelle Anfragen Nein brew install httpie / xh Ja
k6 Last mit Bestanden/Nicht-bestanden-Schwellenwerten Schwellenwerte brew install k6 AGPL-3.0

Wie wählt man aus?

Beginnen Sie mit der Aufgabe, nicht mit dem Tool:

  • Postman-Sammlungen existieren bereits: Nutzen Sie Newman oder die Postman CLI.
  • Tests sollen als überprüfbarer Text im Repository liegen: Wählen Sie Hurl oder Bruno CLI.
  • Ein belastbares OpenAPI-Schema ist vorhanden: Ergänzen Sie Schemathesis für generierte Edge Cases.
  • Mehrstufige Abläufe sollen deklarativ in YAML stehen: Verwenden Sie Step CI.
  • Schnelle manuelle Requests oder eingeschränkte Systeme: Behalten Sie curl, HTTPie oder xh.
  • Kapazität und Latenz prüfen: Ergänzen Sie funktionale Tests um k6.

Wählen Sie die Apidog CLI, wenn Sie Szenarien lieber visuell erstellen und anschließend überall headless ausführen möchten. Dasselbe Projekt kann außerdem API-Design, Mock-Daten und Dokumentation enthalten. Details dazu finden Sie in Apidog CLI: Der API-Client, der in Ihrem Terminal lebt.

Für die übergeordnete Einordnung zeigt der Leitfaden zu API-Teststrategien, wo funktionale Tests, Vertragsprüfungen und Lasttests in Ihre Testpyramide passen.

Häufig gestellte Fragen

Kann ich APIs vollständig vom Terminal aus testen?

Ja. Schreiben Sie Tests als Dateien, etwa mit Hurl, Bruno oder Step CI, oder erstellen Sie sie in einem visuellen Editor wie Apidog oder Postman. Führen Sie sie dann mit dem jeweiligen CLI headless aus. Entscheidend für CI ist der Exit-Code des Runners.

Was ist der Unterschied zwischen einem Terminal-API-Client und einem Test-Tool?

Ein Client wie curl, HTTPie oder xh sendet eine Anfrage und zeigt die Antwort. Ein Test-Tool wie Apidog CLI, Hurl oder Newman prüft die Antwort anhand definierter Assertions und beendet sich bei Fehlern mit einem Exit-Code ungleich 0.

Clients erkunden APIs. Test-Tools steuern Pipelines.

Welche Tools laufen in CI-Pipelines?

Alle Runner in dieser Liste können als CI-Schritt verwendet werden:

apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run
Enter fullscreen mode Exit fullscreen mode

Bei fehlgeschlagenen Prüfungen liefern sie einen Fehlercode zurück. Ein konkretes Beispiel finden Sie unter Apidog CLI Tests in GitHub Actions ausführen.

Behandeln diese Tools Lasttests?

k6 ist in dieser Liste der Spezialist für Lasttests. Es verwendet Schwellenwerte als Bestanden/Nicht-bestanden-Gates. Die anderen Tools prüfen primär funktionale Korrektheit und API-Verträge, nicht Kapazität.

Viele Teams kombinieren daher einen funktionalen Runner mit k6.

Benötige ich eine OpenAPI-Spezifikation?

Nur Schemathesis benötigt ein Schema, weil es daraus Testfälle generiert. Bei den anderen Tools ist eine Spezifikation hilfreich, aber keine Voraussetzung.

Apidog kann OpenAPI 3.x, Swagger 2.0 und Postman-Sammlungen importieren. Step CI kann Antworten gegen ein Schema validieren.

Das Muster ist bei allen zehn Tools gleich: Die Erstellung braucht Komfort, die Ausführung braucht eine Shell. Entscheiden Sie zuerst, wo Ihre Tests leben sollen, und stellen Sie dann sicher, dass der Runner einen eindeutigen Exit-Code an Ihre Pipeline übergibt.

Wenn Sie Erstellung und Ausführung auf einer Plattform verbinden möchten, laden Sie Apidog herunter, erstellen Sie ein Szenario im Editor und fügen Sie apidog run in Ihre CI-Pipeline ein.

Top comments (0)