Zufällige Adressen generieren

Warum generierte Adressen beim Testen nutzen?

Die echte Adresse eines Kunden in eine Staging-Datenbank, ein Bug-Ticket oder eine Demo zu kopieren geht schnell, und genau diese Art von Datenverarbeitung regelt der Datenschutz. Nach der DSGVO ist eine Postanschrift, die zu einer Person gehört, ein personenbezogenes Datum, und Testumgebungen sind keine Ausnahme: Datenminimierung und Zweckbindung gelten auch dort.

• Tickets wandern: ein Bug-Report landet im Chat, wird in Pull Requests verlinkt und in andere Tools exportiert. Alles darin, auch der Screenshot eines ausgefüllten Formulars, wandert mit.
• Staging ist weniger geschützt: Testsysteme haben meist mehr Zugriffsberechtigte, weniger Monitoring und längere Aufbewahrung als die Produktion. Echte Datensätze erhöhen dort das Risiko, ohne die Testabdeckung zu verbessern.
• Demos werden aufgezeichnet: Vertriebsdemos, Onboarding-Videos und Doku-Screenshots werden öffentlich. Eine generierte Adresse wirkt auf dem Bildschirm echt, ohne auf jemanden zu verweisen.
• Das Format zählt trotzdem: Platzhalter wie „test test 123“ prüfen deine Validierung nie wirklich. Generierte Adressen folgen dem echten Postleitzahlformat und der Zeilenfolge jedes Landes, damit Parser, Formatierung und Versandlogik realistisch gefordert werden.

Tritt ein Bug nur mit den Daten einer bestimmten Person auf, bau die Form dieses Datensatzes (gleiches Land, gleiche Feldlängen, gleiche Sonderzeichen) mit generierten Werten nach, statt den Datensatz selbst zu kopieren.

So entsteht jede Adresse

• Echte Orte, passend kombiniert: jede Stadt stammt aus einer kuratierten Liste mit ihrem echten Bundesstaat, ihrer Provinz oder Region und Postleitzahlen, die wirklich zu ihr gehören. Das heißt: vollständige ZIP-Codes in den USA, echte Postcode-Bezirke in Großbritannien, echte Forward Sortation Areas (die ersten drei Zeichen) in Kanada und echte Postleitzahlen in Deutschland, Spanien, Frankreich und Australien.
• Gültige, aber zufällige Endungen: in Großbritannien und Kanada sind die letzten drei Zeichen zufällig, folgen aber dem offiziellen Muster. Den vollständigen Code gibt es deshalb nicht unbedingt als echte Zustelladresse.
• Plausible Straßen: Straßennamen entstehen aus typischen lokalen Mustern wie Maple Avenue, Station Road, Lindenstraße, Calle Mayor oder rue de la République, mit Hausnummern und Adresszusätzen im landesüblichen Stil. Eine bestimmte Straße mit Nummer gibt es vielleicht, vielleicht auch nicht.
• Telefonnummern, die niemandem gehören: Nummern kommen nur aus Bereichen, die in den USA, Kanada, Großbritannien, Australien, Deutschland und Frankreich für Fiktion reserviert sind. Für Spanien ist die Option aus, weil wir keinen reservierten Bereich bestätigen konnten.
• E-Mails auf reservierten Domains: jede E-Mail nutzt example.com, example.org oder example.net, die RFC 2606 für Dokumentation reserviert. Niemand kann sie registrieren, also steckt kein echtes Postfach dahinter. Innerhalb eines Durchgangs ist jede E-Mail einmalig, praktisch zum Testen einer Unique-Constraint.
• Sichere Zufallszahlen: jede Auswahl nutzt crypto.getRandomValues des Browsers, damit sich keine vorhersehbaren Muster ergeben.

Adressformate nach Land

Der Generator gibt jede Adresse in der Zeilenfolge aus, die die örtliche Post erwartet. Das ändert sich von Land zu Land (jeweils nach dem Namen):

Deutschland und Frankreich lassen die Region in der Postanschrift komplett weg, und in Großbritannien ist das County optional. Ein Formular, das für jedes Land ein Bundesland verlangt, lehnt dort völlig gültige Adressen ab.

Grenzfälle, die QA in Adressformularen testen sollte

Adressformulare scheitern immer wieder an denselben Stellen. Erzeuge für jedes Land, in das du lieferst, einen Durchgang und prüfe Folgendes:

• Lange Straßennamen: Avenida de los Reyes Católicos oder Hans-Böckler-Straße sprengen knappe Längenlimits und brechen auf Etiketten unschön um. Prüf jede Stelle, an der die Adresse landet: Formular, Bestätigungsmail, Rechnung, PDF und jede Versand- oder Zahlungs-API, die oft weniger Zeichen erlaubt als dein eigenes Formular.
• Nicht-ASCII-Zeichen: verfolge ß, ñ, é und ü von der Eingabe bis zum Export. Wird ein UTF-8-Wert als Windows-1252 gelesen, wird aus München „München“. Prüf auch die Groß- und Kleinschreibung: in JavaScript liefert "Straße".toUpperCase() den Wert "STRASSE", was exakte Vergleiche aushebeln kann.
• Adresszusätze: stell sicher, dass die optionale zweite Zeile jede Übergabe übersteht. Auch die Reihenfolge unterscheidet sich: in Großbritannien und Frankreich steht die Wohnungsangabe über der Straße. In Spanien gehören Etage und Tür in die Straßenzeile, in Deutschland folgen Wohnung oder Etage nach // auf die Hausnummer, und in den USA, Kanada und Australien steht der Zusatz ebenfalls in der Straßenzeile.
• Postleitzahlen mit Buchstaben und Leerzeichen: britische Postcodes und kanadische Postleitzahlen mischen Buchstaben und Ziffern um ein Leerzeichen. Akzeptiere Kleinbuchstaben und ein fehlendes Leerzeichen und normalisiere danach (aus sw1a1aa wird SW1A 1AA). Nutze für Postleitzahlen nie type="number".
• Führende Nullen: Boston (02108), Dresden (01067), Barcelona (08001), Nizza (06000) und Darwin (0800) beginnen alle mit einer Null. Speichere Postleitzahlen als Text, nie als Ganzzahl. Excel entfernt die Null, wenn du eine CSV per Doppelklick öffnest. Importiere sie deshalb über Daten, Aus Text/CSV und stell die Spalte auf Text.
• Anschriften ohne Bundesland: ein Pflichtfeld „State“ blockiert deutsche und französische Nutzer. Mach Feld, Beschriftung und Validierung vom gewählten Land abhängig.
• Autofill und autocomplete: nutze die Standard-Tokens (name, address-line1, address-line2, address-level2 für den Ort, address-level1 für das Bundesland, postal-code, country, tel, email) und prüf, ob das Autofill des Browsers die richtigen Felder füllt. Wechsle danach das Land und kontrolliere, ob Beschriftungen und Validierung mitziehen.
• Apostrophe und Bindestriche: St. John's, O'Brien und Saint-Étienne sind absichtlich im Datensatz. Sie decken fehlerhaftes Escaping in SQL, HTML und CSV auf, ebenso eine Validierung, die nur Buchstaben erlaubt.