Zufällige Adressen erzeugen sieht nach dem einfachsten Werkzeug im Testbaukasten aus und verhält sich wie eines der subtilsten. Zufall ist gerade deshalb nützlich, weil er Kombinationen erkundet, die niemand aufgeschrieben hätte. Eine Adresse ist aber kein Beutel unabhängiger Werte, sondern ein kleines Geflecht von Beziehungen, und Zufall, der auf jedes Feld einzeln angewendet wird, zerstört genau diese Beziehungen.
Dieser Leitfaden erklärt, was zufällig sein sollte und was niemals, warum ein reproduzierbarer Schlüssel wichtiger ist als ein großer Vorrat an Varianten, wie ein Stapel-Export die Form Ihrer Testsuite verändert und welche Mehrländerfehler immer wieder auftauchen. Am Ende wissen Sie, wie Sie Vielfalt bekommen, ohne Widersprüche zu bekommen.
Warum sind zufällig und widersprüchlich zwei verschiedene Probleme?
Eine zufällige Adresse ist nicht dasselbe wie eine beliebige. Der Zufall sitzt in den Teilen, die keine Beziehungen tragen: die Hausnummer, der Gebäudename, die genaue Schreibvariante einer Straße, die Reihenfolge der Datensätze in einem Stapel. Die deterministischen Teile sind die, die einander einschränken, und die sollten abgeleitet statt gezogen werden.
Betrachten Sie, was passiert, wenn jedes Feld unabhängig gezogen wird. Die Stadt kommt aus einer Liste, die Verwaltungseinheit aus einer zweiten, die Postleitzahl aus einer dritten und die Telefonvorwahl aus einer vierten. Jeder einzelne Wert ist gültig, und die Kombination ist es nicht. Vier gültige Werte ergeben einen ungültigen Datensatz, und keine noch so sorgfältige Auswahl der Listen verhindert das.
Die Regel, die das auflöst, ist die Erzeugungsreihenfolge. Wählen Sie das Land, dann die erste Verwaltungsebene, dann den Ort, und leiten Sie daraus Postleitzahl und Telefonvorwahl ab. Zufall wird anschließend nur dort angewendet, wo er nichts widersprechen kann, und das liefert Vielfalt ohne die Fehlerklasse, an der handgebaute Fixtures leiden. Die Seite Adressgenerator führt dieses Prinzip für einzelne Länder durch.
Es gibt eine hilfreiche Art, den Unterschied zu beschreiben. Ein Werkzeug zum Erzeugen zufälliger Adressen zieht nicht zwölf Felder, sondern es zieht einen Ort und beschreibt ihn anschließend in dem Format, das dieser Ort verwendet. Sobald Sie den Datensatz zuerst als Ort und erst danach als Feldmenge denken, ist die Ableitungsreihenfolge kein technisches Detail mehr, sondern der naheliegende Weg.
Praktisch lässt sich das in drei Zonen einteilen:
- Zone eins: Werte ohne Beziehungen, vollständig zufällig
- Zone zwei: Werte mit Beziehungen, ausschließlich abgeleitet
- Zone drei: Werte, deren Zufälligkeit die Testabsicht bestimmt
Wer diese Zonen in der eigenen Testdatenstrategie nicht trennt, verbringt die meiste Zeit mit der Fehlersuche in Datensätzen, die nie hätten entstehen dürfen.
Was sollte zufällig sein und was fest?
Die Werte, die variieren sollten, sind die, die ein Formular als undurchsichtige Eingabe verbraucht: Straßennamen innerhalb einer gültigen Menge, Hausnummern, Einheitenbezeichner, Firmennamen, Empfängernamen und die Reihenfolge der Datensätze in einem Export. Wenn diese variieren, werden Layout, Längengrenzen und Zeichenbehandlung Ihrer Felder geprüft, und genau dafür ist ein Zufallsgenerator da.
Die Werte, die fest sein sollten, sind die mit angehängten Beziehungen. Die Verwaltungseinheit muss zum Ort passen. Die Postleitzahl muss zur Verwaltungseinheit passen. Die Telefonvorwahl muss zur Region passen. Das Land muss zum Format jedes anderen Feldes passen. Nichts davon darf unabhängig gezogen werden, und ein Werkzeug, das dafür einen vollständig zufälligen Modus anbietet, bietet Ihnen einen Fehler an.
Es gibt eine dritte Kategorie, die einen Namen verdient: Werte, die in manchen Tests zufällig und in anderen eingefroren sein sollten. Ein Geburtsdatum etwa ist nützlich zufällig, wenn Sie nach Fehlern an Altersgrenzen suchen, und schädlich, wenn Sie auf eine bestimmte Antwort prüfen. Die Entscheidung gehört zum Test, nicht zum Generator, weshalb ein Generator, der einzelne Felder festnageln lässt, brauchbarer ist als einer mit einem einzigen Zufallsmodus.
Ein Beispiel macht die Abgrenzung greifbar. Wenn ein Test die Anzeige eines langen Straßennamens prüfen soll, dann ist der Straßenname der Zufallsteil und alles andere fest. Wenn ein Test die Altersgrenze eines Formulars prüfen soll, dann ist das Geburtsdatum der Zufallsteil und der Rest fest. Beides sind Zufallstests, aber sie brauchen unterschiedliche Felder im freien Zustand, und ein Generator, der nur alles oder nichts kann, erzwingt eine Krücke.
Warum schlägt Reproduzierbarkeit die Vielfalt?
Derselbe Schlüssel und dasselbe Land sollten immer denselben Datensatz erzeugen. Das klingt nach einer Einschränkung der Zufälligkeit und ist tatsächlich die Eigenschaft, die erzeugte Daten in automatisierten Tests überhaupt verwendbar macht.
Eine Zusicherung vergleicht einen beobachteten Wert mit einem erwarteten. Ändert sich die Eingabe zwischen den Läufen, muss sich der erwartete Wert mitändern, und der Test hört auf, etwas über das Verhalten auszusagen, und beginnt damit, die Unvorhersehbarkeit des Generators zu behaupten. Das ist ein Test, der nur aus den falschen Gründen scheitern kann.
Reproduzierbarkeit macht Fehlschläge außerdem nachvollziehbar. Wenn ein Test an einem erzeugten Datensatz scheitert, lautet die erste Frage, was der Datensatz enthielt. Mit einem Schlüssel können Sie ihn exakt neu erzeugen und ansehen. Ohne einen ist der Datensatz weg, der Fehlschlag ist nicht wiederholbar, und der Fehlerbericht wird zu einer Anekdote.
Das ist die Eigenschaft, um die herum der Adressgenerator gebaut ist: ein Schlüssel, ein Land, ein stabiler Datensatz und ein anderer Schlüssel, sobald Sie einen anderen Datensatz wollen. Es ist zugleich der Grund, warum ein Werkzeug mit einer einzigen Mischschaltfläche schwächer ist, als es zunächst wirkt, denn ein Mischen lässt sich nicht wiederholen, wenn ein Build im nächsten Monat scheitert und niemand die auslösenden Daten rekonstruieren kann.
Das praktische Muster ist ein stabiler Schlüssel pro Fixture. Ein Schlüssel für die Fixture, die den Normalfall fährt, ein weiterer für den Datensatz mit dem ungewöhnlich langen Straßennamen, ein dritter für den Datensatz, dessen Postleitzahl den erweiterten Zusatz trägt. Ein Schlüssel pro Fixture ist besser als einer pro Test, weil mehrere Tests denselben Datensatz teilen können und eine Änderung daran eine bewusste Handlung wird statt eines Zufalls.
Neben dem Schlüssel lohnt es sich, die Randfälle ausdrücklich aufzuschreiben, die Ihre Suite abdecken soll:
- ein Straßenname an der oberen Längengrenze
- eine Hausnummer mit Buchstabenanhang
- ein Ort mit Sonderbuchstaben und Diakritika
- ein Land ohne Postleitzahlsystem
- eine Empfängername mit Bindestrich oder Apostroph
Jede dieser Zeilen prüft eine andere Stelle in Rendering, Speicherung oder Export, und jede davon lässt sich mit demselben Schlüsselmechanismus dauerhaft reproduzieren.
Wie verändert der Stapel-Export Ihre Testsuite?
Eine einzelne erzeugte Adresse unterstützt eine manuelle Prüfung. Ein Stapel von zehntausend unterstützt eine ganz andere Art des Testens, und das Exportformat ist wichtiger als die Anzahl. Eine CSV-Datei mit einer Zeile pro Adresse und stabilen Spaltenüberschriften erlaubt es Ihnen, eine datengetriebene Testschelfe zu betreiben, eine Staging-Datenbank zu befüllen und nach einer Migration Anzahl und Verteilung zu vergleichen.
Zwei Eigenschaften machen einen Export brauchbar. Die erste ist, dass die Kopfzeile die Felder so benennt, wie Ihr Schema sie benennt, damit die Zuordnung ausdrücklich ist und nicht geraten wird. Die zweite ist, dass jede Zeile eine Markierung trägt, die sie als erzeugte Daten ausweist, sei es in einer eigenen Spalte oder im Dateinamen samt Datensatznotiz, damit ein verirrter Export nicht für einen Produktionsauszug gehalten werden kann.
Große Stapel bringen außerdem Probleme an die Oberfläche, die kleine verbergen. Wenn Sie tausend Adressen für ein Land exportieren und sich die Postleitzahlen auf eine Handvoll Werte ballen, oder wenn sich die Städteliste nach zwanzig Zeilen wiederholt, dann zeigt der Stapel ein Abdeckungsproblem, das eine Stichprobe von zehn Datensätzen nie sichtbar gemacht hätte. Verteilungsfehler sind die Sorte Defekt, die erst bei Menge auftritt, und das ist ein weiterer Grund, mit Menge zu testen.
Bevor Sie einen Stapel in Ihre Suite hängen, prüfen Sie vier Dinge:
- Spaltenüberschriften deckungsgleich mit dem Zielschema
- jede Zeile als erzeugt markiert
- Verteilung der Postleitzahlen über mehrere Werte gestreut
- Zeichensatz der Sonderbuchstaben im Export verlustfrei erhalten
Der letzte Punkt ist der unauffälligste und der teuerste. Ein Export, der beim Öffnen in einer Tabellenkalkulation Zeichen verliert, liefert eine Fixture, deren Fehler niemand auf das Format zurückführt.
Was bricht zuerst, wenn Sie Länder mischen?
Die Mehrländererzeugung ist der Ort, an dem die interessanten Defekte leben, weil die Beziehungen, die innerhalb eines Landes gelten, über Grenzen hinweg nicht existieren. Der erste Fehlschlag ist die Unstimmigkeit zwischen Postleitzahl und Region, bei der eine gültige Postleitzahl aus dem falschen Land an einer gültigen Stadt hängt, was keine Einzelfeldprüfung jemals findet.
Der zweite ist die Telefonvorwahl. Eine Nummer, die die Auslandsvorwahl des einen Landes trägt, während die Adresse in einem anderen liegt, ist eine Unstimmigkeit, die eine sorgfältige Suite melden sollte. Der dritte ist das Feldmengenproblem: Länder teilen kein Schema, ein Datensatz für ein Land ohne Postleitzahl erzeugt also ein leeres Feld dort, wo Ihr Test fünf Ziffern erwartet hat.
Der vierte Fehlschlag ist subtiler und stammt aus dem Formular statt aus den Daten. Wenn Ihre Adressvorlage für jedes Land auf einem Region-Feld besteht, trägt jeder erzeugte Datensatz einen Regionswert, der in den meisten Ländern nichts bedeutet. Die Länderdaten auf dieser Seite zeigen, wie sich Feldmengen je Land unterscheiden und warum eine universelle Vorlage ein Kompromiss statt einer Lösung ist.
Es gibt einen fünften Fehlschlag, der erst sichtbar wird, wenn Datensätze miteinander verglichen werden. Ein Stapel, der Länder mischt, sortiert sich unter einer einzigen Sortierregel nicht korrekt, weil die Buchstaben der einen Sprache anders geordnet werden als die der anderen. Eine Liste, die durcheinandergewürfelt aussieht, ist meist gar nicht gewürfelt: Sie wurde nach den falschen Regeln sortiert, und die Korrektur gehört in die Anzeigeschicht statt in die Daten.
Für die tägliche Arbeit heißt das: Führen Sie je Land eine eigene Feldmenge und ein eigenes Abnahmekriterium. Länder, die Ihre Suite gemeinsam behandelt, verlieren die Beziehungen, die den Wert der Datensätze ausmachen, und die Prüfungswerkzeuge verlieren damit ihre Grundlage. Die Prüfwerkzeuge helfen, Formate einzelner Länder gegen eigene Beispiele zu halten.
Sind zufällige Adressen für Lasttests geeignet?
Sie sind es, unter einer Bedingung: Der Lasterzeuger darf nicht mehr Zeit mit Erzeugen verbringen als das System mit Bedienen. Ein Generator, der einen wohlgeformten Datensatz in konstanter Zeit liefert, taugt für eine Lastprobe; einer, der jeden Datensatz gegen einen entfernten Dienst prüft, taugt nicht.
Das brauchbare Muster ist, einen großen Stapel vorab und außerhalb des Lastlaufs zu erzeugen, ihn zu speichern und den Lasttest daraus lesen zu lassen, statt den Generator in der heißen Schleife aufzurufen. Das macht den Lasttest außerdem reproduzierbar, weil bei jedem Lauf derselbe Stapel abgespielt wird und als einzige Variable das geprüfte System übrig bleibt.
Fuzzing ist der umgekehrte Fall. Dort wollen Sie absichtlich fehlerhafte Eingaben, und ein Generator, der ausschließlich gültige Datensätze liefert, hilft nicht. Der produktive Ansatz besteht darin, einen gültigen Datensatz zu erzeugen und ihn anschließend kontrolliert zu verändern: ein Feld abschneiden, ein Zeichen außerhalb des erwarteten Satzes einfügen, die Postleitzahl gegen einen Wert aus einem anderen Land tauschen. Halten Sie fest, welche Veränderung das System toleriert hat. Eine Veränderung, die eine Formatprüfung passiert und einen nachgelagerten Prozess bricht, ist ein Fund, der es wert ist, festgehalten zu werden. Führen Sie den Katalog der Veränderungen zusammen mit den Generatoreinstellungen in der Versionsverwaltung, damit eine Veränderung, die einmal einen Fehler ausgelöst hat, bei jedem weiteren Lauf erneut abgespielt wird.
Für Identitätsdaten gilt dasselbe Muster mit anderen Beziehungen: Ein Name, ein Geburtsdatum und eine Kennung müssen zueinander passen, sonst prüfen Sie Formulare, die es so nie gibt. Die Identitätsdaten auf dieser Seite behandeln diese Abhängigkeiten getrennt.
Was ein zufälliger Datensatz nicht sein kann
Eine erzeugte Adresse ist synthetischer Datenbestand mit korrekter Struktur und in sich stimmigen Feldern. Sie ist kein zustellbarer Ort, sie entspricht keinem Gebäude, und sie ist auf keine Person und keine Organisation registriert. Sie wird von keinem Zusteller angenommen und kann nicht als Nachweis eines Wohnsitzes dienen.
Diese Grenze sollte im Datensatz selbst stehen und nicht nur in einem Dokument daneben. Eine Spalte, die die Zeilen als erzeugt markiert, ein Dateiname, der es ausspricht, und eine Notiz in der Fixture, die den Zweck der Daten beschreibt, machen einen Unfall deutlich unwahrscheinlicher, und ein Unfall ist der Weg, auf dem Testdaten dorthin gelangen, wo sie nie hingehören sollten.
Zufall macht Daten außerdem nicht anonym, wenn die Werte von echten Personen stammen. Einen echten Namen und eine echte Adresse aus einem realen Datensatz zu ziehen und zu mischen, erzeugt eine andere Art von Problem statt einer Lösung. Der einzig sichere Testdatensatz ist einer, der nie jemandem gehört hat.
Eine weitere Eigenschaft verdient einen Namen, weil sie leicht verloren geht, sobald ein Werkzeug nach der Vielfalt seiner Ausgabe beurteilt wird. Ein zufälliger Datensatz bleibt ein Datensatz, und ein Datensatz mit einem Zweck sollte speicherbar sein. Wenn Sie die erzeugte Adresse nicht in eine Datei schreiben, als Fixture festschreiben und sechs Monate später aus einer Notiz neu erzeugen können, dann kostet der Zufall Sie Reproduzierbarkeit, ohne Ihnen etwas zu kaufen, das eine größere feste Stichprobe nicht auch geliefert hätte.
Jeder so erzeugte Datensatz existiert, um Software zu testen, und für nichts anderes. Er darf nicht verwendet werden, um sich als jemand auszugeben, um echte Konten zu eröffnen oder zu registrieren, um tatsächliche Post zu empfangen, um eine Adresse oder eine Identität nachzuweisen oder um eine Verifizierungsstufe zu umgehen.