Test-Identitätsdaten sind eine erfundene Person, vollständig aufgeschrieben. Es ist ein Name, eine Adresse, ein Geburtsdatum, eine staatliche Identifikationsnummer, eine Telefonnummer und eine Handvoll kleinerer Felder, so zusammengesetzt, dass Software an einem Datensatz arbeiten kann, der gewöhnlich aussieht, ohne irgendjemanden zu beschreiben, den es gibt.
Dieser Leitfaden erklärt, wo solche Datensätze herkommen, in welchen Situationen sie tatsächlich gebraucht werden, warum Produktivdaten ein schlechter Ersatz sind, selbst wenn sie verfügbar sind, und was ein Erzeuger garantiert — und was nicht.
Was Test-Identitätsdaten tatsächlich sind
Nimmt man den Fachjargon weg, bleibt von einem Test-Identitätsdatensatz eine zusammenhängende Menge von Antworten auf die Fragen eines Formulars. Jemand hat einen Vornamen und einen Familiennamen, wohnt an einer Adresse in einer bestimmten Region, wurde an einem bestimmten Tag geboren und besitzt die Identifikationsnummer, die diese Region ausgibt. Der Datensatz ist in dem Sinn zusammenhängend, dass die Antworten zueinander passen.
Was ihn zu Testdaten statt zu echten Daten macht, ist die Herkunft. Nichts darin wurde von einem Menschen abgeschrieben, und nichts darin gehört einem Menschen. Er hat die Gestalt einer Person, damit ein System ihn verarbeiten kann, und hat keinen Bezug außerhalb des Tests.
Dieser Unterschied wiegt schwerer, als er klingt. Ein Datensatz kann gleichzeitig einwandfrei formatiert und vollständig erfunden sein, und beide Eigenschaften sind der Punkt.
Wann braucht ein Team solche Datensätze wirklich?
Fünf Situationen tauchen immer wieder auf. Sie sehen verschieden aus, teilen aber eine Anforderung: Die Software muss eine plausible Eingabe erhalten, während die Ausgabe irgendwo harmlos landet.
| Situation | Was ohne erzeugte Datensätze schiefgeht |
|---|---|
| Funktionstests von Formularen | Prüfregeln für Länge, Zeichensatz und Pflichtfelder lassen sich überhaupt nicht durchspielen |
| Vorführungen und Screenshots | Platzhaltertext aus einem einzigen wiederholten Buchstaben lässt das Produkt unfertig wirken |
| Massenbefüllung und Lastproben | Eine Datenbank braucht Tausende Zeilen, bevor irgendjemand die Leistung ehrlich messen kann |
| Automatisierte Test-Fixtures | Zusicherungen driften, wenn derselbe Test bei jedem Lauf einen leicht anderen Datensatz erzeugt |
| Migrationproben | Ein Umzug zwischen Umgebungen lässt sich nicht an Daten proben, die der echten Form nicht ähneln |
Keine dieser Situationen wird durch Details echter Menschen besser, und mehrere werden schwieriger, sobald echte Details hineingemischt werden. Das ist kein moralischer Punkt, sondern ein praktischer darüber, was ein Test braucht, um nützlich zu sein.
Warum Produktivdaten der falsche Ersatz sind
Der Impuls, einen Ausschnitt der Produktion in eine niedrigere Umgebung zu kopieren, ist verständlich. Echte Daten haben die richtige Verteilung, die richtigen Randfälle und die richtige Unordnung. Sie sind zugleich die teuerste Art von Daten, die man verlieren kann, und niedrigere Umgebungen sind genau der Ort, an dem Sicherheitsvorkehrungen am schwächsten sind.
Daraus folgen zwei Fehler. Der erste ist regulatorisch: Ein Name zusammen mit einem Geburtsdatum, einer Identifikationsnummer oder einem Kontaktdetail ist ein personenbezogenes Datum, und es in eine Entwicklungsumgebung zu verschieben ist eine neue Verwendung, der niemand zugestimmt hat. Der zweite ist betrieblich: Die Kopie bleibt in Sicherungen, in Abfrageprotokollen, in Screenshots an Fehlerberichten und auf den Laptops aller, die sie je wiederhergestellt haben. Die Organisation hat nun weit mehr Kopien derselben sensiblen Datensätze als vorher, an Orten, an denen niemand hinsieht.
Der Artikel Datenschutzregeln für Testdaten geht das ausführlicher durch, einschließlich der Frage, warum das Herausstreichen von Namen aus einer kopierten Tabelle nicht dasselbe ist wie eine anonyme Tabelle. Die Kurzfassung: Der sicherste Testdatensatz ist einer, der nie jemandem gehört hat.
Was ein erzeugter Datensatz enthält
Der Identitätsdatensatz-Erzeuger baut das ganze Set auf einmal auf, statt Feld für Feld. Ein Datensatz trägt üblicherweise einen persönlichen Teil mit Namen, Geburtsdatum und Geschlecht; einen Adressteil mit Straße, Ort, Verwaltungsgliederung und Postleitzahl; Kontaktdetails; und die administrativen Kennungen, die das gewählte Land tatsächlich ausgibt.
Zwei Eigenschaften lohnen sich zu verstehen, bevor man sich auf die Ausgabe verlässt. Die erste ist die innere Stimmigkeit: Die Adresse gehört zu dem Land, das Sie ausgewählt haben, die Telefonnummer trägt dessen Landesvorwahl, und wo die nationale Kennung eines Landes eine veröffentlichte Prüfziffernregel hat, erfüllt die erzeugte Nummer sie. Die zweite ist die Wiederholbarkeit. Die Ausgabe hängt an einem Identitätsschlüssel, und derselbe Schlüssel mit demselben Land erzeugt genau denselben Datensatz — das macht einen erzeugten Datensatz in einem automatisierten Test brauchbar und nicht nur in einem manuellen.
Jeder so erzeugte Datensatz ist synthetisch und existiert allein für Tests; er darf nicht dazu verwendet werden, sich als echte Person auszugeben, und er ist keine Bescheinigung, die eine Behörde ausgestellt hat oder akzeptieren würde.
Müssen erzeugte Datensätze echt aussehen?
Sie müssen gewöhnlich aussehen, und das ist eine schwächere Anforderung. Ein Datensatz, der exotisch aussieht, testet das Falsche: Wenn jeder erzeugte Familienname einsilbig ist oder jeder Straßenname ein Platzhalterausdruck, wird das Layout nie belastet und die Prüfung nie ausgelöst. Erzeugte Daten verdienen ihren Platz, wenn sie in derselben Form landen wie die echte Eingabe, die das System später erhält — einschließlich der unhandlichen Formen: lange Namen, Namen mit diakritischen Zeichen, Adressen ohne Leerzeichen, Nummern mit führender Null.
Gewöhnlich auszusehen ist nicht dasselbe wie brauchbar zu sein. Eine korrekt geformte Identifikationsnummer zu besitzen heißt nicht, dass sie irgendjemandem gehört, und sie wird eine Prüfung bei der ausstellenden Stelle nicht bestehen, weil dahinter kein Eintrag steht, den man befragen könnte.
Warum dieselben Feldpaare immer wieder durch Stimmigkeitsprüfungen fallen
Teams, die Testdatensätze von Hand bauen, treffen dieselben Defekte immer wieder, und es sind fast immer Beziehungsfehler und keine Wertfehler. Die Straße ist plausibel, der Ort ist plausibel, die Postleitzahl ist plausibel — und die drei gehören zu verschiedenen Ländern.
Der Grund ist, dass ein handgeschriebener Datensatz Feld für Feld zusammengesetzt wird, und jedes Feld wird von der Person, die es tippt, für sich beurteilt. Der Zufall macht dasselbe in Schnelligkeit: Unabhängige Ziehungen erzeugen unmögliche Paare weit häufiger, als die Intuition vermuten lässt. Ein Erzeuger vermeidet das, indem er zuerst das Land und die Verwaltungsgliederung festlegt und alles Weitere aus diesen beiden Entscheidungen ableitet; deshalb ist die Frage nach der Feldkonsistenz in Wahrheit eine Frage nach der Reihenfolge der Erzeugung.
Für Entwickler: Woraus ein Identitätsdatensatz besteht
Modellieren Sie den Datensatz als Felder mit Abhängigkeiten und nicht als flache Zeile unabhängiger Spalten. Name und Geschlecht, Geburtsdatum und Alter, Land und Telefonvorwahl, Gliederung und Postleitzahl, Land und Kennungsformat: In jedem Paar schränkt ein Mitglied das andere ein, und ein Schema, das diese Beziehung verbirgt, lässt widersprüchliche Zeilen zu.
Zwei Gewohnheiten auf Feldebene verhindern den meisten Schaden. Leiten Sie das Alter nie aus einer gespeicherten ganzen Zahl ab, wenn auch das Geburtsdatum gespeichert ist — behalten Sie das Datum und berechnen Sie das Alter, sonst widersprechen sich beide, sobald ein Jahr vergeht. Und wo ein Land keine bestimmte Kennung ausgibt, behandeln Sie das Feld als berechtigt leer, statt es mit einer plausibel aussehenden Zeichenfolge zu füllen; ein leeres Feld und ein falsches Feld scheitern auf sehr verschiedene Weise.
Für Fixtures gilt: Bevorzugen Sie einen festen Datensatz gegenüber einem frisch zufälligen, wann immer sich die Zusicherung auf Verhalten richtet und nicht auf Eingabevielfalt. Ein Test, der eine bestimmte Antwort zusichert, muss wissen, welche Eingabe vorlag. Behalten Sie die zufällige Erzeugung den Tests vor, die unbekannte Randfälle suchen, und sobald ein solcher Test etwas findet, frieren Sie diesen Datensatz als Fixture ein, damit die Regression festgeschrieben ist. Was die Fixture auch enthält, der Vermerk in der Datei sollte es klar sagen: Diese Datensätze sind synthetisch, sie dienen allein Softwaretests, und sie sind nicht als Identität irgendeiner Person zu verwenden.
Nächste Schritte
Nehmen Sie ein Formular in Ihrem Produkt und füllen Sie es mit einem erzeugten Datensatz statt mit dem Platzhaltertext, der dort wahrscheinlich noch steht. Nehmen Sie dann denselben Identitätsschlüssel und erzeugen Sie erneut — unterscheidet sich der zweite Datensatz vom ersten, sehen Sie ein Werkzeug, das automatisierte Zusicherungen nicht tragen kann; der Artikel über Test-Fixtures beschreibt, was Sie stattdessen verlangen sollten.