Wochen bis zum ersten Test
Beantragen, freigeben lassen, extrahieren, von Hand maskieren: Wochen vergehen, bevor überhaupt ein Test läuft. Wenn erneut Testdaten benötigt werden, beginnt derselbe Weg von vorn.
INPUTLAB TDP
Die Testdaten, die Ihre Tests brauchen
Statt Produktionskopien zu schützen oder Skripte zu pflegen, modellieren Sie Strukturen, Beziehungen und Geschäftsregeln ein einziges Mal. InputLab TDP erzeugt daraus vollständig synthetische Testdaten oder maskiert Ihren Bestand, Feld für Feld, je nach Schutzbedarf. Und es belegt, welche Fälle Sie damit abdecken und welche offen bleiben.
Ein schematisches Verlaufsdiagramm ohne Zahlenwerte. Waagerecht läuft die Zeit, senkrecht der Aufwand je Zeitraum; in der Mitte steht der Einführungszeitpunkt. Links davon läuft eine gemeinsame Punktspur: vor der Entscheidung ist die Ausgangslage für beide Wege dieselbe, und die Punkte stehen weit zurück einzeln und zur Einführung hin immer dichter. Rechts davon laufen sie auseinander. Ohne InputLab steigt der Aufwand einmal an und bleibt auf diesem Niveau, Release für Release. Mit InputLab TDP schießt er kurz sehr weit darüber hinaus und fällt danach schnell ab, bis er flach unterhalb der Ausgangslage ausläuft: der Aufwand fällt einmal für das Modell an, danach wird nur noch gepflegt. Ein Schnittpunkt ist nicht markiert.
PROBLEM
Ihre Testdaten kosten Sie Wochen und sind ein Datenschutzrisiko. Testabdeckung: Unbekannt.
Ob Produktionskopie, Faker-Daten oder gewachsene Skripte: Woher Ihre Testdaten heute kommen, ändert wenig daran, was sie kosten. Daraus entstehen drei Probleme.
Sensible Daten in Testumgebungen
Die Kopie bleibt personenbezogen, und das Restrisiko der Re-Identifikation bleibt bei Datenübertragungen bestehen. Was von Hand maskiert wurde, prüft im Zweifel niemand nach.
Die Abdeckung kennt niemand
Getestet wird, was der Bestand zufällig enthält oder was ein Skript zufällig erzeugt. Welche Geschäftsregeln, Kombinationen und Randfälle wirklich vorkommen, steht nirgends. Die Lücke fällt in der Produktion auf.
WIE INPUTLAB TDP DAS PROBLEM LÖST
Ein Modell ersetzt die manuelle Testdatenbereitstellung und zeigt Ihnen, was Ihre Testdaten abdecken.
Hinter allen dreien steckt dieselbe Ursache: Es gibt keine zentrale Dokumentation Ihrer (Test-)Datenlandschaft. InputLab TDP schließt diese Lücke mit einem Modell: Strukturen, Beziehungen und Geschäftsregeln werden einmal erfasst. Danach können Sie daraus entweder neue synthetische Testdaten erzeugen oder bestehende Daten maskieren.
Ein Vergleich zweier Abläufe im selben Raster. Oben der Weg über eine Produktionskopie: Anfrage, Freigabe, Extrakt, Maskieren, Laden. Eine Klammer unter allen fünf Schritten hält fest, dass diese Kette bei jeder Anfrage erneut läuft. Unten der Weg über InputLab TDP: Modell, Erzeugen, Laden. Die Klammer unter dem ersten Schritt ist mit „einmalig" beschriftet, die Klammer unter den beiden folgenden Schritten mit „bei jeder Anfrage".
| Mit Produktionsdaten | Mit InputLab TDP | |
|---|---|---|
| Zeit | Mit Produktionsdaten Beantragen, freigeben, extrahieren, maskieren: Wochen, bevor ein Test läuft. Der nächste Bedarf beginnt denselben Weg von vorn. | Mit InputLab TDP Je Branch ein eigener Satz, aus dem Modell abgerufen statt beantragt. Die Arbeit fällt einmal an, im Modell. Weil es versioniert ist, lässt sich derselbe Datensatz jederzeit exakt reproduzieren. |
| Risiko | Mit Produktionsdaten Die Kopie bleibt personenbezogen, und das Restrisiko der Re-Identifikation zieht sich durch jede Umgebung, die sie berührt. | Mit InputLab TDP Vollständig synthetische Datensätze, oder kritische Felder je nach Schutzbedarf synthetisch ersetzt, verschlüsselt oder teilweise überschrieben. Welches Feld welches Verfahren bekommt, steht im Modell. |
| Abdeckung | Mit Produktionsdaten Getestet wird, was der Bestand zufällig enthält. Was der Datensatz abdeckt, steht nirgends. | Mit InputLab TDP Jeder Fall entsteht aus einer Regel, auch wenn er in Produktionsdaten nicht vorkommt. Das Modell zeigt, was abgedeckt ist und wo Lücken bleiben. |
ABLAUF
In fünf Schritten vom Datenmodell zur Testdatenbereitstellung.
Anbinden & Erfassen
APIs, Datenbanken und Schemas anbinden, Strukturen, Beziehungen und Geschäftsregeln modellieren, auch in natürlicher Sprache über den MCP-Server.
Zusammenarbeiten
Fachbereich, QA, Entwicklung und Compliance schärfen Regeln und Randfälle gemeinsam.
Erzeugen oder Maskieren
Auf Knopfdruck synthetische Datensätze erzeugen oder den Bestand Feld für Feld maskieren.
Integrieren
Über REST API und CI/CD landen die Daten dort, wo Ihre Pipeline sie braucht.
Weiterentwickeln
Regeln erweitern und neu erzeugen, sobald sich Anforderungen ändern.
FEATURES
Ein Modell. Und die Funktionen, die darauf aufsetzen.
Von der Modellierung über den Abdeckungsnachweis bis zur Auslieferung in Ihre Pipeline. Alle Funktionen arbeiten auf demselben Modell, und wo die Plattform läuft, entscheiden Sie.
Ein Modell für Strukturen und Abhängigkeiten
Schemas, Beziehungen und Geschäftsregeln in einem versionierten Artefakt.
InputLab TDP unterstützt den Import von relationalen Datenbanken, XML-Schemas, JSON-Schemas und OpenAPI-Schemas oder die Modellierung von Grund auf. Entitäten, Beziehungen, Schlüssel, Verbindungen und Metadaten stehen danach in einem nachvollziehbaren Artefakt statt verteilt in Skripten und Köpfen. Das ist das Basismodell, auf dem alles Weitere aufsetzt.
- One-Click-Integration mit Open Data Contract Standard v3.1.0
- Beziehungen und Schlüssel, auch über Systemgrenzen hinweg
- Wiederverwendbare Spezifikationen statt verteilt in Skripten und Köpfen.
Geschäftsregeln erfassen und kombinieren
Fachliche Geschäftsregeln auf der Grundlage des Basismodells festlegen. Kombinieren Sie Regeln aus der Bibliothek, sodass sie zu Ihren Anwendungsfällen passen.
Legen Sie spezifische Bedingungen für Ihre Testfälle in einer unabhängigen Regel-Definitionsschicht fest. Verwenden Sie Regeln wie Bausteine, die Sie kombinieren und beliebig wiederverwenden können. Vom Standardfall bis zur exotischen Konstellation, die sonst untergehen würde.
- Wertebereiche, Bedingungen und Abhängigkeiten zwischen Feldern
- Regeln über mehrere Entitäten, entlang der Beziehungen im Modell
- Regeln kombinieren und wiederverwenden, statt jeden Fall auszuschreiben
Zusammenarbeit im Team
No-Code-Oberfläche für alle Beteiligten, auch ohne Coding-Kenntnisse.
Die No-Code-Oberfläche öffnet Testdatenspezifikationen für Fachbereich, QA, Entwicklung und Compliance gleichermaßen. Jede Änderung bleibt über die Versionierung nachvollziehbar.
- Teams, Zugriffsrechte und Versionierung
- Gemeinsame Dokumentation der fachlichen Absicht
- Zusammenarbeit von Fachbereich, QA, Entwicklung und Compliance
Garantierte Abdeckung im definierten Modell
Was Sie modelliert haben, kommt in den Daten vor. Belegt, nicht gehofft.
Die Technologie von InputLab ist in der Fuzzing-Forschung verwurzelt: Sie erkundet den modellierten, fachlich relevanten Eingaberaum systematisch, statt Werte zufällig zu ziehen. Für alles, was im Modell steht, von Kombinationen über Randfälle bis zu spezifischen Regeln, garantiert InputLab TDP die Abdeckung im erzeugten Datensatz und macht sichtbar, welche Bereiche des Modells ein Datensatz erreicht.
- Systematische Erkundung statt zufälliger Werte
- Abdeckung des modellierten Eingaberaums sichtbar gemacht
- Reproduzierbar: dasselbe Modell ergibt denselben Datensatz
Integrationen in bestehende Abläufe
Über REST API und CI/CD dorthin, wo Ihre Pipeline die Daten braucht.
Eine flexible REST API, Integrationen für Datenbanksysteme sowie Anbindungen an CI/CD- und Productivity-Tools bringen frische Testdaten direkt in Ihre bestehenden Abläufe. Ein MCP-Server erlaubt die Spezifikationen in natürlicher Sprache.
- API-basierte Bereitstellung
- Anbindung an CI/CD und Testumgebungen
- MCP-Server für die Spezifikation in natürlicher Sprache
Betrieb als SaaS oder On-Premises
Unser Standard-Betriebsmodus ist SaaS/Cloud. On-Premise ist ebenso möglich.
Im Regelfall läuft InputLab TDP als SaaS: keine Installation, keine eigene Infrastruktur, Sie beginnen direkt mit dem ersten Modell. Wenn interne Richtlinien oder der Schutzbedarf einen Betrieb im eigenen Rechenzentrum verlangen, ist das möglich. Wie der Aufbau bei Ihnen konkret aussieht, klären wir im Gespräch und schneiden ihn auf Ihre Umgebung zu.
- SaaS/ Cloud als Standardbetriebsmodus
- On-Premise Betrieb ist ebenfalls möglich
- Den passenden Aufbau klären wir gemeinsam im Gespräch
Ein Modell für Strukturen und Abhängigkeiten
InputLab TDP unterstützt den Import von relationalen Datenbanken, XML-Schemas, JSON-Schemas und OpenAPI-Schemas oder die Modellierung von Grund auf. Entitäten, Beziehungen, Schlüssel, Verbindungen und Metadaten stehen danach in einem nachvollziehbaren Artefakt statt verteilt in Skripten und Köpfen. Das ist das Basismodell, auf dem alles Weitere aufsetzt.
- One-Click-Integration mit Open Data Contract Standard v3.1.0
- Beziehungen und Schlüssel, auch über Systemgrenzen hinweg
- Wiederverwendbare Spezifikationen statt verteilt in Skripten und Köpfen.
WEGE
Neu erzeugen oder maskieren. Sie entscheiden je Datenbestand.
Sie modellieren Strukturen, Beziehungen und Geschäftsregeln einmal. Daraus erzeugt InputLab TDP entweder vollständig neue Datensätze oder maskiert Ihren Bestand. Welchen Weg Sie gehen, entscheiden Sie je Datenbestand und nicht ein für alle Mal.
| Spalte | Feld im Bestand | Vollständig synthetischunabhängig vom Bestand | Maskierter Bestandje Feld nach Schutzbedarf |
|---|---|---|---|
| Kundennummer | Feld im BestandK-880231sensibelPseudonym, aber eindeutig: über die Kundennummer lässt sich ein Satz einer Person zuordnen. | Vollständig synthetischK-100004erzeugtFormat K- plus sechs Ziffern aus dem Schema, fortlaufend und im Datensatz eindeutig. | Maskierter Bestand8f2a…c1verschlüsseltVerschlüsselt. Derselbe Ausgangswert ergibt immer denselben Schlüsseltext, damit Verknüpfungen über Tabellen hinweg erhalten bleiben. |
| Name | Feld im BestandMartina KellersensibelPersonenbezogen im Klartext, der Satz ist damit unmittelbar einer Person zuzuordnen. | Vollständig synthetischNadja BrandterzeugtAus der Namensbibliothek des Modells, passend zu Anrede und Region des Datensatzes. | Maskierter BestandNadja BrandterzeugtAus der Namensbibliothek des Modells, passend zu Anrede und Region des Datensatzes. |
| IBAN | Feld im BestandDE44 5001 … 3000sensibelZeigt auf ein reales Konto und darüber auf die Person, der es gehört. | Vollständig synthetischDE02 1203 … 0200erzeugtGültige Prüfziffer und eine Bankleitzahl aus dem Testbereich, damit Format- und Validierungsregeln greifen. | Maskierter BestandDE02 1203 … 0200erzeugtGültige Prüfziffer und eine Bankleitzahl aus dem Testbereich, damit Format- und Validierungsregeln greifen. |
| Geburtsdatum | Feld im Bestand14.03.1978sensibelZusammen mit Postleitzahl und Geschlecht reicht das Geburtsdatum in vielen Fällen zur Wiedererkennung. | Vollständig synthetisch02.11.1981erzeugtZufällig innerhalb des Altersbands, das die Geschäftsregeln für diesen Vertrag zulassen. | Maskierter Bestand••.••.1978überschriebenTag und Monat überschrieben, das Jahr bleibt stehen, damit Altersprüfungen weiter dasselbe Ergebnis liefern. |
| Vertragsart | Feld im BestandRatenkreditunkritischMacht für sich genommen keine Person erkennbar und braucht deshalb keinen Schutz. | Vollständig synthetischBaufinanzierungerzeugtAus der Werteliste des Modells, gezogen in der Verteilung, die auch im Bestand vorkommt. | Maskierter BestandRatenkreditunverändertBleibt unverändert, weil die Vertragsart für sich genommen keine Person erkennbar macht. |
| Restschuld | Feld im Bestand12.480,00unkritischIdentifiziert niemanden, sobald die kritischen Felder des Satzes ersetzt sind. | Vollständig synthetisch3.905,00erzeugtInnerhalb der Grenzen, die die Regeln für diesen Vertragstyp vorgeben. | Maskierter Bestand12.480,00unverändertBleibt unverändert, weil der Betrag ohne die ersetzten Felder niemanden identifiziert. |
Vollständig synthetisch
Kein Datensatz stammt aus der Produktion, also liegt in der Testumgebung auch kein Personenbezug. So entstehen auch die Fälle, die Ihre Echtdaten nie enthalten haben. Für Werte wie IBANs, Produktnamen und Adressen bringt die Plattform eine erweiterbare Bibliothek mit.
Maskierter Bestand
Für jedes schützenswerte Feld wählen Sie, wie es geschützt wird. Der unkritische Teil bleibt, wie er ist, mit allen gewachsenen Strukturen und Verteilungen. Welches Feld welches Verfahren bekommt, ist eine Entscheidung im Modell und keine Einstellung, die in einem Skript verschwindet.
DEMO
Setzen Sie ein Modell zusammen und sehen Sie, was daraus entsteht.
Probieren Sie es mit ein paar Klicks selbst aus. Das Modell ist winzig, aber was daraus entsteht, hält zusammen: verknüpfte Positionen, stimmige Summen und eine Liste der Edge Cases, die wirklich in den fünf Datensätzen stecken.
order-demo
Vereinfachte Demo · läuft in Ihrem Browser.
Modell
Ein vorbereitetes Beispielmodell für Bestellungen und ihre Positionen. Laden Sie es und ergänzen Sie die beiden Regeln.
Bestellung
orderIdText · Format (ORD-YYYY-XXXX)customerText · Type (Company Names)orderDateText · Type (Date)
Position
mehrere pro BestellunglineIdText · Format (LI-XXXXX)orderIdBeziehung → BestellungproductText · AnyunitPriceNumber · 2 NachkommastellenquantityInteger · Any
Summe
total = Σ (quantity × unitPrice)Die Summe entsteht bei der Erzeugung aus den Positionen.
Menge pro Position
≤ quantity ≤1 ≤ quantity ≤ 5
Jede erzeugte Menge liegt in diesen Grenzen. Sind beide Werte gleich, hat jede Position dieselbe Menge.
Ist die Regel aus, enthält jede erzeugte Bestellung mindestens eine Position.
Fünf Beispiele
Die Regeln haben sich geändert. Die Beispiele unten gehören noch zu den vorherigen Regeln. Erzeugen Sie sie neu.
Noch nichts erzeugt. Setzen Sie das Modell zusammen, stellen Sie die Regeln ein und erzeugen Sie fünf Bestellungen.
Beispiel aus diesem Modell
ORD-2026-0001Nordwind GmbH2026-03-04348,80 €
| Position | Produkt | Menge | Einzelpreis | Zeilensumme |
|---|---|---|---|---|
| LI-00001 | USB-C Hub | 2 | 49,90 € | 99,80 € |
| LI-00002 | Monitor 27" | 1 | 249,00 € | 249,00 € |
| Summe | 348,80 € | |||
Ohne JavaScript erzeugt die Demo keine neuen Datensätze. Dieses Beispiel stammt aus dem Modell oben: zwei Positionen mit Mengen im erlaubten Bereich, und eine Summe, die genau ihren Positionen entspricht.
Mengen sind ganze Zahlen von 1 bis 99.Die kleinste Menge darf nicht größer sein als die größte. Bitte passen Sie die Regel an.1 Position{n} PositionenKeine Positionen, Summe 0,00 €.Positionen der Bestellung {order}PositionProduktMengeEinzelpreisZeilensummeSummeBestellung mit genau einer PositionBestellung mit mehreren PositionenKleinste erlaubte Menge ({n})Größte erlaubte Menge ({n})Feste Menge ({n})Leere Bestellung, Summe 0,00 €in {order}Gezeigte Edge CasesDie Liste nennt die Edge Cases in genau diesen fünf Datensätzen. Sie ist keine Abdeckungsmessung und sagt nichts darüber, was die Plattform an Ihrem Modell abdeckt.JSON ansehenModell geladen. Bestellung und Position stehen im Modell.Beispiele werden erzeugt.Fünf Bestellungen erzeugt.JSON in die Zwischenablage kopiert.Kopieren war nicht möglich. Das JSON steht unten zum Markieren.Zurückgesetzt. Das Modell ist noch nicht geladen.
Und so sieht das Ganze in der Plattform aus.
Die Arbeitsoberfläche von InputLab TDP: aktuelle Datensätze, Projekte, Formate, Statusinformationen und die Aktionen, mit denen die Daten in Ihren Testprozess gehen.
Dr. Dominic Steinhöfel (CEO)
Machen Sie Testdaten zu einem messbaren Teil Ihrer Qualitätssicherung.
Bringen Sie Ihre Datenmodelle, Testfälle und Integrationswege mit. Wir zeigen Ihnen, wo coverage-orientierte Testdaten in Ihrem Testprozess den größten Unterschied machen.