Postman hilft QA, APIs zu erkunden und erfolgreiche manuelle Anfragen in wiederholbare Prüfungen zu verwandeln. Entscheidend ist zu erklären, welcher Vertrag verletzt wurde, welche Daten gesendet wurden und warum die Antwort für Benutzer unzulässig ist. Send anzuklicken und 200 zu sehen reicht nicht: Der Server könnte eine fremde Bestellung, die falsche Währung oder Erfolg ohne Speicherung zurückgeben. Organisieren Sie die Arbeit um Szenarien und prüfbare Erwartungen.
Was eine funktionierende Collection enthält
Eine Anfrage legt Methode, URL, Header, Autorisierung und Body fest. Eine Collection bündelt zusammengehörige Anfragen und gemeinsame Einstellungen; ein Ordner kann eine Benutzerreise abbilden. Ein Environment liefert Parameter einer bestimmten Bereitstellung. Pre-Request-Skripte bereiten Daten vor, Post-Response-Skripte prüfen Ergebnisse. Antworten und Verlauf helfen bei Untersuchungen, ersetzen aber kein gespeichertes Szenario: Kollegen müssen die Prüfung ohne Ihren lokalen Zustand oder mündliche Erklärungen wiederholen können.
Eine API-Untersuchung beginnen
Suchen Sie zunächst die Verhaltensvereinbarung: OpenAPI, Anforderungen, Clientbeispiele und Rollenbeschränkungen. Prüfen Sie Umgebungs-URL und Dienstversion und senden Sie die kleinste gültige Anfrage. Entfernen Sie optionale Felder und bestimmen Sie, welche das Ergebnis beeinflussen. Speichern Sie ein funktionierendes Beispiel mit Zweckbeschreibung. Ändern Sie anschließend jeweils eine Bedingung: Feldtyp, fehlenden Pflichtwert, Benutzerrechte oder Objektzustand. So wird Beobachtung zum kontrollierten Experiment.
Variablen ohne versteckte Abhängigkeiten
Speichern Sie die Dienstadresse in baseUrl und die Kennung der erzeugten Bestellung in orderId. {{baseUrl}}/orders/{{orderId}} ist verständlicher als eine beliebige Adresse mit fester Zahl. Postman-Variablen hängen vom Gültigkeitsbereich ab: global, Collection, Environment, Iterationsdaten und lokal. Gleiche Namen in verschiedenen Bereichen erschweren die Fehlersuche. Prüfen Sie vor Tests das gewählte Environment und den aufgelösten Adresswert; verlassen Sie sich nicht allein auf den Tabnamen.
Verwahren Sie Tokens und Passwörter in einem für Geheimnisse vorgesehenen Mechanismus und übergeben Sie CI-Geheimnisse über die Laufzeitumgebung. Kontrollieren Sie Variablenwerte und Antwortbeispiele vor dem Export getrennt. Eine Sensitivmarkierung und Maskierung im UI beweisen nicht, dass der Wert in Dateien, Konsole oder Berichtsanhängen fehlt.
Übung: Eine Bestellung anlegen und lesen
Angenommen, der Test-API-Vertrag erzeugt Bestellungen über POST /orders und liefert 201, id und totalMinor in kleinsten Währungseinheiten. Benutzer buyer-a und ein Testprodukt stehen bereit; echte Belastungen sind deaktiviert. Im Beispiel kostet ein Produkt 1250, die Menge beträgt zwei und die Lieferung ist kostenlos. Das sind Testeingaben und erwartetes Ergebnis, kein universelles API-Format.
- 1.Erstellen Sie eine Bestellung mit quantity=2. Erwarten Sie 201, eine nicht leere Kennung und totalMinor=2500; speichern Sie id erst nach Prüfung der Antwort.
- 2.Rufen Sie GET /orders/{{orderId}} als derselbe Benutzer auf. Erwarten Sie denselben Eigentümer, Inhalt und Gesamtbetrag; bestätigen Sie die Erstellung durch Zurücklesen.
- 3.Wiederholen Sie das Lesen als buyer-b. Erwarten Sie die vertragliche Ablehnung ohne fremde Bestellinhalte; der genaue Code hängt von der Dienstrichtlinie ab.
- 4.Senden Sie quantity=0. Erwarten Sie den vereinbarten Validierungsfehler und keine neue Bestellung; prüfen Sie die Nebenwirkung über eine verfügbare Methode.
Prüfungen mit aussagekräftigen Ergebnissen
Ein Post-Response-Skript sollte neben dem HTTP-Code Geschäftswerte und Struktur prüfen. Beispielsweise kann eine Erstellungsanfrage folgende Assertions verwenden. Bedingtes Speichern von id schützt den nächsten Schritt vor offensichtlich ungültigen Daten, macht die gesamte Kette aber nicht zustandsunabhängig.
pm.test('Order created', () => {
pm.response.to.have.status(201);
const body = pm.response.json();
pm.expect(body.id).to.be.a('string').and.not.empty;
pm.expect(body.totalMinor).to.eql(2500);
});
if (pm.response.code === 201) {
const body = pm.response.json();
if (typeof body.id === 'string' && body.id.length > 0) {
pm.environment.set('orderId', body.id);
}
}Vergleichen Sie Antworten mit Erstellungszeiten und Zufallskennungen nicht vollständig mit einem einzigen festen Snapshot. Prüfen Sie Pflichtfelder, Typen und gültige Beziehungen zwischen Werten. Bewerten Sie unerwartete Zusatzattribute anhand des Kompatibilitätsvertrags statt automatisch einen Defekt zu melden.
Wiederholbare Läufe und Datenbereinigung
Die Collection sollte eigene Daten erzeugen oder die Vorbereitung ausdrücklich dokumentieren. Löschen Sie alte orderId-Werte vor einer Wiederholung, damit keine Bestellung eines früheren Laufs gelesen wird. Beschreiben Sie Löschung oder Markierung von Testentitäten sowie die Wiederherstellung nach Teilfehlern. Verwenden Sie bei parallelen Läufen eindeutige Laufkennungen. Geteilte Benutzer und dauerhafte Bestellungen verwandeln gültige Prüfungen oft in zufällige Wettläufe zwischen Testern.
Ausführung in CI
Stand Oktober 2026 beschreibt die Postman-v12-Dokumentation das Collection-Format v3 und empfiehlt Postman CLI. Newman ist veraltet, wird nicht mehr unterstützt und kann v3 nicht ausführen. Klären Sie zuerst Collection-Format, verfügbare Skripte und Runner. Erproben Sie immer die Übernahme einer Anfrage aus der Anwendung in CI: Lokale Vaults, Cookies und UI-Funktionen sind in einer anderen Umgebung nicht selbstverständlich verfügbar.
Bei asynchronen Operationen kann Erfolg lediglich die Annahme eines Auftrags bedeuten. Liefert die Erstellung einen Verarbeitungsstatus, definieren Sie Warten auf den Endzustand, Höchstdauer und zulässige Zwischenantworten. Eine beliebig lange Pause verschwendet in schnellen Umgebungen Zeit und bleibt in langsamen instabil. Prüfen Sie Retries nach Timeout separat: Ein dem Client unbekanntes Ergebnis bedeutet nicht, dass kein Objekt entstand. Werden Idempotenzschlüssel unterstützt, behalten Sie bei Wiederholungen derselben Absicht denselben Schlüssel und prüfen Sie, dass keine zweite Bestellung entsteht.
Abweichungen untersuchen
Vergleichen Sie tatsächliche URL, Autorisierung, Header und gesendeten Body sowie anschließend Status, Antwort und Dauer. Prüfen Sie Variablenauflösung und automatische Redirects. Funktioniert ein manueller Lauf, CI aber nicht, sind häufig ein anderes Token, Zeitzonen, fehlende Daten oder Netzwerkbedingungen beteiligt. Ergänzen Sie den Defekt um eine minimale anonymisierte Anfrage, Vertragserwartung, tatsächliche Antwort, Build und Korrelations-ID. Ein vollständiger Environment-Dump enthält meist mehr unnötige Daten als hilfreiche Belege.
Häufige Fehler und QA-Ergebnisse
Typische Fehler sind eine komplette Regression in ungespeicherten Tabs, grüner Status als Korrektheitsbeweis, manuelle Adressänderungen in Dutzenden Anfragen und zustandsändernde Operationen in der falschen Umgebung. Ebenso problematisch ist eine unkontrollierte Kette, deren erster Fehler zwanzig Folgefehler erzeugt. Gute Collections haben klare Vorbereitung, sinnvolle Prüfungen, diagnostizierbare Abhängigkeiten und sichere Bereinigung. Damit unterstützt Postman API-Diskussionen anhand reproduzierbarer Fakten.
Weiterführende Informationen
Eine wiederholbare lokale Collection: Status, Schema und Geschäftszustand
Verwenden Sie eine fiktive API mit GET /items und POST /items. Ihr erklärter Vertrag akzeptiert einen nicht leeren name und eine ganzzahlige quantity von 1 bis 10; gültiges Schreiben liefert 201, eine Menge außerhalb des Bereichs 422 und ungültiges JSON 400. Diese Statuswerte gelten für dieses Beispiel, nicht für jede API. Beginnen Sie mit einem vorbereiteten Item und setzen Sie die temporäre Fixture vor jedem Collection-Lauf zurück.
Ausführungsreihenfolge Anfrage Erwartetes Ergebnis
1 Verwerfbare Test-Fixture zurücksetzen Ein anfänglicher Eintrag
2 GET /items 200; items ist ein Array der Länge 1
3 POST /items {"name":"Pen","quantity":2} 201; id=2, name=Pen, quantity=2
4 POST /items {"name":"Pen","quantity":11} 422; Fehler im Wertebereich von quantity
5 POST /items mit fehlerhaftem JSON 400; Fehler wegen ungültigem JSON
6 GET /items Genau 2 Einträge; abgelehnte Schreibvorgänge haben nichts hinzugefügtEine reine Status-Assertion kann ein falsches Geschäftsergebnis übersehen. Ergänzen Sie eine Schema-Assertion für Pflichtfelder und Typen und vergleichen Sie wichtige Werte. Abschließendes Lesen prüft Speicherung und ausbleibende Nebenwirkungen. Halten Sie baseUrl in einem separaten Environment; echte Zugangsdaten gehören niemals in die exportierte Übungs-Collection.
pm.test('Created', () => pm.response.to.have.status(201));
pm.test('Business values', () => {
const item = pm.response.json();
pm.expect(item.name).to.eql('Pen');
pm.expect(item.quantity).to.eql(2);
});Für neue Automatisierung nutzen Sie den aktuellen Postman-CLI-Workflow. Die offizielle Anleitung empfiehlt nun die gepflegte CLI; Newman dient als Kompatibilitätsoption für bestehende v2.1-Collections. Ein kompatibler Befehl für eine exportierte lokale v2.1-Collection lautet newman run collection.json -e environment.json. Binden Sie den Übungsserver an Loopback und setzen Sie seine temporäre Fixture vor dem Lauf zurück.