Robot-Framework und Selenium: Ein perfektes Team?

Welche Vorteile bringen der gemeinsame Einsatz von Robot-Framework und Selenium für die Testautomatisierung?

Diese Frage wird in dem vorliegenden Beitrag beantwortet. Der Fokus dieses Beitrags liegt auf folgenden wesentlichen Vorteilen:

  • Testfälle können in einer einfachen Syntax erstellt und besser verwaltet werden.
  • Die Testberichte sind aussagekräftiger und unterstützen die Analyse durch Filter- und Suchfunktionen.
  • Neben dem Web-Frontend können weitere Komponenten wie die Datenbank und API-Schnittstellen (SOAP, REST) getestet bzw. automatisiert werden.

Nachfolgend wird ausschliesslich der Selenium Webdriver betrachtet, um die Vorteile von Robot Framework herauszustellen. Es gibt andere Frameworks (z.B. Cucumber), die ähnliche Vorteile bieten. Diese Frameworks sind nicht Gegenstand dieses Artikels.

Testfälle können in einer einfachen Syntax erstellt und besser verwaltet werden.

Robot-Framework ist in Python implementiert, kann aber ohne Kenntnisse dieser Programmiersprache genutzt werden. Robot-Framework verwendet eine eigene an die natürliche Sprache angelehnte Syntax aus Schlüsselwörtern (Keywords), die ohne Programmierkenntnisse leicht zu verstehen und anzuwenden sind. In Robot-Framework können auch eigene Schlüsselwörter (Keywords) bzw. auch ganze Sätze definiert werden. Diese eigenen Schlüsselwörter können verwendet werden, um Testfälle in natürlicher Sprache zu beschreiben und automatisiert auszuführen. Robot-Framework unterstützt auch die sogenannte Gherkin-Syntax, die von Behavior-Driven-Development-Frameworks verwendet wird. Hier ein kleines dokumentiertes Beispiel für den Test eines Logins mit Hilfe der Selenium-Library[1]:

Die Testfälle von Robot-Framework können in verschiedenen Formaten gespeichert werden. Das Standardformat Text, hat mehrere Vorteile: Erstens können die Testfälle mit einem beliebigen Editor erstellt bzw. betrachtet werden. Natürlich gibt es auch unterstützende Plugins für Entwicklungsumgebungen wie z.B IntelliJ und Eclipse und eine eigenständige Umgebung namens RIDE bzw. RED. Zweitens lassen sich die Testfälle gut in einem Source-Repository (z.B. GIT, Subversion) verwalten. Drittens können die Testfälle durch die textuelle Beschreibung auch in beliebige Tools für die Testfallverwaltung integriert werden. Aber auch die Verwaltung der Testfälle ohne zusätzliche Tools ist nach meiner Ansicht sehr einfach, da die Dateien einfach in Verzeichnissen abgelegt werden können. Darüber hinaus können die einzelnen Testfälle markiert und anhand dieser Markierung (Tag) ausgeführt werden.

Testdaten können bei Robot-Framework auf sehr viele verschiedene Arten eingebunden werden. Der Normalfall ist Testdaten direkt im Testfall zu definieren siehe Beispiel. Das hat den zusätzlichen Vorteil, dass die Testfälle sehr leicht lesbar sind. Es können Variablen definiert werden, um alle Arten von Steuerdaten (z.B. Testumgebung, angemeldeter Benutzer, etc.) modular abzubilden. Für datengetriebenen Testfällen[2]können direkt mehrere Kombinationen von Testdaten für einen Testfall angegeben werden. Für grössere Projekte ist es sinnvoll die Testdaten von den Testfällen zu trennen und z.B. in einer Datenbank abzulegen. Auch das ist mit Robot-Framework möglich, erfordert aber je nach Umsetzung Programmierkenntnisse.

Die Testberichte sind aussagekräftiger und unterstützen die Analyse durch Filter- und Suchfunktionen.

Robot-Framework erzeugt bei der Testdurchführung einen Testbericht im HTML-Format. Das hat den Vorteil, dass keine besonderen Tools erforderlich sind, um den Bericht zu lesen. Der HTML-Bericht besteht aus zwei Dateien, die standardmässig report.html und log.html heißen.

Die Datei report.html bietet eine Übersicht über alle ausgeführten Testsuiten und Testfälle und bietet darüber hinaus verschiedene Filter und Suchfunktionen. Für jeden Testfall werden neben dem Namen und Ausführungsstatus noch weitere Daten angezeigt (z.B. Beschreibung, Tags, Fehlermeldung, Dauer der Ausführung). Zusätzlich werden aggregierte Ergebnisse zu den Testfällen berechnet.

Für die detaillierte Analyse eines Testfalls wird das Log (log.html) verwendet. Das Log beinhaltet alle durchgeführten Schritte eines jeden Testfalls entsprechend seiner Hierarchie. In einem Schritt wird genau ein Schlüsselwort ausgeführt. Eine Testsuite kann dabei beliebig viele weitere Testsuiten beinhalten. Ein Testfall ist dabei mindestens einer Testsuite zugeordnet. Konkret wird eine Testsuite als Verzeichnis oder Datei abgebildet. Ein Testfall ist atomar und kann keine weiteren Testfälle beinhalten. Jeder Testfall kann beliebig viele Schlüsselwörter beinhalten. Eigene Schlüsselwörter können beliebig viele weitere Schlüsselwörter enthalten. Jedes Schlüsselwort einer Bibliothek (Library) ist atomar. In folgender Abbildung ist dieser Sachverhalt als UML-Klassendiagramm dargestellt.

Hierarchie der Testdurchführung

Zusätzlich zu diesen zwei HTML-Dateien wird eine XML-Datei erzeugt, die die Basis für die beiden Dateien darstellt. Aus dieser XML-Datei können die HTML-Dateien auch wieder erzeugt werden. Es können aber auch weitere nützliche Funktionen mit dieser Datei ausgeführt werden. Beispielsweise können alle fehlerhaften Testfälle erneut ausgeführt werden. Sehr hilfreich ist auch die Möglichkeit, dass separat durchgeführte Testläufe nachträglich zusammengefasst werden können. So können die Testläufe verschiedener Teststufen in einen Report kombiniert werden. Diese Output-Datei kann auch für die Integration in andere Reporting-Tools genutzt werden. So wurde sie z.B. für ein Jenkins-Plugin genutzt, um die Ergebnisse eines Testlaufs direkt im Jenkins-Job anzuzeigen.

Der Testfokus kann auf weitere Komponenten wie die Datenbank und API-Schnittstellen (SOAP, REST) erweitert werden.

Ein weiterer großer Vorteil der Kombination aus Selenium und Robot-Framework ist, dass durch Robot-Framework das Anwendungsgebiet nicht auf die reine Web-GUI-Automatisierung beschränkt ist. Durch die Anwendung weiterer Bibliotheken kann das Einsatzgebiet der Automatisierung beispielsweise auf die Datenbank oder API-Schnittstellen (SOAP, REST) erweitert werden. So kann Robot-Framework nach dem Bausteinprinzip erweitert werden. In der folgenden Abbildung ist dieser Zusammenhang nochmal schematisch dargestellt. Um weitere Bibliotheken einzusetzen, müssen lediglich ein paar neue Schlüsselwörter genutzt werden. Die Testfallverwaltung, der Testbericht und auch die Einbindung in die Entwicklungs- und Testumgebungen werden dabei nicht beeinträchtigt.

Modularer Aufbau von Robot-Framework

Wenn die existierenden Bibliotheken nicht ausreichen, besteht die Möglichkeit eigene Bibliotheken zu entwickeln. Das ist nicht kompliziert, setzt aber Programmierkenntnisse voraus. Die selbstentwickelten Bibliotheken können in Python oder Java implementiert werden. Über diesen Weg ist es auch möglich weitere Automatisierungstools wie z.B. Sikuli einzubinden.

Fazit

Mit Selenium können Web-Anwendungen sehr gut automatisiert werden. Im Zusammenspiel mit Robot-Framework kann die Automatisierung zu einer vollständigen integrierten Lösung ausgebaut werden. Die Erstellung der Testfälle ist auch für Anwender mit geringen technischen Kenntnissen geeignet. Die Verwaltung von Testfällen und Testdaten wird erleichtert. Robot-Framework stellt einen aussagekräftigen Testdurchführungsbericht bereit und ermöglicht die Automatisierung weiterer Softwarekomponenten wie Datenbank und weitere Schnittstellen (SOAP, REST). Die Kombination dieser beiden Tools ist sehr hilfreich, kann aber nicht mit der Funktionalität und dem Komfort kommerzieller Programme nicht verglichen werden. Dafür ist der Einsatz von Robot-Framework kostenlos und bietet durch die freie Auswahl an Entwicklungswerkzeugen, der toolunabhängigen Verwaltung von Testfällen und der eigenen Entwicklung von Automatisierungsbibliotheken ggf. mehr Flexibilität.

Zum Autor:

Julian Loschelders ist als Berater im Bereich Test- und Qualitätsmanagement bei der adesso AG tätig. Er unterstützt Projekte als Testmanager und technischer Testingenieur.

[1]Eine komplette Übersicht aller Schlüsselwörter der Selenium-Library für Robot-Framework kann hiereingesehen werden

[2]Datengetriebene Testfälle sind Testfälle mit einem gleichen Ablauf aber unterschiedlichen Testdaten