Zufallsdatum-Generator für Tests: Bessere Testdaten erstellen

01 / ZWECK

Was ein Zufallsdatum-Generator für Tests liefern sollte

Ein nützliches Fixture ist mehr als eine Zeichenkette, die wie ein Datum aussieht. Es hat einen Zweck: ein Anmeldedatum, ein Buchungsfenster, eine Frist, einen Berichtsfilter oder ein zu sortierendes Ereignis. Der Generator liefert schnell Variation, doch der Testplan entscheidet, was diese Variation beweisen soll. Benennen Sie zuerst das Feld und das gewünschte Verhalten.

Eine nach created_at sortierte Liste sollte mehrere Monate enthalten und nicht in jeder Zeile denselben Januartag. Ein Buchungsformular braucht Werte vor, innerhalb und nach dem erlaubten Fenster. Eine Altersregel muss den Tag vor dem Geburtstag, den Geburtstag selbst und den Folgetag prüfen. Die Auswahl ist die Eingabe; die Assertion bleibt Ihre Aufgabe.

Diese Abgrenzung trennt den Leitfaden vom Startwerkzeug. Die Startseite löst die direkte Auswahl eines Datums. Dieser Artikel erklärt den nächsten Schritt: die Auswahl in Belege für Softwareverhalten zu verwandeln, für Entwickler, Tester, Analysten und technische Autoren.

• Benennen Sie das Feld oder die Funktion, die das Datum erhält.
• Definieren Sie das Verhalten, das für jeden Wert gelten muss.
• Entscheiden Sie, welche Grenzwerte bewusst ergänzt werden müssen.

02 / DATUMSMODELL

Klären Sie, ob das Feld Datum, Uhrzeit oder Zeitstempel ist

Klären Sie vor der Erzeugung die Bedeutung des Feldes. Ein Kalenderdatum wie ein Fälligkeitstag hat keine Zeitzone. Ein Feld wie created_at enthält eine Uhrzeit und braucht meist eine eindeutige Zone. Ein Datum-Zeit-Auswahlfeld verbindet beides und kann Sommerzeitregeln benötigen. Wird ein reines Datum durch lokale Mitternacht geführt, kann es in einer anderen Zone auf den Vortag springen.

Für reine Datumswerte eignet sich 2026-11-18, wenn der Wert gespeichert, sortiert, verglichen oder an eine API gesendet wird. Halten Sie für Screenshots und manuelle Prüfung eine lange Schreibweise bereit. US- und europäische Zahlenformate sind für Darstellungstests nützlich, aber für Parser mehrdeutig: 03/04 kann der 4. März oder der 3. April sein. Prüfen Sie Anzeige und Parservertrag getrennt.

Der Generator stellt Bereiche und Formate bereit. Die Tests müssen Zeit- und Zeitzonenfälle ergänzen, sobald das Produkt sie verwendet. Ein Datum ohne Uhrzeit deckt kein Zeitstempelverhalten ab.

03 / BEREICH

Verwenden Sie inklusive Grenzen statt eines vagen Zeitraums

Schreiben Sie zwei konkrete Grenzen auf. From und To sind inklusive: Ein Ein-Tages-Bereich hat genau einen möglichen Wert, ein volles Jahr enthält den 1. Januar und den 31. Dezember. Diese Regel lässt sich im Testplan erklären und mit einer Assertion prüfen. Verwendet die Anwendung eine exklusive obere Grenze, muss das Fixture angepasst oder die Abweichung dokumentiert werden.

Ein weiter Bereich zeigt normale Streuung, garantiert aber keine Grenzfälle. Verkleinern Sie den Bereich um ein Monatsende, einen Jahreswechsel oder eine Altersgrenze, damit das erwartete Verhalten eindeutig ist. Nutzen Sie eine Stichprobe für Verteilung und eine bewusst ausgewählte Liste für die Grenzen. Ein zufällig glückliches Ergebnis darf kein falsches Vertrauen erzeugen.

Bewahren Sie den Bereich bei der Ausgabe. Zehn Datumswerte ohne Start, Ende, Wochentagsfilter, Eindeutigkeitsregel und Format sind später nicht nachvollziehbar. Speichern Sie diese Angaben im Fixture-Namen, Testtitel oder QA-Vermerk.

• Weiter Bereich: Sortierung, Gruppierung, Pagination und Verteilung prüfen.
• Kurzer Bereich: inklusive Grenzen und Mengenlimits prüfen.
• Grenzbereich: Monatsenden, Schaltjahre und Geschäftsregeln prüfen.
• Leerer Bereich: Fehlermeldung bei null passenden Wochentagen prüfen.

04 / ERZEUGUNG

Realistische Stichproben erstellen und die Kontrolle behalten

Beginnen Sie mit einer kleinen Menge. Fünf bis zwanzig Daten reichen oft für die manuelle Prüfung; größere Mengen können eine Staging-Tabelle füllen oder Pagination testen. Halten Sie die Werte eindeutig, wenn jede Zeile ein eigenes Ereignis darstellt. Erlauben Sie Duplikate nur für Importfehler, mehrere Einträge am selben Tag oder Sampling mit Zurücklegen.

Wenden Sie den Wochentagsfilter vor der Bewertung an. Montag bis Freitag ist eine Kalenderregel, kein Feiertagskalender. Ein Montag kann in einem Land oder Unternehmen frei sein. Benötigt das Produkt landesspezifische Arbeitstage, erzeugen Sie normale Wochentage und ergänzen Sie ein Feiertagsset aus der eigenen Quelle des Produkts.

Bezeichnen Sie Browser-Zufall nicht als Sicherheitsgarantie. Ein Zufallsdatum eignet sich für Beispiele und normale Auswahl, nicht für Passwort, Token, kryptografischen Seed oder eine formale Auslosung. Diese Grenze gehört in Dokumentation und Fixtures.

• Zuerst eine kleine Stichprobe zur Kontrolle erzeugen.
• Eindeutige Werte für getrennte Zeilen, Duplikate für Duplikattests nutzen.
• YYYY-MM-DD für Maschinen, langes Datum für Menschen verwenden.
• Bereich und Filter neben der Ergebnisliste speichern.

05 / GRENZFÄLLE

Ergänzen Sie Daten, die eine Stichprobe verfehlen kann

Zufallsstichproben zeigen gewöhnliche Variation; seltene Daten müssen jedoch bewusst hinzugefügt werden. Nehmen Sie den 29. Februar eines Schaltjahres und die Nachbartage auf. Ergänzen Sie den letzten Tag eines 30-Tage- und eines 31-Tage-Monats. Verwenden Sie den 31. Dezember und den 1. Januar, wenn ein Bericht oder Abo über das Jahr wechselt.

Für Alters- oder Berechtigungsregeln berechnen Sie die Grenze aus der Anforderung und testen beide Seiten. Wer heute 18 wird, ist nicht im selben Fall wie jemand mit Geburtstag morgen. Für Ablauf und Verlängerung testen Sie den exakten Tag, den Moment davor und den ersten gültigen Tag danach. Der Generator liefert Kalenderwerte, der Plan die Assertion.

Bei Zeitzonen ergänzen Sie ein Datum-Zeit-Fixture um einen Sommerzeitwechsel und vergleichen gespeicherten Zeitpunkt mit lokaler Anzeige. Ein Datum-ohne-Zeit-Artikel ersetzt das nicht, verhindert aber die Verwechslung von Kalenderdatum und Zeitstempel.

• Schaltjahr: 29. Februar und die Nachbartage.
• Monatsenden: Februar, April, Juni, September und ein 31-Tage-Monat.
• Jahreswechsel: 31. Dezember, 1. Januar und Berichtsstichtag.
• Regelgrenzen: Vortag, exakter Tag und Folgetag.

06 / PRÜFUNG

Testdaten erklärbar und wiederholbar machen

Ein Fixture ist leichter zu pflegen, wenn ein Reviewer ohne Generator vier Fragen beantworten kann: welcher Bereich, welche Werte waren erlaubt, waren Duplikate möglich und welches Format wurde kopiert? Schreiben Sie diese Antworten in den Namen oder eine kleine Metadatenstruktur. `orders_2026Q1_unique_iso` sagt mehr als `random_dates_1`.

Vergleichen Sie die Liste mit der echten Validierung. Prüfen Sie Parsing, Ablehnung ungültiger Zeichenfolgen, Übereinstimmung von Anzeige und gespeichertem Wert sowie chronologische statt alphabetische Sortierung. Einige Assertions rund um die Liste sind hilfreicher als die Behauptung, die Stichprobe sei zufällig.

Speichern Sie bei einem Fehler den exakten Bereich und die Ausgabe. Eine deterministische Seed-Behauptung ist nicht nötig, ein gespeichertes Fixture oder Artefakt aber schon. Reproduzierbarkeit entsteht durch bewahrte Eingabe und Ausgabe, nicht durch die Hoffnung auf denselben neuen Zufallslauf.

• Bereich, Filter, Anzahl, Eindeutigkeit und Format bei der Ausgabe halten.
• Gültigkeit, Parsing, Reihenfolge, Anzeige und Grenzen getrennt prüfen.
• Fehlerausgabe als Fixture speichern, damit sie reproduzierbar bleibt.

07 / GRENZEN

Was erzeugte Daten beweisen können und was nicht

Ein erzeugtes Datum zeigt, dass der Code den gewählten Wert akzeptiert und verarbeitet. Es beweist nicht, dass ein Termin frei ist, ein Feiertag in einem Land gilt oder eine gesetzliche Frist korrekt verstanden wurde. Dafür braucht es einen Fachkalender, eine Richtlinie oder eine autoritative Quelle.

Der browserbasierte Generator muss im normalen Ablauf weder Daten hochladen noch ein Konto anlegen. Trotzdem sollten Testteams echte Geburtstage, Kundendaten oder vertrauliche Projektdaten nicht in geteilte Notizen kopieren. Nutzen Sie fiktive Werte und lesen Sie die Datenschutzerklärung zu Hosting, Analyse, Cookies, Web-Beacons, Kennungen und Werbung.

Bleiben Sie beim Umfang: Planung, Beispiele, QA-Fixtures und gewöhnliches Sampling. Für Zugangsdaten, Passwörter, Tokens, regulierte Ziehungen oder auditierbare Entscheidungen ist eine sicherheitsorientierte Zufallsquelle erforderlich.

HÄUFIGE FRAGEN

FAQ zu zufälligen Testdaten