Synthetische Personen für Tests und Demos
Software braucht personenähnliche Datensätze, bevor echte Nutzer existieren: für Formulare, Importwege, CRM-Sandboxes und Screenshots. Die People-Familie erzeugt Beispieldaten und exportiert sie in gängigen Austauschformaten. So bleiben Testdaten reproduzierbar und frei von echten personenbezogenen Daten.
Beginnen Sie beim Personengenerator, wenn Sie Namen, Adressen und Kontaktfelder für einen manuellen Test brauchen. Für dateibasierte Werkzeuge wählen Sie anschließend das passende strukturierte Exportformat.
Warum synthetische Daten wichtig sind
Echte Namen, E-Mail-Adressen und Telefonnummern aus Produktionslogs bergen Datenschutz- und Compliance-Risiken in Tickets, Screenshots oder öffentlichen Repositories. Fiktive Datensätze erlauben Validierung, Sortierung und Serialisierung ohne reale Menschen zu kopieren. Sie wirken bewusst personähnlich — plausible Adressen, eindeutige aussehende E-Mails und produktionsnahe Feldformen — bleiben aber erfunden. Stellen Sie sie niemals als echte Kunden dar und verwenden Sie Generatoren nicht für Betrug, Identitätsvortäuschung oder Konto-Missbrauch.
Generator und Exporter
- Generator erzeugt Datensätze für interaktive Tests.
- JSON liefert Objektarrays für APIs, Node-Skripte und Frontend-Mocks.
- XML passt zu älteren Integrationen und SOAP-artigen Fixtures.
- CSV erstellt Zeilen für Tabellen und Importproben.
- YAML eignet sich für lesbare Konfigurations- und GitOps-Beispiele.
Wählen Sie das Format, das der Empfänger bereits versteht; manuelles Umwandeln ist fehleranfällig. Typische Felder sind Vor- und Nachname, E-Mail, Telefon und Adressbestandteile. In Tests sollten Sie Struktur, Typen und nicht leere Werte prüfen statt einen zufällig generierten Namen fest einzucodieren. Für deterministische CI sind Seeds oder versionierte Golden-Dateien besser als ein Browser-Zufallsgenerator.
Formatdetails und Grenzen
JSON erlaubt keine nachgestellten Kommas. CSV-Programme können führende Nullen, Zeichenkodierung und Formeln mit = fehlinterpretieren; beachten Sie Anführungszeichen in Adresszeilen. Bei XML müssen Elementnamen, Verschachtelung und Escaping zum Parser passen. YAML ist einrückungssensitiv; bei YAML-1.1/1.2-Unklarheiten ist JSON oft sicherer.
Die Daten sind keine Identitätsprüfung, keine KYC-Nachweise und keine Produktions-PII. Lokale und Namen können ungleich realistisch sein, und Browser-Werkzeuge sind für kleine Fixture-Mengen, nicht für Millionen Lasttestzeilen gedacht. Benennen Sie Dateien klar mit sample- oder fixture-, mischen Sie sie nicht unmarkiert mit Kundenauszügen und diversifizieren Sie Namensdaten bewusst für inklusive QA. Diese Werkzeuge dienen der Softwarequalität, nicht Behauptungen über reale Identitäten.