Persone sintetiche per test e demo
Il software ha bisogno di record dall'aspetto umano prima che esistano utenti reali: moduli, importazioni, sandbox CRM e screenshot dimostrativi. La famiglia People genera dati personali di esempio ed esporta formati di interscambio comuni, così le fixture restano riproducibili e prive di dati personali reali.
Parti dal generatore di persone per nomi, indirizzi e campi di contatto in un test manuale; quando un programma richiede un file, scegli l'esportazione strutturata adatta.
Perché servono dati sintetici
Riutilizzare nomi, email e telefoni dai log di produzione in ticket, screenshot o repository pubblici crea rischi di privacy e conformità. I record fittizi permettono di provare validazione, ordinamento e serializzazione senza copiare persone reali. Restano verosimili — email dall'aspetto unico, indirizzi plausibili e campi simili alla produzione — ma sono sempre invenzioni. Non presentarli come clienti reali e non usare generatori per frode, impersonificazione o abuso di account.
Generatore ed esportatori
- Generatore crea record per test interattivi.
- JSON produce array per API, script Node e mock front-end.
- XML è utile per integrazioni legacy e fixture in stile SOAP.
- CSV crea righe per fogli di calcolo e prove di importazione.
- YAML è leggibile per configurazioni e campioni GitOps.
Scegli il formato già parlato dal consumer: convertirlo a mano è fragile. Le fixture includono in genere nome, cognome, email, telefono e componenti dell'indirizzo. Nei test è meglio controllare chiavi, tipi e stringhe non vuote invece di fissare un singolo nome casuale. Per CI deterministica usa seed o file golden versionati; il browser è eccellente per QA esplorativa.
Formati e limiti
JSON rigoroso non ammette virgole finali. I fogli di calcolo possono reinterpretare codifica, zeri iniziali e formule che iniziano con =; apri CSV come testo quando quei campi contano. XML richiede nomi, annidamento ed escape previsti dal parser. YAML dipende dall'indentazione; JSON è più sicuro se YAML 1.1 e 1.2 sono ambigui.
Questi dati non verificano identità, non sono prove KYC e non sono PII di produzione. Il realismo varia per locale e il browser è adatto a piccoli batch, non a milioni di righe per load test. Etichetta i file sample- o fixture-, non mescolarli senza avviso a estratti clienti e diversifica i dati per una QA inclusiva. Lo scopo è la qualità del software, non affermazioni su identità reali.