Aller au contenu

TP 2 – Cas de test

"Un cas de test, c’est une recette : si on suit les étapes, on doit obtenir le même résultat."

Bonne pratique du testing

Objectifs pédagogiques

  • Déduire des cas de test à partir d’un mini cahier des charges
  • Rédiger des cas de test clairs et reproductibles
  • Couvrir succès et erreurs
  • Structurer un tableau de tests exploitable en équipe

Contexte – Mini cahier des charges (backend)

Vous testez un backend API de gestion d’utilisateurs.

Routes à tester

  • POST /users : créer un utilisateur
  • POST /login : authentifier un utilisateur
  • GET /profile : récupérer le profil (authentifié)
  • PUT /profile : modifier le profil (authentifié)

Règles (extraits)

Création utilisateur POST /users

  • champs requis : email, password, fullName
  • email doit être au format email
  • password ≥ 8 caractères
  • email doit être unique

Login POST /login

  • champs requis : email, password
  • si OK → retour 200 avec { token }
  • si KO → retour 401

Profil GET /profile

  • nécessite un token (header Authorization: Bearer <token>)
  • si pas de token → 401
  • si token OK → 200 avec { id, email, fullName }

Travail demandé

  1. Choisissez 2 routes parmi celles ci-dessus.
  2. Pour chaque route, rédigez au minimum 4 cas de test :
  3. 1 cas de succès

  4. 3 cas d’erreur (validation, auth, doublon, etc.)

  5. Pour chaque cas de test, précisez :

  6. préconditions
  7. requête (méthode + endpoint + body + headers si nécessaire)
  8. résultat attendu (status + contenu)

Modèle de cas de test (à compléter)

ID Route Préconditions Requête Résultat attendu

Indices

Indice — Préconditions

Les préconditions peuvent inclure : - un utilisateur déjà créé en base - un token valide obtenu après login - un utilisateur avec un email déjà utilisé

Indice — Erreurs intéressantes à tester
  • champ manquant
  • format email invalide
  • password trop court
  • email déjà utilisé
  • accès sans token
  • token invalide
Indice — Résultat attendu

Pensez à préciser : - code HTTP : 200 / 201 / 400 / 401 / 409… - forme du JSON (au moins les champs principaux) - message d’erreur si disponible

Auto-évaluation

  • J’ai choisi 2 routes
  • J’ai produit au moins 8 cas de test (4 par route)
  • J’ai testé succès + erreurs
  • Mes préconditions sont réalistes
  • Mes résultats attendus sont précis

Solution proposée (exemple)

Voir une proposition de solution (2 routes)

Route 1 : POST /login

ID Route Préconditions Requête Résultat attendu
TC-L01 POST /login utilisateur existe body {email,password} valides 200 + { token }
TC-L02 POST /login utilisateur existe password incorrect 401
TC-L03 POST /login — email manquant 400 + erreur validation
TC-L04 POST /login — format email invalide 400 + erreur validation

Route 2 : GET /profile

ID Route Préconditions Requête Résultat attendu
TC-P01 GET /profile token valide header Authorization 200 + { id, email, fullName }
TC-P02 GET /profile — aucun token 401
TC-P03 GET /profile token invalide Bearer xxxx 401
TC-P04 GET /profile token expiré Bearer token expiré 401 (ou 403 selon design)

✅ Remarque : les codes exacts peuvent varier selon implémentation, l’important est la cohérence.

⬅ TP 1 – Concept de test ➡ TP 3 – Tests automatisés