Test, Debugging & Qualtitätssicherung

Wenn von ,Testen‘ gesprochen wird ist in der Regel das dynamische Ausführen von Software gemeint. Das ist jedoch nur ein Teilbereich. Weitere Disziplinen sind die statische Analyse von Software und das Test-Management. Unter dem Gesichtspunkt, dass die dynamische Ausführung in der Regel die aufwändigste Disziplin ist, lohnt sich auch ein Blick auf die anderen Disziplinen.

Am Ende bleibt noch das Debuggen, das Finden der Ursache für den Fehler. Auch hier lohnt ein Blick auf verfügbare Methoden und Werkzeuge, die anstelle von 'printf debugging' eingesetzt werden können.

GrafikProdukteTest

Willert Embedded UML Target Debugger

Trotz Modellierung in UML wird die entwickelte Software nicht immer frei von Fehlern sein. Debugging bleibt also als wichtige Tätigkeit im Alltagsleben eines Software Entwicklers erhalten.

Wenn nun mit so genannten Embedded Systemen gearbeitet wird, dann ist in der Regel auch eigene Hardware im Spiel und einige der Fehler treten evtl. nur dann auf, wenn die Software auf dieser Hardware ausgeführt wird.

Ein weiteres Kennzeichen von Embedded Systemen ist sehr häufig, dass die Hardware - Ressourcen (z.B. Speicher) begrenzt sind.

Herkömmliche Modellierungslösungen bieten zum Debuggen die Möglichkeit, den aus dem Modell generierten Code auszuführen und parallel das Modell zu animieren. Es kann also auf Modellebene verfolgt werden, wie sich das Programm verhält. Dazu müssen die Laufzeitinformationen auf dem Zielsystem erzeugt und zum Entwicklungs-PC geschickt werden. Das geschieht üblicherweise über so genannte Codeinstrumentierung. Dieses Vorgehen hat den großen Nachteil, dass der auszuführende Code um ein Vielfaches mit Overhead befrachtet wird und sich die reale Laufzeit um ein Vielfaches verlangsamt. Das hat zur Folge, dass Debugging von Modellen auf dem Target nur auf C-Ebene durchgeführt werden kann.

Passend zu IBM® Rational® Rhapsody® gibt es nun eine Debugging-Lösung, die wie herkömmliche Embedded Hochsprachen-Debugger auf Basis eines Monitors arbeitet. Der Vorteil liegt auf der Hand, echtzeitfähiges Debugging mit minimalem Overhead auf UML Modell-Ebene.

Mit dem UML Target Debugger™ ist es nun möglich, das Modell auch auf der realen Hardware auszuführen und zu testen. Das Finden von Fehlern wird somit effizienter, da beim Debugging auf UML-Ebene keine gedankliche Transformierung des C- und C++ - Codes zurück auf die Modell-Ebene erbracht werden muss.

Ebenso können Informationen vom Entwicklungs-PC zum Zielsystem geschickt werden, um dieses zu stimulieren. Das ist eine Voraussestzung, um Tests auf einer realen Hardware durchzuführen. Auf dieser Basis kann z.B. auch der IBM TestConductor genutzt werden, um den Test von UML Modellen auf der Hardware zu automatisieren.

 

Managements Interest

Die UML bietet neben Notationselementen zur Implementation auch Notationselemente zur Spezifikation. Diese können sehr effizient auch zur Spezifikation und Automatisierung von Tests genutzt werden. Somit ist Debugging und Test von komplexen Applikationen auf Modell-Ebene effizienter möglich, als auf Code-Ebene. 

Mit bisherigen Modellierungslösungen konnten die Tests jedoch nicht auf dem Target durchgeführt werden. Das hat zur Folge, dass aussagekräftige Tests von UML Modellen auf dem Target nur auf Code-Ebene möglich waren. 

Der UML Target Debugger ermöglicht nun das Debuggen und Testen von Modellen auf dem realen Target auch auf UML Ebene. Hier stehen sich ein erhebliches Potential an Effizienzgewinn mit vergleichsweise geringen Werkzeugkosten gegenüber.