EXAM 3.0

Neue Funktionen


In EXAM 3.0 sind zahlreiche neue Funktionen integriert:

Tool-Zusammenführung – „Aus 3 mach 1“

Mit der Einführung von EXAM 2.0 wurde die Zahl der Einzeltools von vormals über sieben (EXAM 1.x) bereits auf drei reduziert. Dabei passt sich die Tool-Landschaft nun an die Prozessabläufe an. Der EXAM modeller umfasst alle Funktionalitäten, die für die Testmodellierung benötigt werden. Der EXAM testrunner ermöglicht die Testzusammenstellung und die Ausführung der gewählten Testfälle, während der EXAM reportmanager die Testergebnisse darstellt. Mit EXAM 3.0 wird es nun sogar nur noch ein Tool geben, in dem die bisherigen Tools über verschiedene Perspectives dargestellt werden. Hierbei handelt es sich um funktionale Sichten, die schon in EXAM 2.0 im EXAM modeller genutzt werden. Hier sind beispielsweise die ParameterManager Perspective oder der Composer bereits integriert. Im neuen EXAM existieren nun zwei zusätzliche Perspectives, die Testrunner Perspective und die Reportmanager Perspective.

Was sind die Vorteile der Zusammenführung?

Zum einen wird der Workflow noch weiter optimiert, indem lediglich ein EXAM-Projekt einzurichten ist, das für alle Perspectives genutzt wird. Zum anderen wird der Speicherverbrauch optimiert, da nur noch ein Tool geöffnet ist. Zudem muss nur ein Tool upgedated werden, so dass Versionskonflikte vermieden werden. Diese konnten bisher auftreten, wenn z.B. der EXAM modeller nicht zu der Version des EXAM testrunners kompatibel war. Für die Tool-Vereinigung gibt es auch zwei funktionale Gründe: So ist es möglich, direkt aus der Reportmanager Perspective von einem Test­ergebnis zur Testimplementierung in der Modeller Perspective zu navigieren. Des Weiteren ist die Zusammenführung zwingend notwendig, um eine Debugging-Möglichkeit in EXAM zur Verfügung zu stellen.

Graphical Debugging

In EXAM 2.0 findet ein Debugging der Testabläufe fast ausschließlich über die Ausgabe von Debug-Informationen über das Logfile statt. Da die Komplexität der Testabläufe allerdings immer weiter steigt, ist eine komfortable Debugging-Möglichkeit im Testablauf für eine effiziente Analyse von Fehlern sinnvoll. Mit EXAM 3.0 wird aus diesen Gründen das Graphical Debugging eingeführt. Warum „Graphical“? Mit dem neuen Debugger in EXAM 3.0 arbeitet sich der Anwender nicht direkt schrittweise durch den generierten Code, sondern bekommt die aktuelle Ausführungsposition direkt in den Sequenz-Diagrammen oder ActivityDiagrams angezeigt. Die Position wird durch eine farbige Hervorhebung in den Diagrammen dargestellt. Es können im Diagramm direkt Breakpoints gesetzt werden, bzw. man kann das Diagramm schrittweise ausführen. Zusätzlich wird der Stacktrace angezeigt, um Rekursionen bzw. die Aufrufstruktur zu analysieren. Im Debugger können auch die Werte von einzelnen Variablen angezeigt und verändert werden.

ActivityDiagrams – EXAM wird mehrspurig

Bisher ist mit EXAM 2.0 lediglich ein rein sequentieller Testablauf möglich. Für Aktionen, die parallel ausgeführt werden müssen, ist entweder eine Verlagerung der Aktionen in das Echtzeitmodell des HiL-Systems nötig oder die Erstellung einer eigenen Python-Implementierung, welche die Parallelität abbildet. Der Bedarf an parallelen Abläufen ist im Bereich der Testerstellung für Infotainment-Komponenten durch die stark statusorientierte Test-Herangehensweise sehr ausgeprägt. Diese Art zu Testen macht zusätzlich ein Eventhandling notwendig, um nicht aktiv auf Ereignisse warten zu müssen, sondern über Events benachrichtigt zu werden. EXAM 3.0 unterstützt dies durch die Einführung von ActivityDiagrams, was sicherlich auch für andere Testbereiche nutzbar ist. Diese Diagramme werden mit dem EXAM-Objekt TestActivity eingeführt, das wie eine Testsequenz verwendet werden kann. In dem ActivityDiagram können dann parallele Abläufe über Fork bzw. Join Nodes erzeugt werden.

Scripting-Schnittstelle

In vielen Fällen werden den EXAM-Modellen Informationen hinzugefügt, die dem jeweiligen Testprozess geschuldet sind. Das Hinzufügen dieser Informationen ist oftmals umständlich oder kann nicht effizient für mehrere Objekte gleichzeitig durchgeführt werden. Da die Anforderungen jedoch sehr unterschiedlich sind und die Informationen nicht von allen EXAM-Anwendern gleich genutzt werden, ist es nicht zielführend, diese im EXAM-Tooling unterzubringen. Aus diesem Grund wird EXAM ab Version 3.0 um eine Scripting-Schnittstelle basierend auf der Skriptsprache Groovy von The Codehaus (http://groovy.codehaus.org) erweitert. Mit der Schnittstelle ist es möglich, direkt auf das EXAM-Datenmodell zuzugreifen, sowie Modellobjekte zu erstellen, zu verändern und zu löschen. Gezieltes Ändern von bestimmten Objekten wird durch eine Übergabe des aktuell selektierten Objektes erreicht. Es können also sowohl allgemeine Datenmodell-Operationen als auch objektspezifische Operationen ausgeführt werden. Der Anwender legt für jedes Skript fest, wie es ausgeführt werden kann und für welche EXAM-Objekttypen dieses Skript zur Verfügung steht. Im Kontextmenü der EXAM-Objekte werden nur die jeweils zugeordneten Skripte angezeigt und können auch nur dann ausgeführt werden. Für die Bearbeitung der Groovy-Skripte steht ein eigener Editor zur Verfügung, der folgende Features bietet:

  • Syntax Highlighting
  • Code Completion mit Anzeige von Javadoc
  • Anzeige von Syntax-Fehlern
  • Source Code Formatter

Exception Handling – „Try“ und „catch“

Wenn in EXAM während des Testablaufs eine Exception auftritt, wird derzeit der Testcase abgebrochen und eine allgemeine Exception-Sequenz ausgeführt. Dies ist für alle Laufzeitfehler, die die Aussagekraft des Testergebnisses verändern, durchaus sinnvoll. In vielen Fällen werden jedoch in einem Testcase auch Aktionen durchgeführt, die für die Bewertung des Testfalls nicht unbedingt nötig sind. Hier ist es sinnvoll, dem Anwender die Möglichkeit zu geben, gezielt bestimmte Exceptions selbst zu behandeln, ohne dass der Testcase abgebrochen wird. Realisiert wird das in EXAM 3.0 mit den neuen Interaction Frames „try“ und „catch“. Somit kann dann auch gezielter auf bestimmte bekannte Fehler in der Hardware- bzw. Software-Ansteuerung reagiert werden und so die Ablaufstabilität verbessert werden.

Allgemeine Features

Eine Auswahl der weiteren Verbesserungen, die mit EXAM 3.0 eingeführt werden:

  • Im Package-Baum der Modeller Perspective wird durch Overlay-Icons angezeigt, wo im Modell sich Constraint-Verletzungen befinden und auf welchen Packages nur Leserechte vorhanden sind.
  • Die Suche im EXAM modeller ist erweitert, so dass sowohl nach FullScopedNames als auch nach UUID (Universally Unique Identifier) gesucht werden kann.
  • Die BIRT-Schnittstelle des EXAM reportmanagers wird erweitert, so dass alle Daten der Report-Datenbank für die Erstellung von Reports genutzt werden können, ohne dass Anpassungen am EXAM reportmanager nötig sind.
  • Im EXAM reportmanager können mehrere Reports gleichzeitig geöffnet werden.
  • Die Suche im EXAM reportmanager wurde um neue Elemente erweitert.
  • Im EXAM reportmanager werden Änderungen an der Testbewertung automatisch mit dokumentiert, so dass es möglich ist nachzuvollziehen, welche Änderungen an dem Report bzw. den Testergebnissen durchgeführt wurden.
  • Der Status des Codegenerators wird detaillierter dargestellt. Damit ist besser erkennbar wie viele Elemente noch generiert werden müssen und welche Generierung noch aussteht.

Kontakt


MicroNova AG
Unterfeldring 6
85256 Vierkirchen

Tel.: +49 8139 9300-0
Fax: +49 8139 9300-80
E-Mail: info@who-needs-spam.micronova.de

Mehr

News: Aktuelle Kundenzeitschrift InNOVAtion 01-2019 mehr


Presse: Caritas-Gruppe zu Besuch bei MicroNova mehr


Karriere: Technical Lead Java EE mehr

MicroNova - Kontakt


MicroNova AG
Unterfeldring 6
85256 Vierkirchen

    +49 8139 9300-0
    info@who-needs-spam.micronova.de

» Anfahrtsplan