dataset Testdaten-Generator star

Warum Testen mit echten Nutzerdaten eine schlechte Praxis ist

Eine Entwicklungsdatenbank zu befüllen, indem man einen Ausschnitt der Produktions-Kundentabelle exportiert, fühlt sich bequem an und ist eine der häufigsten Arten, wie Unternehmen versehentlich personenbezogene Daten preisgeben. Unter Regelungen wie der EU-DSGVO und der türkischen KVKK sollen personenbezogene Daten nur für den spezifischen Zweck verarbeitet werden, für den sie erhoben wurden, und mit einer diesem Zweck angemessenen Sicherheit geschützt werden — eine Staging- oder Dev-Umgebung ist routinemäßig weit weniger abgesichert als die Produktion, oft für jeden Ingenieur erreichbar, manchmal sogar in weniger sicheren Speicher geloggt oder gesichert, oder versehentlich offengelegt, wenn eine Staging-URL indexiert wird oder ein Testserver falsch konfiguriert ist. Der Name, die E-Mail, die Telefonnummer und die Adresse eines echten Kunden in einer Datenbank, die nie auf dieses Maß an Exposition geprüft wurde, ist ein Lehrbuchbeispiel für ein Compliance- und Sicherheitsrisiko, und „wir haben Produktionsdaten in einer Demo verwendet" ist ein wiederkehrender Satz in echten Post-Mortems von Datenpannen. Erfundene Daten umgehen das gesamte Problem: Es gibt keine echte Person zu benachrichtigen, keine Einwilligungsgrundlage zu rechtfertigen und keinen Verstoß zu melden, wenn eine Testdatenbank durchsickert, weil die Zeilen nie jemandem entsprachen.

Über die Compliance hinaus sind erfundene Testdaten für QA auch schlicht nützlicher. Echte Produktionsdaten spiegeln wider, wie Ihre bestehenden Nutzer zufällig aussehen — sie enthalten nicht zuverlässig die Grenzfälle, die Tester tatsächlich brauchen, wie Namen mit ungewöhnlichen Zeichen, leere optionale Felder, maximal lange Zeichenketten oder eine gleichmäßige Streuung über jede Eingabe, die ein Formular akzeptiert. Synthetische Erzeugung lässt Sie Umfang und Form präzise kontrollieren: Dieses Werkzeug lässt Sie zwischen 1 und 100 Zeilen anfordern und genau auswählen, welche Felder befüllt werden — ein Arbeitsablauf, für den echte Kundenexporte nie konzipiert waren.

Wie die Zufälligkeit funktioniert

Jeder Wert hier — welcher Name, welche Stadt, welche Ziffern in einer Telefonnummer — wird mit crypto.getRandomValues() ausgewählt, der kryptografisch sicheren Zufallszahlenquelle der Web-Crypto-API, statt mit Math.random(). Um genau zu sein, warum: Das tatsächliche Sicherheitsrisiko bei der Wahl eines falschen Namens für eine Testzeile ist nahezu null, daher ist dies keine Sicherheitsanforderung, wie es etwa bei der Erzeugung eines Passworts oder eines Sitzungstokens der Fall wäre. Der Grund, warum dieses Werkzeug es trotzdem verwendet, ist, die richtige Standardgewohnheit zu demonstrieren — Math.random() ist ein schneller, nicht-kryptografischer Pseudozufallsgenerator, dessen Ausgabe im Prinzip über Umgebungen hinweg vorhersehbar oder reproduzierbar sein kann, während crypto.getRandomValues() aus der sicheren Entropiequelle des Betriebssystems schöpft und das richtige Werkzeug ist, wann immer Zufälligkeit unvorhersehbar sein muss — deshalb vermeidet der standardmäßige Griff danach den Fehler, Math.random() in einem Kontext zu verwenden — etwa bei der Erzeugung eines Rabattcodes oder Reset-Tokens —, in dem Vorhersehbarkeit tatsächlich eine Rolle spielen würde. Um Modulo-Bias zu vermeiden (eine subtile Verzerrung, die manche Werte geringfügig wahrscheinlicher macht als andere, wenn sich der Zufallsbereich nicht gleichmäßig auf den Ausgaberaum verteilt), verwendet jede Auswahl Rejection Sampling: Werte, die diese Verzerrung einführen würden, werden verworfen und neu gezogen.

• Getrennte Namens- und Städtepools je Sprache: Die Wahl von „Türkisch" erzeugt Daten aus einem eigenen Pool türkischer Vornamen, Nachnamen und Städte; die Wahl von „Englisch" schöpft aus einem separaten englischsprachigen Pool, sodass die Daten sprachlich konsistent wirken statt wie eine Mischung nicht zusammenhängender Namenskonventionen.
• Nur erfundene Domains: Erzeugte E-Mails verwenden immer example.com, example.org oder example.net — die durch RFC 2606 formal für Dokumentations- und Testzwecke reservierten Domains — niemals eine echte, registrierbare Domain, die versehentlich Post irgendwohin weiterleiten könnte.
• Der CSV-Export ist im RFC-4180-Format: Felder sind durch Kommas getrennt und in Anführungszeichen gesetzt, sodass Werte mit Kommas, Anführungszeichen oder Zeilenumbrüchen trotzdem korrekt in Excel, Google Sheets oder jedem standardkonformen CSV-Importer geparst werden.
• Vollständig lokal: Die Erzeugung findet in Ihrem Browser statt; nichts wird an einen Server gesendet, protokolliert oder irgendwo außerhalb Ihres eigenen Downloads gespeichert.