DEV Community

Cover image for APIs testen mit Postman: Eine praktische Anleitung
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

APIs testen mit Postman: Eine praktische Anleitung

Postman ist eines der am weitesten verbreiteten Tools zum Senden von HTTP-Anfragen und zum Überprüfen des API-Verhaltens. Es eignet sich für schnelle manuelle Checks, skriptbasierte Tests und Collection-Runs, die sich später auch automatisieren lassen.

Teste Apidog noch heute

In diesem Leitfaden testen Sie eine API in Postman so, wie es im Alltag typischerweise passiert: Anfrage senden, Antwort prüfen, Tests schreiben, Umgebungen verwenden und eine komplette Collection mit dem Collection Runner ausführen. Die Beispiele nutzen JSONPlaceholder, damit Sie ohne eigenes Backend mitmachen können.

Postman einrichten und die erste Anfrage senden

Laden Sie Postman von der offiziellen Website herunter und installieren Sie die Desktop-App. Sie können Postman lokal auch ohne Konto verwenden. Ein Konto ist vor allem nützlich, wenn Sie Collections geräteübergreifend synchronisieren möchten.

Erstellen Sie danach eine neue HTTP-Anfrage:

  1. Öffnen Sie Postman.
  2. Klicken Sie auf New.
  3. Wählen Sie HTTP Request.
  4. Stellen Sie die Methode auf GET.
  5. Tragen Sie diese URL ein: 
GET https://jsonplaceholder.typicode.com/users/1
Enter fullscreen mode Exit fullscreen mode

Klicken Sie auf Send. Postman zeigt Ihnen danach:

  • den Response-Body
  • den Statuscode, z. B. 200 OK
  • die Antwortzeit
  • die Response-Größe
  • Header und Cookies

Wechseln Sie im Body-Bereich zwischen Pretty, Raw und Preview, um die Antwort unterschiedlich darzustellen.

Für eine POST-Anfrage ändern Sie die Methode auf POST, öffnen den Tab Body, wählen raw und dann JSON. Beispiel-Payload:

{
  "name": "Maria Chen",
  "email": "maria.chen@example.com"
}
Enter fullscreen mode Exit fullscreen mode

Wenn Sie den Body-Typ auf JSON setzen, fügt Postman automatisch den Header Content-Type: application/json hinzu. Weitere Header wie Authorization können Sie im Tab Headers ergänzen.

Wenn Sie unsicher sind, welche Statuscodes eine REST-API zurückgeben sollte, hilft diese Referenz zu HTTP-Statuscodes, die REST-APIs verwenden sollten.

Anfragen in Collections organisieren

Eine einzelne Anfrage reicht für einen schnellen Check. Für echte API-Tests brauchen Sie aber zusammenhängende Abläufe, zum Beispiel:

  1. Benutzer erstellen
  2. Benutzer abrufen
  3. Benutzer aktualisieren
  4. Benutzer löschen

Dafür verwendet Postman Collections.

So legen Sie eine Collection an:

  1. Öffnen Sie links den Bereich Collections.
  2. Klicken Sie auf das +-Symbol.
  3. Geben Sie der Collection einen konkreten Namen, z. B. User API Smoke Tests.
  4. Speichern Sie Anfragen mit Strg/Cmd + S in dieser Collection.
  5. Benennen Sie jede Anfrage eindeutig, z. B. Get user by ID.

Sie können zusätzlich Ordner verwenden, etwa:

User API Smoke Tests
├── Auth
│   └── Login
├── Users
│   ├── Create user
│   ├── Get user
│   ├── Update user
│   └── Delete user
Enter fullscreen mode Exit fullscreen mode

Collections sind auch die Einheit, die Sie teilen oder exportieren. Sie können eine Collection als JSON exportieren oder per Link teilen, wenn Sie Postmans Cloud-Sync verwenden.

Praktisch ist außerdem, dass Sie Skripte auf Collection- oder Ordnerebene definieren können:

  • Pre-request Script: läuft vor jeder Anfrage
  • Tests Script: läuft nach jeder Anfrage

Beispiel für einen einfachen Test auf Collection-Ebene:

pm.test("Antwortzeit ist unter 1000ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});
Enter fullscreen mode Exit fullscreen mode

Damit müssen Sie allgemeine Prüfungen nicht in jeder einzelnen Anfrage duplizieren.

Tests im Scripts- oder Tests-Tab schreiben

Das manuelle Prüfen einer Antwort ist fehleranfällig. Besser ist es, Erwartungen als Tests zu formulieren. Postman führt diese Tests nach dem Empfang der Antwort aus.

Je nach Postman-Version finden Sie diese Logik im Bereich Scripts oder im älteren Tests-Tab.

Postman stellt dafür das Objekt pm bereit. Das Grundmuster lautet:

pm.test("Beschreibung des erwarteten Verhaltens", function () {
    // Assertion
});
Enter fullscreen mode Exit fullscreen mode

Typische Assertions:

// 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);
});

// 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");
});

// Header überprüfen
pm.test("Content-Type ist JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});
Enter fullscreen mode Exit fullscreen mode

Die Assertion-Syntax basiert auf Chai. Sie können unter anderem verwenden:

pm.expect(value).to.eql("abc");
pm.expect(value).to.include("json");
pm.expect(value).to.be.above(10);
pm.expect(value).to.be.below(500);
Enter fullscreen mode Exit fullscreen mode

Nach einem Klick auf Send sehen Sie die Ergebnisse im Bereich Test Results.

Gute API-Tests sollten sich auf Verhalten konzentrieren, das für API-Konsumenten relevant ist:

  • richtiger Statuscode
  • erwartete Response-Struktur
  • wichtige Felder im Body
  • relevante Header
  • sinnvolle Antwortzeit

Vermeiden Sie Tests auf Werte, die sich ständig ändern, z. B. servergenerierte Zeitstempel, sofern diese nicht explizit Teil des erwarteten Verhaltens sind.

Beispiel für einen stabileren Test:

pm.test("Antwort enthält eine Benutzer-ID", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body.id).to.be.a("number");
});
Enter fullscreen mode Exit fullscreen mode

Postman bietet außerdem ein Snippets-Panel. Dort können Sie häufige Testbausteine anklicken und in Ihr Skript einfügen.

Für mehr Details zum Design von Assertions lesen Sie die Erklärung zu API-Zusicherungen und wie man sie gut schreibt. Wenn Sie Tests als benannte Fälle strukturieren möchten, ist auch das API-Testfall-Beispiel hilfreich.

Umgebungen und Variablen verwenden

Hardcodierte URLs wie https://api.staging.example.com in jeder Anfrage werden schnell unübersichtlich. Besser ist es, Postman-Umgebungen zu verwenden.

Eine Umgebung ist eine benannte Sammlung von Variablen, z. B.:

base_url = https://jsonplaceholder.typicode.com
auth_token = ...
Enter fullscreen mode Exit fullscreen mode

So richten Sie eine Umgebung ein:

  1. Öffnen Sie den Bereich Environments.
  2. Erstellen Sie eine Umgebung namens Staging.
  3. Fügen Sie eine Variable base_url hinzu.
  4. Setzen Sie den Wert auf: 
https://jsonplaceholder.typicode.com
Enter fullscreen mode Exit fullscreen mode

Verwenden Sie die Variable anschließend in Ihrer Anfrage:

GET {{base_url}}/users/1
Enter fullscreen mode Exit fullscreen mode

Wählen Sie oben rechts die aktive Umgebung aus. Wenn Sie später eine Umgebung Production mit einer anderen base_url erstellen, können dieselben Requests gegen ein anderes Ziel laufen.

Variablen sind auch nützlich, um Daten zwischen Anfragen weiterzugeben. Beispiel: Ein Login-Request speichert ein Token aus der Antwort:

pm.test("Auth-Token speichern", function () {
    const token = pm.response.json().token;
    pm.environment.set("auth_token", token);
});
Enter fullscreen mode Exit fullscreen mode

Danach können spätere Requests diesen Header verwenden:

Authorization: Bearer {{auth_token}}
Enter fullscreen mode Exit fullscreen mode

Wichtige Variablenbereiche in Postman:

Bereich Verwendung
Environment Variables Werte pro Umgebung, z. B. base_url, auth_token
Collection Variables Werte, die zur Collection gehören
Global Variables Werte, die überall verfügbar sind
Local Variables Werte nur für eine einzelne Ausführung

Wählen Sie den kleinsten passenden Scope. Das reduziert Seiteneffekte, wenn Sie zwischen Staging, Produktion und lokalen APIs wechseln.

Eine komplette Collection mit dem Collection Runner ausführen

Wenn Sie jede Anfrage einzeln über Send ausführen, wird das schnell langsam. Der Collection Runner führt alle Requests einer Collection der Reihe nach aus und zeigt am Ende eine Zusammenfassung.

So starten Sie einen Run:

  1. Öffnen Sie Ihre Collection.
  2. Klicken Sie auf Run oder öffnen Sie das Drei-Punkte-Menü und wählen Sie Run collection.
  3. Prüfen Sie die Reihenfolge der Requests.
  4. Wählen Sie die passende Umgebung.
  5. Legen Sie optional Iterationen fest.
  6. Fügen Sie optional eine CSV- oder JSON-Datendatei hinzu.
  7. Klicken Sie auf Run.

Postman führt nun jede Anfrage aus und wertet die zugehörigen Tests aus.

Die Reihenfolge ist wichtig. Typischer Ablauf:

1. Login
2. Create user
3. Get user
4. Update user
5. Delete user
Enter fullscreen mode Exit fullscreen mode

Wenn Login ein Token speichert, können alle nachfolgenden Requests dieses Token verwenden:

pm.environment.set("auth_token", pm.response.json().token);
Enter fullscreen mode Exit fullscreen mode

Für datengetriebene Tests können Sie im Runner eine CSV- oder JSON-Datei verwenden.

Beispiel users.csv:

email,expected_status
maria.chen@example.com,200
invalid-email,400
empty@example.com,400
Enter fullscreen mode Exit fullscreen mode

In der Anfrage verwenden Sie dann Variablen:

{
  "email": "{{email}}"
}
Enter fullscreen mode Exit fullscreen mode

Und im Test prüfen Sie den erwarteten Statuscode:

pm.test("Statuscode entspricht Testdaten", function () {
    pm.response.to.have.status(Number(pm.iterationData.get("expected_status")));
});
Enter fullscreen mode Exit fullscreen mode

So testen Sie mehrere Eingabekombinationen, ohne Requests zu duplizieren.

Mehr dazu finden Sie im Artikel über datengetriebenes API-Testen mit CSV und JSON. Wenn Sie dieselbe Collection ohne GUI in CI ausführen möchten, nutzen Sie Newman. Der Unterschied wird im Vergleich Newman versus Postman erklärt.

Postman in CI mit Newman ausführen

Für automatisierte API-Tests in einer Pipeline exportieren Sie Ihre Collection und Umgebung als JSON-Dateien und führen sie mit Newman aus.

Installation:

npm install -g newman
Enter fullscreen mode Exit fullscreen mode

Ausführung:

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

Wenn ein Test fehlschlägt, beendet Newman den Prozess mit einem Nicht-Null-Exit-Code. Dadurch kann Ihre CI-Pipeline fehlschlagen.

Ein minimales Beispiel für GitHub Actions:

name: API Tests

on:
  push:
    branches:
      - main

jobs:
  postman-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Newman
        run: npm install -g newman

      - name: Run Postman collection
        run: newman run collection.json -e environment.json
Enter fullscreen mode Exit fullscreen mode

Der Leitfaden zum Automatisieren von API-Tests in CI/CD zeigt, wie Sie diesen Ansatz in eine Pipeline integrieren.

Wo Postman komplex wird

Postman ist stark für exploratives Testen und kleine bis mittlere Testsuiten. Bei wachsenden Projekten treten häufig zwei Punkte auf:

  1. Assertions sind JavaScript-basiert

    Das ist flexibel, kann aber für QA-Teams oder nicht-technische Beteiligte eine Hürde sein.

  2. Design, Tests, Mocking und Dokumentation liegen oft getrennt

    Dadurch können API-Vertrag, Testdaten und Dokumentation auseinanderlaufen.

Apidog ist eine All-in-One-API-Plattform, die diese Punkte adressiert. Postman-Collections können importiert werden. Assertions lassen sich visuell ohne Code erstellen, während Skripte bei Bedarf weiterhin möglich sind. Design, Debugging, Mocking, Testen und Dokumentation teilen eine gemeinsame Quelle der Wahrheit.

Wenn Sie Alternativen vergleichen möchten, bietet die Übersicht zu Postman-Alternativen für API-Tests einen Einstieg. Sie können außerdem Apidog herunterladen und eine bestehende Collection importieren, um den Workflow direkt zu vergleichen.

Das heißt nicht, dass Sie Postman ersetzen müssen. Für schnelle Prüfungen und Teams, die bereits mit Postman arbeiten, bleibt es eine solide Wahl. Wichtig ist, den passenden Workflow für Projektgröße, Teamstruktur und Automatisierungsgrad zu wählen.

Häufig gestellte Fragen

Muss ich Code schreiben, um APIs in Postman zu testen?

Zum Senden von Requests und Lesen von Responses: nein. Für automatisierte Assertions: ja, zumindest etwas JavaScript. Postman verwendet dafür das pm-Objekt im Tests- oder Scripts-Bereich. Viele Muster können Sie aus dem Snippets-Panel übernehmen.

Wenn Sie Assertions visuell ohne Code erstellen möchten, kann eine dedizierte Plattform wie Apidog helfen.

Was ist der Unterschied zwischen einer Postman Collection und einer Umgebung?

Eine Collection enthält Requests und Tests. Eine Umgebung enthält Variablen wie base_url, auth_token oder client_id.

Kurz gesagt:

Collection = was gesendet wird
Environment = gegen welches Ziel und mit welchen Werten gesendet wird
Enter fullscreen mode Exit fullscreen mode

So können Sie dieselbe Collection gegen Staging, Produktion oder lokale Systeme ausführen.

Wie führe ich Postman-Tests automatisch in CI aus?

Verwenden Sie Newman:

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

Newman gibt einen Fehlercode zurück, wenn ein Test fehlschlägt. CI-Systeme wie GitHub Actions, GitLab CI oder Jenkins können diesen Exit-Code auswerten.

Kann Postman mehr als REST-APIs testen?

Ja. Postman unterstützt neben HTTP und REST auch GraphQL, gRPC, WebSocket und SOAP. Die genaue Konfiguration hängt vom Protokoll ab, aber das Prinzip bleibt gleich: Anfrage definieren, Antwort prüfen, Tests ergänzen.

Wie viele Assertions sollte eine Anfrage haben?

So viele wie nötig, aber nicht mehr. Eine sinnvolle Basis ist:

  • Statuscode
  • Antwortzeit
  • wichtige Header
  • relevante Felder im Body

Halten Sie jeden pm.test-Block möglichst fokussiert. Dadurch sehen Sie bei einem Fehler schneller, was genau gebrochen ist.

Top comments (0)