Junior
Comment tester correctement le champ de saisie de l'adresse e-mail?
sobes.tech IA
Réponse de l'IA
La validation du champ de saisie de l'email inclut la vérification de la fonctionnalité, la validation, l'utilisabilité et la sécurité.
Tests fonctionnels :
- Saisie d'adresses valides :
test@example.comfirstname.lastname@example.comemail@subdomain.example.comfirstname+lastname@example.comemail@example.co.ukemail@example.museumemail@example.nameemail@example.демо(pour le support des noms de domaine internationalisés - IDN)
- Saisie d'adresses non valides :
- Absence de
@:testexample.com - Plusieurs
@:test@@example.com - Format de domaine incorrect :
test@example - Absence de nom d'utilisateur :
@example.com - Caractères spéciaux dans le nom d'utilisateur :
te!st@example.com,te#st@example.com - Caractères spéciaux dans le domaine :
test@exa!mple.com - Adresse longue (vérification des limites) :
a_very_long_email_address_that_exceeds_typical_limits@example.com(vérifier les limites selon la spécification ou le bon sens) - Adresse avec espaces :
test @example.com - Adresse avec syntaxe incorrecte :
test@.com,test.@example.com - Adresse avec une adresse IP au lieu du domaine (si non supporté) :
test@[192.168.1.1] - Adresse avec cyrillique (si non supporté IDN) :
тест@пример.рф
- Absence de
- Champ vide : Envoi du formulaire avec le champ vide.
Validation :
- Vérification de la conformité des données saisies à la syntaxe de l'email (expressions régulières).
- Affichage de messages d'erreur à l'utilisateur lors de la saisie de données non valides.
- Vérification de la précision et de la clarté des messages d'erreur.
- Vérification que le formulaire ne s'envoie pas en cas d'erreurs de validation.
Usabilité & UI/UX :
- Mise au focus sur le champ lors du chargement de la page (si pertinent).
- Texte de placeholder avec un exemple de format (
par exemple, user@example.com). - Support de l'autocomplétion par le navigateur.
- Présence d'une étiquette (
<label>) pour le champ. - L'utilisateur ne peut pas saisir de caractères non autorisés (si cette logique est présente en front-end).
- Si une masque de saisie est présente, vérifier son fonctionnement.
Sécurité :
- Vérification contre les vulnérabilités XSS : saisie de scripts, balises HTML (
<script>alert('XSS')</script>) dans le champ. - Vérification contre les injections (SQL/NoSQL) : saisie de caractères spécifiques pouvant influencer les requêtes à la base de données (
' OR '1'='1). - Limitation du taux (si le formulaire envoie un email ou effectue des actions gourmandes en ressources) : vérifier la restriction du nombre de tentatives d'envoi depuis une même IP ou utilisateur.
Automatisation :
- Rédaction de tests unitaires pour les fonctions de validation de l'email.
- Rédaction de tests d'intégration pour vérifier le fonctionnement du champ dans le contexte du formulaire.
- Rédaction de tests E2E pour vérifier le scénario complet d'utilisation du formulaire avec le champ email.
Exemple de code pour un test unitaire de validation :
// Supposons que nous ayons la fonction validateEmail
function validateEmail(email) {
const re = /\S+@\S+\.\S+/; // Exemple simple d'expression régulière
return re.test(email);
}
// Tests unitaires avec Jest
describe('validateEmail', () => {
test('devrait retourner true pour un email valide', () => {
expect(validateEmail('test@example.com')).toBe(true);
expect(validateEmail('firstname.lastname@example.com')).toBe(true);
});
test('devrait retourner false pour un email invalide', () => {
expect(validateEmail('testexample.com')).toBe(false);
expect(validateEmail('test@example')).toBe(false);
expect(validateEmail('@example.com')).toBe(false);
});
test('devrait retourner false pour une chaîne vide', () => {
expect(validateEmail('')).toBe(false);
});
});
Exemple de test E2E avec Cypress :
// cypress/integration/email_field.spec.js
describe('Champ de saisie de l'email', () => {
it('valide correctement et affiche une erreur pour une entrée invalide', () => {
cy.visit('/votre-page-formulaire'); // URL de la page avec le formulaire
cy.get('#email-input').type('email-invalide'); // Entrée d'un email invalide
cy.get('button[type="submit"]').click(); // Cliquer sur le bouton d'envoi
cy.get('.error-message').should('be.visible').and('contain', 'Format d'email incorrect'); // Vérification du message d'erreur
});
it('permet de soumettre le formulaire avec un email valide', () => {
cy.visit('/votre-page-formulaire');
cy.get('#email-input').type('valide@example.com');
cy.get('button[type="submit"]').click();
// Vérifications supplémentaires : redirection, message de succès, etc.
cy.url().should('include', '/succès'); // Vérification de l'URL après envoi réussi
});
});
Tableau avec des exemples de cas de test :
| ID | Action de l'utilisateur | Résultat attendu |
|---|---|---|
| TC_01 | Entrer test@example.com |
Le champ est considéré comme valide. Le formulaire est soumis (si tous les champs sont remplis). |
| TC_02 | Entrer email-invalide |
Le champ est considéré comme invalide. Un message d'erreur s'affiche. |
| TC_03 | Laisser le champ vide et essayer d'envoyer le formulaire | Le champ est considéré comme invalide (si obligatoire). Un message d'erreur s'affiche. |
| TC_04 | Entrer test@example.co.uk |
Le champ est considéré comme valide. |
| TC_05 | Entrer <script>alert('XSS')</script> |
Le script ne doit pas être exécuté. Le champ doit être nettoyé ou validé. |
Il faut également prendre en compte les exigences spécifiques du projet (par exemple, support pour certains domaines, sensibilité à la casse), tester sur différents appareils et navigateurs.