Negative API-Tests

Positive Prüfungen zeigen, dass eine API erwartete Szenarien verarbeitet. Negative Prüfungen zeigen ihre Robustheit gegenüber ungültigen, unerwarteten und gefährlichen Eingaben. Für QA ist das besonders wertvoll, weil dabei oft Schwächen in Validierung, Fehlerbehandlung, Sicherheit und Dienststabilität sichtbar werden.

Benutzer und Integrationen verhalten sich selten perfekt. Sie senden leere Felder, falsche Datentypen, abgelaufene Token oder zu große Nutzlasten oder rufen Endpunkte in ungültigen Zuständen auf. Eine gute API muss vorhersehbar und sicher reagieren, nicht nur einen Absturz vermeiden.

Was negative API-Tests bedeuten

Negative API-Tests untersuchen das Systemverhalten bei ungültigen, unerwarteten, verbotenen oder widersprüchlichen Eingaben.

Sie umfassen deutlich mehr als das Senden eines leeren Feldes:

→Fehlende Pflichtfelder
→Falsch formatierte Werte
→Unpassende Datentypen
→Werte außerhalb des zulässigen Bereichs
→Feldkombinationen, die Geschäftsregeln verletzen
→Nicht authentifizierte oder nicht berechtigte Benutzer
→Zu große Nutzlasten
→Unerwarteter Content-Type
→Methoden, die an diesem Endpunkt nicht unterstützt werden sollten
→Wiederholte Anfragen, die Konflikte erzeugen

Negative Tests prüfen daher sowohl die Korrektheit der Eingaben als auch die Widerstandsfähigkeit der API gegen Fehlgebrauch.

Warum das für APIs besonders wichtig ist

Eine UI bietet durch Formulare, Eingabemasken, Auswahllisten und deaktivierte Schaltflächen einen gewissen Schutz. APIs haben diese Schicht nicht in gleicher Weise. Sie erhalten direkte Anfragen und müssen entscheiden, wie sie damit umgehen.

Unzureichende negative API-Tests hinterlassen typischerweise drei Risiken:

→Der Dienst versagt bei fehlerhaften Eingaben.
→Der Dienst verhält sich unvorhersehbar.
→Der Dienst akzeptiert etwas, das er ablehnen sollte.

Wer nur den Erfolgsfall testet, sieht nur einen kleinen Teil des tatsächlichen Systemverhaltens.

Was gezielt herausgefordert werden sollte

Gute negative Tests orientieren sich an Eingabeklassen statt an willkürlichen Versuchen, unsinnige Daten einzugeben.

Diese Gruppen regelmäßig testen:

→Ein Pflichtfeld fehlt.
→Ein Feld ist vorhanden, aber leer.
→Ein Feld ist vorhanden, aber null.
→Der Datentyp ist falsch: eine Zeichenkette statt einer Zahl oder ein Objekt statt eines Arrays.
→Eine Zeichenkette überschreitet die maximale Länge.
→Eine Zahl liegt unter dem Minimum oder über dem Maximum.
→Ein Datum, eine E-Mail-Adresse, Telefonnummer, UUID oder ein Enum-Wert hat ein ungültiges Format.
→Parameter bilden eine ungültige Kombination.
→Unerwartete zusätzliche Felder sind enthalten.
→Die Anfragemethode ist falsch.
→Content-Type ist falsch.
→Das Token ist beschädigt oder abgelaufen.
→Die Anfrage zielt auf die Ressource eines anderen Benutzers.
→Der Anfragenkörper ist zu groß.
→Die Anfrage wird in einem widersprüchlichen Zustand wiederholt.

Ein systematisches Vorgehen macht daraus ein wiederholbares Modell der API-Qualität statt chaotischer Versuche, etwas zu beschädigen.

Was einen guten negativen Test ausmacht

Ein schwacher negativer Test prüft nur, ob ein Fehler auftrat. Ein starker untersucht wesentlich mehr.

→Ist der Statuscode korrekt?
→Ist der Fehler für den Client verständlich?
→Gibt die Antwort unnötige interne Details preis?
→Wurden Daten geändert, obwohl sie unverändert bleiben sollten?
→Gab es Nebenwirkungen?
→Führt dieselbe ungültige Anfrage bei Wiederholung zu konsistentem Verhalten?
→Vermeidet der Dienst einen 500-Fehler bei einem clientseitigen Problem?

Ungültiges JSON rechtfertigt beispielsweise in der Regel 400 statt 500. Der Versuch, die Ressource eines anderen Benutzers zu ändern, verlangt üblicherweise 403 oder 404 statt Erfolg. Ein zu großer Nachrichtenkörper kann 413 rechtfertigen. Ziel ist eine konsistente, verständliche Behandlung, nicht das Erraten eines idealen Codes für jeden Fall.

Was neben dem Fehler geprüft werden sollte

Eine gute Gewohnheit ist, nach einer erfolglosen Anfrage immer den Systemzustand zu prüfen.

→Wurde tatsächlich kein Datensatz angelegt?
→Blieb der Objektstatus unverändert?
→Wurde kein Geld abgebucht?
→Wurde keine E-Mail gesendet?
→Haben Auditierung und Protokollierung das Ereignis korrekt erfasst?
→Blieb das System nach einer Wiederholung der Anfrage in einem gültigen Zustand?

Hier verbergen sich viele gefährliche Fehler. Die API liefert nach außen einen Fehler, hat intern aber bereits einen Teil der Daten geändert. Benutzer sehen die Folgen später vielleicht als scheinbar zufälligen Fehler, obwohl die Ursache eine mangelhafte Behandlung negativer Szenarien war.

Praktisches Beispiel

Betrachten wir einen Endpunkt zum Anlegen von Benutzern.

Der positive Fall ist einfach: gültige E-Mail-Adresse, Namen und Passwort senden und 201 Created erhalten.

Nun die negativen Szenarien betrachten:

→Die E-Mail-Adresse fehlt.
→Die E-Mail-Adresse ist leer.
→Die E-Mail-Adresse ist ungültig.
→Das Passwort ist zu kurz.
→Ein Feld im Nachrichtenkörper hat einen unerwarteten Datentyp.
→Erforderliche Autorisierung fehlt.
→Dieselbe E-Mail-Adresse wird erneut registriert.
→Der Nachrichtenkörper ist zu groß.
→Content-Type ist nicht application/json.

QA sollte überprüfen, dass:

→Der Server vorhersehbar antwortet.
→Der Fehler für den Client ausreichend klar ist.
→Der Statuscode zur Problemklasse passt.
→Kein ungültiger Datensatz angelegt wird.
→Keine unbeabsichtigten Nebenwirkungen auftreten.
→Dieselbe ungültige Anfrage bei Wiederholung das System nicht weiter beschädigt.

Damit werden negative Tests zu einer fundierten Bewertung der API-Reife statt zu einer optionalen Ergänzung.

Wichtige Erkenntnisse für QA-Engineers

→Negative API-Tests untersuchen neben Eingabefehlern auch die Robustheit.
→Ein guter negativer Test prüft Fehlercode und anschließenden Systemzustand.
→Eine robuste API behandelt fehlerhafte Anfragen sicher und vorhersehbar.
→Der Erfolgsfall allein belegt fast nie die tatsächliche Zuverlässigkeit eines Dienstes.
→Negative Prüfungen nach Risikoklassen aufbauen statt nach zufälligen Versuchen, etwas zu beschädigen.

Weiterführende Informationen

→In dieser Wissensbasis: Methoden, Statuscodes und Header
→In dieser Wissensbasis: Authentifizierung und Autorisierung
→Externe Ressource: OWASP REST Security Cheat Sheet

Eine lokale Negativtestmatrix mit Prüfung der Nebenwirkungen

Einen synthetischen lokalen Vertrag verwenden, statt zu raten, was jede API zurückgeben sollte. Die vorbereitete Übungs-Fixture akzeptiert POST /items mit einem Administrator-Schulungstoken, Content-Type application/json, einem Namen aus 3–12 ASCII-Buchstaben und einer ganzzahligen quantity von 1 bis 5. Der Nachrichtenkörper muss genau diese beiden Felder enthalten. Die Daten bleiben im Arbeitsspeicher; für jeden unabhängigen Test einen neuen Server starten.

plain text

Testfall	Beispiel	In dieser Test-Fixture erwartet
Fehlendes Feld	{"name":"abc"}	422 invalid_fields
Falscher Datentyp	{"name":"abc","quantity":"1"}	422 invalid_quantity
Außerhalb des Wertebereichs	{"name":"abc","quantity":6}	422 invalid_quantity
Zusätzliches Feld	{"name":"abc","quantity":1,"admin":true}	422 invalid_fields
Fehlerhaftes JSON	{	400 malformed_json
Falscher Medientyp	Content-Type: text/plain	415 json_required
Nachrichtenkörper über 1024 Bytes	Nachrichtenkörper mit 1025 Bytes	413 payload_too_large

Vor jeder abgelehnten Schreiboperation GET /items ausführen und total erfassen; danach wiederholen und einen unveränderten Gesamtwert verlangen. So wird eine Implementierung erkannt, die erst einen Datensatz schreibt und dann einen Fehler zurückgibt. Bei einem akzeptierten neuen Namen 201 und total + 1 erwarten; erneutes Absenden liefert 409 ohne zweiten Eintrag. Diese Statuscodes beschreiben den hier festgelegten Vertrag, keine für alle Produkte verbindliche Regel.

plain text

python3 mock_api.py --port 8765
# In another terminal, using only the synthetic local token:
curl -i http://127.0.0.1:8765/items -H "Authorization: Bearer demo-admin" -H "Content-Type: application/json" --data '{"name":"abc","quantity":6}'
python3 -m unittest test_mock_api.py -v

Die Test-Fixture ist bewusst lokal und vereinfacht. Sie dient zum Üben der Eingabeauswahl und Nachweissammlung; ihre festen Token oder ihren HTTP-Server nicht in ein produktives Authentifizierungssystem übernehmen.

Weiterlernen

Lokales Übungslabor herunterladen (ZIP)

Autorisierung getrennt prüfen

Grenzwerte ableiten