Testausführung

../_images/Packageeditor_MenuPanel.png

ecu.test stellt für die Testausführung neben einem übersichtlichen Ausführungsfenster, unter anderem einen Debugger und ein Prüfungsmodul zur Verfügung, die im kommenden Abschnitt näher beschrieben werden.

Das Verhalten der Traceanalyse für die einzelnen Ausführungsmodi ist unter Schnittstelle zur Traceanalyse genauer dokumentiert.

Package ausführen

../_images/Packageeditor_Run.png

Über den Button, in der Buttonleiste, kann die Package- und Traceanalyseausführung gestartet werden. Über den schwarzen Pfeil neben dem Button ist es auch möglich, nur die Package- oder nur die Traceanalyseausführung zu starten.

Der sich nun öffnende Ausführungsdialog ist in der folgenden Grafik zu sehen:

../_images/PackageAusfuehrung.png

Der Ausführungsdialog gliedert sich in mehrere Bereiche.

  • Im oberen Bereich werden die bisherige Laufzeit der Ausführung und der aktuelle Ausführungsschritt dargestellt. Die Ausführung gliedert sich in drei Hauptbestandteile: Testfall, Traceanalyse und Reporterstellung.

  • Im linken Bereich wird während der Ausführung des Testfalls ein Überblick über das Hauptpackage mit den bisher vergebenen Bewertungen dargestellt. Der aktive Schritt ist farbig hervorgehoben.

  • Im rechten Bereich wird der Aufruf-Stack dargestellt. Dieser besteht aus dem aktuell ausgeführten Testschritt und den Subpackages, in deren Kontext der aktive Testschritt ausgeführt wird.

Die Buttons am unteren linken Rand des Dialogs ermöglichen das Öffnen des Echtzeit-Logs (Meldungsfenster als eigenständiges Fenster) und das Deaktiveren des automatischen Scrollens in der Packageübersicht.

Am rechten unteren Rand wird das aktuelle Gesamtergebnis der Ausführung dargestellt und es besteht die Möglichkeit die Ausführung abzubrechen.

Testfall und Traceanalyse ausführen

Diese Schaltfläche startet die Ausführung des Testfalles und der Traceanalyse.

Testfall und Traceanalyse parametriert ausführen

ecu.test ermöglicht es jeden Testfall mit einer bestimmten Belegung von Variablen auszuführen. Nachdem die entsprechende Schaltfläche aktiviert wurde, erscheint ein Dialog der alle definierten Variablen übersichtlich darstellt. In diesem Dialog können die Werte von Variablen entsprechend Ihrer Vorstellungen angepasst werden.

../_images/Packageeditor_ParamDlg.png

Mit einem Klick auf OK bestätigt man die derzeitige Belegung und führt den Testfall mit der gewünschten Variablenbelegung aus.

Info

Falls keine Variablen in dem jeweiligen Package definiert wurden, erscheint der Parametrisierungs-Dialog nicht.

Testfall ausführen

Diese Schaltfläche startet die Ausführung des Testfalles. Analysejobs der Traceanalyse werden erstellt, aber nicht ausgeführt.

Ausführung via test.guide

Die Ausführung via test.guide ermöglicht es, ein lokal bearbeitetes Package über die Ausführungsverteilung von test.guide auf einem gewünschten Prüfstand auszuführen. Dadurch können eigene Änderungen schneller getestet werden, ohne dass der Prüfstand während der Entwicklung blockiert wird.

Info

Es empfiehlt sich, die Konfiguration im Offline-Modus zu starten. Dadurch wird sichergestellt, dass ecu.test keine Verbindung zum Prüfstand aufbaut und ihn blockiert.

Grundlage ist ein Git-basierter Workflow. Lokale Änderungen werden auf einen Feature-Branch gepusht, sodass eine Ausführungsaufgabe darauf arbeiten kann. Der lokale Workspace-Stand bleibt dabei unverändert.

Features:

  • Auswahl lokaler Änderungen für den Feature-Branch.

  • Zusätzliche Packagereferenzen werden automatisch erkannt.

  • Auswahl der zu verwendenden Konfiguration sowie die Option, ecu.test nach der Ausführung auf dem Prüfstand zu beenden. Die Konfiguration selbst wird unverändert auf dem Prüfstand verwendet, d.h. lokale Änderungen an der Konfiguration werden nicht auf den Feature-Branch gepusht.

  • Ausführung wahlweise auf einer bestimmten Test Resource Machine oder für einen bestimmten XIL/Type.

  • Favoriten erleichtern die wiederholte Ausführung.

  • Feature-Branches haben immer das Format schedule-test-guide/<package name>_<date and time> (z. B. schedule-test-guide/my_package_20260723-170500).

  • Der erzeugte Feature-Branch wird nur lokal gelöscht und bleibt im Remote-Repository bestehen. Über die Schaltfläche Aktionen… können alle Remote-Feature-Branches auf einmal gelöscht werden.

Voraussetzungen

  • Der Workspace ist Git-versioniert. ecu.test muss über Git in der Lage sein, einen Feature-Branch zu erzeugen und zu pushen.

  • Eine konfigurierte Verbindung zwischen ecu.test und test.guide (Workspace-Einstellungen Punkt test.guide Reports) ist erforderlich.

    • Die Werte uploadAuthenticationKey und projectId der Standardverbindung werden verwendet.

    • Der Authkey benötigt Rechte zum Erstellen von Ausführungsaufträgen.

    • Zum Abfragen der Test Resource Machines wird eine lesende Berechtigung für Monitoring-Daten benötigt.

Info

Durch erweiterte Regeln des Git-Repositories kann ein Push des Feature-Branches abgelehnt werden.

Anwendungsfall 1: GitHub-Regel „Require linear History“

Da der Feature-Branch ausschließlich für die Ausführung verwendet wird, sollten die Feature-Branches über ein Exclusion Pattern von der Regel ausgenommen werden. Zum Beispiel über das Exclusion Pattern schedule-test-guide/*.

Anwendungsfall 2: Regel für Commit-Nachrichten

ecu.test erzeugt standardmäßig einen Commit für alle lokalen Änderungen auf dem Feature-Branch. Entweder verwendet man wie bei Anwendungsfall 1 ein Exclusion Pattern oder man setzt die Umgebungsvariable ECUTEST_SCHEDULE_TG_COMMIT_MESSAGE_PREFIX passend, sodass die resultierende Commit-Nachricht die Regel erfüllt.

Testfall ausführen und Traceanalyse nachgelagert ausführen

Siehe Projektausführung mit nachgelagerter Analysejob-Abarbeitung.

Traceanalyse aus aktuellem Testreport ausführen

Durch diese Option ist es möglich die Analysen aus dem aktuellen Report erneut auszuführen.

Traceanalyse einzeln ausführen

Diese Schaltfläche startet die Ausführung der Traceanalyse. Da kein Testfall ausgeführt wird, werden nur manuell in den Aufnahmegruppen hinterlegte Aufnahmen analysiert.

Package interaktiv ausführen

../_images/Packageeditor_RunInteractive.png

Über diese Schaltfläche kann das Package im interaktiven Modus ausgeführt werden. Das bedeutet, dass die Blöcke, die als Nutzeranweisung gekennzeichnet sind, in einem größeren Fenster angezeigt werden und der Inhalt aus Aktion, Parametern und Erwartung von einer Computerstimme vorgelesen wird. Die Bewertung solcher Blöcke erfolgt manuell durch den Nutzer. Weitere Informationen zum interaktiven Testen.

Über den kleinen schwarzen Pfeil neben dem Startsymbol kann zwischen zwei Ausführungsvarianten gewählt werden.

Testfall und Traceanalyse interaktiv ausführen

Diese Schaltfläche startet Testfall und Traceanalyse im interaktiven Modus. Die Traceanalyse selbst bietet keine gesonderte interaktive Funktionalität, sie wird wie gehabt automatisch und ohne Nutzerinteraktion ausgeführt.

Testfall und Traceanalyse interaktiv parametriert ausführen

Diese Schaltfläche kombiniert die Funktionalität der folgenden beiden Ausführungsoptionen:

Testfall interaktiv ausführen

Diese Schaltfläche startet den Testfall ohne die Traceanalyse. Die Ausführung ohne Traceanalyse ist empfehlenswert, wenn die Ergebnisse der Traceanalyse nicht sofort benötigt werden und die Laufzeit der Traceanalyse gespart werden soll. Die Traceanalyse kann später über den Menüpunkt Traceanalyse einzeln ausführen nachgeholt werden.

Package debuggen

../_images/Packageeditor_Debug.png

In ecu.test ist ein Debugger integriert, um bei aufgetretenen Problemen eine einfache Analyse durchführen zu können.

Der Debugger wird über den Button neben der „normalen“ Testausführung gestartet. Hier kann über den Pfeil daneben noch zusätzlich gewählt werden, ob nur der Test oder auch eine ggf. vorhandene Traceanalyse ausgeführt werden soll.

Wird der Debugger gestartet, läuft die Ausführung wie bei einem normalen Start, aber nur bis zum ersten Breakpoint. Ab hier kann die weitere Ausführung mit verschiedenen Optionen gesteuert werden:

  • die Ausführung bis zum nächsten Breakpoint fortsetzen.

  • Referenz debuggen (das heißt, wenn der Schritt ein Package ist, muss auch im aufgerufenen Package jeder Schritt einzeln bestätigt werden),

  • nur den nächsten Schritt ausführen (und auf nächste Aktion warten),

../_images/Debugger.png

Die Breakpoints werden über das Testschrittkontextmenü (rechte Maustaste auf einen Testschritt) gesetzt oder entfernt und durch einen roten Punkt auf dem Testschritt dargestellt (siehe Abbildung).

../_images/Debugger_Breakpoint.png

Testreport auswerten

Der Testreport wird in einer Datenbank zur Verfügung gestellt. Automatisch nach Testende öffnet sich eine Datenbankansicht, um den Testreport bequem analysieren zu können. Der Testreport stellt alle Testschritte mit ihren Bewertungen (SUCCESS, FAILED, ERROR) dar. Dabei wird die Bewertung entweder als Hintergrundfarbe der Tabellenzelle dargestellt (dieser Testschritt hat diese Bewertung) oder nur als Rahmenfarbe. Letzteres bedeutet, dass der Testschritt selber keine Bewertung hat, aber ihm weitere Testschritte untergeordnet sind und somit die Bewertung der untergeordneten Testschritte dargestellt wird (z. B. bei Packagereferenzen, Block- oder IF-THEN-Schritten).

Alle Funktionen zum Testreport finden Sie im Kapitel Testreport ausführlich erläutert.

Testfall-Coverage

Mit der Funktionalität der Testfall-Coverage kann die Zeilenabdeckung einzelner Testschritte während der Testfallausführung gemessen und anschließend im Package-Editor visualisiert werden.

../_images/testcase_coverage.png
Anwendungsfall
  • Erstellung von Coverage-Metriken im Sinne des Qualitätsmanagements

  • Ermitteln von nicht betretenen Zweigen des Testfalls zwecks Bereinigung

  • Absicherung zentraler User-Bibliotheken (z.B. Library-Workspaces)

Aktivierung

Um die Coverage bei der Testausführung zu messen, muss diese zunächst in der Testkonfiguration aktiviert werden: Testkonfiguration ‣ Ausführung ‣ Testfall-Coverage

Beim Hochladen von Reports zu test.guide werden die zugehörigen Coverage-Dateien automatisch mit übernommen.

Bedienung

Wenn die Coverage-Messung in der Testkonfiguration aktiviert wurde, wird diese direkt bei der Ausführung eines Packages oder Projektes bestimmt. Die Visualisierung der Zeilenabdeckung erfolgt ausschließlich innerhalb von Packages.

Die Visualisierung wird direkt nach der Testfallausführung auf alle im Editor geöffneten Packages angewendet.

Über Extras ‣ Coverage ist es möglich, weitere Coverage-Dateien zu laden sowie die Visualisierung zurückzusetzen.

Ebenso können über Extras ‣ Coverage ‣ Coverage-Dateien via Filter aus test.guide laden… Coverage-Dateien aus test.guide geladen werden. Dazu muss in test.guide ein Projektfilter existieren welcher die relevanten Reports einschließt. Anschließend können unter Angabe der Projektfilter-ID alle Coverage-Dateien geladen werden, die in den gefilterten Reports enthalten sind.

Wichtig

Die Verbindung zu test.guide muss konfiguriert sein. Der verwendete test.guide-Authentifizierungsschlüssel muss einem Nutzer zugeordnet sein, der das Recht besitzt auf den Projektfilter zuzugreifen.

Erstellung eines Coverage-Reports

Über Extras ‣ Coverage ‣ Erzeuge Coverage-Report besteht auch die Möglichkeit, einen Coverage-Report zu erstellen, der alle aktuell geladenen Coverage-Dateien zusammenfasst. Dabei werden folgende Dateien erzeugt:

  • Eine XML-Datei, die die zusammengeführten Coverage-Daten enthält

  • Eine HTML-Datei mit einer grafischen Darstellung der Testfall-Coverage aller Packages im Workspace

  • Eine JSON-Datei mit detaillierten Coverage-Informationen für jedes Package

Die HTML-Darstellung ermöglicht es zudem, Packages im Testfall-Editor zu öffnen und deren Testschrittabdeckung im Detail einzusehen.

Die Schema-Definition der JSON-Datei befindet sich im Installationsverzeichnis unter res/schemas.