Suivre les relations, pas les coïncidences
Une même référence peut relier un objet API, un document et un événement. Construis une petite table : identifiant, source, heure, acteur, action et résultat. Distingue ce qui est observé de ce qui est supposé. Deux montants identiques ne prouvent pas qu’il s’agit de la même opération ; une référence commune et une chronologie cohérente apportent davantage de contexte.
Comprendre une règle métier
Une opération peut être techniquement bien formée et pourtant invalide au regard du processus prévu. Un remboursement, par exemple, devrait dépendre d’un paiement éligible, du bon propriétaire et d’un montant autorisé. Écris d’abord la règle attendue, puis compare les états avant et après. Utilise les objets de test du laboratoire et conserve les étapes intermédiaires au lieu de te fier seulement au dernier écran.
Objet : prêt P-16
Règle attendue : seul son titulaire peut renouveler le prêt.
Avant : titulaire=eleve-a, échéance=15/10
Essai : compte eleve-b, demande de renouvellement
Après : refus, échéance inchangée
Conclusion : ce test respecte la règle attendue.Un refus est un résultat utile. Cette observation valide seulement le cas testé, pas l’ensemble des permissions de l’application.
Écrire une preuve utile
Un compte rendu contient le contexte, les prérequis, la requête ou commande, le résultat observé, le résultat attendu et la limite de la conclusion. Masque les secrets de session dans tes notes partagées. Pour un fichier ou jeton de preuve, conserve les octets exacts : des espaces ajoutés, une troncature ou un changement de casse peuvent invalider la vérification. Explique ensuite la correction de principe, comme vérifier le propriétaire côté serveur.
Vérifie que tu as compris.
3 questions pour mettre les idées en pratique. Réponds avec tes mots, puis vérifie chaque réponse.
La correction repère les notions attendues et certaines formulations proches. Elle reste indicative : lis aussi l’explication. Tes réponses restent dans cette page et ne sont pas enregistrées.