Testmanagement¶
Info
Die Anbindung von Testmanagement-Systemen befindet sich in Bearbeitung. Bitte wenden Sie sich an den Support, wenn Sie ein neues Testmanagement-System verwenden möchten.
Informationen über die in der Entwicklung befindlichen Schnittstelle finden Sie unter Benutzerdefinierte Testmanagement Adapter.
ecu.test bietet Schnittstellen zu verschiedenen Testmanagement-Systemen an. Diese ermöglichen es, Packages, Projekte und Testreports in das jeweilige Testmanagement-System zu exportieren oder deren Repräsentation im Testmanagement-System zu aktualisieren, wenn in ecu.test Änderungen an den jeweiligen Dateien vorgenommen wurden. ecu.test kann auch Packages und Projekte aus dem Testmanagement-System importieren, bzw. wenn dort Änderungen an den jeweiligen Repräsentationen vorgenommen wurden, aktualisieren.
ecu.test kann mit den Testmanagement-Systemen
PTC Integrity und
kommunizieren.
Die meisten im folgenden beschriebenen Operationen können auch über die COM API automatisiert ausgeführt werden.
Terminologie¶
ecu.test und die jeweiligen Testmanagement-Systeme verwenden unterschiedliche Begriffe zur Bezeichnung von einander entsprechenden Artefakten. Die folgende Tabelle zeigt zunächst auf, welche in ecu.test gebräuchlichen Bezeichnungen welchen allgemeinen Begriffen (nach ISTQB) entsprechen.
Die nachfolgende Beschreibung der durch ecu.test unterstützten Funktionalitäten basiert auf den ISTQB-Bezeichnungen. In den Kapiteln der jeweiligen Testmanagement-Systeme ist anschließend beschrieben, welche ISTQB-Begriffe welchen Artefakten des Testmanagement-Systems entsprechen.
ISTQB-Begriff |
Artefakt(e) in ecu.test |
Erläuterung |
|---|---|---|
Testfall |
Package, das (ggf. mit einem Parametersatz) aus dem Projekt heraus aufgerufen wird |
Sofern Parametersätze verwendet werden, ist der Packageaufruf für sich genommen ein abstrakter Testfall, der zusammen mit dem Parametersatz zum konkreten Testfall wird. |
Testskript, Testablaufspezifikation |
Testfall innerhalb des Package |
Packages legen detailliert fest, welche Testschritte in welcher Reihenfolge ausgeführt werden. Oft ist die Ausführung automatisiert möglich. |
Testsuite |
Projekt, ggf. mit bereits angewendetem Filter |
Legt die Menge und die Reihenfoge auszuführender Testfälle fest. |
Testprotokoll |
Testreport, ggf. zusammen mit Logfiles und/oder Signalaufnahmen |
Der Testreport enthält einen Eintrag für jeden ausgeführten Testschritt. Zusätzlich im Reportverzeichnis abgelegte Dateien können weitere Details enthalten. |
Konfiguration¶
Vor der ersten Verwendung muss die Schnittstelle zum Testmanagement-System eingerichtet werden. Die Konfigurationsseite erreicht man über .
Hier kann ein verfügbares Testmanagement-System gewählt sowie die zugehörigen Einstellungen konfiguriert werden. Außerdem wird die aktuell verwendete Java-Version angezeigt.
Info
Standardmäßig ist die Testmanagement-Anbindung deaktiviert.
Allgemeine Einstellungen¶
Diese Einstellungen sind unabhängig vom konfigurierten Testmanagement-System.
- Verwendeter Keystore für Zertifikate
Dient der Überprüfung von vertrauten Zertifikaten. Es kann entweder der benutzerspezifische oder der systemweite Windows-Keystore verwendet werden, oder der Keystore der Java-Laufzeitumgebung.
- Importreihenfolge von Testcases
Definiert die Reihenfolge in der Testcases einer Testsuite beim Projekt-Import importiert werden.
- Attributdefinitionen beim Login aktualisieren
legt fest, ob bei jedem Login die verfügbaren Package- und Projekt-Attribute mit dem Testmanagement-System abgeglichen werden. Die
pkgattr.specundprjattr.specim aktuellen Workspace werden hierbei aktualisiert. Siehe auch Arbeiten mit Attributen.
- Attribute beim Exportieren von Änderungen ignorieren
Wenn diese Option ausgewählt ist, werden ecu.test-Attribute beim „Änderungen exportieren“ nicht mit betrachtet.
- Blöcke als Nutzeranweisung markieren
bietet die Möglichkeit beim Package-Import erstellte Blöcke als Nutzeranweisung im interaktiven Ausführungsmodus zu interpretieren.
- Einstellungen für den Reportexport
Definiert die standardmäßige Konfiguration für das Exportieren von Reports. Diese Einstellungen können bei jedem Export speziell angepasst werden (Exportieren von Testreports ins Testmanagement-System).
- Proxy-Einstellungen
Konfigurationsmöglichkeit für einen Proxy.
- Speicherarme Definitionsabfrage
Fragt die Attributdefinitionen sequentiell ab, was zwar länger dauert, dafür aber nicht so viel Speicher benötigt.
Debug Einstellungen¶
- Port welcher bevorzugt genutzt wird
Der hier spezifizierte Port wird versucht zu benutzen. Sollte dieser nicht verfügbar sein, wird auf den dynamischen Port-Bereich (49152 bis 65535) ausgewichen.
- Debug-Informationen in Log ausgeben
Zusätzliche Informationen werden in die Logdatei geschrieben. Verlangsamt die Interaktionen mit dem jeweiligen Testmanagementsystem.
- Heap Dump aktivieren
Erstellt bei Abstürzen des Java-Prozesses einen Heap Dump.
- Maximale Größe des Heaps (in MB)
Legt die Obergrenze für den Speicherverbrauch des Java-Prozesses fest.
Systemspezifische Einstellungen¶
Diese Einstellungen sind Testmanagement-System bezogen und können abhängig von der getroffenen Auswahl variieren. Häufig muss zum Beispiel die URL des Testmanagement-Systems angegeben werden.
Zusätzlich sollte immer eine domänenspezifische Abbildung der ecu.test-Bewertungen auf die verfügbaren Bewertungen des Testmanagement-Systems vorgenommen werden. Hierzu dient der Dialog Abbildung der Bewertungen.
Info
Standardmäßig ist für alle unterstützten Testmanagement-Systeme eine Abbildung vorgegeben.
Verwendung der Testmanagement-System-spezifischen Bewertungen¶
Beim Exportieren eines Reports nach Testmanagement werden ecu.test-Bewertungen entsprechend der getroffenen Zuordnung abgebildet. Sind mehrere Testmanagement-Bewertungen einer Standardbewertung zugewiesen, so wird immer die oberste bevorzugt.
Weiterhin ist es möglich die Testmanagement-Bewertungen bei der Nachbewertung im Testreport explizit anzugeben. Eine solche Zuordnung wird beim späteren Exportieren des Reports der Standardbewertung vorgezogen.
Info
Es ist möglich, das gleiche Testmanagement-Ergebnis gleichzeitig mehreren ecu.test-Ergebnissen zuzuweisen, z.B. „Cancelled HW = ERROR“ und „Cancelled HW = INCONCLUSIVE“. In diesem Fall ist bei der Report-Nachbewertung in ecu.test das mehrfach verwendete Testmanagement-Ergebnis nur für das schlechteste ecu.test-Ergebnis in der Auswahl der Bewertung verfügbar. Es gilt: ERROR < FAILED < INCONCLUSIVE < NONE < SUCCESS, wobei < „schlechter als“ bedeutet. Im angegebenen Beispiel würde also nur Cancelled HW (ERROR) in der Nachbewertung zur Auswahl angeboten werden.
Benutzerdefinierte Anpassung der Testmanagement-Anbindung¶
Sofern die in den vorherigen Abschnitten angesprochenen Einstellungen nicht ausreichen, ist es möglich die Testmanagement-Anbindung selbst über benutzerdefinierte Skripte (Hooks) anzupassen. Statt die Standardimplementierung zu verwenden, können eigene Hooks verwendet werden, um das Verhalten zu verändern.
Es wird empfohlen die Standardimplementierung aus
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks
als Referenz zu beziehen. Die benutzerdefinierte Version des Hooks muss im Workspace unterhalb von
UserPyModules abgelegt werden, damit ecu.test diese erkennt (ggf. Strg+Shift+R)
und ausführt. Es können auch mehrere Hooks mit unterschiedlichem Verhalten abgelegt werden, welche
ecu.test dann sequentiell ausführen würde.
Die dabei einzuhaltenden Interfaces sind unter
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks/api abgelegt.
Das Verhalten folgender Funktionalitäten kann angepasst werden:
- TestSuite-Import
Interface
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks/api/interface/TestSuiteImportHook.py
- TestScript-Import
Interface
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks/api/interface/TestScriptImportHook.py
- TestScript-Export
Interface
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks/api/interface/TestScriptExportHook.py
- TestScript-Attribute-Export
Interface
<ecu.test-Installationsverzeichnis>/Templates/DefaultData/UserPyModules/AlmHooks/api/interface/TestScriptAttributesExportHook.py
Arbeiten mit Attributen¶
Packages und Projekte können in ecu.test mit Attributen versehen werden. In vielen Testmanagement-Systemen ist es ebenso möglich, Testskripte und Testsuiten mit Attributen zu versehen. ecu.test kann die Attributdefinitionen aus dem Testmanagement-System übernehmen. Dazu klickt man im Kontextmenü eines beliebigen Ordners, Packages oder Projekts im Workspace-Explorer auf .
Sobald dieser Vorgang abgeschlossen ist, kann man für alle Packages und Projekte die vom jeweiligen Testmanagement-System unterstützten Attribute mit Werten befüllen. Sofern für ein Attribut eine Auswahl an Vorgabewerten vorgesehen ist, steht diese Auswahl in ecu.test zur Verfügung. Zudem sind sogenannte Pflichtattribute, deren Befüllung zwingend vorgeschrieben ist, gekennzeichnet.
In den Testmanagement-Einstellungen kann man außerdem festlegen, dass ecu.test die Attributdefinitionen bei jedem Login ins Testmanagement-System automatisch aktualisieren soll.
Für Packages und Projekte, die bereits mit dem Testmanagement-System verknüpft sind, kann man auf Wunsch lediglich die Attribute importieren bzw. exportieren. Entsprechende Funktionen findet man im Kontextmenü der jeweiligen Dateien. Die Funktion ist im Abschnitt zu Packages bzw. zu Projekten näher beschrieben.
Arbeiten mit Packages¶
Mit ecu.test kann man Packages als Testskripte in das jeweilige Testmanagement-System exportieren. Umgekehrt kann man Testskripte aus dem Testmanagement-System als (abstrakte, noch mit konkreten Testschritten auszuimplementierende) Packages importieren. Außerdem kann man Änderungen an Packages in bereits exportierte Testskripte übernehmen.
Ein Package, das ins Testmanagement-System exportiert oder von dort importiert wurde, trägt auf dem Tab Eigenschaften im Abschnitt Allgemein eine Testskript-ID.
Über den Menüpunkt kann man die Verknüpfung eines Packages mit dem Testmanagement aufheben. Dies ist z.B. sinnvoll, wenn ein neues Package durch Kopieren eines bereits mit dem Testmanagement verknüpften Package erstellt wurde. Alle Testmanagement relevanten Informationen werden dann aus dem Package entfernt.
Über den Menüpunkt kann man ein bereits verknüpftes Package mit dem Testskript im Testmanagement-System vergleichen. Dies kann genutzt werden, um sicherzustellen, dass beim Änderungen exportieren auf dem Testmanagement-System keine Änderungen ungesehen überschrieben werden.
Exportieren von Packages ins Testmanagement-System¶
Um ein Package ins Testmanagement zu exportieren, klickt man mit der rechten Maustaste auf das Package im Workspace-Explorer, und wählt .
Man kann auch mehrere Packages auf einmal exportieren, indem man mehrere Packages selektiert oder einen oder mehrere Ordner auswählt. Der Menüpunkt heißt dann Exportiere Packages.
Ebenso kann der Export über angestoßen werden.
Voraussetzung für das Exportieren eines bzw mehrerer Packages ist, dass diese noch nicht mit einem Testmanagement verknüpft sind. Ansonsten können nur die Änderungen mittels Änderungen exportieren ins Testmanagement übernommen werden.
Falls mehrere Packages oder ein Ordner gewählt wurden, erscheint zunächst ein Dialog, auf dessen erster Seite man wählen kann, welche Packages exportiert werden sollen. Diese Seite wird automatisch übersprungen, wenn ausschließlich Dateien selektiert wurden. Um die Auswahl nochmals einzusehen oder einzuschränken, kann über den Zurück-Button auf die erste Seite gewechselt werden. Die eingeblendete Baumstruktur entspricht der Struktur im Dateisystem. Die unter den Ordnern eingeblendeten Packages sind diejenigen Packages, die noch nicht mit dem Testmanagement-System verknüpft sind und noch exportiert werden können.
Die Option Verzeichnishierarchie übernehmen legt fest, ob die Ordnerstruktur in das Testmanagement-System übernommen werden soll.
Info
WICHTIG: Werden ein oder mehrere Ordner exportiert, resultiert der Export immer darin, dass im Zielverzeichnis Unterverzeichnisse angelegt werden (sofern diese noch nicht existieren). Exportiert man also bspw. einen Order „A“ in ein Verzeichnis „TMS“, dann wird unterhalb von „TMS“ ein Ordner „A“ angelegt und darin alle weiteren Artefakte und Verzeichnisse.
Ist die Option nicht ausgewählt, werden die ausgewählten Packages flach in den auf der nächsten Dialogseite festgelegten Ordner exportiert. Unterstützt das verwendete Testmanagement-System keine Verzeichnishierarchie, erscheint anstelle der Option ein entsprechender Hinweistext und die Packages werden ebenso flach exportiert.
Info
Sollte es aufgrund des flachen Exports von Dateien aus mehreren Quellordnern des Dateisystems in einen Zielordner im Testmanagement-System zu Namenskollisionen kommen, erscheint ein Hinweisdialog, der dazu auffordert die Quelldateiauswahl zu überarbeiten.
Auf der zweiten Seite des Dialogs kann man das Zielverzeichnis im Testmanagement-System wählen.
Hier kann man die Stelle im Testmanagement-System wählen, wohin die Packages exportiert werden sollen. Per Rechtsklick kann man hier bei Bedarf noch Unterordner erstellen, sofern dies vom Testmanagement-System unterstützt wird.
Wenn man ein existierendes Testskript wählt, zeigt ecu.test im rechten Teil des Dialogs die Attribute und Testschritte des Testskripts vom Testmanagement-System an. Nach einem Klick auf Fertigstellen bzw. OK werden im gewählten Ordner Testskripte erstellt, die den ausgewählten Packages entsprechen. In den exportierten Packages werden notwendige ID’s des Testmanagement-Systems eingetragen.
Abbildung von Package-Inhalten¶
Beim Export eines Packages wird im Testmanagement-System ein Testskript erstellt bzw. aktualisiert. Das Testskript trägt den Namen und die Attribute des Packages, beschreibt welche Variablen (einschließlich Eingabe- und Rückgabeparameter) das Package hat, und enthält als Testschritte textuelle Repräsentationen der im Testfall-Tab des Packages enthaltenen Testschritte der zweiten Block-Ebene.
Falls das Package eine oder mehrere Traceanalysen enthält, wird als letzter Testschritt ein Schritt erstellt, der die Namen und Beschreibungen aller im Package enthaltenen Traceanalysen durch Zeilenumbrüche getrennt aufzählt.
Die zweite Ebene wurde gewählt, um auf der ersten Ebene eine Gliederung in Precondition (Prüfen/Herstellen von Vorbedingungen), Action (eigentlicher Testablauf) und Postcondition (Herstellen von Nachbedingungen bzw. eines definierten Folgezustandes) zu unterstützen.
Ein Package kann nur exportiert werden, wenn folgende Bedingungen erfüllt sind:
alle Attributwerte erfüllen die vom Testmanagement-System bzw. dessen Konfiguration vorgegebenen Bedingungen
z.B. kann eine Maximallänge vorgegeben sein
evtl. sind nur Werte aus einer vorgegebenen Liste zulässig
es kann Einschränkungen an den Datentyp geben (nur nummerische Werte erlaubt, etc.)
sogenannte Pflichtattribute dürfen nicht leer sein
alle Variablen haben einen unterstützten Typ: String, Numeric, Boolean oder Undefined
alle Testschritte auf zweiter Block-Ebene sind durch die Testmanagement-Schnittstelle textuell darstellbar
Darstellbare Testschritt-Typen sind:
Blöcke
Wait-Testschritte
Lesen-Testschritte mit unterstützter (d.h. nicht manueller) Erwartung vom Typ Numeric oder String
jedoch bei String-Erwartungen nur identisch oder enthalten in (Liste) (dann wird der erste Listeneintrag ausgegeben) und nicht Groß-/Kleinschreibung beachten
Achtung: Python Standardfunktionen (built-ins) werden innerhalb der Erwartung als Variablenzugriffe interpretiert
Schreiben-Testschritte
Aufrufe von Unterpackages
EDIABAS-Diagnoseaufrufe
Fehlende/falsche Attribute oder nicht unterstützte Variablentypen führen dazu, dass der Package-Export abgebrochen wird. Nicht unterstützte Testschritte werden dagegen einfach übergangen.
Info
ecu.test bietet eine Funktion an, über die die Attribute mehrerer Packages gemeinsam bearbeitet werden können. Fehlende Werte für Pflichtattribute oder ungültige Attributwerte kann man so korrigieren ohne jedes betroffene Package einzeln öffnen zu müssen.
Info
Packages mit nicht unterstützten Testschritten auf zweiter Block-Ebene kann man leicht exportierbar machen, indem man die nicht unterstützten Testschritte in neu erstellte Blöcke verschiebt. Den Blöcken gibt man jeweils Texte als Aktion/Name und Erwartung, die die Aktion bzw. Erwartung des/der enthaltenen Testschritte(e) beschreiben. Dann werden diese Texte ins Testmanagement-System exportiert.
Example
Im nachfolgend dargestellten Package „CrankSensor“ sind die nicht unterstützten Testschritte (z.B. Start Trace, Stop Trace und Ausführung JobCall) in Blöcken enthalten, daher kann das Package ins Testmanagement exportiert werden.
Importieren von Packages aus dem Testmanagement-System¶
Um ein Package aus dem Testmanagement zu importieren, klickt man mit der rechten Maustaste auf den Ordner im Workspace-Explorer, in dem das importierte Package abgelegt werden soll, und wählt . Diese Option steht nicht zur Verfügung, wenn mehrere Ordner selektiert wurden.
In dem Dialog, der sich nun öffnet, kann man ein Testskript zum Importieren auswählen. Für das jeweils gewählte Testskript werden im rechten Fensterteil die Attribute und Testschritte dargestellt. Alternativ kann man Testskripte auch über bereits bekannte Id’s importieren.
Nach einem Klick auf OK wird ein Package erstellt. Dieses trägt den Namen, die Attribute und die Variablen des gewählten Testskripts.
Für jeden im Testskript aufgezählten Testschritt wird im Package ein Block-Testschritt erstellt, dessen Aktion und/oder Erwartung mit den entsprechenden Texten befüllt wird. Diese Blöcke werden ggf. in die Blöcke „Precondition“, „Action“ und „Postcondition“ auf oberster Ebene einsortiert. Lediglich Aufrufe von Unterpackages werden wieder als Packageaufrufe importiert.
Der Testschritt, der für die Traceanalyse(n) steht, wird ebenfalls nicht als Block erstellt.
Info
Die so erhaltenen Packages enthalten nur eine textuelle Testablaufspezifikation. Um ein vollwertiges (automatisiertes) Testskript zu erhalten, müssen die automatisch erstellten, leeren Blöcke ausimplementiert werden.
Example
Das weiter oben gezeigte Package „CrankSensor“ sieht nach dem Export und anschließendem Import in einen neuen Ordner wie folgt aus:
Es ist auch möglich, einen Ordner zu wählen. Dann wird im gewählten Workspace-Ordner ein neuer Unterordner erstellt, der so heißt wie der gewählte Ordner im Testmanagement-System, und es werden rekursiv alle Testskripte und Unterordner importiert.
Übertragen von Packageänderungen ins Testmanagement-System¶
Um Änderungen, die man an einem Package vorgenommen hat, das bereits ins Testmanagement-System exportiert wurde, ins Testmanagement zu übernehmen, wählt man den Kontextmenü-Eintrag auf einem Package . Diese Funktion kann auch für einen ganzen Package-Ordner als aufgerufen werden. Die Aktualisierung wird dann ohne jede weitere Rückfrage durchgeführt.
Dabei werden die Attribute des Testskripts mit denen des Packages überschrieben. Gelöschte und hinzugefügte Variablen werden im Testskript ebenfalls gelöscht bzw. hinzugefügt. Umbenennen wird dabei als Löschen und Hinzufügen betrachtet. Ein Schritt des Testskripts wird nur gelöscht, wenn der zugehörige Testschritt auf der zweiten Block-Ebene des Package nicht mehr vorhanden ist. Änderungen an vorhandenen Testschritten sowie an deren Reihenfolge werden unter Wiederverwendung der vorhandenen Schritte ins Testmanagement-System übernommen, damit Verweise auf diese Schritte innerhalb des Testmanagement-Systems (z.B. aus Testprotokollen) intakt bleiben.
Info
Das Wiederverwenden von Testschritten und anderen Package-Bestandteilen wird nicht von allen Testmanagement-Systemen unterstützt. In diesem Fall werden die jeweiligen Objekte überschrieben.
Attribute importieren und exportieren¶
Um lediglich Änderungen an Attributen von mit dem Testmanagement-System verknüpften Packages auf das zugehörige Testskript zu übertragen, kann man im Kontextmenü des Package die Option Exportiere Attribute wählen. Umgekehrt kann man Änderungen an den Attributen des verknüpften Testskripts über Importiere Attribute auf das Package übertragen.
Der Export bzw. Import erfolgt (ggf. nach Rückfrage zum Schließen der betroffenen Packages und/oder Login) ohne weitere Nutzerinteratkion.
Diese beiden Funktionen stehen auch bei Mehrfachauswahl sowie auf Ordnern (dann unter der Bezeichnung Ex-/Importiere Package-Attribute) zur Verfügung.
Arbeiten mit Projekten¶
ecu.test kann Projekte als Testsuiten in das jeweilige Testmanagement-System exportieren. Umgekehrt kann man Testsuiten aus dem Testmanagement-System als Projekte importieren. Außerdem kann man Projekte mit Testsuiten auch ohne Import oder Export verknüpfen, damit beim späteren Export von Testreports das Testprotokoll der Testsuite zugeordnet werden kann. Beim Import und Export erfolgt die Verknüpfung automatisch.
Die Verknüpfung ist bei Parametersätzen als Testfall-ID auf dem Tab Testmanagement des Parametersatz-Dialogs sichtbar. Die Verknüpfung des Projekts selbst wird lediglich als ToolTip im Workspace-Explorer dargestellt. Bei Packageaufrufen ohne Parametersatz ist die Verknüpfung nicht direkt in ecu.test sichtbar.
Über den Menüpunkt kann man die Verknüpfung eines Projekts mit dem Testmanagement aufheben. Dies ist z.B. sinnvoll, wenn ein neues Projekt durch Kopieren eines bereits mit dem Testmanagement verknüpften Projekts erstellt wurde. Alle Testmanagement relevanten Informationen werden dann aus dem Projekt entfernt.
Exportieren von Projekten ins Testmanagement-System¶
Um ein Projekt ins Testmanagement zu exportieren, klickt man mit der rechten Maustaste auf das Projekt im Workspace-Explorer, und wählt .
Man kann auch mehrere Projekte auf einmal exportieren, indem man entweder mehrere Projekte selektiert oder den Rechtsklick auf einem oder mehreren Ordnern ausführt. Der Menüpunkt heißt dann Exportiere Projekte.
Ebenso kann der Export über angestoßen werden.
Falls mehrere Projekte oder ein Ordner gewählt wurden, erscheint zunächst ein Dialog, auf dessen erster Seite man wählen kann, welche Projekte exportiert werden sollen. Diese Seite wird automatisch übersprungen, wenn ausschließlich Dateien selektiert wurden. Um die Auswahl nochmals einzusehen oder einzuschränken, kann über den Zurück-Button auf die erste Seite gewechselt werden. Die eingeblendete Baumstruktur entspricht der Struktur im Dateisystem. Die unter den Ordnern eingeblendeten Projekte sind diejenigen Projekte, die noch nicht mit dem Testmanagement-System verknüpft sind und noch exportiert werden können.
Die Option Verzeichnishierarchie übernehmen legt fest, ob die Ordnerstruktur in das Testmanagement-System übernommen werden soll.
Info
WICHTIG: Werden ein oder mehrere Ordner exportiert, resultiert der Export immer darin, dass im Zielverzeichnis Unterverzeichnisse angelegt werden (sofern diese noch nicht existieren). Exportiert man also bspw. einen Order „A“ in ein Verzeichnis „TMS“, dann wird unterhalb von „TMS“ ein Ordner „A“ angelegt und darin alle weiteren Artefakte und Verzeichnisse.
Ist die Option nicht ausgewählt, werden die ausgewählten Projekte flach in den auf der nächsten Dialogseite festgelegten Ordner exportiert. Unterstützt das verwendete Testmanagement-System keine Verzeichnishierarchie, erscheint anstelle der Option ein entsprechender Hinweistext und die Projekte werden flach exportiert.
Info
Sollte es aufgrund des flachen Exports von Dateien des gleichen Namens aus mehreren Quellordnern des Dateisystems in einen Zielordner im Testmanagement-System zu Namenskollisionen kommen, erscheint ein Hinweisdialog, der dazu auffordert die Quelldateiauswahl zu überarbeiten.
Hier kann man die Stelle im Testmanagement-System wählen, wohin die Projekte exportiert werden sollen. Per Recktsklick kann man hier bei Bedarf noch Unterordner erstellen. Nach einem Klick auf Fertigstellen werden im gewählten Ordner Testausführungspläne erstellt, die den gewählten Projekten entsprechen. Dabei werden die Projekte und die darin enthaltenen Packageaufrufe bzw. Parametersätze mit den zugehörigen Testausführungsplänen und Testfällen verknüpft.
Abbildung von Projekt-Inhalten auf das Testmanagement¶
Beim Export eines Projekts wird im Testmanagement-System eine Testsuite erstellt. Die Testsuite trägt den Namen und die Attribute des Projekts und enthält als Testfälle Verweise auf die Testskripte, mit denen die vom Projekt aus aufgerufenen Packages verknüpft sind. Testfälle, die für Parametersätze stehen, enthalten zusätzlich die Parameterbelegung.
Konfigurationswechsel, Generatoren und Projektaufrufe sowie die Ordnerstruktur des Projekts werden nicht in der Testsuite dargestellt. Ebensowenig alternative Mappings und Belegungen von globalen Konstanten in Parametersätzen, oder spezielle Einstellungen wie z.B. separate Unterprojektausführung und Wiederholung bei Fehler.
Damit man ein Projekt exportieren kann, muss es folgende Bedingungen erfüllen:
alle Attributwerte erfüllen die vom Testmanagement-System bzw. dessen Konfiguration vorgegebenen Bedingungen
z.B. kann eine Maximallänge vorgegeben sein
evtl. sind nur Werte aus einer vorgegebenen Liste zulässig
es kann Einschränkungen an den Datentyp geben (nur nummerische Werte erlaubt, etc.)
sogenannte Pflichtattribute dürfen nicht leer sein
alle vom Projekt aufgerufenen Packages sind bereits mit einem Testskript im Testmanagement-System verknüpft.
Info
Wenn einzelne Packages noch nicht verknüpft sind, besteht im Projekt-Exportieren-Dialog die Möglichkeit, diese Packages vor dem Projekt-Export ebenfalls zu exportieren.
Um ein Package für den Export zu markieren, zieht man es mit der Maus auf den gewünschten Zielordner. Nach Klick auf Fertigstellen werden zuerst die Packages und danach das Projekt exportiert.
Wenn aber die Packages nicht exportiert sondern mit vorhandenen Testskripten verknüpft werden sollen, muss man den Projekt-Export abbrechen und zuerst separat die Package-Verknüpfung herstellen.
Importieren von Projekten aus dem Testmanagement-System¶
Um ein Projekt aus dem Testmanagement zu importieren, klickt man mit der rechten Maustaste auf den Ordner im Workspace-Explorer, in dem das importierte Projekt abgelegt werden soll, und wählt . Diese Option steht nicht zur Verfügung, wenn mehrere Ordner selektiert wurden.
Alternativ kann man den Import über starten.
In dem Dialog, der sich nun öffnet, wählt man eine Testsuite im Testmanagement-System aus. Für die gewählte Testsuite werden als Vorschau deren Attribute und Testfälle (mit Namen, ID und Parameterbelegung) angezeigt. Alternativ kann man auch Testsuites direkt über bereits bekannte Id’s importieren.
Nach einem Klick auf OK wird ein Projekt erstellt. Dieses trägt den Namen und die Attribute der Testsuite. Für jeden in der Testsuite enthaltenen Testfall wird im Projekt ein Packageaufruf erstellt, der auf das Package verweist, das mit dem zugehörigen Testskript verknüpft ist. Wenn der Testfall Parameterbelegungen enthält, wird an den Packageaufruf ein Parametersatz angehängt, in dem die angegebenen Parameter übergeben werden.
Info
Für jeden Testfall wird ein separater Packageaufruf mit einem bzw. keinem Parametersatz erstellt, auch wenn diese sich auf das selbe Testskript beziehen – selbst dann, wenn die Testsuite durch Export eines Projekts entstanden ist, in dem ein Packageaufruf mit mehreren Parametersätzen enthalten war.
Info
Nach dem Auswählen der Testsuite ist es möglich aus den verfügbaren Testfällen eine zu importierende Untermenge zu wählen, indem man nicht benötigte Testfälle in der Voransicht deselektiert.
Damit eine Testsuite als Projekt importiert werden kann, müssen die von den enthaltenen Testfällen referenzierten Testskripte bereits als Packages existieren (d.h. entweder die Testskripte müssen als Packages importiert worden sein, oder die Testskripte müssen durch Exportieren von Packages entstanden sein). Ist das nicht der Fall, bietet ecu.test an, die Packages vorher zu importieren.
Es ist auch möglich, einen Ordner zu wählen. Dann wird im gewählten Workspace-Ordner ein neuer Unterordner erstellt, der so heißt wie der gewählte Ordner im Testmanagement-System, und es werden rekursiv alle Testausführungspläne und Unterordner importiert. Allerdings werden beim Import eines kompletten Ordners fehlende Packages nicht automatisch importiert.
Projekte Verknüpfen bzw. Synchronisieren¶
Um ein vorhandenes Projekt mit einer vorhandenen Testsuite zu verknüpfen, klickt man mit der rechten Maustaste auf das Projekt im Workspace-Explorer und wählt .
In dem nun erscheinenden Dialog wählt man eine Testsuite, mit der das Projekt verknüpft werden soll.
Durch Klick auf Synchronisieren gelangt man auf die zweite Seite des Dialogs, wo die automatisch anhand der Namen erkannte Zuordnung von Parametersätzen und unparametrierten Packageaufrufen des Projekts zu Testfällen der Testsuite dargestellt wird. Hier werden auch Parametersätze bzw. Packageaufrufe, denen kein Testfall zugeordnet werden konnte, und Testfälle, denen kein Parametersatz oder Packageaufruf entspricht, dargestellt.
Nach einem Klick auf Fertigstellen wird im Projekt die Verknüpfung zur Testsuite und zu den einzelnen Testfällen eingetragen.
Um ein Projekt, das bereits mit einer Testsuite verknüpft ist, mit dieser erneut abzugleichen, wählt man dagegen . Dies bietet sich an, wenn das Projekt oder die Testsuite geändert wurde.
Attribute importieren und exportieren¶
Um lediglich Änderungen an Attributen von mit dem Testmanagement-System verknüpften Projekten auf die zugehörige Testsuite zu übertragen, kann man im Kontextmenü des Projekts die Option Exportiere Attribute wählen. Umgekehrt kann man Änderungen an den Attributen der verknüpften Testsuite über Importiere Attribute auf das Projekt übertragen.
Der Export bzw. Import erfolgt (ggf. nach Rückfrage zum Schließen der betroffenen Projekte und/oder Login) ohne weitere Nutzerinteraktion.
Diese beiden Funktionen stehen auch bei Mehrfachauswahl sowie auf Ordnern (dann unter der Bezeichnung Ex-/Importiere Projekt-Attribute) zur Verfügung.
Arbeiten mit Testreports¶
ecu.test kann Testreports als Testprotokolle ins Testmanagement-System exportieren, wenn sie von einem Projekt stammen, das schon zum Zeitpunkt der Ausführung mit dem Testmanagement-System verknüpft war.
Exportieren von Testreports ins Testmanagement-System¶
Um einen Testreport ins Testmanagement-System zu exportieren, klickt man
in der Toolbar des Report Viewer auf den Button
Ergebnisse nach Testmanagement exportieren 
.
Alternativ kann man den Report-Export aus dem ecu.test-Hauptprogramm über
aufrufen. Über diesen
Weg ist es möglich im erscheinenden Dialog direkt eine Reportdatei (*.trf) auszuwählen oder
einen Ordner, wobei alle Reportdateien aus allen Unterordnern gesucht werden.
In dem nun erscheinenden Baum im unteren Teil des Dialogs kann man aus den im Testreport enthaltenen Package-Ausführungen wählen, welche davon ins Testmanagement-System exportiert werden sollen. Es können nur Ausführungen gewählt werden, deren Packageaufrufe bzw. Parametersätze mit einem Testfall verknüpft sind.
Falls ein Ordner gewählt wurde, werden alle in Unterordnern befindlichen Reports gelistet und können eingesehen und selektiert werden.
Info
Achtung, bei großen Verzeichnissen kann das Laden der Reportdaten entsprechend lange dauern!
Info
Es können ausschließlich Projekt-Reports exportiert werden. Außerdem können nur solche Testfallausführungen exportiert werden, die vorher mit dem Testmanagement System verknüpft wurden. Nicht verknüpfte Elemente werden grau und kursiv dargestellt und können nicht selektiert werden.
Reports, die keine gültigen Elemente zum Exportieren enthalten, werden ebenfalls grau und kursiv dargestellt und sind initial eingeklappt.
Auf der durch Weiter erreichbaren, folgenden Seite kann man wählen, welche Artefakte gemeinsam mit dem Report ins Testmanagement-System exportiert werden sollen:
Man kann entweder die Original-TRF-Datei oder die Ausgabe eines Reportdokumenten-Generators auswählen.
Der Reportdokumenten-Generator TRF-Split ermöglicht es, die Packages einzeln als TRF-Dateien aus dem Projekt-TRF zu extrahieren.
Die übrigen Reportdokumenten-Generatoren erstellen unabhängig von ecu.test lesbare Formate wie z.B. HTML.
Zusätzlich kann man Dateien aus dem Reportverzeichnis (z.B. Logs, Signalaufnahmen) mit auswählen
Die Dateien können wahlweise komprimiert werden
Die Dateien können wahlweise in einen bestimmten Ordner (z.B. ein gemeinsam genutztes Netzlaufwerk) kopiert werden
Die Dateien können wahlweise als Anhang oder als Verknüpfung dem Testprotokoll hinzugefügt werden. Eine Verknüpfung bietet sich insbesondere gemeinsam mit dem Kopieren auf ein Netzlaufwerk an.
Info
In den allgemeinen Testmanagement-Einstellungen unter können die Reportexport-Einstellungen global vorkonfiguriert werden (siehe Testmanagement-Einstellungen)
Info
Die Ordnerstruktur wird bei der Ablage der Dateien aus dem Reportverzeichnis übernommen. Wird eine Reportdatei exportiert, so wird der überliegende Ordner zusätzlich auf dem Dateisystem angelegt.
Nach dem Klick auf Fertigstellen wird im Testmanagement-System für jeden Package-Lauf ein Testprotokoll erstellt. Dieser verweist auf den ausgeführten Testfall und die Testsuite und enthält die Gesamtbewertung des Package-Laufs sowie eventuelle Nachbewertungskommentare aus dem Testreport.
Für jeden ausgeführten Testschritt der zweiten Block-Ebene (dem ein Schritt des Testskripts entspricht) wird im Testprotokoll ein Eintrag mit folgenden Informationen erstellt (sofern vom Testmanagement-System unterstützt):
Verweis auf den Testschritt
Bewertung
Zeitstempel
Text des Testschritts
Tatsächlicher Wert
Erwartung
Je nach Typ des Testschritts können einzelne dieser Felder auch leer bleiben.
Die gewählten Artefakte werden dem Testprotokoll als Anhang hinzugefügt. Falls ein Reportdokumenten-Generator gewählt wurde, wird dieser vor dem Erstellen der Testprotokolle ausgeführt. Wenn dessen Ergebnis keine einzelne Datei ist, wird der Ergebnisordner außerdem zu einer *.zip Datei zusammengepackt und diese verwendet.
Besonderheiten der jeweiligen Testmanagement-Systeme¶
Tauglichkeitsmatrix
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
||||
|
|
|
|
|
|
|
||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
|
HP Application Lifecycle Management (ALM)¶
Unterstützte Operationen
|
|
|
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
Konfiguration
Name |
Beschreibung |
|---|---|
URL |
URL vom ALM Server, bestehend aus Name/IP, Port und dem Zugangspunkt qcbin, in der Form https://<server>:<port>/qcbin/. |
Domain |
Die entsprechende Domain im ALM System. |
Project |
Das Projekt innerhalb der entsprechenden Domain. |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
|
SUCCESS |
Passed |
INCONCLUSIVE |
Not Completed |
FAILED |
Failed |
ERROR |
Failed |
IBM Rational Quality Manager (RQM)¶
Unterstützte Operationen
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
Konfiguration
Name |
Beschreibung |
|---|---|
URL |
Adresse vom RQM Server, bestehend aus Name/IP, Port und dem Zugangspunkt qm, bspw. https://<server>:<port>/qm. |
Project Area |
Name der Project Area innerhalb vom RQM, an dem Sie arbeiten. |
Timeout (s) |
Optional kann das Timeout für Requests angepasst werden |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
incomplete |
SUCCESS |
passed |
INCONCLUSIVE |
inconclusive |
FAILED |
failed |
ERROR |
error |
Jama Connect¶
Unterstützte Operationen
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
OAUTH
Konfiguration
Name |
Beschreibung |
|---|---|
Host |
Adresse vom Jama Connect Server. |
Project Key |
Eindeutiger Schlüssel für das Projekt. |
TestCase Type Key |
Eindeutiger Schlüssel eines TestCase Types. Den Wert findet man in Jama, in der Admin-Sektion unter ‚Organization‘, bei ‚Item types‘. |
TestPlan Type Key |
Eindeutiger Schlüssel eines TestPlan Types. Den Wert findet man in Jama, in der Admin-Sektion unter ‚Organization‘, bei ‚Item types‘. |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
NOT_RUN |
SUCCESS |
PASSED |
INCONCLUSIVE |
INPROGRESS |
FAILED |
FAILED |
ERROR |
BLOCKED |
Micro Focus ALM Octane¶
Unterstützte Operationen
|
|
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
BROWSER_BASED
Konfiguration
Name |
Beschreibung |
|---|---|
Host |
URL vom Octane Server, bestehend aus Name/IP und Port, bspw. https://<server>:<port>. |
Shared Space |
Name des Isolated oder Shared Spaces. |
Workspace |
Name des Workspaces innerhalb des angegebenen Spaces. |
Always use Validation Steps |
Exportiere alle Testschritte als Validation Steps (nicht nur Schritte mit einer Erwartung). |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
In Progress |
SUCCESS |
Passed |
INCONCLUSIVE |
Blocked |
FAILED |
Failed |
ERROR |
Failed |
PTC Integrity¶
Unterstützte Operationen
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
EXTERNAL
Konfiguration
Name |
Beschreibung |
|---|---|
Host |
PTC Host Adresse |
Port |
PTC Host Port |
HTTPS |
Verwende SSL für die Verbindung |
Configuration |
Optional. Konfiguration der Systemressourcenhierarchie. „<default>“ verwendet die vordefinierte Konfiguration. |
Upload-Status |
Status der „Test session“, der während des Hochladens der Ergebnisse gesetzt wird. |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
OTHER |
SUCCESS |
PASS |
INCONCLUSIVE |
OTHER |
FAILED |
FAIL |
ERROR |
FAIL |
PTC Integrity (restricted permissions)¶
Unterstützte Operationen
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
EXTERNAL
Konfiguration
Name |
Beschreibung |
|---|---|
Host |
PTC Host Adresse |
Project id |
ID des Projekts, welches genutzt werden soll. |
Port |
PTC Host Port |
HTTPS |
Verwende SSL für die Verbindung |
Configuration |
Optional. Konfiguration der Systemressourcenhierarchie. „<default>“ verwendet die vordefinierte Konfiguration. |
Upload-Status |
Status der „Test session“, der während des Hochladens der Ergebnisse gesetzt wird. |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
OTHER |
SUCCESS |
PASS |
INCONCLUSIVE |
OTHER |
FAILED |
FAIL |
ERROR |
FAIL |
Siemens Polarion ALM¶
Unterstützte Operationen
|
|
|
|
|
|
Unterstützte Authentifizierungsmethoden
BASIC_AUTH
Konfiguration
Name |
Beschreibung |
|---|---|
URL |
Adresse vom Polarion Server, so wie sie auch im Web-Browser funktioniert, bspw. https://<server>/polarion. |
Project |
Name des Projekts in Polarion. |
Custom description field |
Identifier des TestCase-Feldes in Polarion, in dem die Testfallbeschreibung steht. |
Requirement link type |
Art der Verlinkung der Requirements in Polarion, bspw. verifies. |
Testcase type |
Zu verwendender Testfalltyp, z. B. „testcase“ oder „softwareTestCase“. |
Testcase filter |
Filter für weitere Eigenschaften der Polarion-TestCases, bspw. „automated.KEY:(released planned implemented)“. |
Abbildung der Bewertungen
Bewertung in ecu.test |
Zugeordnete Bewertung |
|---|---|
NONE |
notRequired |
SUCCESS |
passed |
INCONCLUSIVE |
blocked |
FAILED |
|
ERROR |
notPerformed |