Jahrelang bedeutete das Ausführen von Postman-Sammlungen außerhalb der Desktop-App ein einziges Tool: Newman. Dann veröffentlichte Postman sein eigenes offizielles Befehlszeilen-Tool, die Postman CLI, und nun gibt es zwei Möglichkeiten, im Großen und Ganzen dasselbe zu tun. Beide führen Sammlungen ohne GUI aus, beide passen in CI/CD-Pipelines und beide führen dieselben Testskripte aus. Warum also zwei Tools, und welches gehört in Ihre Pipeline?
Die Kurzversion: Newman ist der quelloffene, kontounabhängige Runner, der seit den Anfängen der Community-Standard ist. Die Postman CLI ist das neuere, kontoabhängige Tool, das Läufe mit der Postman-Cloud verbindet und dort Ergebnisse meldet. Die richtige Wahl hängt davon ab, ob Sie Ergebnisse in der Postman-Plattform speichern möchten oder einen Runner bevorzugen, der nichts außer einer Sammlungsdatei benötigt. Dieser Artikel vergleicht sie ehrlich, damit Sie sich entscheiden können.
Was Newman ist
Newman ist Postmans ursprünglicher Befehlszeilen-Sammlungs-Runner. Er ist quelloffen, wird als npm-Paket vertrieben und ist völlig kostenlos. Er führt aus Postman exportierte Sammlungsdateien aus, führt jede Anfrage und jede pm.test-Assertion aus und meldet das Ergebnis über seinen Exit-Code.
Newmans prägendes Merkmal ist seine Unabhängigkeit. Es benötigt kein Postman-Konto, keinen API-Schlüssel oder eine Netzwerkverbindung zu Postman-Servern. Man übergibt ihm eine JSON-Sammlungsdatei und es läuft. Das macht es in abgeschotteten Umgebungen vorhersehbar und leicht zu verstehen.
npm install -g newman
newman run checkout-api.postman_collection.json \
--environment staging.postman_environment.json
Newman ist zudem leichtgewichtig und erweiterbar. Es wird mit CLI- und JUnit-Reportern geliefert, und die Community pflegt zusätzliche Reporter wie newman-reporter-htmlextra für eine umfangreiche HTML-Ausgabe. Da es sich um ein Node.js-Paket handelt, können Sie es auch programmgesteuert aus einem Skript aufrufen. Unser Leitfaden zum Unterschied zwischen Newman und Postman behandelt, wie es sich zur Desktop-App verhält.
Was die Postman CLI ist
Die Postman CLI ist das offizielle Befehlszeilen-Tool, das Postman entwickelt hat und jetzt empfiehlt. Es ist eine einzelne Binärdatei, die Sie mit einem Skript installieren, kein npm-Paket, und es ist über einen API-Schlüssel mit Ihrem Postman-Konto verknüpft.
# install (example for macOS/Linux)
curl -o- "https://dl-cli.pstmn.io/install/osx_64.sh" | sh
# authenticate, then run
postman login --with-api-key YOUR_API_KEY
postman collection run checkout-api
Der entscheidende Unterschied ist die Cloud-Verbindung. Wenn Sie eine Sammlung mit der Postman CLI ausführen, kann diese die Sammlung direkt über ihre ID aus Ihrem Postman-Workspace abrufen, und sie überträgt die Ausführungsergebnisse zurück an die Postman-Plattform, wo sie in der Workspace-Historie und in Dashboards erscheinen. Das große Verkaufsargument sind API-Governance- und Sicherheitsprüfungen: Die Postman CLI kann während einer Pipeline Linting für Ihre API-Definitionen ausführen und Schema- und Regelverletzungen als Teil des Builds aufzeigen.
Die Postman CLI ist also weniger ein reiner Sammlungs-Runner als vielmehr ein Pipeline-Agent für die Postman-Plattform. Wenn Ihr Team innerhalb der Postman-Cloud arbeitet und die Ausführungshistorie und Governance dort zentralisiert haben möchte, ist diese Integration der Grund, sich dafür zu entscheiden.
Direkter Vergleich
| Aspekt | Postman CLI | Newman |
|---|---|---|
| Quelle | Closed Source, offizielles Postman-Tool | Open Source |
| Installation | Installationsskript, einzelne Binärdatei | npm-Paket |
| Postman-Konto | Erforderlich (API-Schlüssel-Login) | Nicht erforderlich |
| Sammlungsquelle | Zieht aus der Postman-Cloud per ID oder lokaler Datei | Lokale JSON-Datei |
| Ausführungsergebnisse | Werden an die Postman-Plattform zurückgemeldet | Terminalausgabe und Reporter-Dateien |
| API-Governance/Linting | Integriert | Nicht enthalten |
| Reporter | Begrenzt, Ergebnisse leben in Postman | CLI, JUnit, plus HTML-Reporter der Community |
| Offline-Nutzung | Begrenzt, auf die Cloud ausgelegt | Vollständig offline, sobald die Datei lokal ist |
| Reifegrad | Neuer | Langjähriger Community-Standard |
| Kosten | Kostenlos, aber an die Grenzen eines Postman-Plans gebunden | Kostenlos, kein Konto |
Die entscheidende Achse ist die Postman-Cloud. Die Postman CLI ist darauf ausgelegt, Ergebnisse und Governance in die Postman-Plattform einzuspeisen. Newman ist darauf ausgelegt, eine Datei lokal auszuführen und zu melden, ohne Abhängigkeit von Postman-Servern.
Wie sie in CI/CD passen
Beide Tools funktionieren mit jedem CI-Anbieter, einschließlich Jenkins, GitHub Actions, GitLab CI und CircleCI. Die Mechanismen unterscheiden sich.
Mit Newman committen Sie die Sammlungs- und Umgebungs-JSON-Dateien in Ihr Repository, installieren Newman im Job, führen es aus und lassen den Build bei einem Testfehler durch einen Exit-Code ungleich Null fehlschlagen. Alles ist im Repo und in der Pipeline eigenständig enthalten. Unsere Leitfäden zur Automatisierung von API-Tests in CI/CD und zur API-Testautomatisierung mit GitHub Actions zeigen dieses Muster.
Mit der Postman CLI speichern Sie einen Postman API-Schlüssel als Geheimnis beim CI-Anbieter, authentifizieren sich und führen die Sammlung über ihre ID aus. Die Sammlung wird aus der Postman-Cloud und nicht aus dem Repository gezogen, und die Ergebnisse werden zurück in den Workspace übertragen. Dies hält die „Source of Truth“ in Postman, was einige Teams bevorzugen und andere als einschränkend empfinden.
Ein praktischer Unterschied: Newman hält Tests mit Ihrem Code versioniert, da die Sammlungs-JSON im Repo liegt. Die Postman CLI hält Tests in Postmans Plattform versioniert, da sie per ID zieht. Entscheiden Sie, welche „Source of Truth“ Ihr Team bevorzugt, bevor Sie wählen.
Der Governance-Aspekt
Das einzige Merkmal, das die beiden Tools am deutlichsten trennt, ist die API-Governance. Die Postman CLI kann eine Überprüfung im Stil von postman api lint für eine in Ihrem Postman-Workspace gespeicherte API-Definition durchführen und diese anhand von Regeln für Benennung, Sicherheit, Schemavollständigkeit und Konsistenz bewerten. Wenn diese Überprüfung innerhalb einer Pipeline läuft, führt eine Definition, die eine Regel verletzt, zum Fehlschlagen des Builds, bevor die Änderung überhaupt zusammengeführt wird.
Newman hat kein Äquivalent. Es führt Sammlungen aus und meldet Testergebnisse, und das ist die Grenze seiner Aufgabe. Wenn Ihre Organisation Wert auf die automatische Durchsetzung von API-Designstandards legt, existiert diese Fähigkeit nur in der Postman CLI, und das ist ein echter Grund, sich dafür zu entscheiden. Wenn Sie keine Designregeln in der Pipeline durchsetzen, ist die Funktion irrelevant, und Newmans Einfachheit siegt.
Es ist wichtig, hier ehrlich zu sein, denn es verändert den Vergleich. Die Postman CLI ist nicht einfach „Newman, aber neuer“. Es ist eine andere Art von Tool: ein Pipeline-Agent für die Postman-Plattform, der zufällig einen Sammlungs-Runner enthält. Newman ist und bleibt lediglich ein Sammlungs-Runner. Sobald man es so sieht, geht es bei der Wahl weniger um Funktionen als vielmehr darum, ob man seine Tests überhaupt an die Postman-Plattform binden möchte.
Überlegungen zur Migration
Teams, die bereits Newman verwenden, fragen sich manchmal, ob sie zur Postman CLI wechseln sollten. Es gibt selten einen triftigen Grund dafür. Newman wird weiterhin gepflegt, ist immer noch kostenlos und funktioniert weiterhin bei jedem CI-Anbieter. Ein Wechsel bedeutet das Hinzufügen eines API-Schlüssels als CI-Geheimnis, eine Änderung der Art und Weise, wie Sammlungen bezogen werden, und die Akzeptanz einer Abhängigkeit von der Postman-Cloud. Sofern Sie nicht explizit eine zentralisierte Ausführungshistorie oder Governance-Prüfungen wünschen, kosten die Migration mehr, als sie einbringt.
Teams, die neu starten, stehen vor der interessanteren Wahl. Wenn das Team Postman als primäres Tool nutzt und für einen Plan bezahlt, hält die Postman CLI alles in einem Ökosystem zusammen und ist die natürliche Wahl. Wenn das Team Flexibilität, im Repo versionierte Tests und Unabhängigkeit von der Cloud eines einzelnen Anbieters wünscht, ist Newman oder ein völlig anderes Tool, das nicht von Postman stammt, sinnvoller. Es gibt keine universell richtige Antwort; es gibt nur die Antwort, die dazu passt, wie Ihr Team bereits arbeitet.
Welches sollten Sie wählen
Wählen Sie Newman, wenn Sie einen Runner ohne Kontoabhängigkeit wünschen, wenn Sie Tests in Ihrem Repository versionieren möchten, wenn Sie eine umfangreiche HTML-Berichterstattung durch Community-Reporter benötigen oder wenn Sie in eingeschränkten Umgebungen arbeiten, in denen der Aufruf der Postman-Cloud nicht erlaubt ist. Newmans Unabhängigkeit und Reife machen es zur sicheren Standardoption für die meisten Pipelines.
Wählen Sie die Postman CLI, wenn Ihr Team innerhalb der Postman-Plattform arbeitet, wenn Sie die Ausführungshistorie und Dashboards dort zentralisieren möchten oder wenn API-Governance und Definitions-Linting in der Pipeline für Sie wertvoll sind. Ihre enge Cloud-Integration ist ein echter Vorteil für Postman-zentrierte Teams.
Wenn Sie diese Entscheidung abwägen, lohnt es sich zu fragen, ob Sie überhaupt an das Postman-Ökosystem gebunden sein möchten. Für andere Ansätze siehe unseren Leitfaden zum Ausführen von Postman-Sammlungen in CI ohne Newman und unseren umfassenderen Blick auf das API-Testen ohne Postman.
Eine Single-Tool-Alternative: Apidog
Sowohl Postman CLI als auch Newman setzen voraus, dass Sie Ihre Tests in Postman erstellt haben. Apidog beseitigt diese Trennung. Sie entwerfen APIs, debuggen Anfragen und erstellen automatisierte Testszenarien mit visuellen Assertions in einer Anwendung und führen diese Szenarien dann in CI/CD mit dem integrierten Befehlszeilen-Runner aus. Es gibt keinen Export-Schritt und kein separates Runner-Paket, da die Testdefinitionen und die Ausführungs-Engine dasselbe Produkt sind.
Apidog integriert auch API-Design, Mock-Server und Performance-Tests, sodass ein Team den gesamten API-Lebenszyklus abdecken kann, ohne Tools miteinander zu verbinden. Sie können Apidog herunterladen und dessen Testfunktionen kostenlos nutzen, einschließlich des CLI-Runners für Pipelines.
Häufig gestellte Fragen
Ersetzt die Postman CLI Newman?
Postman positioniert die Postman CLI als sein offiziell empfohlenes Befehlszeilen-Tool, aber Newman wird weiterhin gepflegt und широко genutzt. Newman bleibt die bessere Wahl, wenn Sie einen kontounabhängigen, im Repo versionierten Runner wünschen. Beide werden wahrscheinlich noch einige Zeit koexistieren, sodass kein dringender Migrationsbedarf besteht.
Benötigt die Postman CLI ein Postman-Konto?
Ja. Die Postman CLI authentifiziert sich mit einem Postman API-Schlüssel und ist darauf ausgelegt, Ausführungen mit Ihrem Postman-Workspace zu verbinden. Newman hingegen benötigt kein Konto und läuft rein von einer lokalen Sammlungsdatei aus.
Welches Tool liefert bessere Berichte?
Newman bietet eine flexiblere Berichterstattung durch Community-Reporter, insbesondere newman-reporter-htmlextra für detaillierte HTML-Ausgaben und JUnit XML für CI-Dashboards. Die Postman CLI meldet Ergebnisse direkt an die Postman-Plattform, was praktisch ist, wenn Ihr Team dort arbeitet, aber weniger flexibel für eigenständige Berichtsdateien.
Kann die Postman CLI eine lokale Sammlungsdatei ausführen?
Die Postman CLI kann Sammlungen aus lokalen Dateien ausführen, ist aber darauf ausgelegt, Sammlungen über ihre ID aus der Postman-Cloud zu ziehen und Ergebnisse zurückzumelden. Wenn Sie ein Tool wünschen, das eine lokale JSON-Datei als „Source of Truth“ ohne Cloud-Beteiligung behandelt, passt Newman besser zu diesem Modell.
Welches ist in CI schneller?
Für die reine Sammlungs-Ausführung ist der Unterschied gering und hängt von der Sammlungsgröße und den Netzwerkbedingungen ab. Newman hat einen kleineren Fußabdruck und keine Cloud-Roundtrips. Die Postman CLI fügt den Overhead der Authentifizierung und Synchronisierung von Ergebnissen mit der Plattform hinzu. Wählen Sie für die meisten Pipelines basierend auf der Workflow-Eignung und nicht auf der reinen Geschwindigkeit.