.mzT in drei Schritten: von der Idee zum Modell
Das Modellieren von Testsystemen mithilfe von .mzT ist leicht und intuitiv erlernbar. Zu Beginn stellen sich folgende Fragen:
1. Welches Werkzeug möchte ich verwenden?
.mzT ist komplett werkzeugunabhängig. Prinzipiell könnte man modellzentriertes Testdesign mit Bleistift und Papier betreiben, nur ist dies natürlich nicht sinnvoll. Um aus Ihren Testmodellen automatisiert Testfälle zu generieren, benötigen Sie ein Werkzeug, das die detaillierte Beschreibung der Testschritte bzw. Funktionsaufrufe sowie der erwarteten Ergebnisse ermöglicht. Aktuell unterstützt .
MBTsuite folgende Modellierungswerkzeuge:
Kontaktieren Sie uns, wenn Sie Interesse an einem Testfallgenerator haben, aber ein anderes Modellierungswerkzeug verwenden!
2. Welche Modellform ist geeignet, mein Testsystem zu beschreiben?
Die Modellierung der Testsysteme folgt üblicherweise UML-Regeln, wenn auch nicht zwangsläufig bis ins letzte Detail. Verbreitete Modellformen, die auch von MBTsuite ausgewertet werden können, sind:
- Aktivitäten-Diagramm
- Zustands-Diagramm
- Message Sequence Charts
- Business Process Modeling Notation (BPMN)
3. Wie kann ich meine Inhalte in meinem Modell ablegen?
Um Testfälle automatisiert aus dem Testmodell ableiten zu können, müssen Funktionsaufrufe oder Testanweisungen im Modell hinterlegt sein. Hier gibt es verschiedene Möglichkeiten:
- TaggedValue
- Stereotype
- bestehende Attribute (z. B. Description-Feld)
Je nach Projekt und Umfeld können auch Mischformen dieser Optionen sinnvoll sein. Um Sie optimal zu unterstützen, haben wir flexible Modellierungsrichtlinien für .mzT erstellt. Dabei handelt es sich um eine semiformale UML-Notation gemäß den Prinzipien des .mzT:
- intuitiv
- praxisnah
- flexibel
Wir helfen Ihnen gern bei der Einführung des modellzentrierten Testens. Hier finden Sie Informationen über unsere Schulungen zum Thema .mzT.
Im Folgenden finden Sie beispielhafte Modelle aus unterschiedlichen Branchen...
Automotive: Test der Blinkersteuerung
TBS_mzT_MBTsuite: .mzT in der Automotive-Welt
Beim Blinken wird zwischen Richtungs- und Warnblinken unterschieden. Der Richtungsblinker wird entweder angetippt oder dauerhaft aktiviert. Die Warnblinkanlage kann durch einen Richtungsblinker unterbrochen werden und muss nach Beendigung des Richtungsblinkens wieder aktiviert werden. Die erste Abbildung zeigt die Möglichkeiten des Wechselns zwischen Richtungs- und Warnblinken, wobei die Aktivität des Warnblinkens weiter verfeinert dargestellt ist. An jedem Knoten befindet sich entweder eine Anweisung an das Testsystem oder eine Überprüfungsanweisung zum aktuellen Zustand der Blinker.
Mithilfe des Testfallgenerators MBTsuite lassen sich aus diesem Modell Testfälle zur manuellen Durchführung generieren, die textuelle Anweisungen und Prüfungsschritte für den Tester enthalten. Außerdem können automatisierte Testfälle direkt in ein Testmanagementwerkzeug generiert werden, sofern die entsprechenden Bibliotheks-Funktionen in der Testumgebung zur Verfügung stehen und die Aufrufe im Modell hinterlegt sind. Es stehen verschiedene Steuerungsmechanismen durch das Modell zur Verfügung und unterschiedliche Strategien, die beim Durchlaufen des Modells angewandt werden können. Es besteht die Möglichkeit, Teilpfadwiederholungen sowie Knoten- oder Kantenwiederholungen zu unterbinden bzw. einzuschränken.


Embedded Systems: Test der UNIX-Datumsfunktion
TBS_mzT_MBTsuite: .mzT in der Embedded World
Ein Beispiel für die praktische Anwendung von .mzT ist der Test der UNIX-Datumsfunktion. Diese Funktion berechnet anhand eines gegebenen Datumswertes die Sekunden, die seit dem 1.1.1970 vergangen sind. Um die Robustheit der Funktion zu testen, müssen verschiedene Kombinationen an gültigen und ungültigen Datumswerten als Inputvektoren verwendet werden. Die Funktion, die diese Eingabedaten erhält, muss korrekt auf fehlerhafte und richtige Daten reagieren. In diesem Beispiel (s. Abb.) wird der Aufbau der Inputvektoren durch mehrere Subdiagramme realisiert. Zuerst wird eine Jahreszahl ausgewählt, die entweder ungültig oder gültig sein kann, wobei ein gültiges Jahr außerdem ein Schaltjahr sein kann usw. Diese Unterscheidung wird in den Subdiagrammen für die Monats- und Tagesauswahl wichtig.
Der nächste Schritt modelliert die Monatsauswahl. Hier werden gültige Monate unterschieden zwischen einem Monat mit 31, 30 oder 28 bzw. 29 Tagen.
Anschließend wird ein gültiger oder ungültiger Tag ermittelt, abhängig vom vorher gewählten Jahr und Monat. Die Stunden, Minuten und Sekunden für den Inputvektor werden durch einen Rangetest erzeugt, der abhängig vom aufrufenden Diagramm unterschiedliche obere und untere Grenzwerte erhält. Sobald ein ungültiger Wert im Inputvektor enthalten ist, wird der Ausführungsumgebung mitgeteilt, dass der Funktionsaufruf nicht erfolgreich sein darf. Dadurch wird das erwartete Ergebnis (Expected Result) „failed“ ermittelt.
Die Abbildung zeigt die .mzT-Darstellung der beschriebenen Modelle. Mithilfe des Testfallgenerators MBTsuite lassen sich aus diesem Modell 11016 Testfälle (bzw. Funktionsaufrufe) generieren.
Das Beispiel zeigt, dass es durch den Einsatz von .mzT möglich ist, eine große Menge an Testdaten und Testskripten effizient und damit wirtschaftlich und außerdem visuell leicht verständlich darzustellen. Die Pflege der generierten Testsuiten und Testfälle wird durch die automatische Generierung aus den Modellen stark vereinfacht und notwendige Änderungen beschränken sich auf das Modell.
Logistik: Test eines ERP-Systems
TBS_mzT_MBTsuite: .mzT in der Logistik
Die Validierung von komplexen Materialwirtschafts- oder ERP-Systemen verlangt umfangreiche und aufwendige Tests, denn hohe Konfigurierbarkeit und starke Abhängigkeit zwischen einzelnen Features erschweren die Erstellung von Testfällen.
Im hier beschriebenen Projekt wurde ein ERP-System kundenspezifisch modifiziert. Die Validierung dieser Anpassungen mit einem modellzentrierten Testansatz startete mit der Ausformulierung von Workflows und der Übertragung der einzelnen Aktivitäten in ein UML-basiertes Modell.
Die Testmodelle wurden kontinuierlich dem aktuellen Stand der Applikation angepasst. Dabei zeigten sich die großen Vorteile in Bezug auf die Wartung von existierenden Testmodellen.
Neue Testfälle ließen sich sehr schnell integrieren, was die Erweiterbarkeit der Methodik zeigt. Sie bietet somit eine hohe Zukunftssicherheit, da gegebenenfalls nicht von Grund auf neu begonnen werden muss.
Alle Modelle wurden mit den Stakeholdern einem Review unterzogen. Für einen manuellen Abnahmetest wurden dann mit MBTsuite aus den resultierenden 47 Modellen insgesamt 175 Testfälle generiert, und zwar im Vergleich zur konventionellen Vorgehensweise signifikant schneller.
Durch die Generierung der Testfälle mit MBTsuite und den schnellen Einstieg in die Testphase fand der Test schon parallel zur Anpassung des ERP-Systems statt, sodass die Ergebnisse (Fehler/Mängel) aus dem Test noch berücksichtigt bzw. korrigiert werden konnten.
Martin Seel
Fragen Sie direkt unseren Experten: Herr Martin Seel steht ihnen gerne als Gesprächspartner zur Verfügung - nur ein Klick entfernt.


