{ freetool24 }
Developer Tools

API-Testing-Leitfaden: Von den Grundlagen bis zu automatisierten Workflows

Lerne, wie du REST APIs effektiv testest – von manuellen Tests mit HTTP-Clients bis hin zu automatisierten Test-Suites, Status-Codes und Authentifizierungsstrategien.

8 Min. Lesezeit

Entwickler überprüft API-Dokumentation auf dem Bildschirm

APIs sind die Verträge zwischen Softwaresystemen. Wenn eine API ausfällt, bricht alles zusammen, was davon abhängt. Dennoch wird API-Testing oft als nachrangig behandelt – etwas, das man kurz vor dem Deployment schnell im Browser-Tab erledigt. Eine durchdachte API-Teststrategie erkennt Fehler frühzeitig, dokumentiert das erwartete Verhalten und gibt dir die Sicherheit, deine Software auszuliefern.

Was ist ein API-Test?

Ein API-Test sendet eine HTTP-Anfrage und prüft bestimmte Eigenschaften der Antwort:

  • Status-Code – Erhalten wir 200 OK oder 404 Not Found?
  • Response-Body – Stimmt die Datenstruktur? Sind die Werte korrekt?
  • Header – Ist Content-Type richtig gesetzt? Ist der Auth-Header vorhanden?
  • Antwortzeit – Antwortet der Endpoint innerhalb eines akzeptablen Zeitrahmens?
  • Fehlerbehandlung – Was passiert bei ungültigen Eingaben? Erhalten wir aussagekräftige Fehlermeldungen?

HTTP-Status-Codes, die du kennen musst

Code Bedeutung Wann du ihn siehst
200 OK Erfolgreiche GET-, PUT-, PATCH-Anfragen
201 Created Erfolgreicher POST, der eine Ressource erstellt
204 No Content Erfolgreicher DELETE oder eine Aktion ohne Body
400 Bad Request Ungültige Eingabe, fehlerhaftes JSON, fehlende Felder
401 Unauthorized Fehlender oder ungültiger Authentifizierungs-Token
403 Forbidden Authentifiziert, aber nicht autorisiert
404 Not Found Ressource existiert nicht
409 Conflict Doppelte Ressource, Versionskonflikt
422 Unprocessable Entity Validierungsfehler bei gültigem JSON
429 Too Many Requests Rate-Limit überschritten
500 Internal Server Error Fehler auf der Serverseite
503 Service Unavailable Server nicht verfügbar oder überlastet

401 bedeutet „Wer bist du?" – 403 bedeutet „Ich weiß, wer du bist, aber das ist dir nicht erlaubt."

Manuelles Testen mit dem API Request Builder

Bevor du mit der Automatisierung beginnst, solltest du deine Endpoints manuell verstehen. Unser API Request Builder ermöglicht dir:

  • Die HTTP-Methode festlegen (GET, POST, PUT, PATCH, DELETE)
  • Header hinzufügen (Authorization, Content-Type, benutzerdefinierte Header)
  • Query-Parameter ohne manuelles URL-Encoding aufbauen
  • Einen JSON-Request-Body mit Syntax-Highlighting schreiben
  • Die vollständige Antwort inklusive Header und Zeitangaben einsehen

Das ist ideal, um eine neue API zu erkunden, einen bestimmten Endpoint zu debuggen oder einen Fix schnell zu überprüfen.

REST APIs testen: der vollständige CRUD-Zyklus

Für eine hypothetische /users-API umfasst eine vollständige Test-Suite Folgendes:

Erstellen (POST)

POST /users
Content-Type: application/json

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor"
}

Prüfen:

  • Status 201 Created
  • Response-Body enthält den erstellten Benutzer mit einer generierten id
  • Location-Header verweist auf die neue Ressource (z. B. /users/42)

Lesen (GET)

GET /users/42
Authorization: Bearer <token>

Prüfen:

  • Status 200 OK
  • Body stimmt mit dem erstellten Benutzer überein
  • id ist 42

Aktualisieren (PUT / PATCH)

PATCH /users/42
Content-Type: application/json

{ "role": "admin" }

Prüfen:

  • Status 200 OK
  • role ist in der Antwort nun "admin"
  • Andere Felder unverändert

Löschen (DELETE)

DELETE /users/42
Authorization: Bearer <token>

Prüfen:

  • Status 204 No Content
  • Nachfolgender GET /users/42 gibt 404 zurück

Negativtests: die Tests, die die meisten überspringen

Positive Tests prüfen den Erfolgspfad. Negativtests prüfen, ob die API fehlerhafte Eingaben zuverlässig behandelt:

  • Fehlende Pflichtfelder → 400 mit klarer Fehlermeldung
  • Ungültige Datentypen ("age": "twenty") → 400
  • Nicht vorhandene Ressource (GET /users/99999) → 404
  • Abgelaufener Token → 401
  • Zugriff auf die Daten eines anderen Benutzers → 403
  • Senden eines 10 MB großen Payloads → 413 Payload Too Large
  • Rate-Limit überschreiten → 429 mit Retry-After-Header

Eine gut gestaltete API schlägt vorhersehbar und informativ fehl.

Testmuster für Authentifizierung

Bearer Tokens (JWT)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Testszenarien:

  • Gültiger Token → korrekte Antwort
  • Abgelaufener Token → 401 mit der Meldung "Token expired"
  • Manipulierter Token (ein Zeichen ändern) → 401
  • Fehlender Header → 401
  • Token für eine andere Umgebung → 401

Verwende unseren JWT Decoder, um Tokens zu inspizieren und Ablaufzeiten beim manuellen Testen zu prüfen.

API-Keys

X-API-Key: sk_live_abc123

Testen: falscher Key, fehlender Key, Key mit unzureichenden Berechtigungen.

OAuth 2.0 Flows

OAuth erhöht die Komplexität – teste die Token-Exchange-Endpoints getrennt von den Ressourcen-Endpoints.

Response-Bodies validieren

Prüfe nicht nur Status-Codes. Validiere die Struktur der Antworten:

// Using Jest + supertest
test("GET /users/:id returns the correct user", async () => {
  const response = await request(app).get("/users/42").set("Authorization", `Bearer ${token}`);

  expect(response.status).toBe(200);
  expect(response.headers["content-type"]).toMatch(/json/);
  expect(response.body).toMatchObject({
    id: 42,
    name: expect.any(String),
    email: expect.stringMatching(/^[^\s@]+@[^\s@]+\.[^\s@]+$/),
    role: expect.oneOf(["admin", "editor", "viewer"]),
  });
});

Für größere Response-Schemas nutze die JSON-Schema-Validierung mit unserem JSON Schema Validator, um die erwartete Struktur einmalig zu definieren und alle Endpoints dagegen zu testen.

Contract Testing

In Microservices stellt Contract Testing sicher, dass Consumer und Provider sich auf die Form der API einigen. Der Consumer definiert, was er benötigt; der Provider überprüft, ob er das erfüllt. Tools wie Pact automatisieren diesen Prozess.

Das ist besonders wertvoll, wenn Teams unterschiedliche Services verantworten – ein Contract Test schlägt sofort fehl, wenn ein Feld umbenannt oder entfernt wird, noch vor der Integration.

Performance- und Lasttests

Funktionale Tests sagen dir, ob die API funktioniert. Performance-Tests sagen dir, wie gut sie unter Last funktioniert:

  • Baseline – Wie sind die p50/p95/p99-Antwortzeiten bei einem einzelnen Benutzer?
  • Lasttest – Wie verhält sie sich beim erwarteten Spitzenverkehr?
  • Stresstest – Ab wann beginnt sie zu versagen?
  • Spike-Test – Was passiert bei einem plötzlichen 10-fachen Anstieg des Traffics?

Ein gängiges Ziel: < 200ms für p95 beim erwarteten Spitzenverkehr.

API-Testing-Checkliste

  • Alle CRUD-Operationen für jede Ressource testen
  • Negativfälle testen: ungültige Eingaben, fehlende Authentifizierung, nicht gefundene Ressourcen
  • Response-Bodies gegen ein Schema validieren (nicht nur Status-Codes)
  • Authentifizierungs-Grenzfälle testen: abgelaufene, fehlende, manipulierte Tokens
  • Sicherstellen, dass Fehlerantworten hilfreiche Meldungen enthalten
  • Prüfen, ob Paginierung, Filterung und Sortierung korrekt funktionieren
  • Verhalten beim Rate-Limiting testen
  • Sicherstellen, dass keine sensiblen Daten in Fehlerantworten erscheinen
  • Antwortzeit unter erwartetem Last prüfen

Gute API-Tests sind dein Sicherheitsnetz beim Refactoring und die beste Dokumentation, die du haben kannst – sie zeigen exakt, was jeder Endpoint tut und was er erwartet.

Zurück zu allen ArtikelnTools durchsuchen