IBAN di prova per QA: dati sintetici sicuri

Risposta rapida: cos'è un IBAN di prova?

Un IBAN di prova è un International Bank Account Number sintetico creato per esercitare il comportamento di un software. I team lo usano per moduli di pagamento, selettori di Paese, normalizzazione, fixture API, test del browser, screenshot, formazione e documentazione tecnica. La stringa dovrebbe seguire il formato del Paese scelto e può superare i controlli matematici richiesti dal codice.

La parola importante è prova. Un valore generato non permette di trovare un conto reale, un beneficiario o un registro bancario. Il generatore IBAN multiplo crea righe sintetiche isolate, mentre il verificatore IBAN controlla i caratteri forniti. Nessuno dei due contatta una banca o verifica la titolarità.

• Uso corretto: moduli, parser, fixture, test di regressione, demo e documentazione.
• Uso scorretto: bonifici, addebiti, beneficiari, prove di proprietà o ricerca di conti.
• Conserva etichetta, limite dell'ambiente e regola di pulizia accanto al dato.

Un dato sintetico non è un conto bancario reale

Un valore sintetico serve a esercitare un formato. Può avere il prefisso del Paese, la lunghezza totale prevista, classi BBAN plausibili e un resto MOD-97 pari a 1. Questo risponde a una domanda tecnica limitata: la stringa si comporta come un IBAN strutturalmente valido per quella regola?

Un IBAN emesso da una banca risponde ad altre domande. Può essere collegato a conto, banca, filiale, valuta, circuito di pagamento e stato attuale. Un controllo locale non può dimostrare questi fatti dai soli caratteri. Una stringa può quindi superare il checksum e restare non assegnata, inattiva, inadatta a un pagamento o pensata solo come fixture.

Verifica un IBAN di prova in tre livelli

Un fixture QA utile non è una semplice stringa casuale. Parti dal formato registrato del Paese e prova ogni livello separatamente, così l'errore porta al codice giusto. La directory dei Paesi IBAN confronta lunghezze e schemi BBAN; il decoder IBAN mostra le parti visibili di un valore completo.

Controlla prima codice Paese e lunghezza totale. Poi verifica i caratteri numerici, alfabetici o alfanumerici consentiti. Infine esegui MOD-97-10. Una suite deve contenere valori validi e errori intenzionali: anche la gestione dell'errore fa parte del contratto.

1. 1. Paese e lunghezzaScegli un Paese supportato e conferma la lunghezza fissa registrata.
2. 2. Schema dei caratteriControlla che ogni campo nazionale accetti cifre o lettere previste.
3. 3. Checksum MOD-97Esegui il calcolo internazionale e conferma il resto atteso.
4. 4. Limite di businessRegistra che è valida solo la struttura, non la proprietà o il pagamento.

• Separa errore di lunghezza ed errore di checksum per mostrare il primo problema utile.
• Cambia una sola cifra di controllo in un fixture valido per provare un messaggio preciso.
• Usa una lettera in un campo numerico solo per un caso negativo intenzionale e documentato.

Un flusso sicuro per i fixture QA

Tratta un IBAN di prova come qualsiasi fixture sintetico: definisci lo scopo, generalo con una regola nota, verificalo, etichettalo e mantienilo nell'ambiente che lo usa. L'ordine conta perché una stringa matematicamente valida diventa rischiosa se finisce in un seed di produzione, una fattura, un export clienti o un elenco di beneficiari.

Per pochi casi usa il generatore della home. Per una matrice o una regressione usa il generatore multiplo ed esporta CSV o JSON. Nel tuo fixture aggiungi Paese, lunghezza, risultato atteso, scopo e responsabile della pulizia. Il browser genera i valori, ma repository e CI devono avere controlli propri sui dati di produzione.

1. DefinireScrivi Paese, comportamento del campo, risultato atteso e motivo del fixture.
2. GenerareCrea valori sintetici secondo la regola; non copiare conti cliente in un database di test.
3. VerificareEsegui asserzioni su lunghezza, schema e MOD-97 e salva il risultato atteso.
4. Isolare e pulireSepara i fixture, blocca la promozione e cancellali o ruotali dopo il test.

Crea una matrice, non solo il caso felice

Un solo valore valido dimostra poco. Una suite robusta copre differenze tra Paesi, presentazioni e errori prevedibili. Inserisci almeno un formato breve e uno lungo, BBAN numerici e alfanumerici, un valore stampato con spazi, uno elettronico compatto, input minuscolo e un valore con una cifra di controllo modificata.

I Paesi dipendono dal prodotto. La tabella è un modello di pianificazione, non una promessa che ogni valore funzioni nella sandbox di un provider. Se un provider offre identificativi sandbox propri, segui la sua documentazione e separali dai fixture generici di formato.

• Salva il risultato atteso insieme al fixture per rendere verificabili i cambi del validatore.
• Usa ID descrittivi come `iban-de-length-22-valid` invece di una stringa casuale senza etichetta.
• Non inserire nomi, carte, fatture o estratti reali in un caso sintetico.

Errori comuni e limiti pratici

L'errore più comune è usare fake IBAN come se fosse automaticamente un valore sicuro per pagare. Nelle ricerche fake può indicare un fixture sintetico, ma anche suggerire una frode. Nel codice e nella documentazione preferisci IBAN di prova, IBAN sintetico o fixture. Per un pagamento reale usa una fonte bancaria aggiornata e autorevole.

Un altro errore è trattare il verificatore come una query bancaria. Uno strumento del browser può spiegare i caratteri visibili, ma non sa se un identificativo è attivo, a chi appartiene il conto, se il beneficiario è stato controllato o se il pagamento arriverà. Per queste domande servono banca, provider o processo di verifica appropriato.

• Non chiamare un valore sintetico ufficiale, sicuro per i pagamenti, assegnato o verificato per titolarità.
• Non dedurre un IBAN da nome, carta, numero locale o screenshot.
• Non pubblicare un fixture in fatture, paghe, rimborsi o mandati reali.
• Non affidarti a un intervallo universale riservato; isola ed etichetta tutti i dati generati.