Selenium ist ein Open-Source-Framework zur Browserautomation, das über standardisierte Webdriver-Schnittstellen alle gängigen Browser fernsteuert. Bei der Testautomatisierung mit Selenium geht es vor allem um 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.
- Testautomatisierung mit Selenium bleibt auch bei häufigen UI-Änderungen wartbar, wenn man CSS- und XPath-Selektoren beherrscht und das Page-Object-Pattern konsequent einsetzt.
- 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 Testautomatisierung mit 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?
Häufig gestellte Fragen
Warum braucht Selenium für jeden Browser einen eigenen WebDriver?
Der WebDriver übernimmt die eigentliche Fernsteuerung. Selenium spricht ihn an und verbirgt dabei die Unterschiede zwischen Chrome, Firefox, Safari oder Opera, sodass ein Test nur einmal geschrieben werden muss. Seit dem WebDriver-Standard liefern die Browserhersteller die passende Unterstützung selbst mit. Das brachte gegenüber früheren Lösungen mehr Stabilität und bessere Performance.
Lassen sich mit Selenium auch Browser-Einstellungen verändern?
Ja. Selenium arbeitet auf zwei Ebenen: Auf Browser-Ebene öffnest du Tabs, navigierst, lädst Seiten neu und setzt Einstellungen, auf Seiten-Ebene liest du Elemente aus und interagierst mit ihnen. Ein typisches Beispiel ist ein PDF, das der Browser sonst im internen Viewer anzeigt. Per Einstellung lässt sich der Download erzwingen. Solche Konfigurationen stabilisieren Testläufe.
Warum brechen automatisierte Oberflächentests schon bei kleinen Änderungen?
Häufigste Ursache sind absolute XPath-Ausdrücke, die per Rechtsklick und “Copy XPath” aus dem Browser in den Testcode wandern. Sie reichen vom Root-Element bis zum Ziel, kippen bei jeder Kleinigkeit und lassen niemanden mehr erkennen, welches Element gemeint war. Lesbare CSS- und XPath-Selektoren zusammen mit dem Page-Object-Pattern, das jeden Locator an einer Stelle bündelt, halten den Wartungsaufwand klein.
Welche Programmiersprache sollte man für die Testautomatisierung wählen?
Am besten die Sprache, in der das Produkt gebaut wird. Selenium gibt es als Anbindung für Ruby, Python, Java, Kotlin, C# und weitere Sprachen, die Wahl ist also frei. Dieselbe Sprache holt die Entwickler ins Boot: Sie finden Fehler im Testlauf schneller, beheben sie selbst und schreiben eigene Testfälle. Testautomatisierung mit Selenium ist Entwicklungsarbeit.
Wie viele Szenarien gehören auf die UI-Ebene?
Wenige. UI-Tests sitzen in der Spitze der Testpyramide: Du nimmst einen Business-Fall und spielst ihn auf Geschäftsfall-Ebene durch. Varianten, die an der Oberfläche nichts Wesentliches ändern, gehören in Integrations- und Unit-Tests. Zu Projektbeginn darf man mehr über die UI prüfen, um überhaupt Abdeckung zu haben. Solche Tests kann man später löschen oder archivieren.
Was gehört in einen Report, damit ein Team fehlgeschlagene Tests ernst nimmt?
Der Report muss den Step zeigen, an dem der Test scheiterte, und den Grund, etwa ein nicht identifiziertes Objekt oder einen nicht verfügbaren Backend-Service. Dazu kommen ein Screenshot und der HTML-Code der Seite. Die entscheidende Frage lautet: Hat die Applikation einen Fehler oder der Test? Videos der Testläufe lohnen sich meist nur als Ausnahme.
Muss man die passenden WebDriver-Binaries selbst bereitstellen?
Früher war das nötig: Für jede Chrome-Version musste der passende ChromeDriver für das jeweilige Betriebssystem beschafft, das Binary ins richtige Verzeichnis gelegt und der Pfad gesetzt werden. Der WebDriver Manager von Boni Garcia, ursprünglich ein eigenes GitHub-Projekt, wurde als Selenium Manager integriert. Ab den 4.6er- und 4.8er-Versionen war das Treiber-Handling 2023 out of the box dabei.
Kann künstliche Intelligenz das Testen von Webanwendungen übernehmen?
Zunächst eher als Unterstützung, besonders im visuellen Bereich. Im Mobile-Bereich existierten 2023 Bibliotheken, die eine Anweisung wie “drücke den Login-Button” entgegennehmen und selbst ermitteln, welches Element gemeint ist. Ein Bot, dem man nur die Webseite übergibt und der eigenständig testet und einen Report liefert, lag weiter entfernt. Offen bleibt die Vertrauensfrage: Wer testet die Testautomatisierung?
