Die Kluft überbrücken

By Renate Stuecka | 24/06/2022 | Reading time: 3 min

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.

Bildschirmfoto 2022-06-24 um 15.43.21

            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.

Bildschirmfoto 2022-06-24 um 15.47.10

                         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.

Renate Stuecka

Renate Stuecka is a Consultant at SodiusWillert. Prior to joining SodiusWillert, Renate held various management positions in marketing and product marketing with a focus on advanced engineering tools for more than 20 years. Earlier, Renate had specialized in communication systems and led product management and software development teams in that industry. Renate has a Master of Science degree in Computer Science from Technical University Dortmund, Germany.

Leave us your comment

Discover our webinar

Connect Jira + Polarion ALM to maximize the efficiency of your entire software development process

“Join Robert Baillargeon, Chief Product Officer, to learn how you can connect artifacts in Siemens Polarion ALM to your Jira assets and kickstart seamless collaboration throughout the software development lifecycle. ”

Save Your Spot

Subscribe to our blog

Watch the product demo

OSLC Connect for Jira: integrate Jira with IBM Engineering Lifecycle Management.

Icon_OSLC Connect for Jira_color_144*144px_SodiusWillert_2020_RVB

 

OSLC Connect for Jira leverages Open Services for Lifecycle Collaboration (OSLC) technology to collaboratively allow linking across design and implementation teams and better manage requirements and compliance.

 

 

Most read articles