Was ist API Testing?

Was ist API Testing?

API Testing ist die Praxis, ein HTTP-, REST-, GraphQL- oder gRPC-Interface direkt gegen seine Spezifikation zu validieren: Vertragsform, Status Codes, Response Payloads, Authentifizierung, Autorisierung, Error Handling, Rate Limits und Performance unter Last. Die Tests überspringen die UI komplett und üben den Endpoint so aus, wie es ein anderer Service tun würde.

Weil die API normalerweise der Integrationspunkt zwischen Services ist (und die Surface, gegen die ein öffentliches SDK baut), fangen API Tests Brüche, die UI Tests verpassen: Schema-Drift, stille rückwärts-inkompatible Änderungen, kaputte Auth-Flows und Vertragsverletzungen, die erst scheitern, wenn ein Downstream-Konsument die Response parst.

API Testing vs UI Testing

Beide validieren das System; sie leben auf unterschiedlichen Schichten.

• UI Testing treibt einen Browser durch einen Flow (Login, Suche, Checkout) und assertet auf sichtbaren Elementen. Langsam (Sekunden pro Assertion), flaky (Network, Animation-Timing, Headless-Quirks), teuer zu warten.
• API Testing sendet HTTP Requests direkt und assertet auf Status, Headers, Body. Schnell (zehntel Millisekunden pro Assertion), deterministisch (keine Rendering-Surface), billig zu warten. Deckt Vertrag- und Integrations-Belange ab, die die UI nicht erreichen kann.

Die pragmatische Aufteilung: 80% der Testabdeckung auf API-Schicht, 20% auf UI-Schicht für die paar Flows, die Benutzer tatsächlich end-to-end sehen. Diese Ratio umzukehren ist die häufigste Ursache für langsame, flaky CI-Pipelines.

Was API Tests abdecken

• Vertragsvalidierung. Response-Schema matched die OpenAPI- / GraphQL- / protobuf-Spec. Feldtypen, Pflichtfelder, Enum-Werte. Brüche im Moment des Auslieferns fangen.
• Status Codes. 2xx bei Erfolg, korrektes 4xx bei schlechtem Input (400 vs 401 vs 403 vs 404 vs 422), 5xx erscheint nur bei echten Server-Fehlern.
• Authentifizierung und Autorisierung. Unauthentifizierte Requests geben 401. Authentifizierte Requests vom falschen Tenant geben 403. Tokens laufen wie beworben ab.
• Edge Cases. Leere Arrays, null-Felder, Max-Length-Strings, malformatiertes JSON, fehlende erforderliche Headers, übergroße Payloads.
• Idempotenz. POST- / PUT-Requests mit einem Idempotency Key zweimal angewendet produzieren einen einzigen Side Effect.
• Rate Limits und Quotas. 429 bei dokumentierter Schwelle mit korrektem Retry-After zurückgegeben.
• Performance. p95-Latenz unter SLO bei erwarteter Last. Siehe Load Testing für die Messung.

Wann API Tests ausführen

1. Bei jedem PR. Teil der Regression Suite. Funktionale und Vertrags-Checks laufen in Sekunden.
2. Post-Deploy-Smoke. Eine Handvoll Critical-Endpoint-Checks nach jedem Deploy, um zu bestätigen, dass die Live-API korrekt antwortet. Siehe Smoke Testing.
3. Performance-Regression. Führen Sie einen Load Test gegen die API bei erwartetem Peak vor jedem Release aus. Asserten Sie, dass p95 + Fehlerrate nicht regressiert sind.
4. Pre-Launch-Kapazitäts-Sizing. Führen Sie Capacity Testing und Spike Testing gegen die API aus, um die Obergrenze zu kennen, bevor Traffic ankommt.

Wichtige API-Testing-Tools

• Postman / Insomnia. Interaktive Request-Builder mit Collection-Runner-Support. Gut für Exploration; Collections können in CI laufen.
• REST-assured (Java), supertest (Node), pytest+requests (Python). Code-first API Tests, die neben dem Applikations-Code leben. Der Default für Regression Suites.
• Schemathesis, Dredd. Generieren Testfälle automatisch aus einer OpenAPI- / GraphQL-Spec. Fangen Schema-Drift, für den Sie keine Tests geschrieben haben.
• JMeter und k6. Performance-seitiges API Testing. Beide unterstützen HTTP, JSON- / XML-Assertions, Custom Headers, Auth-Flows. k6 hat First-Class GraphQL via JS; JMeter handhabt SOAP, JDBC, MQTT für Nicht-REST-APIs.

Wie API-Performance-Tests ausführen

Ein funktionaler API Test bestätigt, dass der Endpoint die richtige Shape bei niedriger Last zurückgibt. Ein Performance-API-Test bestätigt, dass er das bei Produktions-Last immer noch tut. Beides ist wichtig; das zweite fängt das Leck, das die API am Launch Day herunterbringt.

In k6 definieren Sie Ihren Endpoint-Flow in JavaScript, fügen check()-Assertions auf jeder Response hinzu und konfigurieren ein ramping-vus-Szenario auf erwarteten Peak. In JMeter verwenden Sie einen HTTP Request Sampler mit JSON Path / Response Assertions und eine Thread Group passend zur erwarteten Concurrency.

Führen Sie von LoadFocus aus für Traffic aus mehreren Cloud-Regionen, der die API gleichzeitig trifft. Echte API-Konsumenten sind geo-verteilt; Single-Origin-Load-Tests verfehlen DNS-, regionales Gateway- und Edge-Cache-Verhalten, das Produktion trifft.

Wenn Sie die Skripte nicht selbst schreiben möchten, bietet LoadFocus Load Testing Services, wo Ingenieure API-Szenarien aus Ihrer OpenAPI-Spec designen, sie skaliert ausführen und eine Analyse mit Latenz-pro-Endpoint- und Fehlerrate-pro-Endpoint-Aufschlüsselungen liefern.