Realistische Kundendaten generieren: Namen, Adressen & mehr

„Max Mustermann, Hauptstr. 1, 12345 Musterstadt" ist für Smoke-Tests ok – aber sobald du ein Formular designen, eine Rechnung in Produktion mocken oder einem Kunden ein Feature zeigen willst, brauchst du realistische Kundendaten. Hier geht es um das Wie: ohne DSGVO-Risiko, ohne reale Personen, aber mit genug Vielfalt für echte Tests.

Warum Dummy-Daten nicht reichen

Layout-Edge-Cases: lange Namen (von Hohenzollern-Sigmaringen), Umlaute, Bindestriche – alles Dinge, die Max Mustermann nicht hat, die aber dein Interface sprengen können.
Validierungs-Logik: PLZ-Prüfungen, IBAN-Checks, deutsche Telefonnummern-Formate – nur mit realistischen Werten findest du Fehler.
Demo-Glaubwürdigkeit: Ein Pitch mit 10 identischen Mustermanns wirkt billig; mit 10 plausiblen Namen wirkt es wie ein echtes System.

Was zu einem realistischen Kundendatensatz gehört

Feld	Beispiel	Besonderheit
Anrede	Herr / Frau / Divers	Mindestens Herr, Frau und neutral
Vorname	Lukas, Sophie, Mehmet	Statistisch passende Verteilung
Nachname	Weber, Schmidt, Yıldız	Umlaute und nicht-ASCII einbeziehen
Straße + Nr.	Lindenstraße 42a	Hausnummer-Zusätze mittesten
PLZ + Ort	80331 München	Plausible Zuordnung PLZ → Ort
E-Mail	lukas.weber@example.de	Nur `example.de/com/org` nutzen (RFC 2606)
Telefon	+49 30 1234567	Internationales Format E.164
Geburtsdatum	1988-04-12	Verteilung über realistische Altersspanne
IBAN	DE89 3704 0044 0532 0130 00	Gültige Prüfziffer, aber nicht echt

DSGVO: Was ist noch „personenbezogen"?

Kurz: Daten, die eine Person identifizierbar machen, fallen unter die DSGVO – auch wenn du sie „nur fürs Testen" verwendest. Das heißt konkret:

Niemals Produktions-Exporte in Dev- oder Staging-Umgebungen übernehmen. Auch nicht „pseudonymisiert", wenn Rückschlüsse möglich bleiben.
Fiktive Namen aus einer statistischen Verteilung sind unbedenklich – auch wenn eine real existierende Person zufällig genauso heißt. Entscheidend ist, dass der Datensatz nicht aus realen Daten abgeleitet ist.
Für E-Mails die reservierten Domains nach RFC 2606 nutzen: example.com, example.org,example.de. Diese sind garantiert ohne Mail-Server.

Generieren statt tippen

Mit dem Testdaten-Generator wählst du die Felder, die du brauchst, legst die Anzahl fest (10, 100, 10 000…) und exportierst als JSON, CSV oder SQL-INSERT. Deutsche Namen und Adressen sind voreingestellt, inkl. Umlaute und plausibler PLZ→Ort-Zuordnung.

Beispiel-Output (JSON)

[
  {
    "anrede": "Frau",
    "vorname": "Marie",
    "nachname": "Schmidt",
    "strasse": "Lindenstraße 42",
    "plz": "80331",
    "ort": "München",
    "email": "marie.schmidt@example.de",
    "telefon": "+49 89 1234567",
    "geburtsdatum": "1989-07-14",
    "iban": "DE89370400440532013000"
  }
]

Wenn du über 100 Datensätze brauchst

Für Performance-Tests oder Reports brauchst du schnell 10 000+ Zeilen. Zwei Tipps:

Deterministischer Seed: Mit festem Seed-Wert produziert der Generator reproduzierbare Daten – wichtig, wenn du Bugs anhand konkreter Zeilen debuggst.
Streamen, nicht in-memory: Bei großen Mengen den Export als CSV wählen und zeilenweise in die DB streamen (COPY FROM bei Postgres, LOAD DATA INFILE bei MySQL).

Praxis: 500 Demo-Kunden in 2 Minuten

Testdaten-Generator öffnen.
Felder wählen: Anrede, Name, Adresse, E-Mail, Telefon, Geburtsdatum, IBAN.
Anzahl auf 500 setzen, Land „Deutschland".
Als JSON oder CSV exportieren.
In deine Datenbank oder dein Demo-System importieren.

Fertig: ein überzeugender Demo-Datenstand ohne eine einzige reale Person im Datensatz.