1. Ausgangslage
In einem Projekt einer grösseren Schweizer Kantonalbank zur Testautomatisierung des Avaloq Banking Systems mit Tricentis Tosca ist das Reporting ein wichtiges Thema. Derzeit findet viermal im Jahr ein Release statt. Aufgrund des zunehmend geringeren Aufwands für die manuelle Durchfühurng von Regressionstests ist ein monatlicher Release-Zyklus geplant. Trotz intensiver Bemühungen konnte Tosca Analytics fürs Testreporting bisher nicht erfolgreich in Betrieb genommen werden. In dieser Situation ist die Idee entstanden, mit einfachen technischen Mitteln einen grundlegenden automatisch erzeugten Testreport aus Tosca heraus zu implementieren.
2. Zielsetzung
Im aktuellen Projekt werden in jedem Testfall während dessen Durchführung relevante Informationen, wie z.B. der Testfallname, Auftragsnummer(n), Verifikationsergebnisse u.a., in eine Textdatei geschrieben (basierend auf einer Idee meines Kollegen Michael Weiglein). Diese wird dem Fachbereichsverantwortlichen zur Verfügung gestellt, damit er die Testdurchführung einfacher nachvollziehen kann. Jedoch enthält diese Datei keine Aussage darüber, ob ein Testfall tatsächlich erfolgreich durchgelaufen ist oder ob beispielsweise die Verifikation eines Sachverhalts nicht erfolgreich war. Da diese Textdatei vor dem Ende der Testausführung geschrieben wird, existiert deren Ergebnis zu diesem Zeitpunkt noch nicht.
Daher soll den Fachbereichsverantwortlichen auf einfache Weise ermöglicht werden, an einem für sie direkt zugänglichen Ort jederzeit zu prüfen, ob und wann ein Testfall das letzte Mal erfolgreich durchgelaufen ist. Ausserdem soll der zeitliche Aufwand zur Generierung eines einfachen Testreports stark verringert werden.
3. Technische Voraussetzungen
Grundsätzliche Voraussetzung für die Umsetzung ist die Testdurchführung mit Jenkins, da auf den so erzeugten Resultatdateien im XML-Format aufgebaut wird. Standardmässig werden diese Dateien von Jenkins in ein Verzeichnis auf dem betreffenden Server geschrieben, das dem jeweiligen Testdurchführungsauftrag entspricht, z.B. C:\jenkins\workspace\Finanzieren. Auf dieses Verzeichnis lässt sich von einem Tosca-Agent für die Distributed Execuction, der auf einem anderen Rechner läuft, aufgrund potentiell fehlender Berechtigungen nicht einfach zugreifen. Deswegen ist die Jenkins-Konfiguration so anzupassen, dass die Resultatdateien auf einem vom Netz aus zugänglichen Laufwerk abgespeichert werden (vgl. Abb. 1). Die verwendeten Verzeichnisse zur Ablage dieser Dateien sollten vor der Testdurchführung angelegt werden, hier z.B. «Kreditantrag erstellen».
Abb. 1: Beispielhafte Jenkins-Konfigurationsdatei für die Testdurchführung eines bestimmten Fachbereichs
4. Allgemeiner Prozess
Unter anderem mittels Regex-Ausdrücken werden aus einer Jenkins-Resultatdatei die folgenden relevanten Daten herausgefiltert (vgl. Abb. 2):
- Bezeichnung des Testfalls
- Zeitstempel
- Ergebnis (Passed, Failed)
Abb. 2: Auszug aus einer beispielhaften Jenkins-Resultatdatei
Diese Informationen werden zu einem String im CSV-Format zusammengesetzt, der anschliessend in eine Datei desselben Formats ins Zielverzeichnis geschrieben wird. Verallgemeinert wird der folgende Algorithmus angewandt (vgl. Abb. 3):
Abb. 3: Algorithmus zur Extraktion der relevanten Daten aus der Jenkins-Resultatdatei
Manchmal wird ein Testfall nicht durchgeführt, ist aber in der Jenkins-Resultatdatei enthalten. Darum wird zunächst geprüft, ob die initiale Suche nach dem relevanten Textstring überhaupt ein Ergebnis liefert. Falls das Suchergebnis leer ist, wird für den Zeitstempel und das Testergebnis ein standardmässiger Text in die Zieldatei geschrieben. Damit ist gleich ersichtlich, dass dieser Testfall beim letzten Testlauf nicht ausgeführt worden ist.
5. Konkrete Umsetzung mit Tosca
Zur variablen Umsetzung wird in Tosca ein TestSheet mit der folgenden Struktur eingesetzt (vgl. Abb. 4):
Abb. 4: Tosca-TestSheet
Im aktuellen Projekt wird pro Fachbereich, wie z.B. Finanzieren oder Zahlungsverkehr, ein solches TestSheet verwendet, damit die Liste der Testfälle nicht allzu umfangreich und ein adressatengerechtes Ergebnis sichergestellt wird.
Auf einige der relevanten Schritte im TestTemplate wird im Folgenden näher eingegangen (vgl. Abb. 5).
Abb. 5: Tosca-TestTemplate
Der Inhalt der XML-Resultatdatei, die durch Jenkins generiert worden ist, lässt sich basierend auf dem Tosca-TestSheet über einen Pfad wie folgt aus dem jeweiligen Verzeichnis laden: \\Tosca\Resultat\Jenkins\{XL[Bezeichnung des Stage]}\{XL[Bezeichnung der Parallel]}_Resultat.xml.
Die Suche nach dem Umgebungsstring ist so umgesetzt, dass direkt nach der zutreffenden Bezeichnung für die Testumgebung gesucht wird (z.B. INT für eine Integrationstestumgebung).
Nach dem Ausgangsstring, aus dem danach die gesuchten Daten herausgefiltert werden, wird über den folgenden Regex-Ausdruck gesucht: ({XL[Instance.Name]}).* log=“[-+] (Failed|Passed)(wobei die XL-Referenz in Form der konkreten Bezeichnung eines Testfalls aufgelöst wird). Diese Testfallbezeichnung entspricht genau dem jeweiligen Instanznamen im TestSheet, so dass dieser nicht aus dem Ausgangsstring herauszufiltern ist.
Der Text zwischen der Testfallbezeichnung und dem Zeitstempel wird mit folgendem Regex-Ausdruck gefunden und danach entfernt: .*“.*timestamp=“.
Der Zeitstempel nach UTC hat die folgende Form: 2020-01-31T12:49:54.1985841+01:00. Er wird ins Format YYYY-MM-DD HH:MM umgewandelt. Der Zeitstempel wird in folgenden Schritten ins Zielformat transformiert:
- Datum extrahieren
- Zeit extrahieren
- Zeitstempel im intendierten Format zusammensetzen
Das Testergebnis selbst wird über eine direkte Suche als Text extrahiert: (Failed|Passed).
Wenn dieser gesamte Prozess nicht mit Tosca umgesetzt würde, sondern beispielsweise skriptbasiert, liesse sich die Suche nach allen Ergebnisstrings unter Verwendung spezifischer Testfall-Listen pro Fachbereich in einem Schritt ausführen, anstatt konkrete Tosca-Testfälle dafür einzusetzen.
Anschliessend wird der jeweils aktuelle Ergebnisstring ans Ende einer Datei im CSV-Format geschrieben. Diese Datei wird unter einem Namen mit der Struktur {Testumgebung_Fachbereich_Datum}.csv in einem geeigneten Verzeichnis historisiert abgespeichert, z.B. INT_Finanzieren_2020-01-31.csv (respektive in variabler Form: {B[AVQ_Testumgebung]}_{XL[Fachbereich]}_{DATE[][][yyyy-MM-dd]}.csv). Falls diese Textdatei noch nicht existiert, wird zunächst die Kopfzeile mit dem String Testfall;Zeitstempel;Ergebnis in eine leere Datei geschrieben. Bei jedem Durchgang wird geprüft, ob die CSV-Datei bereits existiert. Ist dies der Fall, so wird der bestehende Inhalt kopiert, am Ende um den neuen Textstring ergänzt und der neue Inhalt in dieselbe Datei zurückgeschrieben. Als Platzhalterstring eingesetzt wird dieser Text:{XL[Instance.Name]};Nicht ausgeführt;–.
Der Prozess liefert damit beispielsweise eine CSV-Datei mit dem folgenden Inhalt:
Testfall;Zeitstempel;Ergebnis
Finanzieren Smoketests – Darlehen erfassen;2020-01-31 16:38:35;Passed
Finanzieren Kreditantrag erstellen – Eigenheim;Nicht ausgeführt;–
Finanzieren Kreditantrag erstellen – Betriebskreditlimite;2020-01-31 16:52:10;Failed
6. Ausführung
Die Generierung des Testreports kann entweder manuell über eine ExecutionList in Tosca erfolgen. Für die automatisierte Ausführung gleich im Anschluss an einen Testdurchlauf wird in der Jenkins-Konfiguration ein eigener stage eingerichtet, mit den zugehörigen Elementen für die verteilte Testausführung in Tosca.
7. Nutzen
Dieser automatisch erzeugte einfache Testreport kann einzelnen Funktionen etwa folgenden Nutzen bringen:
- Der Testmanager benötigt weniger Zeit für die manuelle Erstellung des Testreportings. Fehlgeschlagene Testfälle lassen sich vor der Verteilung an einen Fachbereichsverantwortlichen über eine zusätzliche Spalte in einer Excel-Datei im Nachhinein mit einer Bemerkung versehen.
- Der Testingenieur behält den Überblick über die konkreten Testfallinstanzen, da er die TestSheets laufend mit neu implementierten Testfällen ergänzt und konfiguriert. Die Testinstanzen selbst sind mit Tosca rasch erzeugt.
- Der Fachvertreter erhält ständigen Zugriff auf die Testresultate, ohne dass diese explizit zu verteilen sind. Dies führt zu einer besseren Sichtbarkeit der Testergebnisse.
Der tatsächliche Nutzen hängt freilich von der konkreten Umgebung und der Art des erforderlichen Testreporting ab.
8. Weiterer Ausbau
8.1 Bessere Lesbarkeit mit einer Excel- oder PDF-Datei
Sofern auf dem Rechner, auf dem der Tosca-Agent zur Testausführung mit Jenkins läuft, Microsoft Excel installiert ist, lässt sich die CSV-Datei besser lesbar gestalten. Zunächst wird eine Excel-Vorlage mit bedingter Formatierung erstellt, so dass sich das Testergebnis durch die grüne oder rote Farbe einfacher erkennen lässt. In den Bereich A4:C54 u.ä. wird der Inhalt der CSV-Datei importiert. Eventuell liesse sich diese Excel-Datei auch im PDF-Format abspeichern.
Abb. 6: Excel-Vorlage mit bedingter Formatierung der Testergebnisse
8.2 Verteilung per E-Mail
Die erzeugten Testreporte lassen sich mittels eines PowerShell-Skripts der folgenden Art an die gewünschten Empfänger versenden:
Send-MailMessage -to @(„test@example.com“) -from „Regressionstests <no-reply@example.com>“ -SmtpServer „servername.example.com“ -Subject „Testergebnis“ -Body „Das Testergebnis findet sich im Anhang.“ -Attachments „Testergebnis.csv“ -Encoding ([System.Text.Encoding]::UTF8)‘)
Über die Windows-Aufgabenplanung (oder einen Cronjob auf Unix-basierten Umgebungen) wird dieser Auftrag zum gewünschten Zeitpunkt ausgeführt.
9. Fazit
Die vorliegende Beschreibung zeigt, wie sich mit einfachen technischen Mitteln ein automatisiertes Reporting aus Tricentis Tosca heraus umsetzen lässt, wenn die Testdurchführung mit Jenkins erfolgt. Die Gestaltung und Verteilung der Testreporte können im jeweiligen Kontext rasch auf die erforderlichen Bedürfnisse angepasst werden. Natürlich sind diese grundlegenden Reporte kein Ersatz für ein ausführliches Reporting gegenüber dem Management. Der Fokus liegt auf einem automatisiert bereitgestellten Ergebnis eines Testlaufs, auf das die Fachbereichsverantwortlichen nach dem eigenen Bedarf Zugriff haben.
3. Februar 2020, Bernhard Fuchs
Ergänzung vom 02.03.2020:
In der ursprünglichen Version wurde das Datumsformat von z.B. 2020-01-31T12:49:54.1985841+01:00 nicht korrekt interpretiert. Da im Vergleich zur mitteleuropäischen Zeit keine Zeitverschiebung enthalten ist, wurde der Abschnitt zur Zeitumwandlung in der obigen Darstellung entfernt.
Eine deutlich elegantere Version zur Generierung eines Testreports aus den Jenkins-Resultatdateien beschreibe ich im Blog Eleganter zum einfachen Report über Jenkins-Testdurchführung.
