Modellbasierter Systemtest auf beiden Seiten des V-Modells
Dieses Thema steht im Mittelpunkt bei einer der Open Space Sessions auf der MESCONF 2022 (Modeling of Embedded Systems Conference) und wir freuen uns darauf, mit Ihnen die verschiedenen Aspekte dieses Ansatzes zu erörtern.
Modellbasierte Entwicklungsprozesse helfen, die Komplexität von Systemen besser zu verstehen und zu handhaben. Mit Hilfe von Modellen werden kritische Aspekte frühzeitig im Entwicklungsprozess erkannt, und können zeitnah nach dem Auftreten behandelt oder beseitigt werden. Intuitive graphische Modellierungstechniken ergänzen oder ersetzen umfangreiche und schlecht wartbare textuelle Dokumentationsunterlagen.
Mit geeigneten Werkzeugen kann die Ausführung der modellierten Systeme simuliert werden, was die Validierung mit dem Kunden und die Verifikation der Spezifikation erleichtert.
Insbesondere die modellbasierte Systementwicklung hilft, eine frühzeitige Reife während der Entwicklung zu erreichen. Fehler bei der Systemspezifikation fallen häufig erst während später Phasen der Entwicklung auf, z.B. bei Systemintegrationstests. Solche Fehler sind besonders schmerzhaft, weil für ihre Behebung nicht selten die Systemspezifikation geändert werden muss, was viele folgende Arbeitsschritte nach sich zieht – und das, zu einem späten Zeitpunkt der Entwicklung.
Der modellbasierte Systemtest ist der Königsweg zur Vermeidung von Fehlern bei der Erstellung der Systemspezifikation. In einem Systemtestmodell werden während der Systemdefinition Testszenarien (siehe Abb. 1) definiert, die man während der Simulation anwendet. Als Basis für die Testszenarien dienen Anwendungsfälle. Sind die Anwendungsfälle auch modellbasiert definiert, fällt die Herleitung der Testszenarien leicht. Das Modellierungswerkzeug IBM Engineering Systems Design Rhapsody erlaubt mit dem TestConductor Plug-In die automatische Erstellung von Testmodellen auf der Basis von UML- und SysML-Modellen. Testszenarien können manuell erstellt werden oder lassen sich automatisch aus den Abläufen der Anwendungsfälle erzeugen. So ist selbst eine testgetriebene Systementwicklung denkbar, wie sie in der Softwareentwicklung schon seit Jahren erfolgreich praktiziert wird.
Abb. 1: Beispiel für ein Testszenario unter Anwendung der Uml und des Testing Profiles
In der Regel finden die Systemtests während der Verifikation des fertig integrierten Systems unabhängig von der Systemdefinitionsphase statt. Systemtests werden auf der Basis der Systemspezifikation neu definiert. Oft sind andere Abteilungen zuständig. Die Entwicklungswerkzeuge (z.B. Teststände) unterscheiden sich extrem von den Entwicklungswerkzeugen, die während der Spezifikationsphase eingesetzt werden.
Die Unabhängigkeit des Systemtests hat natürliche Vorteile und wird manchmal sogar von Behörden gefordert. Es lauern aber neue Fehlerquellen: z.B. die Systemspezifikation wird von den Testingenieuren falsch interpretiert, der neu definierte Systemtest enthält Fehler, oder es fehlt am Ende der Entwicklung schlicht die Zeit, die Systemtests nach jedem Update vollständig durchzuführen.
Es ist aber durchaus denkbar, die Testszenarien, die bei der Erstellung des Testmodells entstanden sind, während der Verifikationsphase wiederzuverwenden (Siehe Abb. 2). Das kann manuell geschehen. Sind die Testszenarien im Testmodell nach einer standardisierten Methode definiert worden (beim TestConductor wird z.B. das OMG Testing Profile verwendet), ist eine Fehlinterpretation nahezu ausgeschlossen.
Abb. 2: Weg vom klassischen Testansatz hin zum modellgetriebenen Test
Optimal wäre eine automatische Transformation der Testszenarien des Testmodells in Testprozeduren des Teststands. Werden zum Beispiel die Testprozeduren in C/C++ definiert, könnten die Testszenarien von einem Werkzeug in C/C++ Kommandos übersetzt werden. So könnte für jedes Update der Systemspezifikation automatisch nach der Systemintegration geprüft werden, ob das integrierte System das gleiche Verhalten aufweist, wie das Systemmodell (das ja der Systemspezifikation entspricht). Die Testingenieure könnten sich auf die Systemtests konzentrieren, die am Systemmodell nicht durchgeführt werden können wie z.B. Performance- oder Stabilitäts-Tests.
Dieser Ansatz wirft aber auch neue Fragen auf. So ist z.B. eine exakte Abbildung der Systemschnittstellen auf die Schnittstellen des Teststands notwendig, was nicht immer ganz einfach sein wird – man denke nur an die Mensch-Maschine-Schnittstelle.