La vraie question est : quel code est valide maintenant ?
Tester les OTP par e-mail sans accepter le mauvais code
Testez les OTP autour de la récence, du renvoi, de l'expiration, des tentatives et de l'état créé après le bon code, pas autour d'un simple nombre trouvé dans la boîte.
Les tests OTP deviennent aléatoires quand plusieurs nombres plausibles coexistent dans la même boîte. Le système possède pourtant des règles précises : quelle demande a créé le code, combien de temps il vit, si un renvoi invalide l'ancien et ce qu'il se passe après un succès ou plusieurs erreurs. Le test doit rendre ces règles visibles.
Rendez l'état OTP explicite
| Événement | Question | Assertion |
|---|---|---|
| Première demande | Quel code est valide ? | Le code de la demande courante suit la politique |
| Renvoi | L'ancien reste-t-il valide ? | Testez la règle réelle |
| Expiration | Quand cesse-t-il de fonctionner ? | Le code expiré échoue proprement |
| Succès | Peut-il être rejoué ? | Le comportement one-time est vérifié |
Une séquence déterministe
- 1
Créez une frontière de demande
Utilisez un destinataire propre ou une fenêtre temporelle sans ambiguïté.
- 2
Attendez le bon message
Faites correspondre expéditeur, objet, destinataire et instant avant d'extraire le code.
- 3
Soumettez le code courant
Contrôlez la réponse et l'état du compte ou de la session.
- 4
Testez le renvoi séparément
Demandez un second code uniquement dans le cas consacré à cette politique.
- 5
Testez expiration et replay
Ne supposez pas que le happy path prouve ces propriétés.
Les retries peuvent eux-mêmes créer un nouvel OTP
Playwright et Cypress peuvent relancer un test en échec. Si chaque tentative redemande un OTP alors que la boîte persiste, le retry modifie l'état à diagnostiquer.
Utilisez une nouvelle identité par tentative ou une corrélation qui distingue clairement les demandes. Un retry ne doit pas réussir simplement parce qu'il a accepté le dernier nombre visible.
Un OTP e-mail n'est pas automatiquement phishing-resistant
Un code à usage unique ne rend pas le canal résistant au phishing. NIST distingue l'e-mail des authentificateurs out-of-band liés à un appareil. Testez les propriétés réellement livrées sans exagérer le niveau de sécurité du canal.
La fiabilité d'un test OTP dépend surtout du contrôle de l'état : demande connue, code courant connu, puis tests séparés pour renvoi, expiration, replay et retries.
Besoin d’un destinataire propre pour la QA e-mail manuelle ?
Utilisez MailOnce pour inspecter de vrais messages d’inscription, OTP, liens magiques, réinitialisation de mot de passe et notifications sans placer votre boîte personnelle dans les données de test.
Créer un e-mail temporaireSources et lectures complémentaires
Documentation primaire de sécurité et d’exécution de tests utilisée pour étayer les recommandations.
Poursuivre les tests
Passez à la prochaine frontière du même problème de test e-mail.