Testautomatisierung mit Selenium WebDriver Best Practices
Selenium hat sich beim Testen webbasierter Oberflächen bewährt und ist bereits seit über elf Jahren auf dem Markt. Eine der wichtigsten Komponenten von Selenium ist das WebDriver API, das auch von vielen anderen Testframeworks eingesetzt wird.
Wie bei jedem Softwareprojekt gibt es auch bei der Testautomatisierung mit Selenium WebDriver einige Grundprinzipien zu beachten. Des Weiteren existieren Selenium-spezifische Besonderheiten, die der Testautomatisierer berücksichtigen muss. In diesem Artikel wollen wir kurz auf diese Prinzipien und Besonderheiten eingehen.
Testbarkeit
Um Software testen zu können, muss diese zunächst einmal testbar sein. Auch wenn es logisch klingt, die zu testende Software wird nicht primär für dieses Ziel entwickelt, sodass spezielle Anpassungen zur Testunterstützung der Testbarkeit eher die Regel sind. Wenn Sie Testautomatisierung in einem seit langem laufenden Softwareprojekt einführen wollen, kann die zu testende Software Ihnen das Leben sehr schwermachen, da Oberflächenelemente nicht eindeutig erfasst werden können.
>> NEU Testautomatisierung mit Selenium | Schulung, Training
Das wandelbare Testobjekt
Für die Tester in einem Softwareprojekt gilt: Das Testobjekt ändert sich. Diese Erkenntnis ist nicht nur für Projekte in der Entwicklungsphase gültig – auch während der späteren Wartungsphase können große und kleine Änderungen am Programm vorgenommen werden.
Softwareupdates können Pfade und Verlinkungen ändern, Namen oder Funktionen der Komponenten können modifiziert werden. Damit automatisierte Tests weiterhin funktionieren, müssen sie oft ihrerseits angepasst werden.
Um zu gewährleisten, dass dies ohne zu großen Aufwand geschehen kann, müssen von Anfang an gewisse Designprinzipien beachtet werden.
Page Objects
Um das Testprojekt wartbar zu halten, ist es wichtig, die einzelnen Komponenten in separaten Modulen zu pflegen. Eine effektive und populäre Methode hierfür ist das Page Object Design Pattern. In diesem Entwurfsmuster gilt, dass die Funktionen und Elemente des Testobjekts separat von den eigentlichen Tests kodiert werden.
Wenn z.B. eine Webseite zu testen ist, würden im Page Object die Elemente (Buttons, Textfelder, Slider etc.) und die Funktionen (Suchen, Einloggen etc.) definiert sein. Die separat geschriebenen Tests würden auf diese Elemente und Funktionen über das Page Object zugreifen.
Der Vorteil dieser Methode ist, dass sich das Testprojekt Änderungen leicht anpassen kann. Wenn z.B. an dieser Webseite der Name eines Textfelds geändert wird (und dadurch sich der Pfad, mit dem auf dieses Element zugegriffen wird, ebenfalls ändert), dann muss nicht jeder Test, der dieses Textfeld benutzt, angepasst werden, sondern nur das Page Object.
Selektoren
Die richtige Wahl bei Selektoren stellt sicher, dass Komponenten eindeutig identifiziert werden können. Es gibt mehrere Arten von Selektoren – Identifizierung über die ID des Objektes, zum Beispiel, ist sehr einfach, es kann aber unter Umständen passieren, dass zwei Objekte die gleiche ID haben.
Aus gutem Grund populär sind Xpath- und CSS-Selektoren, wobei die letzteren zwar schwieriger aufzubauen, dafür aber schneller, robuster und weit verbreitet einsetzbar sind. Beide erlauben eine eindeutige Identifizierung des Objektes.
Lesbarer Code
Die Namen von Variablen und Methoden sollten aussagekräftig sein. Das Gleiche gilt für die Namen von Tests – der Name sollte nicht nur sagen, was getestet wird (z.B. loginTest), sondern auch wie und welches das erwartete Ergebnis ist; z.B. loginTest_validPassword_HTTP200 sagt uns, dass der Login-Test mit einem gültigen Passwort durchgeführt wird und das erwartete Ergebnis eine Antwort mit dem HTTP-Statuscode 200 ist.
Ebenfalls wichtig ist, dass es im Projekt eine konsistente Namensstruktur geben sollte. Vor allem in größeren Teams sollte diese Struktur von vorneherein vereinbart werden.
Kommentierter Code
Egal wie lesbar der Code ist, die natürliche Sprache ersetzt er nur selten. Oft brauchen selbst die eigentlichen Programmierer eines Softwareprojekts viel Zeit und Aufwand, um nach einem Jahr ihren eigenen Code zu verstehen.
Deshalb ist es unerlässlich, das Programm umfassend zu kommentieren. Jede Methode sollte neben grundsätzlichen Informationen wie Name des Autors, Erstellungsdatum, Parameter und Rückgabewerte eine Beschreibung seiner Funktion haben.
Selenium Testreporting
Selenium an sich hat keine Reporting Möglichkeiten. Das Testreporting wird in dem Testframework realisiert, in das Selenium implementiert wird. z.B. TestNG, JUnit, NUnit, PHPUnit.
Es sollte ausreichend Zeit investiert werden, um ein effektives und einheitliches Selenium Testreporting zu implementieren. Darauf aufbauend müssen weitere detaillierte Informationen (Teststufen, Fehlerklassen, Testprioritäten, etc.) eruiert werden, die für den Verlauf der Tests sehr wichtig sind.
Viele der hier aufgelisteten Prinzipien gelten auch für Softwareprojekte, denn es gilt: Ein Testautomatisierungsprojekt ist auch ein Softwareprojekt.
Selenium Testautomatisierung Schulungen/Training
Sie wollen lieber selbst anspruchsvolle, automatisierte Tests von Webapplikation durchführen, um unabhängig zu sein?
Qytera bietet Seminare zu Selenium an:
Selenium Sponsoring durch Qytera
Schon seit einigen Jahren ist Qytera Silver-Level-Sponsor von Selenium und fördert so aktiv die Weiterentwicklung und Pflege des Projekts.
Webinar: Testautomatisierung mit Open Source Tools (Selenium, Kubernetes, Docker) - Live Demo
Über den Autor
