Was ist API Testing?

Was ist API Testing?

API Testing bedeutet, Anfragen direkt an eine API zu senden und die Antwort mit dem zu vergleichen, was die Spezifikation verspricht: Statuscode, Header, Aufbau der Payload, Authentifizierung, Fehlerbehandlung und Antwortzeit. Ein Browser oder eine Oberfläche ist nicht beteiligt. Der Test ruft den Endpunkt so auf, wie es ein anderer Dienst oder ein SDK tun würde, und findet Vertragsbrüche, bevor ein Konsument sie bemerkt.

So funktioniert API Testing

Ein Test besteht aus einer Anfrage und Prüfungen (Assertions). Du wählst einen Endpunkt, setzt Methode, Header, Auth und Body, sendest ab und prüfst die Antwort. Verkette Anfragen, wenn ein Aufruf vom anderen abhängt (Bestellung anlegen, dann mit der zurückgegebenen ID abrufen).

POST /orders
Authorization: Bearer <token>
{"sku": "A-100", "qty": 2}

assert status == 201
assert body.id ist ein String
assert body.qty == 2
assert Antwortzeit < 300 ms

Dieselben Prüfungen laufen bei jedem Pull Request im Test-Runner, ein reduzierter Satz läuft zeitgesteuert gegen die Live-API.

Was API-Tests abdecken

• Vertrag. Feldnamen, Typen und Pflichtfelder entsprechen dem OpenAPI- oder GraphQL-Schema.
• Statuscodes. 2xx bei Erfolg, der passende 4xx bei ungültiger Eingabe (400, 401, 403, 404, 422), 5xx nur bei echten Serverfehlern.
• Authentifizierung und Autorisierung. Ohne Token kommt 401, mit dem Token eines anderen Mandanten 403, abgelaufene Tokens werden abgewiesen.
• Randfälle. Leere Arrays, Nullwerte, Maximallängen, fehlerhaftes JSON, fehlende Header, übergroße Bodys.
• Rate Limits. Ein 429 an der dokumentierten Schwelle, mit sinnvollem Retry-After.
• Performance. Latenz und Fehlerrate bei der erwarteten Last. Siehe API-Performance-Metriken.

API Testing vs. UI-Testing

UI-Tests steuern einen Browser durch einen Ablauf und prüfen, was sichtbar ist. Sie sind langsam und brechen bei Layout-Änderungen. API-Tests prüfen die Antworten direkt, laufen in Millisekunden und scheitern aus genau einem Grund. Die meisten Teams legen den Großteil der Prüfungen auf die API-Ebene und halten wenige UI-Tests für die Wege, die Nutzer wirklich gehen. Beide gehören in die Regressionstests.

Arten von API-Tests

• Funktions- und Vertragstests prüfen die Korrektheit gegen die Spezifikation.
• Integrationstests prüfen das Zusammenspiel von Diensten, oft gegen einen Stub aus API-Mocking, wenn eine Abhängigkeit fehlt.
• Sicherheitstests prüfen Auth, Injection und zu viel preisgegebene Daten.
• Smoke-Tests rufen nach einem Deployment wenige kritische Endpunkte auf. Siehe den Smoke-Testing-Leitfaden (englisch).
• Lasttests prüfen Tempo und Fehler bei gleichzeitigem Traffic. Siehe Load Testing.
• Monitoring wiederholt Prüfungen zeitgesteuert in Produktion. Siehe API-Monitoring.

Häufige Fehler

• Nur den Statuscode prüfen. Ein 200 mit falschem Body ist trotzdem ein Fehler.
• Nur den Idealfall testen und Auth-Fehler sowie ungültige Eingaben auslassen.
• Veränderliche Testdaten zwischen Tests teilen, sodass die Reihenfolge das Ergebnis ändert.
• Tokens und URLs fest eincodieren statt Variablen je Umgebung zu nutzen.
• Performance-Prüfungen von einem Rechner direkt neben dem Server fahren, was Netzwerk- und Regionseffekte verbirgt.
• Nie gegen Produktion prüfen, sodass ein Deployment, das in Staging läuft, unbemerkt ausfällt.

Tools und wo LoadFocus passt

Code-basierte Runner (pytest mit requests, supertest, REST-assured) eignen sich für Regressionssuiten. Postman und ähnliche Clients eignen sich zum Erkunden. Spezifikationsgetriebene Tools wie Schemathesis erzeugen Testfälle aus einer OpenAPI-Datei.

• curl online sendet eine einzelne Anfrage von LoadFocus-Servern und zeigt Status, Header, Body und eine Zeitaufschlüsselung. Es ist eine Einzelprüfung, Weiterleitungen werden gemeldet statt verfolgt.
• Der API Status Checker prüft eine öffentliche URL gleichzeitig aus 6 AWS-Regionen. Er liefert eine Momentaufnahme, ohne Zeitplan, Verlauf oder Alarme.
• API-Monitoring führt Prüfungen zeitgesteuert aus und prüft Statuscodes, Response-Bodys, Header und Antwortzeit, mit Alarmen per E-Mail, Slack, Microsoft Teams und weiteren Kanälen. Der kostenlose Plan prüft alle 5 Minuten, bezahlte Pläne häufiger.
• OpenAPI zu k6 wandelt eine OpenAPI- oder Swagger-Spezifikation im Browser in ein k6-Skript um. Du kannst es auf der Load-Testing-Plattform ausführen, die JMeter und k6 aus 25 Cloud-Regionen betreibt.

Was browserbasierte Tester können und was nicht, steht im Leitfaden zum Online-API-Tester (englisch).

Häufige Fragen: API Testing

Ist API Testing dasselbe wie Unit-Testing?

Nein. Ein Unit-Test prüft eine einzelne Funktion isoliert. Ein API-Test ruft den laufenden Dienst per HTTP auf und prüft den Vertrag, den er anbietet. Dabei werden auch Routing, Auth, Serialisierung und oft die Datenbank mitgeprüft.

Muss ich programmieren können, um APIs zu testen?

Zum Einstieg nicht. Ein Client wie curl oder ein Request-Builder reicht, um Anfragen zu senden und Antworten zu lesen. Beim Automatisieren in der CI kommen Code oder eine Konfigurationsdatei ins Spiel.

Wie oft sollten API-Tests laufen?

Funktions- und Vertragsprüfungen bei jedem Pull Request, einige kritische Prüfungen nach jedem Deployment und eine zeitgesteuerte Auswahl in Produktion, damit du Ausfälle vor deinen Nutzern bemerkst.

Was ist der Unterschied zwischen API Testing und API-Monitoring?

Testing läuft vor dem Release und sucht Fehler. Monitoring wiederholt Prüfungen zeitgesteuert gegen die Live-API und alarmiert dich, wenn etwas ausfällt oder langsamer wird.