The API Testing Checklist I Use for Every Endpoint

Vor drei Jahren habe ich um 2 Uhr morgens zugesehen, wie eine Produktions-API spektakulär scheiterte, weil niemand getestet hatte, was passiert, wenn man ein Datumsfeld im Format "32/13/2021" sendet. Der Kaskadeneffekt war auf die schlimmste Art schön: 47.000 fehlgeschlagene Transaktionen, verärgerte Kunden, die die Supportkanäle überschwemmten, und ein CEO, der Antworten wollte, die ich nicht hatte. Diese Nacht hat für immer verändert, wie ich API-Tests angehe.

Ich bin Sarah Chen, und ich bin seit acht Jahren QA-Automatisierungsingenieurin, wobei sich die letzten fünf Jahre ausschließlich auf API-Tests für Fintech- und Gesundheitsplattformen konzentrierten. Ich habe alles getestet, von einfachen CRUD-Endpunkten bis hin zu komplexen Zahlungsabwicklungs-APIs, die täglich Millionen von Dollar bearbeiten. Was ich gelernt habe, ist dies: Die meisten API-Fehler sind keine exotischen Randfälle – sie sind vorhersehbare Probleme, die eine systematische Checkliste erfasst hätte.

Die Checkliste, die ich heute teile, ist genau die, die ich für jeden einzelnen Endpunkt verwende, den ich teste. Sie hat mein Team im letzten Jahr allein vor mindestens einem Dutzend Produktionsvorfällen gerettet und ist umfassend genug, dass Junior-Ingenieure ihr folgen können, während sie detailliert genug ist, um Probleme zu erfassen, die erfahrene Entwickler übersehen. Das ist keine Theorie – das ist ein bewährter Prozess, der durch Hunderte von API-Implementierungen verfeinert wurde.

Authentiifizierung und Autorisierung: Die Fundamentalschicht

Bevor ich irgendetwas anderes teste, überprüfe ich den Sicherheitsperimeter. Es geht nicht nur darum, zu prüfen, ob die Authentifizierung funktioniert – es geht darum, systematisch jedes Authentifizierungsszenario und jede Autorisierungsgrenze zu prüfen. Ich habe zu viele APIs gesehen, die mit gültigen Anmeldeinformationen perfekt funktionieren, aber katastrophal scheitern oder Daten leaken, wenn Anmeldeinformationen fehlen, fehlerhaft sind oder zu einem falschen Benutzer gehören.

Zuerst teste ich ohne Authentifizierungstoken. Der Endpunkt sollte einen Status von 401 Unauthorized zurückgeben, nicht einen 500 Internal Server Error und definitiv keine echten Daten. Ich habe Produktions-APIs gesehen, die vollständige Benutzerdaten zurückgaben, wenn kein Authentifizierungstoken bereitgestellt wurde, weil der Entwickler angenommen hatte, dass die Authentifizierungsmiddleware immer ausgeführt wird. Das tat sie nicht.

Als Nächstes teste ich mit einem abgelaufenen Token. Dies erfasst eine überraschende Anzahl von Problemen, da die Logik zur Tokenablauf häufig in einem anderen Teil des Codes als die ursprüngliche Authentifizierung lebt. Die Antwort sollte klar 401 mit einer Nachricht sein, die darauf hinweist, dass das Token abgelaufen ist, nicht ein allgemeines "unauthorized", das den Client raten lässt, ob er aktualisieren oder sich neu authentifizieren soll.

Dann teste ich mit einem fehlerhaften Token – zufällige Zeichenfolgen, Token mit entfernten Zeichen, Token von anderen Systemen. Die API sollte diese elegant behandeln, ohne Stack-Traces oder interne Fehlermeldungen offenzulegen. Ich habe einmal eine API gefunden, die den gesamten Dienst zum Absturz brachte, wenn ihr ein Token mit bestimmten Unicode-Zeichen gegeben wurde, weil die JWT-Parsing-Bibliothek die Kodierung nicht ordnungsgemäß behandelte.

Die Autorisierungstests sind der interessante Teil. Ich teste mit gültigen Tokens, die von Benutzern stammen, die keinen Zugang zur Ressource haben sollten. Für einen GET /users/123-Endpunkt werde ich mich als Benutzer 456 authentifizieren und versuchen, auf die Daten von 123 zuzugreifen. Die Antwort sollte 403 Forbidden sein, nicht 404 Not Found (was Informationen über die Existenz der Ressource leakt) und definitiv nicht 200 mit den Daten.

Ich teste auch die rollenbasierte Zugriffskontrolle systematisch. Wenn Ihre API administrative, Manager- und Benutzerrollen hat, teste ich jeden Endpunkt mit jeder Rolle. Ich führe eine Matrix-Spreadsheet: Zeilen sind Endpunkte, Spalten sind Rollen, Zellen enthalten die erwarteten Statuscodes. Das erfasst Berechtigungsfehler, bevor sie in die Produktion gelangen, wo sie zu Sicherheitsanfälligkeiten werden.

Anforderungsvalidierung: Grenzwerttests für Eingaben

Die Eingabevalidierung ist der Bereich, in dem die meisten APIs ihre wahre Qualität zeigen. Eine gut gestaltete API validiert jedes Eingabefeld gründlich und gibt klare, umsetzbare Fehlermeldungen zurück. Eine schlecht gestaltete akzeptiert entweder fehlerhafte Daten oder stürzt mysteriously ab.

"Die meisten API-Fehler sind keine exotischen Randfälle – sie sind vorhersehbare Probleme, die eine systematische Checkliste erfasst hätte."

Ich beginne mit Tests für erforderliche Felder. Für jedes erforderliche Feld sende ich eine Anfrage ohne dieses. Die API sollte 400 Bad Request mit einer Nachricht zurückgeben, die klar angibt, welches Feld fehlt. Ich habe APIs gesehen, die "Validierungsfehler" zurückgeben, ohne anzugeben, was fehlgeschlagen ist, was die Entwickler zwingt, zu raten, welches von 15 Feldern das Problem verursacht hat.

Dann teste ich die Validierung des Datentyps. Wenn ein Feld eine ganze Zahl erwartet, sende ich Zeichenfolgen, Floats, Booleans, null, Arrays und Objekte. Jedes sollte eine 400 mit einer klaren Nachricht wie "Alter muss eine ganze Zahl sein" zurückgeben, nicht "ungültiges Anfrageformat". Ich habe einmal eine E-Commerce-API getestet, bei der das Senden einer Zeichenfolge für die Menge das System dazu brachte, Bestellungen für null Artikel zu erstellen, was die gesamte Erfüllungspipeline brach.

Die Zeichenlängenvalidierung ist entscheidend und wird oft übersehen. Ich teste mit leeren Zeichenfolgen, einzelnen Zeichen, Zeichenfolgen an der maximalen Länge, Zeichenfolgen mit einem Zeichen über der maximalen Länge und absurd langen Zeichenfolgen (10.000+ Zeichen). Ich habe Produktionsdatenbanken zum Absturz gebracht, indem ich Megabyte große Zeichenfolgen an Felder sendete, die nicht ordnungsgemäß validiert wurden, was zu einem Speicherüberlauf führte.

Für numerische Felder teste ich Grenzwerte systematisch.