IBAN de test pour la QA : données synthétiques sûres

Réponse rapide : qu'est-ce qu'un IBAN de test ?

Un IBAN de test est un International Bank Account Number synthétique créé pour exercer le comportement d'un logiciel. Les équipes l'utilisent pour les formulaires de paiement, les sélecteurs de pays, la normalisation, les fixtures d'API, les tests de navigateur, les captures, la formation et la documentation technique. La chaîne doit ressembler au format du pays sélectionné et peut satisfaire les règles mathématiques que le code doit gérer.

Le mot important est test. Une valeur générée ne permet pas de trouver un compte réel, un bénéficiaire ou un annuaire bancaire. Le générateur IBAN en masse produit des lignes synthétiques isolées et le vérificateur IBAN examine les caractères fournis. Aucun des deux ne contacte une banque ni ne confirme une propriété.

• Bon usage : formulaires, parsers, fixtures, tests de régression, démos et documentation.
• Mauvais usage : virements, prélèvements, bénéficiaires, preuve de propriété ou recherche de compte.
• Conservez l'étiquette, la limite d'environnement et la règle de nettoyage avec la donnée.

Une donnée synthétique n'est pas un compte bancaire réel

Une valeur synthétique sert à exercer un format. Elle peut contenir le bon préfixe de pays, la longueur attendue, des classes de caractères BBAN plausibles et un reste MOD-97 égal à 1. Cela répond à une question technique limitée : la chaîne se comporte-t-elle comme un IBAN structurellement valide pour cette règle ?

Un IBAN émis par une banque répond à d'autres questions. Il peut être lié à un compte, une banque, une agence, une devise, un moyen de paiement et un état actuel. Un outil local ne peut pas établir ces faits à partir des caractères. Une chaîne peut donc passer le checksum tout en étant non attribuée, inactive, impropre à un paiement ou réservée à un fixture.

Vérifier un IBAN de test en trois niveaux

Une fixture QA utile n'est pas une simple chaîne aléatoire. Commencez par le format enregistré du pays, puis testez chaque niveau séparément pour relier l'échec au bon code. L'annuaire des pays IBAN compare les longueurs et motifs BBAN ; le décodeur IBAN montre les parties visibles d'une valeur complète.

Vérifiez d'abord le code pays et la longueur totale. Contrôlez ensuite les caractères numériques, alphabétiques ou alphanumériques autorisés. Enfin, calculez MOD-97-10. Une suite de tests doit contenir des valeurs correctes et des erreurs intentionnelles : le traitement d'erreur fait partie du contrat.

1. 1. Pays et longueurChoisissez un pays pris en charge et confirmez la longueur fixe enregistrée.
2. 2. Motif des caractèresVérifiez que chaque champ national accepte les chiffres ou lettres prévus.
3. 3. Checksum MOD-97Exécutez le calcul international et confirmez le reste attendu.
4. 4. Limite métierNotez qu'il s'agit d'une validité structurelle, pas d'une preuve de propriété ou de paiement.

• Séparez l'erreur de longueur de l'erreur de checksum pour afficher le premier problème utile.
• Changez un seul chiffre de contrôle dans une fixture valide pour tester un message précis.
• N'utilisez une lettre dans un champ numérique que pour un cas négatif volontaire et documenté.

Un cycle sûr pour une fixture QA

Traitez un IBAN de test comme toute fixture synthétique : définissez son but, générez-le avec une règle connue, vérifiez-le, étiquetez-le et gardez-le dans l'environnement concerné. L'ordre compte, car une chaîne mathématiquement valide devient risquée si elle se retrouve dans une seed de production, une facture, un export client ou une liste de bénéficiaires.

Pour quelques cas, utilisez le générateur de la page d'accueil. Pour une matrice ou une régression, utilisez le générateur en masse et exportez CSV ou JSON. Ajoutez dans votre fixture le pays, la longueur, le résultat attendu, le but et le responsable du nettoyage. Le navigateur génère les valeurs, mais le dépôt et la CI doivent garder leurs propres contrôles de données de production.

1. DéfinirÉcrivez le pays, le comportement du champ, le résultat attendu et le but.
2. GénérerCréez des valeurs synthétiques selon la règle ; ne copiez pas de comptes clients dans une base de test.
3. VérifierTestez longueur, motif et MOD-97 et stockez le résultat attendu.
4. Isoler et nettoyerSéparez les fixtures, bloquez leur promotion et supprimez-les ou faites-les tourner après le test.

Construire une matrice plutôt qu'un seul cas heureux

Une valeur qui passe ne prouve presque rien. Une suite solide couvre les différences de pays, de présentation et les échecs prévisibles. Incluez un format court et un format long, des BBAN numériques et alphanumériques, une valeur imprimée avec espaces, une valeur électronique compacte, des minuscules et une valeur dont le chiffre de contrôle a changé.

Les pays exacts dépendent de votre produit. Le tableau est un modèle de planification, pas la promesse que chaque valeur fonctionnera dans la sandbox d'un prestataire. Si un prestataire fournit ses propres identifiants sandbox, suivez sa documentation et séparez-les des fixtures de format génériques.

• Stockez le résultat attendu avec la fixture pour rendre les changements de validateur auditables.
• Utilisez des identifiants comme `iban-de-length-22-valid` plutôt qu'une chaîne aléatoire non étiquetée.
• N'intégrez jamais de nom, carte, facture ou relevé réel dans un cas synthétique.

Erreurs courantes et limites pratiques

L'erreur la plus fréquente est de traiter fake IBAN comme une valeur sûre pour payer. Dans les recherches, fake peut désigner une fixture synthétique mais aussi suggérer une tromperie. Dans le code et la documentation, préférez IBAN de test, IBAN synthétique ou fixture. Pour un vrai paiement, utilisez une source bancaire actuelle et autorisée.

Autre erreur : prendre le vérificateur pour une requête bancaire. Un outil de navigateur peut expliquer les caractères visibles, mais il ne sait pas si un identifiant est actif, à qui appartient le compte, si le bénéficiaire est contrôlé ou si le paiement sera réglé. Ces questions relèvent de la banque, du prestataire ou du processus de vérification approprié.

• Ne qualifiez pas une valeur synthétique d'officielle, sûre pour un paiement, attribuée ou vérifiée au nom d'un titulaire.
• Ne déduisez pas un IBAN à partir d'un nom, d'une carte, d'un numéro local ou d'une capture.
• Ne publiez pas une fixture dans une facture, une paie, un remboursement ou un mandat réel.
• Ne comptez pas sur une plage universelle réservée ; isolez et étiquetez les données générées.