Fornisci un esempio di come sceglieresti i casi di test per una richiesta PUT.

La selezione dei casi di test per le richieste PUT mira a verificare l'aggiornamento corretto della risorsa, la gestione di diversi tipi di dati e scenari negativi.

Esempi di casi di test:

1. Scenario positivo (aggiornamento riuscito):

   • Aggiornamento della risorsa con tutti i campi validi.
   • Aggiornamento della risorsa solo con una parte dei campi validi (se l’API consente aggiornamenti parziali).
   • Aggiornamento dei campi con diversi tipi di dati (stringhe, numeri, valori booleani), se previsto nello schema.
   • Aggiornamento della risorsa con valori minimi consentiti (se applicabile).
   • Aggiornamento della risorsa con valori massimi consentiti (se applicabile).

2. Scenari negativi (errori ed eccezioni):

   • Tentativo di aggiornare una risorsa inesistente. Risposta attesa: 404 Not Found.
   • Invio di richiesta senza corpo. Risposta attesa: 400 Bad Request o 422 Unprocessable Entity.
   • Invio di richiesta con formato del corpo non valido (ad esempio, JSON non valido). Risposta attesa: 400 Bad Request.
   • Invio di richiesta con tipi di dati non validi per i campi. Ad esempio, stringa invece di numero. Risposta attesa: 400 Bad Request o 422 Unprocessable Entity.
   • Invio di richiesta con campi obbligatori omessi nel corpo. Risposta attesa: 400 Bad Request o 422 Unprocessable Entity.
   • Invio di richiesta con campi che superano la lunghezza o il range consentito. Risposta attesa: 400 Bad Request o 422 Unprocessable Entity.
   • Invio di richiesta con valore non valido nel percorso (ad esempio, ID non valido). Risposta attesa: 400 Bad Request o 404 Not Found.
   • Tentativo di aggiornare una risorsa bloccata o non accessibile (se applicabile). Risposta attesa: 403 Forbidden o 409 Conflict.
   • Invio di richiesta con intestazioni errate (ad esempio, Content-Type). Risposta attesa: 415 Unsupported Media Type o 400 Bad Request.
   • Aggiornamento con caratteri speciali o emoji nei campi di testo.

3. Condizioni limite:

   • Aggiornamento di campi con valori limite (ad esempio, data minima/massima, numeri limite).
   • Aggiornamento di campi con stringhe vuote o valori null (se consentito).

4. Scenari di accesso parallelo:

   • Tentativo simultaneo di aggiornare la stessa risorsa da più fonti (se pertinente per il sistema testato).

5. Verifica delle conseguenze dell’aggiornamento:

   • Verifica che i dati siano stati aggiornati correttamente nel database o in altri sistemi.
   • Verifica che le risorse o i dati dipendenti siano stati aggiornati/modificati di conseguenza (se ci sono dipendenze).
   • Verifica che una richiesta GET alla risorsa aggiornata restituisca dati aggiornati.
   • Verifica che altre operazioni (DELETE, POST) con la risorsa aggiornata funzionino correttamente.

I criteri di selezione di casi di test specifici dipendono dalla specifica API, dai requisiti di business, dall’analisi dei rischi e dalle priorità. Tecniche di progettazione dei test, come la partizione equivalente e l’analisi dei limiti, sono utilizzate per determinare le opzioni di input più rappresentative.