Testautomatisierung mit Selenium

Selenium ist ein Open-Source-Framework zur Browserautomation, das über standardisierte Webdriver-Schnittstellen alle gängigen Browser fernsteuert. Der Hauptanwendungsfall ist das automatisierte Testen von Webapplikationen: Seitenelemente lassen sich auslesen, anklicken und befüllen. Selenium unterstützt viele Programmiersprachen und gilt seit Version 4 als deutlich stabiler, weil Browserhersteller den Webdriver selbst mitliefern.

Das Wichtigste in Kürze

• Selenium ist kein Testtool, sondern eine Browserautomation: Es steuert über den Webdriver beliebige Browser fern, unabhängig von Hersteller und Betriebssystem.
• Wer CSS- und XPath-Selektoren beherrscht und das Page-Object-Pattern konsequent einsetzt, hält den Wartungsaufwand auch bei häufigen UI-Änderungen minimal.
• Dieselbe Programmiersprache für Tests und Produktcode zu wählen erhöht die Bereitschaft der Entwickler, Testfehler selbst zu fixen und eigene Testfälle zu schreiben.
• Cucumber in Kombination mit Selenium macht für den Product Owner sichtbar, welche Fachlichkeit ein Test abdeckt, ohne dass er den Code lesen muss.

Was Selenium wirklich ist: Browserautomation, kein Testtool

Selenium ist eine Schnittstelle zur Browserautomation und kein Testwerkzeug im engeren Sinn. Diese Unterscheidung wird oft verwischt. In Ausschreibungen und Stellenanzeigen taucht Selenium als “das Testautomatisierungstool” auf, doch das Selenium-Projekt selbst beschreibt es als Mittel, um Browser fernzusteuern.

Der praktische Hauptanwendungsfall ist trotzdem die Testautomatisierung. Weil ein Großteil der Software als Web-Applikation gebaut wird, liegt es nahe, einen Browser präzise zu steuern und damit Testfälle auszuführen.

Technisch sitzt zwischen Selenium und dem Browser der WebDriver. Für jeden Browser gibt es einen eigenen WebDriver, der die Fernsteuerung übernimmt. Selenium spricht diesen WebDriver an und verbirgt dabei die Unterschiede zwischen Chrome, Firefox, Safari oder Opera. Du schreibst deinen Test einmal, ohne dich pro Browser um die Details zu kümmern.

Seit dem WebDriver-Standard sind die Browserhersteller selbst dafür zuständig, dass diese Anbindung funktioniert. Wer einen Webbrowser herausbringt, liefert die passende WebDriver-Unterstützung mit. Das Ergebnis ist mehr Stabilität, mehr Effizienz und bessere Performance als zu früheren Zeiten.

In welchen Programmiersprachen man Selenium nutzt

Selenium gibt es als Anbindung für viele Programmiersprachen, und genau das macht es flexibel. Tests lassen sich in Skriptsprachen wie Ruby oder Python schreiben, ebenso in Java, Kotlin oder C#. Die Zahl der Implementierungen übersteigt die Sprachen, die ein einzelner Entwickler überhaupt beherrscht.

Die Einbindung läuft über die jeweilige Sprachbibliothek. In Java oder Kotlin bindest du die Dependencies in dein Projekt ein und greifst damit auf die Selenium-Bibliothek zu, um die Browser zu steuern.

Diese Freiheit hat eine konkrete Konsequenz für Teams: Du kannst die Sprache wählen, die ohnehin im Projekt verwendet wird. Damit fällt die Testautomatisierung nicht aus dem technischen Rahmen des Produkts heraus.

Wie Selenium den Browser steuert

Selenium arbeitet auf zwei Ebenen, ähnlich wie ein Mensch den Browser bedient. Auf der Browser-Ebene öffnest du Tabs, navigierst, lädst Seiten neu und setzt Einstellungen. Auf der Seiten-Ebene liest du Informationen aus und interagierst mit den Web-Elementen.

Auf Element-Ebene fragst du Zustände ab, klickst, gibst Text ein, wählst Werte aus oder führst Drag-and-drop aus. Das deckt im Wesentlichen das ab, was ein Nutzer im Browser tut.

Browser-Einstellungen sind genauso steuerbar. Ein typisches Beispiel: Eine Web-Applikation bietet ein PDF zum Download an, das der Browser standardmäßig im internen Viewer öffnet. Per Einstellung lässt sich erzwingen, dass die Datei stattdessen heruntergeladen wird. Solche Konfigurationen gehören zu den Stellschrauben, die einen Testlauf stabil machen.

Gute Selektoren entscheiden über den Wartungsaufwand

Die Wahl der Selektoren bestimmt, wie pflegeintensiv eine Testautomatisierung ist. Für einfache Fälle reichen ID oder Tag-Name. Sobald es komplexer wird, brauchst du solide Kenntnisse in CSS-Selektoren und vor allem in XPath-Selektoren. Wer diese klug zusammenbaut, hält den Wartungsaufwand klein.

Ein verbreiteter Fehler ist der absolute XPath aus dem Browser-Kontextmenü. Per Rechtsklick “Copy XPath” landet ein Pfad im Testcode, der vom Root-Element bis zum Zielelement reicht. Ändert sich eine Kleinigkeit auf der Seite, bricht der Test, und niemand erkennt mehr, welches Element gemeint war. Selektoren sollen lesbar sein.

Es existieren Bibliotheken, die einen fehlgeschlagenen Locator automatisch durch einen neuen ersetzen. Doch ein fehlschlagender Test bei einer Oberflächenänderung ist kein Mangel, sondern ein Signal. Der Test hat festgestellt, dass sich etwas geändert hat, und das ist sein Zweck.

Folgst du dem Page-Object-Pattern, änderst du einen Locator an genau einer Stelle, auch wenn hundert Testskripte ihn ansprechen. Saubere Struktur reduziert den Wartungsaufwand auf ein Minimum.

Selenium ist Entwicklungsarbeit

Viele Probleme, die scheinbar Selenium verursacht, kommen in Wirklichkeit aus der verwendeten Programmiersprache. Testautomatisierung mit Selenium ist Entwicklungsarbeit, kein Klickskript.

Wenn man viele Probleme, die man vermeintlich mit Selenium hat, dann hat man die meistens nicht mit Selenium selbst, sondern mit der Programmiersprache, mit der man es gemacht hat. (Boris Wrubel)

Daraus folgt eine klare Empfehlung für die Sprachwahl: Nimm die Sprache, in der das Produkt gebaut wird. Das holt die Entwickler ins Boot. Tritt während eines Testlaufs ein Fehler auf, finden sie ihn schneller und können selbst Hand anlegen, beim Fixen wie beim Schreiben neuer Tests.

Dieser Ansatz passt zur Idee von Scrum, dass es keinen abgekoppelten Tester gibt. Qualität wird zur Aufgabe des ganzen Teams, nicht zur Auslagerung an eine Einzelperson.

Wie man die Fachlichkeit einbindet

Die fachliche Seite kommt über Cucumber ins Spiel. Selenium in Verbindung mit Cucumber macht Product Owner und Fachbereich sichtbar, was ein Test prüft, ohne dass sie den Code lesen müssen. Gut geschriebene Szenarien zeigen die getestete Fachlichkeit direkt.

Wer die Szenarien schreibt, ist eine eigene Frage. Den Fachbereich allein die Szenarien schreiben zu lassen, ist nicht ideal. Sinnvoller ist es, sie gemeinsam zu formulieren, sodass die fachliche Sicht und die technische Umsetzbarkeit zusammenkommen.

Cucumber-Steps brauchen einen vernünftigen Schnitt. Endlos lange Szenarien, in denen jeder einzelne UI-Schritt hochparametrisiert beschrieben ist, werden unübersichtlich. In solchen Fällen ist berechtigt zu fragen, wozu Cucumber überhaupt dient. Wenn du jeden Klick als Step abbildest, kannst du den Ablauf genauso gut sauber in der Testklasse herunterschreiben. Cucumber lohnt sich erst, wenn die Szenarien Fachlichkeit ausdrücken, nicht Mausbewegungen.

Wie man UI-Tests richtig schneidet

UI-Tests gehören in die Spitze der Testpyramide, also bewusst dünn besetzt. Du pickst einen Business-Fall heraus und spielst ihn auf Geschäftsfall-Ebene durch. Varianten, die an der Oberfläche nichts Wesentliches ändern, gehören in Integrationstests und Unit-Tests.

Zu Projektbeginn darf das anders aussehen. Solange die Software klein ist, testet man gerne mehrere Varianten über die UI und prüft, ob Dinge richtig angezeigt werden, um überhaupt etwas in der Hand zu haben. Solche Tests darfst du später löschen oder archivieren, wenn die tieferen Ebenen die Abdeckung übernehmen.

Diese Disziplin verhindert, dass die langsame, teure UI-Ebene mit hundert Szenarien überladen wird, die woanders besser aufgehoben sind.

Warum gutes Reporting über die Akzeptanz im Team entscheidet

Reporting ist der Hebel, der Entwickler zum Mitmachen bewegt. Schlägt ein Selenium-Test fehl, muss der Report die Ursache schnell sichtbar machen. Sonst bleibt die Testautomatisierung eine Insel.

Ein brauchbarer Report zeigt den Step, an dem der Test fehlschlug, und den Grund: ein nicht identifiziertes Objekt oder ein nicht verfügbarer Backend-Service. Dazu gehören ein Screenshot, der HTML-Code der Seite und je nach Bedarf ein, zwei Zusatzinformationen. Videos der Testläufe sind möglich, lohnen sich aber meist nur als Ausnahme, wenn das normale Reporting nicht ausreicht.

Die zentrale Frage, die ein Report beantworten muss, ist simpel: Hat die Applikation einen Fehler oder hat der Test einen Fehler? Wer das schnell erkennt, hält die Hürde fürs Team niedrig.

Jenkins bietet eine der besten Cucumber-Report-Engines für die Integration in die Pipeline. Cucumber liefert sein Ergebnis als JSON-Datei, und es gibt Open-Source-Tools auf GitHub, die diese Datei lesbar aufbereiten und teils ein PDF daraus erzeugen, samt Screenshots und weiteren Anhängen.

SeleniumCucumberGrow: in unter einer Stunde startklar

Ein häufiges Gegenargument lautet, der Aufbau von der grünen Wiese sei zu aufwendig, obwohl Selenium nichts kostet. Genau dieses Problem adressiert das Open-Source-Projekt SeleniumCucumberGrow, dessen Name für Selenium, Cucumber und Grow steht.

Das Tool ist ein Projektgenerator. Du gibst Projektname und Package-Namen ein, und es erzeugt ein lauffähiges Selenium-Projekt mit einem Beispiel, das auf einer Wikipedia-Seite nach “Software Testen” sucht. Damit fällt das wiederholte Umbauen von Package- und Klassennamen weg, das frühere Projektkopien so mühsam machte.

Der Anspruch des Projekts steht im Titel seiner Konferenzvorträge: Get started with less than one hour. Innerhalb einer Stunde steht der erste Testfall gegen die eigene Webseite. Das Projekt wird auf den aktuellen Selenium-Versionen und Dependencies gehalten und nutzt für das Reporting die Bordmittel von Cucumber, ergänzt um die Informationen, die zur schnellen Fehlersuche zählen. Eine Erweiterung für Accessibility-Testing ist in Arbeit, die das Element anzeigt, das einen Accessibility-Check nicht bestanden hat.

Was du brauchst, um sauber durchzustarten

Der größte Fallstrick ist ein fehlendes Konzept für die Testautomatisierung. Ein lauffähiges Beispiel allein reicht nicht; du brauchst eine Vorstellung, wie du die Automatisierung angehst, bevor du die Wikipedia-Demo gegen die eigene Anwendung tauschst.

Zwei Dinge tragen den Start:

• Page-Object-Pattern befolgen. Es bündelt Locators an einer Stelle und hält die Tests wartbar.
• CSS- und XPath-Locators beherrschen. Ohne dieses Wissen entstehen die brüchigen absoluten Pfade, die bei der kleinsten Änderung kippen.

Moderne IDEs wie Eclipse oder IntelliJ helfen mit guten Plugins, die die Testentwicklung beschleunigen. In Kombination mit dem Page-Object-Pattern führt das dazu, dass der erste Testfall gegen die eigene Webseite tatsächlich in kurzer Zeit steht.

Aktuelle Entwicklungen: von Selenium 3 zu 4

Mit Selenium 4 hat sich nach langer Ankündigung einiges bewegt. Die Version 3 lief über lange Zeit, der Sprung auf 4 zog sich, ist inzwischen aber etabliert.

Neu sind die Relative Locators. Du suchst nach Elementen, die links, rechts, ober- oder unterhalb eines anderen Elements liegen. Für bestimmte Layouts vereinfacht das die Lokalisierung.

Die größere Erleichterung betrifft das WebDriver-Handling. Früher musstest du für jede Chrome-Version den passenden ChromeDriver für dein Betriebssystem bereitstellen, das Binary ins richtige Verzeichnis legen und den Pfad setzen. Der WebDriver Manager von Boni Garcia, ursprünglich ein eigenes GitHub-Projekt, ist als Selenium Manager in das Projekt integriert worden. Seit den 4.6er/4.8er-Versionen ist das Treiber-Handling out of the box dabei, und du kümmerst dich nicht mehr um den richtigen Treiber-Download.

Wohin sich Testautomatisierung mit KI bewegt

Künstliche Intelligenz wird die Testautomatisierung verändern, am ehesten zunächst als Unterstützung. Erste Ansätze überlassen der KI Teile des Testens, besonders im visuellen Bereich.

Im Mobile-Bereich gibt es Bibliotheken, die eine Anweisung wie “drücke den Login-Button” entgegennehmen und selbst herausfinden, welches Element der Login-Button ist, ob über Machine Learning oder andere Verfahren. Diese Art assistierter Automation ist absehbar.

Die Vision eines Test-Bots, dem du nur deine Webseite gibst und der eigenständig testet und einen Report zurückliefert, steht weiter weg. Mit ihr kommt sofort die offene Frage des Vertrauens: Wie sicher kannst du sein, dass der Bot das Richtige prüft? Oder, zugespitzt: Wer testet die Testautomatisierung?