QF-Test kann leicht in gängige CI-Tools wie Jenkins und TeamCity integriert werden.
Für Jenkins ist ein QF-Test Plug-in direkt verfügbar, was die Dinge ziemlich einfach macht, aber auch mit anderen CI-Tools ist eine Integration mit nur wenigen Schritten möglich.

In diesem Beitrag zeigen wir diese Schritte für TeamCity CI.

Wichtiger Hinweis: CI-Tools empfehlen häufig die Verwendung eines Headless Service für den Agent-Prozess. Für GUI-Tests ist es jedoch entscheidend, eine echte Benutzersitzung zu verwenden, um sicherzustellen, dass sich die Desktop-Umgebung wie erwartet verhält. Dies ist möglicherweise nicht der Fall, wenn ein CI-Agent als Dienst ausgeführt wird. Aus diesem Grund empfehlen wir, den Agenten in einer echten Benutzersitzung zu starten. Weitere Informationen finden Sie im Kapitel Integration mit Entwicklungswerkzeugen in unserem Benutzerhandbuch.

Schritt 1: Build Step mit Befehlszeilen-Ausführung

Hinweis: Ihr Projekt muss bereits eine fertige Build-Konfiguration haben.

Zentrales Element für die Integration von QF-Test mit TeamCity ist der Build-Schritt “Ausführung”. QF-Test bietet eine umfangreiche Kommandozeilenschnittstelle, die im Referenzhandbuch dokumentiert ist.

In TeamCity fügen Sie einen neuen Build-Schritt hinzu …

… und wählen Sie einen “Kommandozeile” Build Step.

Hier

1. legen Sie einen geeigneten Schrittnamen fest,
2. wählen Sie “Ausführbar mit Parameter”,
3. setzen Sie “qftestc.exe” als “Command executable” (qftestc.exe ist eine Version von qftest.exe, die für die Verwendung auf der Kommandozeile optimiert ist),
4. und definieren Sie die folgenden Parameter:

-batch -report.html report
-report.junit junitreport
-exitcode-ignore-exception -exitcode-ignore-error -exitcode-ignore-warning
-nomessagewindow
"<Voller Pfad zur auszuführenden Testsuite>"

Hier eine kurze Erklärung der verwendeten Kommandozeilenparameter:

• -batch: QF-Test soll im Batch-Modus ohne QF-Test GUI ausgeführt werden
• -runlogdir runlog: Protokolle sollen in einem eigenen Unterverzeichnis abgelegt werden
• -report.html report: Ein HTML-Bericht soll erstellt werden, den wir später in TeamCity integrieren werden
• -report.junit junitreport: Ein zusätzlicher Bericht im JUnit-Format ermöglicht es TeamCity, die Testergebnisse richtig zu parsen
• -exitcode-ignore-exception -exitcode-ignore-error -exitcode-ignore-warning: Gibt bei Testfehlern keinen Exitcode ungleich Null zurück, da diese von TeamCity als harter Abbruch interpretiert werden würden
• -nomessagewindow: Keine Fehlermeldungsfenster anzeigen, stattdessen alles auf die Standardausgabe ausgeben

So, nun haben wir den ersten Schritt abgeschlossen und können einen ersten Testlauf starten, bevor wir die nächste Konfiguration erstellen.

Hinweis: Sie müssen mindestens einen TeamCity-Agenten zur Verfügung haben. Als Voraussetzung muss QF-Test auf dem Host des Agenten installiert sein.

Wir können zur “Build-Konfiguration”-Seite wechseln, um das Build-Ergebnis zu sehen.

Hier sollten wir die Ergebnisse unseres ersten Testlaufs sehen, hoffentlich mit dem Status “Erfolg”.

Das klingt zwar super, “Erfolg” bedeutet hier jedoch nur, dass der QF-Test-Prozess einen “0”-Exit-Code auf der Kommandozeile zurückgegeben hat. Es gibt noch keine Informationen über tatsächlich erfolgreiche oder fehlgeschlagene Testfälle.

Schritt 2: Berichterstellung für Testergebnisse

Um das zu erreichen, werden wir die von QF-Test generierten JUnit-Berichte verwenden. Diese enthalten die Informationen über erfolgreiche und fehlgeschlagene Testfälle in einem Format, das von TeamCity interpretiert werden kann.

In TeamCity müssen wir

• in den Bereich “Build Features” wechseln
• ein neues Build-Feature hinzufügen
• Wählen Sie “XML-Berichtsverarbeitung” mit dem Berichtstyp “Ant JUnit”.
• Erstellen Sie die Überwachungsregel %teamcity.build.workingDir%/junitreport/report_junit.xml, mit der der JUnit-Report von QF-Test erstellt wird, wie im Kommandozeilen-Bauschritt erklärt
• Aktivieren Sie “Ausführliche Ausgabe” (optional)

Durch Speichern und anschließendes Auslösen eines weiteren Laufs auf der Build-Konfigurationsseite erhalten wir ein wesentlich detaillierteres Ergebnis. Beachten Sie, dass es in unserem Lauf einen erfolgreichen und einen fehlgeschlagenen Test gab, was bei der von mir verwendeten Beispielsuite zu erwarten war.

So weit, so gut. Aber eine wichtige Funktion fehlt noch. Für die Analyse der Testergebnisse bietet QF-Test Ablaufprotokolle, die aus TeamCity heraus verfügbar sein sollten, genau wie die QF-Test HTML-Berichte, die einen guten Überblick bieten.

Schritt 3: Integration von Protokollen und HTML-Berichten

Zunächst müssen sowohl die Protokolle als auch der HTML-Bericht als Build-Artefakte definiert werden, damit sie von TeamCity gespeichert werden können.
Das geht im Bereich “Allgemeine Einstellungen”:

• Report => report.zip: Das Report-Verzeichnis wird gezippt und gespeichert
• runlog => runlog: Das Verzeichnis runlog wird ebenfalls gespeichert. Da die .qrz Protokolle bereits komprimiert sind, wäre ein zusätzliches Zippen nicht sinnvoll.

Zur Erinnerung: Ablaufprotokolle liefern detaillierte Informationen über den Testlauf. HTML-Berichte bieten einen Überblick.

Ein weiterer Lauf liefert uns die entsprechenden Artefakte, die das Verzeichnis runlog und report.zip enthalten, bereit zum Herunterladen.

Nun fehlt nur noch ein letztes Detail in unserer Integration: die Anzeige des QF-Test HTML-Berichts in einem separaten Build-Tab.

Um dies zu erreichen:

• Navigieren Sie zur Administrationsseite Ihres Projekts
• und von dort zur Seite “Report Tabs”
• und wählen Sie “Neuen Build-Report-Tab erstellen”
• mit dem Titel “QF-Test Bericht”
• und einer “Startseite” von report.zip!report.html, was zur Seite report.html innerhalb des report.zip Build-Artefakts führt.

Nachdem Sie zum Projekt zurückgekehrt sind und einen weiteren Build ausgeführt haben, öffnen Sie die Build-Details, indem Sie auf den Link unter “Status” klicken …

… und dann finden Sie den gewohnten QF-Test HTML-Bericht direkt im neuen Reiter “QF-Test Report”.

Dies ist nur ein erster Vorgeschmack auf die möglichen Integrationen zwischen TeamCity und QF-Test.

Sie sollten einen Blick auf die anderen QF-Test Kommandozeilenparameter, die in unserem Referenzhandbuch dokumentiert sind werfen – zum Beispiel kann der Parameter -suitesfile <file> praktisch sein, um die auszuführenden Testsuiten außerhalb des Build Steps anpassen zu können. Auch die TeamCity Dokumentation beinhaltet noch fortgeschrittene Möglichkeiten der Integration, wie das Konzept der Service Messages, die während der Testausführung den Testfortschritt über die Standardausgabe übermitteln.

Falls Sie weitere Vorschläge oder Fragen zur Integration von QF-Test mit TeamCity CI haben, können Sie sich gerne an uns wenden, indem Sie unser Support-Team kontaktieren.