Une matrice de test d'adresse de caisse pour le comportement réel du formulaire
Créez une petite matrice pour les exigences sur le terrain, la localisation et les erreurs de validation récupérables.
Résumé IA
Testez les champs obligatoires et facultatifs, les longues rues, les unités, les codes postaux manquants autorisés et le texte non latin.
Commencez par le comportement sur le terrain, pas par le nombre de pays
Choisissez des cas qui appliquent des valeurs obligatoires par rapport aux valeurs facultatives, une longue rue, une unité, un code postal manquant lorsque cela est autorisé et des caractères non latins. Un pays présentant des cas limites significatifs peut révéler plus que de nombreux chemins heureux en double.
Gardez une matrice de scénarios compacte
Exemple : référence valide ; localité requise manquante ; unité facultative omise ; code postal avec un zéro non significatif ; nom accentué ou en écriture locale ; séparateur invalide ; rejet du serveur avec valeurs conservées.
Case Input Expected Baseline Boston / MA / 02108 Accepted Leading zero ZIP 02108 Value remains 02108 Optional unit Unit omitted No unit error Required locality City empty Inline city error; other values remain Unicode Québec Characters preserved
Vérifier l'interaction et l'accessibilité
Vérifiez les étiquettes persistantes, l'ordre du clavier, l'association des erreurs en ligne, le focus après un échec et que les noms de champs traduits ne débordent pas d'une fenêtre d'affichage étroite. Évitez d’effacer les valeurs de l’utilisateur lorsqu’une correction est nécessaire.
Séparer le paiement de l'exécution
Un test réussi du formulaire de paiement prouve que l'application a accepté ses entrées. Utilisez le bac à sable du transporteur pour les règles d'expédition et les accessoires synthétiques uniquement pour le comportement de l'application.