Donne un exemple de comment tu choisirais les cas de test pour une requête PUT.

La sélection des cas de test pour les requêtes PUT vise à vérifier la mise à jour correcte de la ressource, la gestion des différents types de données et les scénarios négatifs.

Exemples de cas de test :

1. Scénario positif (mise à jour réussie) :

   • Mise à jour de la ressource avec tous les champs valides.
   • Mise à jour de la ressource avec seulement une partie des champs valides (si l’API permet la mise à jour partielle).
   • Mise à jour des champs avec différents types de données (chaînes, nombres, valeurs booléennes), si cela est prévu dans le schéma.
   • Mise à jour de la ressource avec des valeurs minimales autorisées (si applicable).
   • Mise à jour de la ressource avec des valeurs maximales autorisées (si applicable).

2. Scénarios négatifs (erreurs et exceptions) :

   • Tentative de mise à jour d’une ressource inexistante. Réponse attendue : 404 Not Found.
   • Envoi d’une requête sans corps. Réponse attendue : 400 Bad Request ou 422 Unprocessable Entity.
   • Envoi d’une requête avec un format de corps invalide (par exemple, JSON invalide). Réponse attendue : 400 Bad Request.
   • Envoi d’une requête avec des types de données non valides pour les champs. Par exemple, une chaîne au lieu d’un nombre. Réponse attendue : 400 Bad Request ou 422 Unprocessable Entity.
   • Envoi d’une requête avec des champs obligatoires omis dans le corps. Réponse attendue : 400 Bad Request ou 422 Unprocessable Entity.
   • Envoi d’une requête avec des champs dépassant la longueur ou la plage autorisée. Réponse attendue : 400 Bad Request ou 422 Unprocessable Entity.
   • Envoi d’une requête avec une valeur non valide dans le chemin (par exemple, ID non valide). Réponse attendue : 400 Bad Request ou 404 Not Found.
   • Tentative de mise à jour d’un ressource bloquée ou inaccessible (si applicable). Réponse attendue : 403 Forbidden ou 409 Conflict.
   • Envoi d’une requête avec des en-têtes incorrects (par exemple, Content-Type). Réponse attendue : 415 Unsupported Media Type ou 400 Bad Request.
   • Mise à jour utilisant des caractères spéciaux ou emoji dans les champs de texte.

3. Conditions limites :

   • Mise à jour de champs avec des valeurs limites (par exemple, date minimale/maximale, nombres limites).
   • Mise à jour de champs avec des chaînes vides ou des valeurs nulles (si cela est autorisé).

4. Scénarios d’accès parallèle :

   • Tentative simultanée de mise à jour du même ressource depuis plusieurs sources (si pertinent pour le système testé).

5. Vérification des conséquences de la mise à jour :

   • Vérification que les données ont été correctement mises à jour dans la base de données ou d’autres systèmes.
   • Vérification que les ressources ou données dépendantes ont été mises à jour/modifiées en conséquence (si des dépendances existent).
   • Vérification que la requête GET sur la ressource mise à jour renvoie des données actuelles.
   • Vérification que d’autres opérations (DELETE, POST) avec la ressource mise à jour fonctionnent correctement.

Les critères de sélection des cas de test spécifiques dépendent de la spécification de l’API, des exigences métier, de l’analyse des risques et des priorités. Des techniques de conception de tests, telles que la partition équivalente et l’analyse des limites, sont utilisées pour déterminer les options d’entrée les plus représentatives.