Gib ein Beispiel, wie du die Testfälle für eine PUT-Anfrage auswählen würdest.

Die Auswahl von Testfällen für PUT-Anfragen zielt darauf ab, die korrekte Aktualisierung der Ressource, die Verarbeitung verschiedener Datentypen und negative Szenarien zu überprüfen.

Beispiele für Testfälle:

1. Positives Szenario (erfolgreiche Aktualisierung):

   • Aktualisierung der Ressource mit allen gültigen Feldern.
   • Aktualisierung der Ressource nur mit einem Teil der gültigen Felder (wenn die API partielle Aktualisierungen erlaubt).
   • Aktualisierung der Felder mit verschiedenen Datentypen (Zeichenketten, Zahlen, boolesche Werte), falls im Schema vorgesehen.
   • Aktualisierung der Ressource mit minimal zulässigen Werten (falls zutreffend).
   • Aktualisierung der Ressource mit maximal zulässigen Werten (falls zutreffend).

2. Negative Szenarien (Fehler und Ausnahmen):

   • Versuch, eine nicht existierende Ressource zu aktualisieren. Erwartete Antwort: 404 Not Found.
   • Senden einer Anfrage ohne Body. Erwartete Antwort: 400 Bad Request oder 422 Unprocessable Entity.
   • Senden einer Anfrage mit ungültigem Body-Format (z.B. ungültiges JSON). Erwartete Antwort: 400 Bad Request.
   • Senden einer Anfrage mit ungültigen Datentypen für Felder. Zum Beispiel, String anstelle einer Zahl. Erwartete Antwort: 400 Bad Request oder 422 Unprocessable Entity.
   • Senden einer Anfrage mit fehlenden Pflichtfeldern im Body. Erwartete Antwort: 400 Bad Request oder 422 Unprocessable Entity.
   • Senden einer Anfrage mit Feldern, die die zulässige Länge oder den Bereich überschreiten. Erwartete Antwort: 400 Bad Request oder 422 Unprocessable Entity.
   • Senden einer Anfrage mit ungültigem Wert im Pfad (z.B. ungültige ID). Erwartete Antwort: 400 Bad Request oder 404 Not Found.
   • Versuch, eine gesperrte oder nicht zugängliche Ressource zu aktualisieren (falls zutreffend). Erwartete Antwort: 403 Forbidden oder 409 Conflict.
   • Senden einer Anfrage mit falschen Headern (z.B. Content-Type). Erwartete Antwort: 415 Unsupported Media Type oder 400 Bad Request.
   • Aktualisierung mit Sonderzeichen oder Emojis in Textfeldern.

3. Grenzwerte:

   • Aktualisierung von Feldern mit Grenzwerten (z.B. minimale/maximale Daten, Grenzwerte bei Zahlen).
   • Aktualisierung von Feldern mit leeren Strings oder null-Werten (falls zulässig).

4. Parallelzugriffs-Szenarien:

   • Gleichzeitiger Versuch, dieselbe Ressource aus mehreren Quellen zu aktualisieren (falls relevant für das getestete System).

5. Überprüfung der Aktualisierungsfolgen:

   • Überprüfung, ob die Daten korrekt in der Datenbank oder anderen Systemen aktualisiert wurden.
   • Überprüfung, ob abhängige Ressourcen oder Daten entsprechend aktualisiert/geändert wurden (bei Abhängigkeiten).
   • Überprüfung, ob eine GET-Anfrage an die aktualisierte Ressource die aktuellen Daten zurückgibt.
   • Überprüfung, ob andere Operationen (DELETE, POST) mit der aktualisierten Ressource korrekt funktionieren.

Kriterien für die Auswahl spezifischer Testfälle hängen von der API-Spezifikation, den Geschäftsanforderungen, der Risikoanalyse und den Prioritäten ab. Es werden Testdesign-Techniken wie Äquivalenzpartitionierung und Grenzwerkanalyse verwendet, um die aussagekräftigsten Eingabemöglichkeiten zu bestimmen.