Newman vs. Postman: Was ist der Unterschied?

Newman und Postman sind keine Konkurrenten. Sie sind zwei Hälften eines Workflows. Postman ist die Desktop-Anwendung, in der Sie Anfragen entwerfen, Tests schreiben und APIs manuell erkunden. Newman ist das Befehlszeilentool, das die in Postman erstellten Collections ohne grafische Benutzeroberfläche ausführt. Wenn Postman die Werkstatt ist, dann ist Newman die Maschine, die Ihre fertige Arbeit nach einem Zeitplan ausführt.

Die Verwirrung entsteht meist aus der Frage: „Welches davon soll ich verwenden?“ Die ehrliche Antwort ist: beide, aber in verschiedenen Phasen. Sie erstellen in Postman, weil eine grafische Benutzeroberfläche dies beschleunigt. Sie führen in Newman aus, weil eine Pipeline keine Schaltflächen klicken kann. Dieser Artikel erklärt die genaue Beziehung, zeigt, wo jedes Tool hingehört, und führt Sie durch die Integration von Newman in eine CI/CD-Pipeline.

Was Postman ist

Postman ist eine grafische API-Plattform. Sie installieren sie als Desktop-App, erstellen Anfragen, organisieren diese in Collections und Ordnern und fügen Umgebungen hinzu, die Variablen wie Basis-URLs und Tokens enthalten. Nach jeder Antwort führt Postman JavaScript-Testskripte aus, die Sie auf der Registerkarte „Tests“ der Anfrage schreiben.

Ein Postman-Testskript überprüft die Antwort:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Order total is a positive number", function () {
    const body = pm.response.json();
    pm.expect(body.total).to.be.a("number");
    pm.expect(body.total).to.be.above(0);
});

Postman ist für interaktives Arbeiten konzipiert. Ein Entwickler, der einen neuen Endpunkt debuggt, sendet Anfragen, inspiziert Antworten, passt Header an und iteriert in Sekundenschnelle. Ein QA-Ingenieur wandelt diese Anfragen in eine gespeicherte Regressionstest-Suite um. Teams teilen Arbeitsbereiche, sodass alle mit derselben Collection arbeiten. All das profitiert von einer visuellen Oberfläche. Unser Leitfaden zum Testen von APIs mit Postman behandelt diesen Workflow ausführlich.

Wofür Postman nicht gebaut wurde, ist die unbeaufsichtigte Ausführung. Das Ausführen einer Suite bedeutet, die App zu öffnen und auf den Collection Runner zu klicken. Das ist für eine Person am Schreibtisch in Ordnung. Für einen Build-Server ist es nutzlos.

Was Newman ist

Newman ist Postmans offizieller Befehlszeilen-Collection-Runner. Es ist ein Open-Source-npm-Paket, kostenlos nutzbar, das genau dieselben Collection-Dateien ausführt, die Postman erzeugt. Sie exportieren eine Collection als JSON-Datei, übergeben sie an Newman, und Newman führt jede Anfrage und jedes Testskript aus und meldet dann die Ergebnisse an Ihr Terminal.

Installieren Sie es mit npm:

npm install -g newman

Führen Sie eine Collection aus:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

Newman führt jede Anfrage aus, führt dieselben pm.test-Assertions aus, die Postman verwenden würde, und druckt eine Zusammenfassung aus. Das entscheidende Detail ist, dass Newman dieselbe Ausführungsengine wie Postman verwendet, sodass eine Collection, die in der GUI besteht, sich in der Befehlszeile identisch verhält. Es gibt kein Umschreiben und keine separate Testsprache.

Newman beendet sich auch mit einem Nicht-Null-Statuscode, wenn ein Test fehlschlägt. Dieses einzige Verhalten macht es für die Automatisierung wertvoll: Ein Build-System liest diesen Exit-Code und schlägt den Build bei einer fehlerhaften Assertion fehl. Ein erfolgreicher Durchlauf beendet sich mit Null und die Pipeline läuft weiter.

Gegenüberstellung

Die Collection-JSON-Datei ist die Brücke zwischen den beiden. Sie erstellen sie einmal in Postman, und Newman führt sie für immer in der Automatisierung aus.

Wie Newman in CI/CD passt

Newman dient hauptsächlich dazu, API-Tests in die kontinuierliche Integration zu integrieren. Das Muster ist über alle Anbieter hinweg konsistent. Sie committen die exportierten Collection- und Umgebungsdateien in Ihr Repository, installieren Newman in der Pipeline, führen es aus und lassen den Exit-Code den Build steuern.

Hier ist der Workflow in nummerierten Schritten:

1. Exportieren aus Postman. Exportieren Sie in Postman Ihre Collection und deren Umgebung als JSON-Dateien.
2. Committen Sie sie in das Repo. Speichern Sie sie zusammen mit Ihrem Code, sodass sie mit der API versioniert werden.
3. Installieren Sie Newman in der Pipeline. Fügen Sie npm install -g newman zum CI-Job hinzu oder verwenden Sie das Docker-Image postman/newman.
4. Führen Sie die Collection aus. Rufen Sie newman run mit den Collection- und Umgebungsdateien auf.
5. Kontrollieren Sie den Exit-Code. Wenn ein Test fehlschlägt, beendet sich Newman mit einem Nicht-Null-Wert, und der CI-Anbieter markiert den Build als fehlgeschlagen.

Ein GitHub Actions-Schritt sieht so aus:

- name: Run API tests
  run: |
    npm install -g newman
    newman run orders-api.postman_collection.json \
      --environment staging.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export results.xml

Der Flag --reporters ist wissenswert. Newman wird mit integrierten Reportern für CLI und JUnit XML geliefert, und Community-Reporter fügen HTML-Ausgabe und mehr hinzu. JUnit XML ermöglicht es CI-Dashboards insbesondere, Testergebnisse nativ anzuzeigen. Für eine vollständige Anleitung siehe unseren Leitfaden zum Automatisieren von API-Tests in CI/CD und die Besonderheiten der API-Testautomatisierung mit GitHub Actions.

Nützliche Newman-Befehlszeilenoptionen

Newman verfügt über eine Reihe von Flags, die die Schwierigkeiten automatisierter Läufe bewältigen. Das Wissen um einige davon macht den Unterschied zwischen einem fragilen und einem zuverlässigen Job aus.

Der Flag --iteration-data weist Newman auf eine CSV- oder JSON-Datei hin und führt die gesamte Collection einmal pro Zeile aus, wobei die Werte der Zeile als Variablen eingesetzt werden. So steuern Sie einen Newman-Lauf datengesteuert: eine Collection, viele Eingaben. Der Flag --iteration-count wiederholt die Collection einfach eine feste Anzahl von Malen.

Der Flag --bail weist Newman an, beim ersten Fehler anzuhalten, anstatt den Rest der Collection auszuführen. In einer Fast-Feedback-Pipeline ist dies oft das, was Sie wollen, da eine einzige fehlerhafte Anfrage normalerweise bedeutet, dass der Build ohnehin fehlschlagen wird. Der Flag --timeout-request begrenzt, wie lange eine einzelne Anfrage dauern darf, was den Job davor schützt, bei einem nicht reagierenden Dienst hängen zu bleiben.

Der Flag --delay-request fügt eine Pause zwischen den Anfragen ein, nützlich, wenn eine API Ratenbegrenzungen erzwingt. Und --folder ermöglicht es Ihnen, nur einen benannten Ordner innerhalb einer Collection auszuführen, sodass ein Smoke-Test-Job eine kleine Untermenge ausführen kann, während der vollständige Regressionstest-Job alles ausführt. Keine dieser Optionen existiert im Collection Runner der Postman-GUI in derselben skriptfähigen Form, und zusammen sind sie der Grund, warum Newman die praktische Wahl für die unbeaufsichtigte Ausführung ist.

Häufige Fehler beim Wechsel von Postman zu Newman

Einige Probleme treten immer wieder auf, wenn Teams eine Collection zum ersten Mal von der GUI zu Newman übertragen. Der häufigste Fehler sind hartkodierte Werte. Eine Anfrage, die in Postman funktionierte, weil eine Variable zufällig in der aktiven Umgebung gesetzt war, wird in Newman fehlschlagen, wenn diese Umgebungsdatei nicht mit --environment übergeben wird. Exportieren und übergeben Sie die Umgebung immer explizit.

Der zweite Fehler ist die Abhängigkeit von der Postman Cloud. Collections, die auf Cloud-synchronisierte Variablen verweisen oder Funktionen verwenden, die an eine angemeldete Postman-Sitzung gebunden sind, verhalten sich möglicherweise nicht gleich, wenn sie aus einer einfachen JSON-Datei ausgeführt werden. Testen Sie die exportierte Datei lokal mit Newman, bevor Sie ihr in CI vertrauen.

Der dritte Fehler ist das Vergessen, dass exportierte Dateien veralten. Die Collection-JSON in Ihrem Repository ist ein Schnappschuss. Wenn jemand die Collection in Postman bearbeitet und nicht erneut exportiert, führt die Pipeline weiterhin die alte Version aus. Teams lösen dies durch Disziplin, indem sie den Export als bewussten Commit behandeln, oder indem sie zu einem Tool wechseln, bei dem die Testdefinition und der Runner dasselbe sind.

Wann man jedes Tool verwenden sollte

Verwenden Sie Postman, wenn ein Mensch die Arbeit erledigt. Das Entwerfen einer neuen API, das Debuggen eines fehlerhaften Aufrufs, das Erkunden eines Drittanbieterdienstes, das Erstellen und Verfeinern einer Testsuite: All dies ist interaktiv und gehört in die grafische Benutzeroberfläche.

Verwenden Sie Newman, wenn kein Mensch anwesend ist. Das Ausführen der Suite bei jeder Pull-Anfrage, nach einem nächtlichen Zeitplan oder als Smoke-Test nach der Bereitstellung: All dies erfordert ein Tool, das von einem Skript aus ausgeführt wird und Ergebnisse über einen Exit-Code meldet.

In der Praxis ist die Grenze "Erstellen versus Ausführen". Sie werden nicht das eine dem anderen vorziehen. Sie werden Postman zum Erstellen und Newman zum Automatisieren verwenden, und die Collection-Datei transportiert Ihre Arbeit zwischen den beiden. Wenn Sie überhaupt keinen separaten Runner warten möchten, deckt unser Leitfaden zum Ausführen von Postman-Collections in CI ohne Newman andere Optionen ab.

Eine einheitliche Alternative: Apidog

Die Wartung eines Postman-plus-Newman-Setups bedeutet, Collections zu exportieren, JSON-Dateien synchron zu halten und einen separaten Runner zu verwalten. Apidog fasst dies auf einer Plattform zusammen. Sie entwerfen APIs, debuggen Anfragen und erstellen automatisierte Testszenarien mit visuellen Assertions in derselben App und führen diese Szenarien dann in CI/CD mit dem integrierten Befehlszeilen-Runner aus. Es gibt keinen Export-und-Synchronisationsschritt, da die Testdefinitionen und die Ausführungsengine zusammenleben.

Apidog deckt auch API-Design, Mock-Server und Performance-Tests im selben Arbeitsbereich ab, sodass die von Ihnen erstellten Funktionstests dieselben sind, die Ihre Pipeline ausführt. Sie können Apidog herunterladen und dessen Testfunktionen kostenlos nutzen. Einen Vergleich der Tools in diesem Bereich finden Sie in unserer Liste der besten Postman-Alternativen für API-Tests.

Häufig gestellte Fragen

Ist Newman ein Ersatz für Postman?

Nein. Newman kann Collections nicht erstellen oder bearbeiten; es führt sie nur aus. Sie benötigen immer noch Postman oder ein anderes Tool, um die Collection zu erstellen und die Testskripte zu schreiben. Newmans Aufgabe ist es, diese fertige Arbeit "headless" auszuführen. Sie ergänzen sich, sind nicht austauschbar.

Kostet Newman Geld?

Nein. Newman ist Open Source und komplett kostenlos. Es wird als npm-Paket vertrieben. Postman hat eine kostenlose Stufe plus kostenpflichtige Pläne für größere Teams, aber Newman selbst ist kostenlos, unabhängig davon, wie Sie es verwenden.

Verhalten sich meine Postman-Tests in Newman gleich?

Ja. Newman verwendet dieselbe Ausführungsengine wie Postman, sodass die pm.test-Assertions und die Anfragelogik identisch ausgeführt werden. Eine Collection, die im Postman Collection Runner erfolgreich ist, liefert in Newman dieselben Ergebnisse, was sie sicher für CI macht.

Wie meldet Newman Testfehler?

Newman druckt eine Zusammenfassung ins Terminal und beendet sich mit einem Nicht-Null-Statuscode, wenn ein Test fehlschlägt. Dieser Exit-Code ist die Art und Weise, wie CI-Systeme Fehler erkennen. Newman unterstützt auch Reporter, einschließlich JUnit XML und HTML, sodass Ergebnisse in Dashboards und Build-Berichte einfließen können.

Kann ich Newman ohne die Installation von Node.js ausführen?

Newman ist ein npm-Paket, daher erfordert eine direkte Installation Node.js. Um dies zu vermeiden, verwenden Sie das offizielle postman/newman Docker-Image, das alles bündelt. Der Docker-Ansatz ist in CI-Umgebungen üblich, in denen Sie keine Node.js-Laufzeit im Build-Job verwalten möchten.