Postman ist eines der am weitesten verbreiteten Tools zum Senden von HTTP-Anfragen und zur Überprüfung des Verhaltens einer API. Es begann als Browser-Erweiterung und entwickelte sich zu einer vollwertigen Desktop-Anwendung, die alles abdeckt, von einer schnellen GET-Anfrage bis hin zu skriptgesteuerten Test-Suites, die in CI ausgeführt werden. Wenn Sie APIs entwickeln oder nutzen, werden Sie mit ziemlicher Sicherheit darauf stoßen.
Dieser Leitfaden führt Sie durch das Testen einer API in Postman, wie Sie es im täglichen Betrieb tun würden. Sie senden eine Anfrage, überprüfen die Antwort, schreiben Zusicherungen im "Tests"-Tab, richten Umgebungen ein, um zwischen Staging und Produktion wechseln zu können, und führen eine ganze Collection auf einmal mit dem Collection Runner aus. Die Beispiele verwenden eine öffentliche API, sodass Sie ohne vorherige Einrichtung folgen können.
Postman einrichten und Ihre erste Anfrage senden
Laden Sie Postman von der offiziellen Website herunter und installieren Sie die Desktop-Anwendung. Sie können es für lokale Arbeiten ohne Konto verwenden, obwohl das Anmelden Ihre Collections geräteübergreifend synchronisiert. Öffnen Sie die Anwendung und klicken Sie auf die Schaltfläche Neu, wählen Sie dann HTTP-Anfrage.
Eine Anfrage benötigt mindestens drei Dinge: eine Methode, eine URL und manchmal einen Body. Wählen Sie GET aus der Methoden-Dropdown-Liste und geben Sie einen echten Endpunkt ein. Der JSONPlaceholder-Dienst ist praktisch zum Üben:
GET https://jsonplaceholder.typicode.com/users/1
Klicken Sie auf Senden. Das Antwortfeld füllt sich mit dem Body, dem Statuscode (200 OK), der Antwortzeit und der Größe. Wechseln Sie die Body-Ansicht zwischen Pretty, Raw und Preview, um das JSON formatiert oder wie vom Server gesendet anzuzeigen.
Für eine POST-Anfrage ändern Sie die Methode, öffnen Sie den Body-Tab, wählen Sie raw und dann JSON aus der Format-Dropdown-Liste. Fügen Sie eine Nutzlast wie diese ein:
{
"name": "Maria Chen",
"email": "maria.chen@example.com"
}
Header wie Content-Type: application/json werden automatisch für Sie hinzugefügt, wenn Sie den JSON-Body-Typ auswählen. Der Headers-Tab ermöglicht es Ihnen, alles andere hinzuzufügen, was die API benötigt, wie einen Authorization-Header. Wenn Sie neu sind, welche Antwortcodes zu erwarten sind, ist der Leitfaden zu den HTTP-Statuscodes, die REST-APIs verwenden sollten, eine nützliche Referenz.
Anfragen in Collections organisieren
Eine einzelne Anfrage ist für eine schnelle Überprüfung ausreichend. Echtes Testen bedeutet viele Anfragen, die zusammengehören: einen Benutzer erstellen, diesen Benutzer abrufen, aktualisieren, löschen. Postman gruppiert diese in Collections.
Klicken Sie in der Seitenleiste auf Collections und dann auf das +-Symbol, um eine zu erstellen. Nennen Sie sie etwas Konkretes wie „User API Smoke Tests.“ Speichern Sie jede Anfrage mit Strg/Cmd + S in der Collection und geben Sie ihr einen klaren Namen. Sie können Ordner innerhalb einer Collection verschachteln, um beispielsweise Authentifizierungsanfragen von Ressourcenanfragen zu trennen.
Collections sind auch die Einheit, die Sie teilen. Exportieren Sie eine als JSON-Datei oder teilen Sie einen Link, wenn Sie mit der Cloud synchronisieren. Teammitglieder importieren sie und haben genau dieselben Anfragen wie Sie. Dies ist die Grundlage für alles andere, da der Collection Runner und automatisierte Tests beide mit Collections statt mit losen Anfragen arbeiten.
Eine Collection kann auch gemeinsames Verhalten tragen. Postman ermöglicht es Ihnen, Skripte auf Collection- oder Ordnerebene anzuhängen, nicht nur an einer einzelnen Anfrage. Ein Pre-request-Skript in der Collection wird vor jeder Anfrage darin ausgeführt, was nützlich ist, um ein Token zu aktualisieren oder einen Zeitstempel zu setzen. Ein Testskript auf Collection-Ebene wird nach jeder Anfrage ausgeführt, was praktisch ist für eine Zusicherung, die Sie überall haben möchten, wie „Die Antwortzeit ist angemessen.“ Wenn Sie diese einmal definieren, bleiben Ihre individuellen Anfragen auf das fokussiert, was für sie einzigartig ist.
Tests im "Tests"-Tab schreiben
Das Senden einer Anfrage zeigt Ihnen, was zurückkam. Ein Test sagt Ihnen, ob das, was zurückkam, korrekt ist – automatisch, jedes Mal. Postman führt JavaScript im Scripts-Bereich einer Anfrage (ältere Versionen nannten dies den Tests-Tab) aus, nachdem die Antwort eingetroffen ist.
Postman stellt ein pm-Objekt zum Schreiben von Zusicherungen bereit. Das Kernmuster ist pm.test(name, callback), wobei der Callback einen Fehler auslöst, wenn eine Erwartung fehlschlägt. Hier sind Zusicherungen, die Sie ständig verwenden werden:
// Statuscode überprüfen
pm.test("Statuscode ist 200", function () {
pm.response.to.have.status(200);
});
// Antwortzeit überprüfen
pm.test("Antwort ist unter 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Ein Feld im JSON-Body überprüfen
pm.test("Benutzer hat die erwartete E-Mail", function () {
const body = pm.response.json();
pm.expect(body.email).to.eql("maria.chen@example.com");
});
// Einen Header überprüfen
pm.test("Content-Type ist JSON", function () {
pm.expect(pm.response.headers.get("Content-Type"))
.to.include("application/json");
});
Die Zusicherungssyntax stammt von Chai, sodass pm.expect .to.eql, .to.include, .to.be.above und den Rest unterstützt. Klicken Sie auf Senden und die Ergebnisse werden im Test Results-Tab angezeigt, jeder Test grün oder rot.
Einige Gewohnheiten machen Tests nützlich. Benennen Sie jeden pm.test-Block nach dem Verhalten, das er überprüft, nicht nach dem Endpunkt, damit eine Fehlermeldung wie ein Satz klingt. Überprüfen Sie die Dinge, die einen Konsumenten der API tatsächlich stören würden: den Statuscode, die Form des Bodys und die Felder, von denen ein Client abhängt. Vermeiden Sie Zusicherungen für Werte, die Sie nicht kontrollieren, wie z.B. einen servergenerierten Zeitstempel, da diese zu unzuverlässigen Fehlern führen, die Menschen dazu bringen, rote Anzeigen zu ignorieren. Postman liefert auch ein Snippets-Panel neben dem Editor mit vorgefertigten Zusicherungen, die Sie anklicken können, um sie einzufügen, was der schnellste Weg ist, die pm-API zu lernen. Wenn Sie einen tieferen Einblick in das Zusicherungsdesign wünschen, sehen Sie sich die Aufschlüsselung der API-Zusicherungen und wie man sie gut schreibt an. Für die umfassendere Idee der Strukturierung von Prüfungen in benannte Fälle ist der Leitfaden zum API-Testfall-Beispiel lesenswert.
Umgebungen und Variablen verwenden
Das Festkodieren von https://api.staging.example.com in jeder Anfrage wird schmerzhaft, sobald Sie auf die Produktion verweisen müssen. Umgebungen lösen dies. Eine Umgebung ist eine benannte Menge von Variablen.
Klicken Sie auf das Umgebungs-Symbol in der Seitenleiste und erstellen Sie eine namens „Staging.“ Fügen Sie eine Variable base_url mit dem Wert https://jsonplaceholder.typicode.com hinzu. Erstellen Sie eine zweite Umgebung namens „Production“ mit einer anderen base_url. Referenzieren Sie die Variable nun in Ihren Anfragen mit doppelten geschweiften Klammern:
GET {{base_url}}/users/1
Wählen Sie die aktive Umgebung aus dem Dropdown-Menü oben rechts, und jede Anfrage, die {{base_url}} verwendet, wechselt damit.
Variablen übertragen auch Daten zwischen Anfragen. Eine Anmeldeanfrage kann ein Token aus ihrer Antwort erfassen und für spätere Anfragen speichern:
pm.test("Auth-Token speichern", function () {
const token = pm.response.json().token;
pm.environment.set("auth_token", token);
});
Jede spätere Anfrage kann dann Authorization: Bearer {{auth_token}} senden. Diese Verkettung ist, wie Sie Flows testen, die von Zuständen abhängen, wie das Erstellen einer Ressource und das anschließende Überprüfen ihrer Existenz.
Postman hat zwei verwandte Variablenbereiche, die es wert sind, beachtet zu werden. Umgebungsvariablen gehören zur ausgewählten Umgebung und ändern sich, wenn Sie Umgebungen wechseln. Collection-Variablen gehören zu einer Collection, unabhängig von der Umgebung, was für Werte geeignet ist, die für diese API konstant sind. Es gibt auch globale Variablen, die überall gelten, und kurzlebige lokale Variablen, die nur für eine Ausführung existieren. Die Wahl des richtigen Umfangs hält einen Wert dort, wo er hingehört, und vermeidet Überraschungen, wenn Sie Ziele wechseln.
Eine ganze Collection mit dem Collection Runner ausführen
Das Klicken auf „Senden“ bei jeder Anfrage wird schnell mühsam. Der Collection Runner führt jede Anfrage in einer Collection der Reihe nach aus, führt alle ihre Tests durch und gibt Ihnen eine Erfolgs-/Fehlerübersicht.
Öffnen Sie eine Collection, klicken Sie auf die Schaltfläche Run (oder das Drei-Punkte-Menü, dann Run collection). Der Runner zeigt Ihre Anfragen in Reihenfolge an. Wählen Sie die Umgebung, legen Sie fest, wie viele Iterationen ausgeführt werden sollen, und fügen Sie optional eine Datendatei hinzu. Klicken Sie auf Run und Postman feuert jede Anfrage von oben nach unten ab und führt die Tests jeder Anfrage aus.
Die Ergebnisseite listet jede Zusicherung über jede Anfrage auf, mit Summen für bestanden und fehlgeschlagen. Dies ist Ihre Regressionsprüfung. Führen Sie sie nach einer Bereitstellung aus und Sie wissen in Sekundenschnelle, ob sich die API noch wie erwartet verhält. Der Runner speichert auch einen Verlauf früherer Läufe, sodass Sie das heutige Ergebnis mit dem von gestern vergleichen und erkennen können, wann eine zuvor grüne Suite zu scheitern begann.
Die Reihenfolge ist im Runner wichtig. Da Anfragen von oben nach unten ausgeführt werden, können Sie eine Anmeldeanfrage zuerst platzieren, damit sie ein auth_token füllt, und dann jede darunter liegende Anfrage dieses Token verwenden lassen. Dasselbe gilt für Einrichtung und Bereinigung: eine Ressource am Anfang erstellen, sie in der Mitte verwenden, am Ende löschen. Eine gut geordnete Collection skriptet effektiv eine vollständige Benutzerreise.
Für datengetriebenes Testen hängen Sie eine CSV- oder JSON-Datei im Runner an. Jede Zeile wird zu einer Iteration, und Sie referenzieren Spalten als Variablen wie {{username}}. Dies ermöglicht es einer Anfrage, Dutzende von Eingabekombinationen zu testen, ohne die Anfrage zu duplizieren. Ein Login-Endpunkt kann beispielsweise mit einer Zeile gültiger Anmeldeinformationen und mehreren Zeilen ungültiger getroffen werden, wobei jede Zeile den von ihr erwarteten Statuscode zusichert. Der Artikel über datengetriebenes API-Testen mit CSV und JSON behandelt das Muster detailliert. Um dieselbe Collection in CI ohne GUI auszuführen, stellt Postman das Befehlszeilentool Newman bereit, beschrieben im Vergleich Newman versus Postman.
Wo Postman komplex wird und was zu beachten ist
Postman eignet sich hervorragend für exploratives Testen und kleine bis mittlere Testsuiten. Zwei Reibungspunkte treten auf, wenn Projekte wachsen. Erstens sind Zusicherungen in JavaScript, sodass Nicht-Entwickler und QA-Mitarbeiter, die einen visuellen Ansatz bevorzugen, eine Lernkurve haben. Zweitens hält Postman API-Design, Testen, Mocking und Dokumentation an separaten Orten, was bedeutet, dass Ihre Testdaten und Ihr API-Vertrag auseinanderdriften können.
Apidog ist eine All-in-One-API-Plattform, die beides adressiert. Es importiert Postman-Collections direkt, sodass die Migration keine Neuentwicklung ist. Zusicherungen können visuell ohne Code erstellt werden, während Skripte bei Bedarf weiterhin zulässig sind. Da Design, Debugging, Mocking, Testen und Dokumentation eine einzige Quelle der Wahrheit teilen, bleiben Ihre Tests mit der tatsächlichen API-Spezifikation abgestimmt. Wenn Sie Optionen abwägen, stellt die Übersicht über Postman-Alternativen für API-Tests die Kompromisse dar. Sie können Apidog herunterladen und eine bestehende Collection importieren, um direkt zu vergleichen.
Nichts davon bedeutet, dass Sie Postman aufgeben sollten. Es bleibt eine solide Wahl, besonders für schnelle Überprüfungen und Teams, die bereits darin investiert sind. Der Punkt ist zu wissen, wo jedes Tool passt.
Häufig gestellte Fragen
Muss ich Code schreiben, um APIs in Postman zu testen?
Zum Senden von Anfragen und Lesen von Antworten, nein. Für automatisierte Zusicherungen, ja, zumindest ein wenig. Postmans "Tests"-Tab führt JavaScript aus und verwendet das pm-Objekt. Die Muster sind einfach, und Sie können sie aus Postmans integriertem Snippets-Panel kopieren, aber es ist immer noch JavaScript. Wenn Sie einen visuellen Zusicherungs-Builder ohne Code wünschen, übernimmt dies eine dedizierte Plattform wie Apidog.
Was ist der Unterschied zwischen einer Postman Collection und einer Umgebung?
Eine Collection ist eine Gruppe von Anfragen, oft zusammen mit ihren Tests. Eine Umgebung ist eine benannte Menge von Variablen, wie base_url oder auth_token. Collections enthalten das, was Sie senden. Umgebungen enthalten die Werte, die sich zwischen Staging, Produktion und lokal ändern. Sie richten eine Collection auf verschiedene Umgebungen aus, um dieselben Anfragen gegen verschiedene Server zu testen.
Wie führe ich Postman-Tests automatisch in CI aus?
Verwenden Sie Newman, Postmans Kommandozeilen-Runner. Exportieren Sie Ihre Collection und Umgebung, dann führen Sie newman run collection.json -e environment.json aus. Newman beendet sich mit einem Nicht-Null-Code, wenn ein Test fehlschlägt, was Ihre CI-Pipeline überprüft. Der Leitfaden zum Automatisieren von API-Tests in CI/CD beschreibt, wie dies in eine Pipeline integriert wird.
Kann Postman mehr als nur REST-APIs testen?
Ja. Modernes Postman unterstützt GraphQL-, gRPC-, WebSocket- und SOAP-Anfragen zusätzlich zu einfachem HTTP und REST. Der "Tests"-Tab und die Zusicherungen funktionieren bei den meisten davon, obwohl die genaue Anfrageroutine je nach Protokoll variiert.
Wie viele Zusicherungen sollte eine Anfrage haben?
Genug, um zu bestätigen, dass die Antwort korrekt ist, aber nicht so viele, dass eine einzelne Änderung ein Dutzend Tests sprengt. Eine gängige Basislinie sind der Statuscode, die Antwortzeit und die zwei oder drei Felder, die für diesen Endpunkt relevant sind. Halten Sie jeden pm.test-Block auf eine Erwartung konzentriert, damit ein Fehler Ihnen genau sagt, was kaputt ist.