Tab Report¶

Der Tab Report beinhaltet die Einstellungen für die Dokumentation der Testergebnisse.

Verzeichnis¶

Im oberen Bereich wird der Ordner angegeben, in dem die Dokumentationsergebnisse abgespeichert werden. Die Bedienung ist ähnlich der im Abschnitt Tab Plattform beschriebenen Auswahl von Dateien, nur mit dem Unterschied, dass hier ein Verzeichnis ausgewählt wird.

Ausgabeformat¶

Unter Ausgabeformat können die benötigten Ausgabeformate angelegt werden. Ein Ausgabeformat kombiniert einen Reportgenerator mit einer bestimmten Parametrierung wie Optionen und Filtern. Die Ausgabeformate sind sowohl über Mako-Templates als auch über Reportgeneratoren in Python implementiert. Für die Ausgabeformate HTML und JSON werden in ecu.test Mako-Templates verwendet, für weitere Formate wie EXCEL oder TXT werden Python-Module zur Generierung genutzt. Diese Formatvorlagen bzw. Reportgeneratoren werden aus Gründen der Übersichtlichkeit im Folgenden nur noch als Reportgeneratoren bezeichnet.

Mit der Checkbox vor dem jeweiligen Ausgabeformat lässt sich die automatische Generierung ein- bzw. ausschalten. Ist das Häkchen gesetzt, wird der entsprechende Report nach jedem Testlauf automatisch generiert. Ist das Häkchen nicht gesetzt, kann die jeweilige Generierung bei Bedarf manuell im Testreport gestartet werden.

Das erste Symbol () dient dazu, ein neues Ausgabeformat zu erstellen. Mit können die Einstellungen des ausgewählten Ausgabeformats geändert werden (entspricht einem Doppelklick auf das Ausgabeformat). Mit wird das ausgewählte Ausgabeformat gelöscht.

Um beispielsweise ein neues HTML-basiertes Ausgabeformat für den Testreport zu erstellen, klicken Sie auf und wählen Sie HTML.

In diesem Dialog kann man als erstes einen Namen für das Ausgabeformat angeben. Weiterhin kann festgelegt werden, ob das Ausgabeformat immer automatisch nach jeder Ausführung erstellt werden soll. Man kann auch angeben, dass die hier getroffenen Einstellungen neben der TRF abgelegt werden, damit das Ausgabeformat später z.B. via Jenkins oder per COM API ‚GenerateTestReportDocument()‘ generiert werden kann.

Unter Pre/Post-Skript kann ein Skript angegeben werden, das vor bzw. nach dem Reportgenerator ausgeführt wird. Ein solches Skript muss im Verzeichnis für Benutzer-Python-Bibliotheken abgelegt werden und folgende Struktur aufweisen:

MODULE_TYPE = 'REPORT_PRE_POST_SCRIPT'

class MyReportPrePostScript:
    def __init__(self, reportApi):
        self._reportApi = reportApi

    def ExecutePreScript(self):
        ...

    def ExecutePostScript(self):
        ...

Mittels Projektfilter, Testfallfilter und Traceanalysefilter können verschiedene Filter auf den zu generierenden Testreport angewendet werden. Die Filter entsprechen den Anzeigefiltern im Testreport.

Zusätzlich kann angegeben werden, ob Javascript verwendet werden soll und ob für jedes Subpackage eine eigene HTML-Datei erstellt werden soll. Während bei False alle Subpackages in eine gemeinsame HTML-Datei kommen, wird bei True für jedes Subpackage eine separate HTML-Datei angelegt, die untereinander verlinkt sind. Bei separaten HTML-Dateien sind die Dateigrößen kleiner und die Darstellung großer Testreports mit vielen Subpackages geht deutlich schneller.

Benutzerdefinierte Reportgeneratoren¶

Reportgeneratoren sind in ecu.test als Plugins konzipiert. Der Anwender hat damit die Möglichkeit, die Standardvorlagen (z.B. HTML und TXT) anzupassen oder durch eigene Reportgeneratoren zu ergänzen bzw. zu ersetzen. Die Standardvorlagen liegen im ecu.test Programmverzeichnis unter Templates/Report.

Eigene Reportgeneratoren können im Workspace im Unterverzeichnis für Templates hinterlegt werden (siehe Verzeichnisse). Für jede Vorlage existiert ein eigener Ordner. Der Ordnername bestimmt den Namen des Reportgenerators. Dabei können auch Unterordner zur Strukturierung verwendet werden, dann wird nur der innerste Ordnername als Name des Reportgenerators verwendet.

Um einen neuen Reportgenerator auf Basis eines bereits vorhandenen zu erstellen, muss lediglich der jeweilige Ordner kopiert werden. Anschließend kann die Kopie bearbeitet und an die eigenen Anforderungen angepasst werden. Existieren mehrere gleichnamige Reportgeneratoren, haben zunächst die im Workspace abgelegten Varianten Vorrang vor den im Programmverzeichnis mitgelieferten. Sind im Workspace wiederum mehrere gleichnamige Reportgeneratoren definiert, wird die zuletzt geladene Variante verwendet. In beiden Fällen wird eine Warnmeldung ausgegeben, in welcher der tatsächlich verwendete Reportgenerator genannt wird.

Reportgeneratoren werden entweder in Form von Mako-Templates realisiert (analog zur mitgelieferten HTML-Vorlage) oder als Python-Skripte (wie die mitgelieferte TXT-Vorlage).

Die technische Implementierung von Reportgeneratoren ist in der Report API beschrieben. In diesem Kontext wird der Begriff Reportgenerator auch synonym für Formatvorlagen und Mako-Templates verwendet.

Benutzerdefinierte Informationen¶

Im Abschnitt Benutzerdefinierte Informationen können Daten hinterlegt werden, welche zusätzlich zu den automatisch erstellten Informationen im Testreport erscheinen sollen. Zum Einen können statische Einträge bestehend aus Name, Wert und Beschreibung hinterlegt werden. Diese Einträge erscheinen im Report auf der Hauptseite all jener Packages, die in Kombination mit eben dieser Testkonfiguration ausgeführt wurden. Im Folgenden wurden zwei Einträge manuell festgelegt:

Wird eine solche Konfiguration gestartet und ein beliebiges Package ausgeführt, so erscheinen diese Informationen unter der Rubrik Benutzerdefinierte Informationen im Testreport:

Darüber hinaus können in der Testkonfiguration unterhalb von Generator-Skripte nach Priorität Python-Skripte referenziert werden, welche dynamische Inhalte in den Testreport einfügen. Diese Skripte werden beim Starten der Testkonfigurationen einmalig in der angezeigten Reihenfolge ausgeführt:

Jedes dieser Python-Skripte muss über eine Funktion Init verfügen. Der Parameter userReportData referenziert eine Instanz von UserReportData, über welche Einträge hinzugefügt und geändert werden können. Das folgende Skript demonstriert dies anhand von zwei hinzugefügten Einträgen:

# -*- coding: utf-8 -*-

def Init(userReportData):
    # define new entries
    userReportData.AppendEntry('Name2', 'dynamic2', 'Beschreibung 2')
    userReportData.AppendEntry('Name3', 'dynamic3', 'Beschreibung 3')

    # evaluate if given entry exists (previously defined, e.g. in TCF)
    if "AnImportantEntry" not in userReportData.GetAllEntryNames():
      raise AbortConfigError('Value of AnImportantEntry is not set!')

Wird diese Konfiguration erneut gestartet und ein Package ausgeführt, stehen sowohl statische als auch von den Skripten gelieferte Informationen im Report:

Zu beachten ist, dass der Eintrag mit dem Namen „Name2“ sowohl statisch definiert als auch vom Skript geliefert wurde, aber dennoch nur einmal im Report erscheint. Die statisch definierten Einträge werden mit den von den Skripten gelieferten Einträgen vereinigt. Im Beispiel hat das Skript die höhere Priorität, weswegen der vom Skript gelieferte Eintrag im Report erscheint. Die Priorität der Quellen kann durch die Pfeil-Nach-Oben- und Pfeil-Nach-Unten-Buttons angepasst werden.

Diverses¶

Über die Checkbox Logdateien in Reportordner kopieren wird eingestellt, ob ecu.test nach jeder Testausführung automatisch die zugehörigen Ausgabe Logs mit in den jeweiligen Testreportordner kopieren soll.