Je umfangreicher und komplexer Formulare in einer Anwendung werden, desto aussichtsloser ist das manuelle Bereitstellen von Testdaten. mgm hat deshalb ein Verfahren entwickelt, das Testdaten vollständig automatisiert für die entwicklungsbegleitende Qualitätssicherung von Enterprise Software erzeugt. Der mgm A12 Testdatengenerator (TDG) erzeugt ausgehend von fachlichen Modellen vollautomatisch technische Testdaten und erkennt „nebenbei“ Widersprüche in den Regeln.
Kurz & knapp
- Zum Testen von komplexen Geschäftsanwendungen werden gültige Testdaten benötigt. Diese Testdaten lassen sich nur mit sehr großem Aufwand manuell erzeugen.
- Der mgm A12 Testdatengenerator übersetzt die den Feldern eines A12-Formulars zugrundeliegenden Validierungs- und Berechnungsregeln in mathematische Gleichungssysteme, löst sie, und erzeugt so gültige Testdaten.
- Die Testdatengenerierung erfolgt vollständig automatisiert und deckt 100 Prozent aller Felder in den Modellen ab. Es ist kein Fachwissen über den Inhalt der Formulare erforderlich.
- Der mgm A12 Testdatengenerator erkennt zudem Widersprüche in den Regeln und generiert einen detaillierten Bericht, der dem Nutzer hilft, die Widersprüche zu verstehen und zu beheben. Diese Funktion ist bereits in die Modellierungswerkzeuge der modellbasierten A12 Enterprise Low Code Plattform integriert.
Um komplexe Geschäftsanwendungen automatisiert oder manuell testen zu können, werden technisch korrekte Testdaten benötigt. Das ist insbesondere deswegen kompliziert, weil komplexe Geschäftsanwendungen normalerweise komplexe fachliche Regeln beinhalten. Diese Regeln definieren, welche Werte in den Daten erlaubt sind und dienen somit als Richtlinien für die Erzeugung der Testdaten. Normalerweise erfordert die manuelle Erstellung und Pflege solcher Testdaten den Einsatz von großen Teams aus Fachexperten, was mit beträchtlichem Aufwand verbunden ist.
Bei der Entwicklung der mgm Low Code-Plattform A12 war deshalb schon früh klar, dass eine generische Lösung erforderlich ist, um diese Aufgaben zu bewältigen und Testdaten automatisch zu generieren, ohne dabei auf Fachwissen angewiesen zu sein. Da die Fachlichkeit einer A12-Anwendung in Modellen abgebildet ist, lassen sich die Modelle als Grundlage für diese automatisierte Testdatenerzeugung heranziehen. Das automatische Generieren von Testdaten für modellbasierte Formulare ist allerdings keine einfache Aufgabe, da die Validierungsregeln den Prozess erheblich erschweren.
Eine mögliche Herangehensweise besteht darin, dass wir einen Brute-Force Ansatz nutzen. Dabei erzeugen wir zufällige Testdaten und überprüfen diese anschließend auf ihre Gültigkeit. Die Validierungsregeln schränken dabei die Menge der möglichen Lösungen ein. Allerdings sinkt die Wahrscheinlichkeit, einen gültigen Datensatz zu finden, exponentiell mit der Anzahl der Felder und Regeln. Wir haben festgestellt, dass ein Rechner bereits bei einem kleinen Formular mit 100 Feldern und 100 Regeln mehrere Tage brauchen würde, um mit einer Wahrscheinlich von 50 Prozent einen einzigen gültigen Datensatz zu generieren. Bereits bei mittelgroßen Formularen würde die benötigte Rechenzeit sogar länger sein als das Alter des Universums seit dem Urknall.
Im Labyrinth der Möglichkeiten: Widersprüche und richtige Abzweigungen
Darum ist es bei der Generierung von Testdaten von entscheidender Bedeutung, die Validierungsregeln zu analysieren. In A12 sind diese Regeln in der mächtigen A12-Regelsprache formuliert. Doch hier taucht das nächste Problem auf: Die meisten Regeln bestehen aus mehreren Teilbedingungen, die durch „Oder“ miteinander verknüpft sind. Das bedeutet, es gibt mehrere Möglichkeiten, sie nicht zu verletzen. Wer automatisiert Testdaten erzeugen möchte, muss für jede Regel entscheiden, welche Möglichkeit er wählt. Jede dieser Entscheidungen gleicht einer Abzweigung in einem komplexen Labyrinth. Die Größe dieses Labyrinths wächst exponentiell mit der Anzahl der „Oder“-Verknüpfungen. Bereits bei mittelgroßen Formularen wird dieses Labyrinth praktisch unendlich groß. Zudem führen die meisten Abzweigungen in diesem Labyrinth zu Sackgassen. Aus diesem Grund gestaltet sich die Suche nach einem Weg durch dieses schier unendliche Labyrinth äußerst herausfordernd.
Auswege aus dem Labyrinth: der SMT-Solver
Zum Glück gibt es spezielle Algorithmen, die genau auf solche Problemstellungen spezialisiert sind. Sie gehen den Fragen nach,
- in welcher Reihenfolge man die Entscheidungen treffen sollte,
- wie man schnell herausfindet, welche Abzweigung eine Sackgasse ist
- und wie man bei Zusatzbedingungen frühere Erkenntnisse verwerten kann und zu welchen Abzweigungen man zurückgehen muss.
Diese Algorithmen gehören in der Informatik und Mathematik zum Bereich der sogenannten „satisfiability modulo theories“ (SMT). Sie beschäftigen sich mit Entscheidungsproblemen, bei denen es um die Lösbarkeit von logischen Formeln geht. Für den Einsatz in der Praxis gibt es spezielle SMT-Solver, die die Algorithmen in Bibliotheken bereitstellen. Und es gibt die standardisierte Sprache SMT-LIB, um mit den SMT-Solvern zu kommunizieren.
Um für die Testdatenerzeugung von Anwendungen, die mit der A12-Plattform entwickelt wurden, einen SMT-Solver nutzen zu können, übersetzt der mgm-Testdatengenerator die fachlichen Regeln aus der A12-Regelsprache in SMT-LIB. Das Ergebnis ist ein Gleichungssystem, das vom SMT-Solver gelöst wird. Die Lösung wird in einen A12 Datensatz zurückübersetzt.
Beispiel für eine Übersetzung von A12 nach SMT-LIB
Angenommen, in einem A12-Modell gibt es die Felder DatumsFeld1 und DatumsFeld2. Und es ist eine Anforderung, dass DatumsFeld2 immer ein späteres Datum als DatumsFeld1 enthält. Dann wird im A12-Modell eine Validierungsregel definiert, um dies zu gewährleisten. Diese Regel beschreibt immer den Fall eines Fehlers. In diesem Fall tritt ein Fehler auf, wenn sowohl DatumsFeld1 als auch DatumsFeld2 angegeben sind und der Wert in DatumsFeld1 größer oder gleich dem Wert in DatumsFeld2 ist.
Die entsprechende Validierungsregel in der A12-Regelsprache lautet:
[DatumsFeld1] >= [DatumsFeld2]
Im mgm A12 Testdatengenerator wird DatumsFeld1 in vier Variablen übersetzt: Dabei gibt es die boolsche Variable DatumsFeld1-B, die den Wert wahr annimmt, wenn das Feld angegeben ist. Weiter gibt es die Integer-Variablen DatumsFeld1-y, DatumsFeld1-m und DatumsFeld1-d für Jahr, Monat und Tag. Die Übersetzung von DatumsFeld2 erfolgt auf analoge Weise.
Unsere Validierungsregel in SMT-LIB sieht wie folgt aus:
(assert
(not
(and
DatumsFeld1-B
DatumsFeld2-B
(or
(> DatumsFeld1-y DatumsFeld2-y)
(and
(= DatumsFeld1-y DatumsFeld2-y)
(> DatumsFeld1-m DatumsFeld2-m))
(and
(= DatumsFeld1-y DatumsFeld2-y)
(= DatumsFeld1-m DatumsFeld2-m)
(>= DatumsFeld1-d DatumsFeld2-d))))))
In SMT-LIB erfolgt die Verwendung von Operatoren durch eine vorangestellte Notation. Darüber hinaus werden Regeln positiv formuliert, weshalb der Regel ein not vorangestellt wird.
Herausforderungen und Erfolge der Übersetzung der A12-Regelsprache in SMT-LIB
Dieses Verfahren erfordert jedoch eine Übersetzung der kompletten A12 Regelsprache: Für jedes Feld und für jede Regel wird eine Entsprechung in SMT-LIB benötigt. An dieser Übersetzung haben wir im Team für de mgm-Testdatengenerator jahrelang gearbeitet und immer wieder verschiedene Übersetzungsmöglichkeiten ausprobiert. Mittlerweile deckt der mgm-Testdatengenerator 100 Prozent unserer produktiven Formulare ab und wir setzen unsere Bemühungen fort, mit der Entwicklung der A12-Regelsprache Schritt zu halten.
Performance im mgm A12 Testdatengenerator: Ein schmaler Pfad
Die zweite große Herausforderung im mgm-A12-Testdatengenerator liegt in der Leistungsfähigkeit der SMT-Solver. Es besteht die Gefahr einer exponentiell zunehmenden Rechenzeit, was die Komplexität des Problems verdeutlicht, wie zuvor erläutert. Die Performance wird durch Faktoren wie die Größe und Komplexität des Formulars, die Art der Übersetzung der A12-Regelsprache in SMT-LIB und die generelle Handhabung des SMT-Solver beeinflusst.
Die Arbeit an der Performance im mgm-A12-Testdatengenerator gleicht der Suche nach einem schmalen befestigten Weg durch ein Sumpfgebiet: Der kleinste Fehltritt kann zu enormen Laufzeitverzögerungen führen. Obwohl die SMT-Solver immer weiter verbessert werden, kann die Testdatenerzeugung bei großen Modellen mit komplexen Regelwerken Stunden in Anspruch nehmen. Die optimale Übersetzung der A12-Regelsprache in SMT-LIB sowie die beste Einstellung und Verwendung der SMT-Solver sind das Ergebnis jahrelanger Forschung und kontinuierlicher Verbesserung. Im Vergleich zu unseren frühen Versuchen benötigt die aktuelle Lösung nur einen Bruchteil der ursprünglichen Laufzeit.
Mit zunehmender Komplexität der Geschäftsanwendungen werden auch die Modelle immer umfangreicher und komplexer. Aus diesem Grund investiert das Team für den mgm-Testdatengenerator kontinuierlich in die Verbesserung der Performance, um mit der steigenden Komplexität der Fachlichkeit in den Formularen Schritt zu halten.
Lösung für Nichtlinearitäten im mgm A12 Testdatengenerator
Im Testdatengenerator stellen Nichtlinearitäten einen komplexen Algorithmus dar. Wenn in einer Regel ein Feld mit einem anderen Feld multipliziert wird, entsteht eine Nichtlinearität. Die Verwendung herkömmlicher Algorithmen in SMT-Solvern für Modelle mit Nichtlinearitäten ist jedoch aufgrund ihrer langen Ausführungszeit für unsere Zwecke nicht praktikabel.
Um dieses Problem zu bewältigen, haben wir im mgm A12 Testdatengenerator ein Verfahren entwickelt, das Nichtlinearitäten beseitigt. Hierbei werden einzelne Felder vor der Weitergabe an den SMT-Solver mit sinnvollen Werten vorbelegt. Die Umsetzung dieses Verfahren ist äußerst komplex, da die Vorbelegung potenziell Widersprüche hervorrufen kann.
Unser erster Algorithmus zur Vorbelegung wurde kontinuierlich verbessert, erreichte jedoch schließlich seine Grenzen. Im Sommer 2022 haben wir einen völlig neuen Ansatz ausprobiert, der mittlerweile erfolgreich in der Produktivumgebung eingesetzt wird und die Performance und Datenqualität erheblich verbessert hat. Durch diesen neuen Ansatz konnten wir die Herausforderungen der Nichtlinearitäten erfolgreich meistern.
Vielfältige Testdaten für unterschiedliche Anwendungsfälle
Der mgm A12 Testdatengenerator bietet die Möglichkeit, verschiedene Arten von Datensätzen für unterschiedliche Anwendungsfälle zu erzeugen. Die generierten Testdaten variieren je nach Anforderung:
- Minimaltestfälle für Smoke-Tests: Diese Testdaten dienen dazu, grundlegende Funktionalitäten zu überprüfen und stellen minimale Eingaben dar, um eine schnelle Überprüfung zu ermöglichen.
- Testfälle mit hoher Testabdeckung für automatisierte Tests: Diese Testdaten werden speziell für automatisierte Tests entwickelt und decken eine breite Palette von Szenarien ab, um eine umfassende Überprüfung der Anwendung zu gewährleisten.
- Negativtests: Diese Testdaten werden gezielt erstellt, um einzelne Validierungsregeln absichtlich zu verletzen und somit potenzielle Schwachstellen und Fehler zu identifizieren.
- Testfälle mit allen erlaubten Zeichen für automatisierte Tests: Diese Testdaten umfassen alle möglichen zulässigen Zeichen und dienen der Überprüfung der Robustheit und Zuverlässigkeit der Anwendung.
- Testfälle mit „schönen“ Testdaten für manuelle Tests: Bei diesen Testdaten liegt der Fokus auf der Erzeugung von leserlichen und realistischen Testdaten für manuelle Tests, um eine benutzerfreundliche und praxisnahe Überprüfung zu ermöglichen.
Durch die Erzeugung dieser vielfältigen Testdaten kann der mgm A12 Testdatengenerator verschiedene Anwendungsszenarien effektiv abdecken.
Effiziente Identifizierung von Regelwidersprüchen im mgm A12 Testdatengenerator: Eine Lösung für komplexe Fälle
Bei der Entwicklung des mgm A12 Testdatengenerators haben wir eine weitere Herausforderung erkannt, die er effektiv bewältigen kann: das Aufspüren von Regelwidersprüchen, die dazu führen, dass manche Felder nicht angegeben werden können.
Ein einfaches Beispiel: Regel 1 besagt, dass die Felder A und B eines Formulars gemeinsam angegeben sein müssen. Regel 2 besagt, dass die Felder A und B nicht gemeinsam angegeben sein dürfen. Als Folge können Anwender für die betroffenen Felder keine Eingaben machen. Sie lassen sich durch den Regelwiderspruch nicht mehr nutzen.
In der Praxis fallen solche einfachen Widersprüche direkt auf. Es gibt jedoch deutlich komplexere Fälle, die sich über mehrere Regeln erstrecken. Diese lassen sich nur sehr schwer auffinden. In der Praxis hat die Testdatenerzeugung zum Beispiel einen Widerspruch aufgedeckt, der sich in einem Steuerformular über einen Zusammenhang von acht Regeln und acht Feldern erstreckt hat. Ein Mensch hat kaum eine Chance, solche Fehler zu entdecken.
Widersprüche während der Modellierung erkennen
Das Verfahren erkennt nicht nur, dass solche Widersprüche existieren. Es legt auch offen, welche Regeln und Felder betroffen sind. Für eine fehlerfreie Modellierung sind diese Informationen von unschätzbarem Wert – insbesondere, wenn Business Analysten und Fachexperten möglichst früh im Entwicklungsprozess darauf Zugriff haben.
In der Enterprise Low Code Plattform A12 ist dieses Tool bereits in die Modellierungswerkzeuge integriert. Der mgm A12 Testdatengenerator weist auf Widersprüche direkt bei der fachlichen Modellierung hin und stellt sicher, dass die Modelle aus mathematischer Sicht einwandfrei sind.
Das ist ein schönes Beispiel, wie die Ergebnisse eines internen Forschungsprojekts zweitverwertet werden können. Somit haben wir nicht nur die Wege aus dem Labyrinth gefunden, sondern im Vorbeigehen auch gleich den darin hausenden Drachen gezähmt.
Übrigens: Der Testdatengenerator lässt sich auch für Anwendungen, die nicht auf A12 basieren, einsetzen.
