Blog

Oxygen für Robot Framework: Test-Reporting neu konsolidiert

JUL 11, 2020

Oxygen ist ein neues Tool für Robot Framework, das sämtliche Testberichte zentral bündelt – für mehr Transparenz und bessere Qualitätskennzahlen.

Tatu Kairi

Principal Consultant

Tatu enjoys piña coladas, getting caught in the rain, is not into yoga and has half a brain.

Oxygen ist ein neues Open-Source-Tool von Eficode, das alle einzelnen Testberichte in einem Bericht zusammenführt. Oxygen bietet verschiedene Möglichkeiten, Berichte mithilfe des Berichtsformats und der Erweiterbarkeit von Robot Framework zu kombinieren. Das schafft mehr Transparenz und ermöglicht weitergehende Analysen von Qualitätsmetriken. Ich zeige euch, wie das funktioniert.

Von bedeutungslosen Daten zu relevanten Informationen

Mehrere Tools zum Testen von Software einzusetzen, ist eine gute Möglichkeit, die Qualität zu steigern und dadurch mehr Vertrauen in eure Arbeit zu gewinnen. Jedes Tool erstellt jedoch eigene Ergebnisberichte. Um das Gesamtbild zu verstehen, müsst ihr daher an mehreren Stellen nachsehen. Da die Berichte unterschiedlich strukturiert sind, müsst ihr ständig den Kontext wechseln – das kostet Produktivität. Am problematischsten ist jedoch, dass Entwickler die Ergebnisse vage interpretieren müssen, um daraus eine Release-Entscheidung abzuleiten.

Oxygen ist ein Tool, das unterschiedliche Testberichte mithilfe von Robot Framework, dem allgemeinen Open-Source-Framework für Automatisierung, zusammenführt. Die konsolidierten Ergebnisse liefern bessere Qualitätsmetriken und sparen Entwicklern Zeit. Oxygen lässt sich einfach in euren Workflow und sogar in automatisierte Pipelines integrieren.

Das richtige Tool für die Aufgabe wählen

Einer der Grundsätze von DevOps ist, für jede Aufgabe das richtige Tool zu wählen. Zu den gängigsten Tools in der Testautomatisierung gehören:

  • Ein technisches Testtool auf niedriger Ebene, das zeigt, dass die Software wie vom Programmierer vorgesehen funktioniert

  • Ein End-to-End-Testtool auf hoher Ebene, das zeigt, dass die geschäftlichen Anforderungen erfüllt sind und funktional funktionieren

  • Ein Performance-Testtool, das uns die Sicherheit gibt, dass die Software ausreichend effizient ist

  • Ein Security-Testtool, das prüft, ob offensichtliche Sicherheitsrisiken bestehen.

Je nach Geschäftskontext ist die Liste spezialisierter Testtools, die ein Projekt benötigt, nahezu endlos. Unsere Kunden brauchen zusätzlich zu den oben genannten häufig Tools, um Folgendes zu testen:

  • Kritische API-Integrationen

  • Infrastruktur bei der Nutzung von Infrastructure-as-Code (IaC)

  • Barrierefreiheitsstandards wie WCAG

  • Regulatorische Rückverfolgbarkeit in der Schwerindustrie

Den Überblick behalten

Die unterschiedlichen Berichte dieser Tools zu interpretieren, schafft Wissenssilos innerhalb eines Projekts. Nur wenige Personen können einschätzen, wie der tatsächliche Zustand des Projekts ist. Das führt zum berüchtigten Bus-Faktor.

Die Daten aus diesen Berichten werden häufig verdichtet und als Metriken auf einem Dashboard angezeigt. In der Praxis führt das entweder zu umfangreichem Wartungsaufwand, um die Metriken am Laufen zu halten, oder dazu, dass die Toolauswahl auf bereits in die Dashboard-Lösung integrierte Tools beschränkt wird.

Wartungsaufwand lässt sich gegenüber dem Management nur schwer rechtfertigen, denn Ressourcen sind ohnehin knapp. Ebenso wenig hilft es Teams, ihre benötigten Tools einzusetzen, wenn die Toolauswahl eingeschränkt wird. Das kann zu ineffizienter und wenig sinnvoller Arbeit führen.

Wenn eine kleine Auswahl von Testtools schlecht gewählt ist, kann das sogar die Aussagekraft unserer Qualitätsmetriken beeinträchtigen. Einige weit verbreitete Tools für Unit-Tests bieten Entwicklern beispielsweise keine Möglichkeit, den Zweck eines Testfalls zu kennzeichnen. Dadurch werden alle Testfälle als Unit-Tests zusammengefasst, obwohl einige davon Komponenten-, Integrations- oder Systemtests sein können.

Oxygen für Robot Framework vorgestellt

Eficode beteiligt sich am europaweiten Forschungsprogramm Testomat Project, das von Business Finland finanziert wird. Auf Grundlage der Erkenntnisse daraus hat Eficode ein neues Tool für Robot Framework entwickelt, mit dem sich unterschiedliche Testberichte unkompliziert in einem Bericht zusammenführen lassen.

Mit Oxygen könnt ihr für jedes Tool, das ihr ausführen möchtet, passende Akzeptanztests schreiben. Anschließend wandelt Oxygen deren Berichte automatisch in Testfälle von Robot Framework um und integriert so alles zusammen. Für jeden Testfall, den das andere Tool ausgeführt hat, gibt es einen entsprechenden Testfall im Log und Bericht von Robot Framework – mit allen relevanten Informationen wie dem Status des Testfalls.

Schauen wir uns an, wie das aussieht. Unten seht ihr vier Testfälle von Robot Framework. Die ersten beiden führen über Maven JUnit-Testfälle aus, der dritte führt Performance-Tests mit Gatling aus und der letzte einen Security-Scanner mit ZAP. Wie ihr an den ersten beiden sehen könnt, lassen sich Testausführungen desselben Tools voneinander trennen. So könnt ihr ihren Zweck besser einordnen.

Beispiel aus der Keyword-Dokumentation von Oxygen

Wenn ihr verschiedene Test-Tools in separaten CI/CD-Pipelines oder unterschiedlichen Umgebungen ausführen müsst, bietet Oxygen eine Command Line Interface, die sich einfach in jede CI/CD-Pipeline integrieren lässt. So könnt ihr einen einzelnen Testbericht eines anderen Tools in eine einzelne output.xml von Robot Framework umwandeln:

$ python -m oxygen oxygen.junit my_junit_results.xml

Die resultierende Datei könnt ihr anschließend mit weiteren Testergebnissen über das integrierte rebot-Tool von Robot Framework zusammenführen.

Erweiterbares Tool für vielfältige Anforderungen

Zum Zeitpunkt der Erstellung dieses Artikels unterstützt Oxygen drei Test-Tools standardmäßig: JUnit, Gatling und ZAP. Ein zentrales Designziel von Oxygen ist jedoch, dass jeder das Tool erweitern können soll. Im Sinne von Open Source können Entwickler weitere Testberichtsformate integrieren – davon profitieren alle.

Oxygen erweitert die Funktionen von Robot Framework und kann ebenso von euch erweitert werden, um eure Anforderungen an die Berichterstattung zu erfüllen. Dazu schreibt ihr einen Handler: eine einfache Python-Klasse, die 1) ein Robot-Framework-Keyword zum Ausführen des anderen Tools bereitstellt und 2) eine Methode, die den Bericht analysiert und die gewünschten Informationen als einfaches verschachteltes Dictionary zurückgibt.

Der folgende Beispiel-Handler stellt das Robot-Framework-Keyword Run My Tests bereit, das Testergebnisse in eine Datei im JSON-Format schreibt. Die Methode parse_results() liest diese Datei und erstellt eine Dictionary-Darstellung der Ergebnisse, die Oxygen versteht.

Beispiel-Handler aus dem Oxygen-Repository.

Das oben gezeigte Beispiel ist bewusst einfach gehalten und veranschaulicht die beiden Kernkonzepte. Erstens stellt OxygenLibrary eine Methode als Keyword bereit, die das externe Test-Tool ausführt. Zweitens transformiert eine Methode die gewünschten Informationen aus dem Bericht des externen Test-Tools in die Darstellung von Oxygen. Ab diesem Punkt weiß Oxygen, wie alles in das Log und den Bericht von Robot Framework übernommen wird. Außerdem stellt es automatisch eine erweiterbare oder überschreibbare Command Line Interface für euren Handler bereit.

Eficode arbeitet derzeit an einem ausführlichen Tutorial – bleibt dran!

Oxygen ermöglicht bessere Qualitätsmetriken

Sobald ihr eure Testberichte in einem einheitlichen Robot-Framework-Bericht zusammengeführt habt, könnt ihr die Daten mit Tools wie dem InfluxDB Plugin oder DbBot einfach in eine Datenbank übertragen. Anschließend könnt ihr mit Tools wie Grafana Visualisierungen erstellen. Von dort aus lassen sich die Daten mühelos analysieren und aussagekräftige Metriken erstellen.

Oxygen arbeitet mit Testfällen von Robot Framework. Tags, die dem ursprünglichen Testfall hinzugefügt wurden, werden daher ebenfalls Teil der Ergebnisse. So könnt ihr Testfälle kategorisieren, unabhängig davon, ob das externe Test-Tool diese Funktion bietet (ich schaue dich an, XCTest). Ihr könnt beispielsweise Unit-Tests von Integrationstests trennen. Da Tags eine leistungsstarke Funktion von Robot Framework sind, lassen sie sich auch mit Oxygen nutzen: Ihr könnt Statistiken erfassen, kritische von weniger wichtigen Testfällen trennen, Testausführungen definieren und auswählen, was in welcher Phase der CI/CD-Pipeline ausgeführt werden soll.

Besucht gern den Oxygen Issue Tracker, um neue Funktionen vorzuschlagen oder Bugs zu melden. Wenn ihr eine Erweiterung für Oxygen entwickelt, hoffen wir, dass ihr sie im Python Package Index veröffentlicht und uns Bescheid gebt, damit wir auf euch verlinken können.

  • CI/CD

Subscribe to our newsletter