Points clés
- Testez que le changement de pays met à jour les étiquettes, les exigences et les formats ensemble
- Séparez les entrées brutes, les valeurs normalisées et les résultats du serveur
- Configurer les jetons de saisie semi-automatique sémantique et les étiquettes visibles localisées
- Préserver les entrées après un échec et déplacer le focus sur une erreur utile
Auteur et révision
Principes éditoriaux- Rédigé par
- Équipe éditoriale du générateur d'adresses aléatoires
- Révisé par
- Équipe d’examen des formulaires et de l’assurance qualité
- Dernière mise à jour substantielle
- Ajout du changement de pays, des champs dynamiques, des jetons de saisie semi-automatique et d'une matrice de test en couches.
Première couche : état de changement de pays
La sélection d'un pays peut renommer Ville, changer l'État en Province ou Préfecture, masquer une région et remplacer l'indice de code postal. Affirmez que l’interface utilisateur et API dérivent de la même configuration nationale.
N’effacez jamais silencieusement le texte saisi lors d’un changement de pays. Confirmez d'abord ou conservez les brouillons par pays, puis verrouillez ce comportement dans des tests de régression.
| Pays | Étiquettes localisées | Comportement clé |
|---|---|---|
| États-Unis | État/Code postal | État à deux lettres et code postal à cinq chiffres |
| Canada | Province/Code postal | A1A 1A1 avec espace |
| Royaume-Uni | Post Town / Code postal | County normalement facultatif |
| Japon | Préfecture / Code postal | Code à sept chiffres et plusieurs niveaux |
| Australie | Banlieue/État/code postal | Code postal à quatre chiffres |
Couche deux : HTML sémantique et remplissage automatique
le nom, l'étiquette et la saisie semi-automatique ont des tâches distinctes. Les étiquettes expliquent la signification locale ; le nom suit le contrat API ; la saisie semi-automatique utilise des jetons standardisés tels que le pays, address-line1, address-level1, address-level2 et code postal.
Ne combinez pas l'adresse postale avec address-line1 et address-line2 pour la même représentation d'adresse.
<input name="addressLine1" autocomplete="shipping address-line1" />
<input name="locality" autocomplete="shipping address-level2" />
<input name="region" autocomplete="shipping address-level1" />
<input name="postalCode" autocomplete="shipping postal-code" />Troisième couche : validation, normalisation et vérification
La validation demande si la forme d'entrée est acceptable. La normalisation standardise le cas et les séparateurs. La vérification compare les données de référence. Donnez-leur des états et des messages séparés.
Évitez de réécrire à chaque frappe. Normalisez le flou ou soumettez et affichez le changement résultant.
- Distinguer les erreurs de caractères vides, trop longs et invalides
- Conserver rawValue avant la normalisation
- Ne pas effacer le formulaire après un délai de recherche
- Ne qualifiez jamais une correspondance d'expression régulière comme livrable
Couche quatre : récupération après erreur et accessibilité
Après un échec, concentrez-vous sur un résumé des erreurs ou sur le premier champ invalide. Connectez les messages avec aria-describedby, ne comptez jamais uniquement sur la couleur et conservez les autres valeurs de champ.
Sélections de pays de test au clavier, listes de suggestions, liens d'erreur et focus post-soumission. Localisez les tests automatisés par étiquettes ou par rôles plutôt que par espaces réservés spécifiques au pays.
Couche cinq : vérifier le payload réel de l’API
Capturez la demande soumise et affirmez countryCode, regionCode, postalCode, rawAddress et normalizedAddress. Relisez l'enregistrement pour détecter les échecs d'encodage et de conversion nulle.
Une assertion uniquement pour l'interface utilisateur peut manquer une sélection de province qui affiche correctement l'Ontario mais soumet l'Ontario au lieu de l'ON. Il peut également manquer une deuxième ligne effacée qui laisse la valeur précédente en stockage. Exécutez un enregistrement via la création, la modification, la réouverture et l'exportation afin que le test prouve un aller-retour complet plutôt qu'un état d'écran réussi.
Exercez un comportement de recherche tiers avec des réponses lentes, une limitation du débit, des erreurs de serveur, aucune suggestion et plusieurs suggestions plausibles. Une panne de réseau ne doit pas être formulée car votre adresse est erronée. L'indisponibilité du système et les entrées inacceptables sont des états différents avec des solutions différentes.
Versionnez la configuration du pays utilisée par le test. Lorsque les règles postales ou les exigences du produit changent, un échec doit identifier si l'application a changé ou si l'instantané de référence a changé.
- Instantané de la requête finale JSON
- Confirmer que la suppression d'un champ facultatif supprime son ancienne valeur
- Simuler un délai d'attente, 429, 500, aucun résultat et plusieurs résultats
- Séparer la copie d'erreur système de la copie input-error
Questions fréquentes
Chaque pays devrait-il afficher un champ État ?
Non. Renommez-le Province, Préfecture ou Région le cas échéant, et masquez-le là où le pays n'exige pas ce niveau.
La saisie semi-automatique peut-elle remplacer une étiquette visible ?
Non. La saisie semi-automatique sert le navigateur ; les étiquettes sont au service des personnes et des technologies d'assistance.
Une recherche échouée peut-elle effacer le formulaire ?
Cela ne devrait pas être le cas. Conservez la saisie, identifiez le champ et laissez l'utilisateur le corriger sur place.