dataset Generatore di Dati di Test Falsi star

Perché Testare con Dati Utente Reali È una Cattiva Pratica

Popolare un database di sviluppo esportando una porzione della tabella clienti di produzione sembra comodo, ed è uno dei modi più comuni in cui le aziende fanno trapelare accidentalmente dati personali. Sotto regolamenti come il GDPR dell'UE e il KVKK turco, i dati personali dovrebbero essere trattati solo per lo scopo specifico per cui sono stati raccolti e protetti con una sicurezza appropriata a quello scopo - un ambiente di staging o sviluppo è di solito molto meno protetto della produzione, spesso accessibile a ogni ingegnere, a volte perfino registrato o salvato su storage meno sicuro, oppure esposto accidentalmente se un URL di staging viene indicizzato o un server di test è configurato male. Il nome, l'email, il numero di telefono e l'indirizzo di un cliente reale seduti in un database mai controllato per quel livello di esposizione è un classico caso di responsabilità di conformità e sicurezza, e "abbiamo usato dati di produzione in una demo" è una frase ricorrente nei post-mortem reali di violazioni di dati. I dati inventati aggirano completamente il problema: non c'è nessuna persona reale da notificare, nessuna base di consenso da giustificare, e nessuna violazione da segnalare se un database di test viene compromesso, perché le righe non sono mai corrisposte a nessuno.

Al di là della conformità, i dati di test inventati sono anche semplicemente più utili per il QA. I dati di produzione reali riflettono l'aspetto dei tuoi utenti esistenti - non conterranno in modo affidabile i casi limite di cui i tester hanno realmente bisogno, come nomi con caratteri insoliti, campi opzionali vuoti, stringhe di lunghezza massima, o una distribuzione uniforme su ogni input che un modulo accetta. La generazione sintetica ti permette di controllare precisamente volume e forma: questo strumento ti permette di richiedere tra 1 e 100 righe e scegliere esattamente quali campi popolare, un flusso di lavoro per cui le esportazioni di clienti reali non sono mai state progettate.

Come Funziona la Casualità

Ogni valore qui - quale nome, quale città, quali cifre in un numero di telefono - viene scelto usando crypto.getRandomValues(), la fonte di numeri casuali crittograficamente sicura della Web Crypto API, anziché Math.random(). Per essere precisi sul perché: la reale posta in gioco per la sicurezza nello scegliere un nome falso per una riga di test è vicina allo zero, quindi questo non è un requisito di sicurezza nel modo in cui lo sarebbe, ad esempio, generare una password o un token di sessione. Il motivo per cui questo strumento lo usa comunque è dimostrare la corretta abitudine predefinita - Math.random() è un generatore pseudo-casuale veloce e non crittografico il cui output può, in linea di principio, essere previsto o riprodotto tra ambienti diversi, mentre crypto.getRandomValues() attinge dalla fonte di entropia sicura del sistema operativo ed è lo strumento giusto ogni volta che la casualità deve essere imprevedibile - quindi ricorrervi per impostazione predefinita evita l'errore di usare Math.random() in un contesto - come la generazione di un codice sconto o un token di reset - dove la prevedibilità conterebbe davvero. Per evitare il bias del modulo (una distorsione sottile che rende alcuni valori leggermente più probabili di altri quando l'intervallo casuale non divide esattamente lo spazio di output), ogni estrazione usa il campionamento per rigetto: i valori che introdurrebbero quella distorsione vengono scartati e ripescati.

• Pool di nomi e città separati per lingua: scegliere "Turco" genera da un pool dedicato di nomi propri, cognomi e città turche; scegliere "Inglese" attinge da un pool separato in lingua inglese, così i dati risultano coerenti con la locale anziché un mix di convenzioni di denominazione non correlate.
• Solo domini falsi: le email generate usano sempre example.com, example.org o example.net, i domini formalmente riservati dalla RFC 2606 per uso di documentazione e test - mai un dominio reale e registrabile che potrebbe accidentalmente instradare posta da qualche parte.
• L'esportazione CSV è formattata secondo RFC 4180: i campi sono separati da virgole e racchiusi tra virgolette, così i valori contenenti virgole, virgolette o interruzioni di riga vengono comunque analizzati correttamente in Excel, Google Fogli, o qualsiasi importatore CSV conforme agli standard.
• Completamente locale: la generazione avviene nel tuo browser; nulla viene inviato a un server, registrato, o memorizzato da nessuna parte oltre al tuo download.