Testdaten-Tool-PoC: eine wiederverwendbare Abnahme-Checkliste

Redaktionell geprüft: 2026-10-11 · Quellen und Geltungsbereich unten

PoC-Prüfplan herunterladen (.md)

Was muss das Beispiel enthalten?

Erzeuge vier Kunden-IDs, 1–4, und sechs Zahlungs-IDs, 101–106. Die Tabelle legt Kunde, Status und Betrag in ganzzahligen Cent fest. Kunde 4 hat bewusst keine Zahlung. Der Report darf nur Zahlungen mit Status settled ab 10.000 Cent auswählen. Erwartet werden exakt 101, 104 und 106 mit insgesamt 60.000 Cent. Zahlung 103 ist settled, liegt aber bewusst unter der Grenze; pending und rejected müssen ausgeschlossen bleiben.

Ein kleines Fixture mit exaktem Soll-Ergebnis

Die Kundentabelle muss IDs 1, 2, 3 und 4 enthalten. Kunde 4 hat bewusst keine Zahlung. Nutze diese Abfrage auf der generierten Zahlungstabelle; prüfe Beziehungen separat.

SELECT payment_id FROM payments
WHERE status = 'settled' AND amount_cents >= 10000
ORDER BY payment_id;

Erwartete IDs: 101, 104, 106. Gesamtbetrag: 60.000 Cent.

Was zählt als bestanden?

Verlange vier eindeutige Kunden-IDs, sechs eindeutige Zahlungs-IDs, keine verwaisten Zahlungen und exakte Übereinstimmung mit jeder Szenariozeile. Prüfe Report-IDs und Summe unabhängig. Die Zeilenzahl allein reicht nicht: Ein Tausch von settled und rejected kann sechs Zeilen erhalten, aber das fachliche Ergebnis ändern. Ein erfolgreicher Generator-Log ist ein Ausführungsnachweis, kein fachlicher Sollwert.

Wie vergleichst du den tatsächlichen Aufwand?

Nutze für jeden Kandidaten ein frisches Ziel. Dokumentiere Produkt und Edition, Modell oder Skript, Laufzeitversionen, manuelle Änderungen und Zeit bis zum ersten korrekten Ergebnis. Erfasse separat eine geänderte Fachregel, Wiederherstellung nach Fehler und einen zweiten Engineer, der den Aufbau wiederholt. Halte eine nicht unterstützte oder nicht geprüfte Anforderung sichtbar, statt daraus einen erfundenen Null-Score zu machen.

Was ergänzt du für dein eigenes System?

Ersetze dieses kleine Schema nach erfolgreichem Grundtest durch einen repräsentativen Teil deines Systems. Ergänze Konnektor, zusammengesetzte Schlüssel, Zielbereinigung und benötigte Fehlerfälle. Bei Quelldaten kommen erlaubte Auswahl und Transformations-Assertions hinzu. Prüfe bei mehreren Zielsystemen jedes Ziel und systemübergreifende Kennungen. Dieses Fixture ist kein Produkt-Benchmark und belegt weder Datenschutz noch Lastfähigkeit oder Protokollkonformität.

Ausgeführtes Fixture für Kundenlabels

Der lokale Prüf-Harness führte Faker, DATAMIMIC CE und SDV am 11. Oktober 2026 unter Linux mit Python 3.12 aus. Jedes Produkt liefert vier Kundenlabels. Der gemeinsame Python-Adapter setzt IDs und die sechs festen Zahlungszeilen. SQLite prüft dieses zusammengesetzte Fixture. Die Produkte bauen dessen Beziehungen nicht selbst.

Faker nutzt seed_instance(42); CE person/v1 erhält Seed 42 und eine feste Uhr. SDV trainiert einen GaussianCopulaSynthesizer mit 256 rein synthetischen Label-/Score-Zeilen. Nur die Label-Spalte gelangt ins Fixture. Es gibt keine Produktionsdaten, Datenschutzkennzahl oder Verteilungsbewertung. Das neutrale SQLite-Skript prüft Bereinigung und Rollback.

MOSTLY AI SDK 6.1.5 mit LOCAL-Abhängigkeiten wurde ohne Account installiert. Der tatsächliche Trainingsversuch wurde blockiert, weil die Umgebung AF_UNIX-Sockets verweigert (Operation not permitted). Dem Produkt wird weder generierte Ausgabe noch ein fehlgeschlagenes fachliches Ergebnis zugeschrieben.

Dies prüft keine vom Produkt verwalteten Beziehungen, Enterprise-Editionen, Datenbank-Konnektoren, Subsetting, Datenschutz, Durchsatz oder Portabilität. Geprüfte Versionen werden nicht als neueste Releases bezeichnet.

Skripte, Abhängigkeits-Lock und Ergebnisse herunterladen (.zip) · Laufnachweis lesen (.json)

python run_fixture.py
python3.12 -m venv .venv
.venv/bin/python -m pip install -r requirements-poc.lock
.venv/bin/python compare_generators.py --model-dir .fixture-model --output results-local.json

Beispielszenarien und redaktionelle Abnahmekriterien; keine gemessenen Produkt-Benchmarks.

Wähle den nächsten Schritt

• Anforderungen und Proof of Concept festlegen
• Reproduzierbare Testdaten für CI/CD: was du fixieren und prüfen musst
• Open-Source-Testdaten-Tools: Faker, DATAMIMIC CE und Alternativen
• Dokumentierte Fähigkeiten deiner engeren Auswahl vergleichen