Was sind Beispieldaten und Testdaten?

Beispieldaten und Testdaten: gleiche Idee, anderer Zweck

Beispieldaten zeigen, wie etwas aussieht: eine Musterrechnung, ein ausgefülltes Formular in einer Anleitung, eine Demo-Oberfläche für eine Präsentation. Testdaten füllen eine Software, damit sich prüfen lässt, ob sie sich richtig verhält: Datenbank-Seeds, Lasttests, automatisierte Tests, Importe. In beiden Fällen gilt dieselbe Regel: Die Werte müssen plausibel wirken, dürfen aber keinem echten Menschen, Konto oder Unternehmen gehören.

Wann erfundene Daten sinnvoll sind

• Entwicklung und Tests: Formulare, Validierungen, Importe und Berichte lassen sich nur prüfen, wenn Daten vorhanden sind, möglichst viele und mit Sonderfällen wie Umlauten, langen Namen oder fehlenden Angaben.
• Demos und Schulungen: Wer eine Software vorführt oder lehrt, braucht Daten, die man gefahrlos auf dem Bildschirm zeigen darf.
• Dokumentation und Screenshots: Anleitungen sollen echte Formate zeigen, ohne dass jemand eine Person oder ein Konto wiedererkennt.
• Vorlagen: Eine Musterrechnung mit erkennbar erfundenen Angaben verhindert, dass versehentlich Daten eines Kunden in Umlauf geraten.

Warum echte Daten in Tests nichts verloren haben

Namen, Adressen, Kontonummern und Steuerkennzeichen realer Personen sind personenbezogene Daten. Die Datenschutz-Grundverordnung verlangt unter anderem, dass solche Daten nur für festgelegte Zwecke verarbeitet und angemessen geschützt werden. Testsysteme sind oft weniger streng abgesichert als der Produktivbetrieb, werden von mehr Personen genutzt und landen in Backups, Logs und Screenshots. Kopien echter Kundendaten dort zu verwenden, vergrößert das Risiko eines Datenlecks und ist in vielen Fällen nicht vom ursprünglichen Zweck gedeckt. Erfundene Daten umgehen das Problem von vornherein. Das ist eine allgemeine Einordnung und keine Rechtsberatung; für Ihren konkreten Fall klären Sie die Anforderungen mit Ihrer Datenschutzbeauftragten oder einer fachkundigen Stelle.

Was erzeugte Werte sicher macht

„Erfunden“ allein genügt nicht: Eine zufällig erzeugte Zahl kann zufällig einer echten gehören. Sichere Beispielwerte werden deshalb aus Bereichen gewählt, die gezielt frei von echten Inhabern sind.

E-Mail-Adressen und Webadressen

RFC 2606 reserviert die Domains example.com, example.net und example.org für Beispiele und Dokumentation. Ebenso sind die Top-Level-Domains .test, .example, .invalid und .localhost reserviert. Eine Adresse wie anna.mueller@example.org kann deshalb nie in einem echten Postfach ankommen. Der Testdaten-Generator verwendet ausschließlich diese Beispiel-Domains.

Telefonnummern

Die Bundesnetzagentur hat für Medienproduktionen Rufnummernbereiche freigegeben, die dauerhaft keinem Teilnehmer zugeteilt werden („Drama Numbers“). Für Festnetznummern sind das je 1.000 Nummern in fünf Ortsnetzen, darunter 030 23125-000 bis -999 (Berlin) und 089 99998-000 bis -999 (München). Der Testdaten-Generator zieht seine Festnetznummern aus diesen Bereichen. Quelle ist die Mitteilung 148/2021 der Bundesnetzagentur (siehe Quellen unten).

IBANs

Eine IBAN besteht aus Ländercode, zwei Prüfziffern und der nationalen Kontokennung, in Deutschland Bankleitzahl und Kontonummer. Erzeugte Test-IBANs verwenden eine Bankleitzahl, die kein Institut führt (00000000), und berechnen die Prüfziffern korrekt. Formulare und Validatoren, die nur die Prüfsumme prüfen, akzeptieren sie, ein echtes Konto gibt es dahinter nicht. Wie das genau funktioniert, zeigt der IBAN-Generator.

Bewusst falsche Prüfziffern

Bei Kennzeichen, deren Prüfziffer sich aus den übrigen Stellen berechnen lässt, besteht ein Restrisiko: Eine zufällig erzeugte Nummer mit richtiger Prüfziffer könnte tatsächlich vergeben sein. Deshalb tragen die Beispiel-USt-IdNr. dieser Seite eine absichtlich falsche Prüfziffer. Sie bestehen den Formatcheck, scheitern aber an der Prüfziffer und können keiner realen Nummer entsprechen. Bei Beispiel-Steuer-IDs beginnt die erste Ziffer mit 0, was bei echten Nummern nicht vorkommt. Der Unterschied zwischen den Prüfstufen steht im Beitrag Format-gültig, prüfsummen-gültig, vergeben.

Grenzen von Beispieldaten

Namen werden aus häufigen Vor- und Nachnamen zusammengesetzt. Eine Person mit genau diesem Namen kann existieren; der Rest des Datensatzes (Adresse, Konto, Nummern) ist jedoch erfunden. Ortsnamen sind fiktiv, die Postleitzahl ist nur fünfstellig gewählt und gehört nicht zwingend zu einem bestehenden Ort. Wer eine Software gegen echte Prüfdienste testen will, etwa eine Adress- oder Bonitätsprüfung, braucht die Testwerte des jeweiligen Anbieters aus dessen Dokumentation.

Weiter

Erzeugen Sie komplette Datensätze mit dem Testdaten-Generator oder lesen Sie unter Methodik und Quellen nach, nach welchen Regeln die Werte entstehen.