Kapitel 12. Import/Export

Inhaltsverzeichnis

12.1. Testfälle aus Excel-Tabellen importieren
12.1.1. Import-Format
12.1.2. Vorbedingungen
12.1.3. Ausführen
12.2. Testfälle aus XML-Dateien importieren
12.2.1. Vorbedingungen
12.2.2. Ausführen
12.3. Anforderungen aus Excel-Tabellen importieren
12.3.1. Import-Format
12.3.2. Vorbedingungen
12.3.3. Ausführen
12.4. Importieren und Synchronisieren von Anforderungen aus XML
12.4.1. Vorbedingungen
12.4.2. Importieren
12.4.3. Synchronisierung
12.5. Testergebnisse importieren
12.5.1. Das JUnit XML++ Format
12.5.2. Vorbedingungen
12.5.3. Ausführen
12.5.4. Jenkins Plugin
12.6. Testergebnisse exportieren
12.6.1. Ausführen
12.7. Tabelleninhalte exportieren
12.8. Backup und Wiederherstellen
12.8.1. Backup via REST

Klaros-Test­management bietet zahlreiche Schnittstellen zum Importieren von Daten aus anderen Anwendungen sowie zum Exportieren eigener Daten in verschiedene Formate an.

Für alle Importvorgänge ist eine Benutzerauthentifizierung erforderlich. Die benötigte Benutzerrolle hängt von der Art der zu importierenden Daten ab. Für den Import von Testergebnissen ist die Rolle Tester ausreichend, für Anforderungen und Testfälle ist die Rolle Manager erforderlich.

[Wichtig] LDAP-Authentifizierung

Ist die Einstellung Login Voreinstellung in der LDAP-Konfiguration aktiviert, so erfolgt die Authentifizierung ausschließlich über das LDAP-Verzeichnis. Lokale Authentifizierungsinformationen werden in diesem Fall immer ignoriert.

12.1. Testfälle aus Excel-Tabellen importieren

Um Testfälle korrekt aus Excel-Tabellen zu importieren, müssen die Daten in einem vorgegebenen Format vorliegen. Dieses Format ist in Abschnitt 12.1.1, „Import-Format“ detailliert beschrieben.

In der Klaros-Test­management Enterprise Edition können neben den Standardfeldern auch Daten für benutzerdefinierte Felder importiert werden. Dafür müssen im entsprechenden Projekt einige Vorbedingungen erfüllt sein. Weitere Informationen hierzu finden Sie unter Abschnitt 12.1.2, „Vorbedingungen“.

Die Importschnittstelle besteht aus einem REST-Interface, dass sowohl per Kommandozeile als auch über andere Anwendungen erreicht werden kann. Detailinformationen dazu finden sich in Abschnitt 12.1.3, „Ausführen“.

12.1.1. Import-Format

Um Testfälle korrekt zu importieren, muss die Excel-Tabelle einem bestimmten Format entsprechen:

  1. Jeder Testfall muss in einer separaten Tabelle definiert sein.

  2. Jede Tabelle ist in drei Abschnitte unterteilt: allgemeine Eigenschaften, Testfallschritte und benutzerdefinierte Eigenschaften.

  3. Dabei sind die Felder A:1 bis A:22 für die Standard-Attribute eines Testfalls reserviert. Die entsprechenden Werte werden in die Felder B:1 bis B:22 eingetragen. Es ist nicht zwingend notwendig, alle Felder zu befüllen.

  4. Die Spalte G ist für die Namen von beliebig vielen benutzerdefinierten Eigenschaften vorgesehen. In Spalte H werden die entsprechenden Werte dazu eingegeben.

  5. Das Feld Step in der Zelle A:25 muss bestehen bleiben. Ändern oder Löschen des Feldes A:25 führt dazu, dass der Import dieser Tabelle abgewiesen wird. Ab hier beginnt die Definition der Testschritte:

    • Spalte A für die Testschrittnummer,

    • Spalte B für die Aktion,

    • Spalte C für die Vorbedingung,

    • Spalte D für die Nachbedingung und

    • Spalte E für das erwartete Ergebnis.

Beispiel für einen Testfall in Excel

Abbildung 12.1. Beispiel für einen Testfall in Excel


12.1.1.1. Allgemeine Eigenschaften

In der unten dargestellten Tabelle sind die Zellkoordinaten für die Werte der einzelnen allgemeinen Testfallattribute dargestellt. Die ID des Testfalls wird beim Import automatisch erzeugt. Keines dieser Felder muss zwingend befüllt werden. Einige Felder können nur vordefinierte Werte annehmen. Diese sind in Klammern aufgeführt.

Koordinate

Wert

B2

Name

B3

Revision (Verwendung nur beim Export)

B5

Beschreibung

B6

Vorbedingung

B7

Nachbedingung

B8

Erwartetes Ergebnis

B10

Bemerkung

B11

Testart ( FUNCTIONAL, NON_FUNCTIONAL, STRUCTURAL, REGRESSION, RE_TEST)

B12

Entwurfsverfahren ( BLACK_BOX, WHITE_BOX)

B13

Ergebnisart ( POSITIVE, NEGATIVE)

B14

Ausführung ( MANUAL, AUTO)

B15

Priorität ( LOW, MEDIUM, HIGH)

B16

Status ( NEW, APPROVED, LOCKED, INVISIBLE)

B17

Team

B18

Level ( COMPONENT, INTEGRATION, SYSTEM, ACCEPTANCE)

B19

Dokument

B20

Abhängigkeit

B21

Auswertung

B22

Verfolgbarkeit

B23

Geschätzte Dauer (ms)

Tabelle 12.1. Koordinaten der allgemeinen Eigenschaften von Testfällen


12.1.1.2. Testschritte

Testfälle können eine beliebige Anzahl von Testschritten enthalten. Diese werden ab Zelle A:26 pro Zeile einzeln in aufsteigender Reihenfolge aufgelistet. Ist in einer Zeile keine Schrittnummer enthalten, wird die Verarbeitung der Excel-Tabelle beendet.

Koordinaten

Wert

A26 (ff)

Schritt-Nummer

B26 (ff)

Aktion

C26 (ff)

Vorbedingung

D26 (ff)

Nachbedingung

E26 (ff)

Erwartetes Ergebnis

Tabelle 12.2. Koordinaten der Testschritte


12.1.1.3. Benutzerdefinierte Eigenschaften

Testfälle können benutzerdefinierte Eigenschaften enthalten. Diese werden als Name/Wert-Paare ab Zelle G:1 und H:1 abwärts aufgelistet.

Der Name der in Spalte G aufgelisteten Eigenschaft muss exakt mit dem Namen der benutzerdefinierten Eigenschaft im entsprechenden Projekt übereinstimmen.

Handelt es sich bei der benutzerdefinierten Eigenschaft um eine Aufzählung, so muss das Wertfeld exakt mit einem der dort definierten Aufzählungswerte übereinstimmen.

Wird eine leere Namenszelle gefunden, stoppt die Verarbeitung.

Koordinaten

Wert

G1 (ff)

Eigenschafts-Name

H1 (ff)

Eigenschafts-Wert

Tabelle 12.3. Koordinaten der benutzerdefinierten Eigenschaften von Testfällen


12.1.2. Vorbedingungen

Um Testfälle aus Excel-Tabellen importieren zu können, müssen folgende Vorbedingungen erfüllt sein:

  1. Die zu importierende Datei muss in den Formaten XLS oder XLSX vorliegen.

  2. Das Projekt, in welches die Testfälle importiert werden sollen, muss bereits erstellt sein.

  3. Benutzerdefinierte Eigenschaften (können nur in der Klaros-Test­management Enterprise Edition erstellt werden!) müssen bereits im entsprechenden Projekt definiert sein.

12.1.3. Ausführen

Testfälle aus Excel-Tabellen lassen sich über eine REST-Schnittstelle mit Hilfe eines Kommandozeilen- basierten Werkzeuges oder anderen beliebigen Anwendungen hochladen.

Das folgende Beispiel zeigt, wie eine Excel-Tabelle mit Testfällen in das Projekt mit der ID P00001 unter Verwendung der Curl-Kommandozeile importiert werden kann. Curl sollte in jeder Linux-Distribution enthalten sein. Für die Microsoft Windows-Betriebssystemfamilien ist es als Teil der Cygwin-Distribution http://www.cygwin.com/ oder als Kommandozeilenwerkzeug von http://curl.haxx.se/download.html erhältlich.

[Wichtig] Inkompatibler Windows Powershell-Curl-Alias

Windows Powershell definiert ebenfalls einen Alias namens curl, der auch für diesen Zweck verwendet werden kann. Dieser benötigt allerdings andere Argumente. Wollen Sie das Linux-kompatible Curl-Programm unter Powershell verwenden, geben Sie curl.exe anstelle von curl ein.

curl -v -T TestCases.xls "<klaros-app-url>/seam/resource/rest/import/testcase/xls?config=P00001\
&username=user&password=secret"

Beispiel 12.1. Testfallimport aus Excel-Tabellen über die Kommandozeile


[Anmerkung] ID-Format

Alle Objekte, die während des Imports referenziert werden (wie Projekte oder Testfälle), enthalten fünf Ziffern in ihrer ID.

So ist P00001 eine gültige Projekt-ID, während P0001 und P000001 ungültig sind.

12.2. Testfälle aus XML-Dateien importieren

Beim Importieren von Testfällen aus XML-Dateien erzeugt jeder Importvorgang neue Instanzen der gelieferten Testfälle.

Das Format der XML-Datei ist in Anhang C, Dateiformat für Testfall-Import beschrieben. Das XML-Schema ist unter der folgenden URL erhältlich: https://www.klaros-testmanagement.com/files/schema/klaros-testcases-1.0.xsd.

12.2.1. Vorbedingungen

Um Testfälle aus XML-Dateien importieren zu können, müssen folgende Vorbedingungen erfüllt sein:

  1. Die zu importierende Datei muss im XML-Format vorliegen.

  2. Das Projekt, in welches die Testfälle importiert werden sollen, muss bereits erstellt sein.

  3. Wenn benutzerdefinierte Eigenschaften importiert werden sollen, müssen sie vor dem Importvorgang im Projekt angelegt werden.

12.2.2. Ausführen

Für den Import von XML-basierten Testfällen steht eine REST-Schnittstelle zur Verfügung, über die die Daten aus der Kommandozeile oder anderen Anwendungen hochgeladen werden können.

Das folgende Beispiel zeigt, wie eine XML-Datei mit einem Testfall in das Projekt mit der ID P00001 unter Verwendung der Curl-Kommandozeile importiert werden kann. Curl sollte in jeder Linux-Distribution enthalten sein. Für die Microsoft Windows-Betriebssystemfamilien ist es als Teil der Cygwin-Distribution http://www.cygwin.com/ oder als Kommandozeilenwerkzeug von http://curl.haxx.se/download.html erhältlich.

curl -v -T TestCases.xml "<klaros-app-url>/seam/resource/rest/import/testcase/xml?config=P00001\
&username=user&password=secret"

Beispiel 12.2. XML-Testfall-Import über die Kommandozeile


12.3. Anforderungen aus Excel-Tabellen importieren

Um Anforderungen korrekt aus Excel-Tabellen zu importieren, müssen die Daten in einem vorgegebenen Format vorliegen. Dieses Format ist im folgenden Abschnitt Abschnitt 12.1.1, „Import-Format“ detailliert beschrieben.

In der Klaros-Test­management Enterprise Edition können neben den Standardfeldern auch Daten für benutzerdefinierte Felder importiert werden. Dazu ist es notwendig, das Projekt entsprechend vorzubereiten. Weitere Informationen dazu finden Sie unter Abschnitt 12.1.2, „Vorbedingungen“.

Die Importschnittstelle besteht aus einem REST-Interface, dass sowohl per Kommandozeile als auch über andere Anwendungen erreicht werden kann. Dies wird in Abschnitt Abschnitt 12.1.3, „Ausführen“ detailliert beschrieben.

12.3.1. Import-Format

Um Anforderungen korrekt zu importieren, muss die Excel-Tabelle einem bestimmten Format entsprechen:

  1. Jede Anforderung muss in einer separaten Tabelle definiert sein.

  2. Jede Tabelle ist in zwei Abschnitte unterteilt: allgemeine Eigenschaften und benutzerdefinierte Eigenschaften.

  3. Dabei sind die Felder A:1 bis A:9 für die Standard-Attribute einer Anforderung reserviert. Die entsprechenden Werte werden in die Felder B:1 bis B:9 eingetragen. Es ist nicht zwingend notwendig, alle Felder zu befüllen.

  4. Die Spalte G ist für die Namen für beliebig viele benutzerdefinierte Eigenschaften vorgesehen. In Spalte H werden die entsprechenden Werte dazu eingegeben.

Beispiel für eine Excel-Tabelle mit Anforderungen

Abbildung 12.2. Beispiel für eine Excel-Tabelle mit Anforderungen


12.3.1.1. Allgemeine Eigenschaften

In der unten dargestellten Tabelle sind die Zellkoordinaten für die Werte der einzelnen allgemeinen Eigenschaften der Anforderungen dargestellt. Die ID der Anforderung wird beim Import automatisch erzeugt. Keines dieser Felder muss zwingend befüllt werden. Einige Felder können nur vordefinierte Werte annehmen. Diese sind in Klammern aufgeführt.

Koordinate

Wert

B1

ID (nur im Export verwendet)

B2

Name

B3

Revision (nur im Export verwendet)

B5

Zusammenfassung

B6

Beschreibung

B8

Priorität ( LOW, MEDIUM, HIGH)

B9

Status ( NEW, APPROVED, LOCKED, INVISIBLE)

Tabelle 12.4. Koordinaten für allgemeine Eigenschaften von Anforderungen


12.3.1.2. Benutzerdefinierte Eigenschaften

Anforderungen können benutzerdefinierte Eigenschaften enthalten. Diese werden als Name/Wert-Paare ab Zelle G:1 und H:1 abwärts aufgelistet.

Damit der Import erfolgreich ist, müssen die Namen der aufgelisteten Eigenschaften mit den benutzerdefinierten Eigenschaften übereinstimmen, die für das vom Import betroffene Projekt definiert wurden.

Der Name in der Namensspalte und der Name einer benutzerdefinierten Eigenschaft in Klaros-Test­management müssen exakt übereinstimmen, andernfalls kann der Wert nicht korrekt verarbeitet werden. Wird eine leere Namenszelle gefunden, stoppt die Verarbeitung. Das Wertfeld für Aufzählungseigenschaften muss exakt mit dem Namen der zu verarbeitenden Definition der Aufzählungseigenschaftswerte übereinstimmen.

Koordinaten

Wert

G1 (ff)

Eigenschaftsname

H1 (ff)

Eigenschaftswert

Tabelle 12.5. Koordinaten für benutzerdefinierte Eigenschaften


12.3.2. Vorbedingungen

Um Anforderungen aus Excel-Tabellen importieren zu können, müssen folgende Vorbedingungen erfüllt sein:

  1. Die zu importierende Datei muss in den Formaten XLS oder XLSX vorliegen.

  2. Das Projekt, in welches die Anforderungen importiert werden soll, muss bereits erstellt sein.

  3. Benutzerdefinierte Eigenschaften (können nur in der Klaros-Test­management Enterprise Edition erstellt werden!) müssen bereits im entsprechenden Projekt definiert sein.

12.3.3. Ausführen

Für den Import von Excel-basierten Anforderungen steht eine REST-Schnittstelle zur Verfügung, über die die Daten über die Kommandozeile oder anderen Anwendungen hochgeladen werden können.

Das folgende Beispiel zeigt, wie eine Excel-Tabelle mit Anforderungen in das Projekt mit der ID P00001 unter Verwendung der Curl-Kommandozeile importiert werden kann. Curl sollte in jeder Linux-Distribution enthalten sein. Für die Microsoft Windows-Betriebssystemfamilien ist es als Teil der Cygwin-Distribution http://www.cygwin.com/ oder als Kommandozeilenwerkzeug von http://curl.haxx.se/download.html erhältlich.

curl -v -T Requirements.xls "<klaros-app-url>/seam/resource/rest/import/requirement/xls?config=P00001\
&username=user&password=secret"

Beispiel 12.3. Anforderungen aus Excel-Tabellen über die Kommandozeile importieren


12.4. Importieren und Synchronisieren von Anforderungen aus XML

Mit Klaros-Test­management können Anforderungen sowohl importiert als auch aus XML-Dateien synchronisiert werden.

Ein Import ist auf eine einmalige Aktion beschränkt, die immer neue Instanzen der gelieferten Anforderungen erzeugt. Die Synchronisierung hingegen ermöglicht es, vorhandene Anforderungen mit dem Inhalt der XML-Datei zu aktualisieren und bei Bedarf neue Revisionen davon zu erstellen.

Das Format der XML-Datei ist in Anhang D, Dateiformat für Anforderungs-Import beschrieben. Das XML-Schema ist unter der folgenden URL erhältlich: https://www.klaros-testmanagement.com/files/schema/klaros-requirements-1.0.xsd.

12.4.1. Vorbedingungen

Um Anforderungen aus XML-Dateien importieren zu können, müssen folgende Vorbedingungen erfüllt sein:

  1. Die zu importierende Datei muss im *.XML-Format vorliegen.

  2. Das Projekt, in welches die Anforderungen importiert werden soll, muss bereits erstellt sein.

  3. Wenn benutzerdefinierte Eigenschaften importiert werden sollen, müssen sie vor dem Importvorgang im Projekt angelegt werden.

  4. Wenn die importierten Anforderungen via externalTestCaseId Testfällen zugeordnet werden sollen, müssen Testfälle mit dieser externen ID bereits vorliegen.

12.4.2. Importieren

Für den Import von XML-basierten Anforderungen steht eine REST-Schnittstelle zur Verfügung, über die die Daten über die Kommandozeile oder anderen Anwendungen hochgeladen werden können.

Das folgende Beispiel zeigt, wie eine XML-Datei mit Anforderungen in das Projekt mit der ID P00001 unter Verwendung der Curl-Kommandozeile importiert werden kann. Curl sollte in jeder Linux-Distribution enthalten sein. Für die Microsoft Windows-Betriebssystemfamilien ist es als Teil der Cygwin-Distribution http://www.cygwin.com/ oder als Kommandozeilenwerkzeug von http://curl.haxx.se/download.html erhältlich.

curl -v -T Requirements.xml "<klaros-app-url>/seam/resource/rest/import/requirement/xml?config=P00001\
&username=user&password=secret"

Beispiel 12.4. Anforderungen aus XML-Dateien über die Kommandozeile importieren


12.4.3. Synchronisierung

Zur Synchronisierung von XML-basierten Anforderungen steht eine andere REST-Schnittstelle zur Verfügung (endet mit /sync/requirement/xml). Sie versteht dasselbe Importformat, wie es für das Importieren von Anforderungen definiert ist, erfordert jedoch das Vorhandensein zusätzlicher Elemente für den korrekten Betrieb.

Im Gegensatz zu einem Import dient eine Synchronisierungsaktion dazu, den in Klaros-Test­management gespeicherten Satz von Anforderungen aus beliebigen externen Anwendungen regelmäßig zu aktualisieren.

Die Synchronisation unterstützt das Erstellen und Aktualisieren sowie das Überarbeiten von Anforderungen. Änderungen an den Anforderungen werden in der Klaros-Test­management Datenbank für jedes Feld bei jeder Synchronisierungsaktion berücksichtigt.

[Achtung] Synchronisierung überschreibt lokale Änderungen!

Beachten Sie, dass bei der Synchronisierung bereits gespeicherte Änderungen überschrieben werden.

[Tipp] externalId

Das Element externalId (Siehe Abschnitt D.11, „<externalId>“) identifiziert eine Anforderung für nachfolgende Synchronisierungsversuche. Es ist ein Pflichtfeld bei Verwendung dieser Schnittstelle. Wird dieser Wert geändert, wird ein neues Anforderungsobjekt erstellt, anstatt den Inhalt der zuvor erstellten Anforderung zu ersetzen.

[Tipp] revision

Das Element revision (Siehe Abschnitt D.15, „<revision>“) identifiziert die Version einer Anforderung für nachfolgende Synchronisierungsversuche.

  • Ist der Wert leer, so wird die aktuell ausgewählte Revision der Anforderung aktualisiert.
  • Wird ein neue Revision eingegeben, so wird eine neue Version der Anforderung erstellt und aktualisiert.
  • Falls eine ältere Revision eingegeben wird, wird die eingegebene Revision aktualisiert.

Das folgende Beispiel zeigt, wie eine XML-Datei mit Anforderungen in das Projekt mit der ID P00001 unter Verwendung der Curl-Kommandozeile synchronisiert werden kann. Curl sollte in jeder Linux-Distribution enthalten sein. Für die Microsoft Windows-Betriebssystemfamilien ist es als Teil der Cygwin-Distribution http://www.cygwin.com/ oder als Kommandozeilenwerkzeug von http://curl.haxx.se/download.html erhältlich.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<r:container xmlns:r="http://klaros-testmanagement.com/export-requirements-1.0">
 <r:requirements>
  <r:requirement>
   <r:attributes/>
   <r:externalId>RTM-00001</r:externalId>
   <r:revision>1.0</r:revision>
   <r:priority>MEDIUM</r:priority>
   <r:shortname>Remote-controlled door panels / unlocking</r:shortname>
   <r:summary>Doors must me remote controllable.</r:summary>
  </r:requirement>
 </r:requirements>
</r:container>

Beispiel 12.5. XML-Anforderungssynchronisation über die Kommandozeile


curl -v -T Requirements.xml "<klaros-app-url>/seam/resource/rest/sync/requirement/xml?config=P00001\
&username=user&password=secret"

Beispiel 12.6. XML-Anforderungsimport über die Kommandozeile


12.5. Testergebnisse importieren

Testautomatisierungswerkzeuge erzeugen Testergebnisse typischerweise in Dateiform. Diese Dateien können über eine REST-Schnittstelle importiert und automatisch in Testergebnisse umgewandelt werden.

12.5.1. Das JUnit XML++ Format

JUnit XML++ ist das von Klaros-Testmanagement intern verwendete, generische Format für den Import von Testfallergebnissen aus externen Quellen. Dieses Format ist aufwärtskompatibel mit dem JUnit XML Format.

Durch Erweiterung des JUnit XML Format bietet das JUnit XML++ Format Möglichkeiten einzelne Testschritte eines Tests zu beschreiben, sowie binäre Anhänge in ein XML-Dokument einzubetten. Zudem bietet es mit dem Ergebnistyp inconclusive die Möglichkeit nicht eindeutige Ergebnisse darzustellen.

12.5.1.1. Das JUnit XML Format

Eine eindeutige formale JUnit XML-Format-Spezifikation existiert leider nicht, weil JUnit selbst keine XML-Berichte erstellt. Die XML-Berichterstellung resultiert gewöhnlich aus der Aufbereitung des JUnit Aufrufs innerhalb eines Build-Tools wie bspw. eines Ant JUnit-Tasks, des Maven Surefire Plugin oder Gradle. Das XML-Berichtsformat wurde erstmalig in Ant eingeführt und später von Maven und Gradle angepasst.

Das JUnit XML Format konnte sich mittlerweile über Tool- und Programmiersprachen- grenzen hinweg als ein generisches (Quasi-)Standardformat für Testfallergebnisse etablieren und wird von einer Vielzahl von Automatisierungswerkzeugen unterstützt. Trotz der Uneindeutigkeit des Formats, wurden in der Vergangenheit mehrfach Versuche vorgenommen, das Format in Form eines XML-Schemas zu dokumentieren. Ausführlich kommentierte Schemadefinitionen finden sich bspw. hier: https://llg.cubic.org/docs/junit/ und hier: https://github.com/windyroad/Junit-Schema/blob/master/JUnit.xsd.

12.5.1.2. Das JUnit XML++ Format

  • Beschreiben und Bewerten von Tests auf Testschrittebene
  • Ergänzen der Testergebnisse um binäre Anhänge (Bilder, Dokumente, etc.)
  • Unterstützen von weiteren Testbewertungen (unklar)

Diese haben wir dem JUnit XML Format hinzugefügt, ohne den bestehenden Syntax zu ändern. Dieses neue Format nennen wir im weiteren JUnit XML++.

12.5.1.2.1. Testschrittergebnisse

Innerhalb eines testcase-Elements können nun beliebig viele teststep-Elemente vorkommen. Diese enthalten zwingend ein time-Attribut, das die Ausführungsdauer des Testschritts in Sekunden angibt.

Wie auch bei Testfällen, steuern error, failure oder skipped Elemente innerhalb eines Testschritts deren Bewertung.

Ebenfalls analog zu den Testfällen werden system-out sowie system-err Elemente unterstützt. Enthalten diese Inhalte, so werden sie automatisch als binäre Anhänge dem beim Import erzeugten Testfallergebnis hinzugefügt.

Optional können dem Testschrittergebnis noch die Elemente action, precondition, postcondition und expectedResult untergeordnet werden.

Sind diese vorhanden, werden sie in Klaros-Test­management in die entsprechenden Felder eines Testschrittergebnisses übernommen. Die Angabe ist nicht zwingend erforderlich, aber zumindest für das Feld action zu empfehlen um einzelne Testschritte besser identifizieren zu können.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testcase name="Test 1" time="0.008">
    <teststep time="0.006">
        <action>Textual description of the action taken in this step</action>
        <precondition>Precondition information</precondition>
        <postcondition>Postcondition information</postcondition>
        <expectedResult>Expected result of this test step</expectedResult>
    </teststep>
    <teststep time="0.002">
        <failure>
            Detailed failure message
        </failure>
        <system-out>Log message</system.out>
    </teststep>
</testcase>

Beispiel 12.7. Beispiel Testschrittergebnis.xml


12.5.1.2.2. Anhänge

Für die Dokumentation eines Test(schritt)ergebnisses kann es sinnvoll sein, dieses neben der textuellen Beschreibung um eine Datei (Screenshot, Dokument etc.) zu ergänzen. Um dies zu ermöglichen, können in den Elementen system-out und system-err zusätzliche Inhalte definiert werden.

Nach erfolgreichem Extrahieren und Speichern werden diese Inhalte nicht in eventuell zusätzlich angelegte system-out/system-err Attachments übernommen. Die Inhalte werden in Anlehnung an das Jenkins Plugin JUnit Attachments definiert und können in drei verschiedenen Ausprägungen vorkommen:

Base64 Encoded Attachment

Syntax: [[ATTACHMENT_DATA|«attached-file.xyz»|«encoded data»]]

In encoded data wird ein base64-encodierter binärer Inhalt erwartet. Dieser wird nach erfolgreicher Dekodierung unter dem Dateinamen attached-file.xyz als Anhang am Testfallergebnis oder Testschrittergebnis gespeichert.

Bei dieser Methode wird also den gesamten Anhang als Teil der Ergebnisdatei gespeichert. Dies erfordert mehr Speicherplatz, ermöglicht aber jederzeit den Zugriff auf den Inhalt.

URL Attachment

Syntax: [[ATTACHMENT_URL|/«url/to/attached-file.xyz»]]

Es wird versucht, den Inhalt der URL url/to/attached-file.xyz herunterzuladen und unter dem Dateinamen attached-file.xyz als Anhang zu speichern.

Bei dieser Methode wird erwartet, dass das Attachment im Netz bereitgestellt ist. Es ist zwingend notwendig, dass die Klaros-Instanz zum Importzeitpunkt Zugang auf diese URL hat, damit die Extraktion gelingt.

File Attachment

Syntax: [[ATTACHMENT|/«path/to/attached-file.xyz»]]

Es wird versucht, den Inhalt der Datei path/to/attached-file.xyz herunterzuladen und unter dem Dateinamen attached-file.xyz als Anhang zu speichern.

Bei dieser Methode wird erwartet, dass das Attachment im lokalen Filesystem bereitgestellt ist. Es ist zwingend notwendig, dass die Klaros-Instanz zum Importzeitpunkt Zugang auf diese Datei hat, damit die Extraktion gelingt.

12.5.1.2.3. Testergebnisse

Sowohl bei Testfallergebnissen ( testcase) als auch bei Testschrittergebnissen ( teststep), ist es möglich neben error, failure oder skipped auch inconclusive (unklar) als Ergebnistyp zu setzen, da dieser zwar in Klaros-Test­management nicht aber in JUnit unterstützt wird.

12.5.2. Vorbedingungen

Um Testergebnisse zu importieren müssen folgende Vorbedingungen erfüllt sein:

  1. Das Projekt, die Iteration, die Testumgebung und das Testsystem, das die Ergebnisse des importierten Testfalls oder der Testsuite enthalten soll, müssen bereits erstellt sein.

12.5.3. Ausführen

Die URL der Importschnittstelle finden Sie unter http://localhost:18080/klaros-web/seam/resource/rest/importer. Der Inhalt wird über eine HTTP-PUT-Anforderung unter Verwendung der obigen URL und verschiedener URL-Query-Parameter übertragen.

[Tipp] Der Ausdruck <klaros-app-url>

Die oben gezeigte URL http://localhost:18080/klaros-web ist die Standard-URL der Klaros-Anwendung, auf die der vom Host zugreift und kann je nach Ihrer Einrichtung variieren. In diesem Kapitel wird stattdessen der Begriff <klaros-app-url> verwendet, um dies wiederzugeben.

Die folgenden Parameter werden unterstützt:

config

Die ID des Projekts, in das die Ergebnisse importiert werden sollen (z.B. P0001).

iteration

Die ID der Iteration, zu der die Ergebnisse in Beziehung gesetzt werden sollen (z.B. ITR00001). Dieser Parameter ist optional.

env

Die ID der Testumgebung, in der die Tests durchgeführt wurden (z.B. ENV00001). Bitte stellen Sie sicher, dass diese Testumgebung bereits im Projekt definiert ist, bevor Sie mit dem Import beginnen.

sut

Die ID des Testsystems, in dem die Tests durchgeführt wurden (z.B. SUT00001). Bitte stellen Sie sicher, dass das Testsystem bereits im Projekt definiert ist, bevor Sie mit dem Import beginnen.

type

Der Typ des Importformats. Die folgenden Typen werden unterstützt:

aunit

AUnit

boost

Boost Test

Check

Check

cpptest

CppTest

cppunit

CppUnit

ctest

ctest (CMake)

cunit

CUnit

fitnesse

Fitnesse

fpunit

Free Pascal Unit

gtester

GLib/gtester

googletest

GoogleTest

jbehave

JBehave

jmeter

JMeter

jsunit

JsUnit

jubula

Jubula / GUIdancer

junit

JUnit / Gauge / Robot Framework / Selenium / Squish / TestNG

mbunit

MBUnit

mstest

MSTest

nunit

NUnit

phpunit

PHPUnit

qftest

QF-Test

qtestlib

QTestLib

tessy

TESSY

testcomplete

TestComplete

tusar

TUSAR

uft

Unified Functional Testing (UFT) / QuickTest Professional (QTP)

cpptestunit

UnitTest++

valgrind

Valgrind

xUnit.net

xunitdotnet

job

Die optionale ID der Aufgabe, der dieser Testlauf zugeordnet werden soll (z.B. JOB00001). Falls angegeben, muss die Aufgabe vor Beginn des Imports bereits im Projekt vorhanden sein.

time

Der Zeitpunkt der Testausführung. Das Format für diese Zeitangabe ist dd.MM.yyyyy_HH:mm. Dieser Parameter kann verwendet werden, um den Ausführungszeitpunkt des Testlaufs zu überschreiben. Ansonsten wird der Zeitpunkt des Imports verwendet.

createTestSuiteResults

Wenn dieser Parameter auf true gesetzt ist, so werden automatisch Testsuiteergebnisse aus den in der Ergebnisdatei enthalten Informationen erzeugt. Diese Informationen können je nach Importformat variieren. Zusätzlich wird eine entsprechende Testsuite für das Testsuiteergebnis erstellt, falls diese noch nicht vorhanden war.

autoCreateTestCases

Ist dieser Parameter auf true gesetzt, so werden automatisch Testfälle aus den in der Ergebnisdatei enthalten Informationen erzeugt, wenn kein zugehöriger Testfall gefunden werden konnte.

username

Der Benutzername für den Import.

password

Das Passwort für den Import.

Ein vollständiges Beispiel für eine QF-Test-Import-URL würde wie folgt aussehen:

http://localhost:18080/klaros-web/seam/resource/rest/importer?\
config=P00001&env=ENV00001&sut=SUT00001&type=qftest&time=01.03.2011_12:00&username=me&password=secret

Beispiel 12.8. Beispiel QF-Test Import-URL


Die Ergebnisdatei ist im HTTP-Request-Body enthalten.

Mit dem Kommandozeilen-Werkzeug curl kann der Import unter Linux oder Cygwin unter Windows in einer einzigen Befehlszeile ausgelöst werden.

curl -v -H "Content-Type: text/xml" -T <test result file> \
"<klaros-app-url>/seam/resource/rest/importer?config=P00001&env=ENV00001&sut=SUT00001&type=junit\
&time=23.05.2011_14:55"

Beispiel 12.9. Curl Kommandozeilen Beispiel


[Wichtig] Inkompatibler Windows Powershell-Curl-Alias

Windows Powershell definiert ebenfalls einen Alias namens curl, der für diesen Zweck verwendet werden kann, aber einen völlig anderen Satz von Argumenten benötigt. Nutzen Sie das Linux-kompatible Curl-Programm unter Powershell, verwenden Sie curl.exe anstelle von curl.

curl -Method put -InFile <test result file> -Uri \
"<klaros-app-url>/seam/resource/rest/importer?config=P00001&env=ENV00001&sut=SUT00001&type=junit\
&time=23.05.2011_14:55"

Beispiel 12.10. Powershell curl Alias Kommandozeilen-Beispiel


12.5.4. Jenkins Plugin

Das Plugin integriert den kontinuierlichen Integrationsserver Jenkins mit Klaros-Test­management und spielt die Testergebnisse eines Jenkins-Builds in Klaros-Test­management ein. Die Testergebnisse werden in der Datenbank für weitere Auswertungen gespeichert. Die Installations- und Konfigurationsanleitung für das Plugin finden Sie auf der Seite Jenkins GitHub.

12.6. Testergebnisse exportieren

Klaros-Testmanagement besitzt eine JUnit XML Export Schnittstelle zum exportieren von Testergebnissen.

12.6.1. Ausführen

Die URL der Exportschnittstelle finden Sie unter http://localhost:18080/klaros-web/seam/resource/rest/export/result/junit. Der Inhalt wird über eine HTTP-GET-Anforderung unter Verwendung der obigen URL und verschiedener URL-Query-Parameter übertragen.

[Tipp] Der Ausdruck <klaros-app-url>

Die oben gezeigte URL http://localhost:18080/klaros-web ist die Standard-URL der Klaros-Anwendung, auf die der vom Host zugreift und kann je nach Ihrer Einrichtung variieren. In diesem Kapitel wird stattdessen der Begriff <klaros-app-url> verwendet, um dies wiederzugeben.

Die folgenden Parameter werden unterstützt:

config

Die ID des Projekts, aus dem die Ergebnisse exportiert werden sollen (z.B. P0001).

env

Die ID der Testumgebung, in der die Tests durchgeführt wurden (z.B. ENV00001).

sut

Die ID des Testsystems, in dem die Tests durchgeführt wurden (z.B. SUT00001).

job

Die ID der Aufgabe, dessen Ergebnisse exportiert werden sollen (z.B. JOB00001).

testRun

Die ID des Testlaufs, dessen Ergebnisse exportiert werden sollen (z.B. TRU0000001).

username

Der Benutzername für den Export.

password

Das Passwort für den Export.

Es besteht die Möglichkeit sowohl einzelne Testergebnisse einer Aufgabe oder eines Testlaufs als auch alle Testergebnisse eines Testsystems oder einer Kombination aus Testsystem und Testumgebung zu exportieren. Über die Angabe der Parameter kann dies gesteuert werden.

Mit dem Kommandozeilen-Werkzeug curl kann der Export unter Linux oder Cygwin unter Windows in einer einzigen Befehlszeile ausgelöst werden.

curl \
"<klaros-app-url>/seam/resource/rest/export/result/junit?config=P00001&job=JOB00001&user=me&password=secret"

In diesem Beispiel werden die Ergebnisse der Aufgabe JOB00001 aus dem Projekt P00001 exportiert.

Beispiel 12.11. Curl Kommandozeilen Beispiel


[Wichtig] Inkompatibler Windows Powershell-Curl-Alias

Windows Powershell definiert ebenfalls einen Alias namens curl, der für diesen Zweck verwendet werden kann, aber einen völlig anderen Satz von Argumenten benötigt. Nutzen Sie das Linux-kompatible Curl-Programm unter Powershell, verwenden Sie curl.exe anstelle von curl.

curl -Method get -Uri \
"<klaros-app-url>/seam/resource/rest/export/result/junit?config=P00001&testRun=TRU0000001&username=me&password=secret"

In diesem Beispiel werden die Ergebnisse des Testlaufs TRU0000001 aus dem Projekt P00001 exportiert.

Beispiel 12.12. Powershell curl Alias Kommandozeilen-Beispiel


12.7. Tabelleninhalte exportieren

Mit Klaros-Test­management kann der Inhalt aller Tabellen in die Formate Excel, PDF oder XML exportiert werden. Die aktuellen Filter- und Sortiereinstellungen werden dabei berücksichtigt.

Tabelleninhalte in Excel-Tabellen exportieren

Abbildung 12.3. Tabelleninhalte in Excel-Tabellen exportieren


12.8. Backup und Wiederherstellen

Das Verschieben von Daten zwischen verschiedenen Datenbankinstallationen oder zum selektiven Import von Daten kann über XML-Dateien erfolgen. Abschnitt 10.6, „Sicherung“ erklärt die Import- und Exportfunktionalität im Detail.

12.8.1. Backup via REST

Klaros-Test­management Enterprise Edition enthält eine REST-basierte Schnittstelle, die Zugriff auf Sicherungsdateien einzelner Projekte gewährt. Der folgende Beispiel-URI gibt die XML-Datei der Sicherung des Projekts P00004 zurück: http://{host}:{port}/klaros-web/seam/resource/rest/io/backup/project/P00004.

[Anmerkung] Anmerkung

Weitere Informationen darüber, wie Sie auf REST-basierte Schnittstellen zugreifen können, finden Sie Kapitel 13, Die Remote API.