Glossar · UI-Automatisierung
Selenium Grid
Auch genannt: Selenium Grid 4, Grid, RemoteWebDriver, Selenium Hub
Definition
Ein Selenium-Server, der WebDriver-Sessions an entfernte Browser-Nodes weiterleitet, damit Tests parallel über viele Browser, Versionen und Rechner laufen können.
Mit Selenium Grid kann ein Test seinen Browser woanders starten lassen. Der Test verwendet RemoteWebDriver und richtet ihn auf die URL des Grids; das Grid findet einen Node mit passendem Browser (zum Beispiel Chrome unter Linux), startet dort eine Session und leitet jeden Befehl weiter. Da viele Nodes gleichzeitig Sessions bedienen können, ist Grid der klassische Weg, eine Selenium-Suite parallel und über mehrere Browser hinweg auszuführen.
Beispiel
Starten Sie mit dem offiziellen Docker-Image ein Grid auf einem einzelnen Rechner:
docker run -d -p 4444:4444 --shm-size="2g" selenium/standalone-chrome
Verbinden Sie sich dann aus einem Test (Selenium 4, Java 21):
ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
URI.create("http://localhost:4444").toURL(), options);
driver.get("https://example.com");
Die Browser-Optionen sind die „Capabilities“, die das Grid mit seinen Nodes abgleicht. Die Grid-Oberfläche unter http://localhost:4444 zeigt Nodes, Slots und laufende Sessions.
Wie es aufgebaut ist (Grid 4)
Selenium Grid 4 kann in drei Modi laufen:
- Standalone: alles in einem Prozess, gut für die lokale Nutzung und kleine CI-Jobs.
- Hub und Node: Ein Hub nimmt Sessions entgegen, und mehrere Nodes führen Browser aus. Starten Sie mit
java -jar selenium-server-<version>.jar hubund... node. - Vollständig verteilt: Die internen Komponenten des Hubs (Router, Distributor, Session Map, New Session Queue, Event Bus) laufen als separate Prozesse, was gut zu Kubernetes passt.
Grid 4 hat außerdem den alten Pfad /wd/hub überflüssig gemacht, akzeptiert ihn aber weiterhin.
Häufige Fehler
- Erwarten, dass Grid Tests parallelisiert. Grid stellt Browser bereit. Ihr Test-Runner (JUnit 5, TestNG) muss trotzdem so konfiguriert sein, dass er Tests nebenläufig ausführt, und die Tests müssen isoliert sein.
- Mehr Threads als Slots. Zusätzliche Session-Anfragen landen in einer Warteschlange und können in einen Timeout laufen. Passen Sie die Parallelität des Runners an die verfügbaren Slots an.
- Treiber nicht beenden. Ein fehlendes
driver.quit()lässt Sessions Slots belegen, bis sie ablaufen. - Zu wenig Shared Memory in Docker. Chrome stürzt mit dem Standardwert für
/dev/shmim Container ab, daher das Flag--shm-size.
Gehostete Cloud-Dienste stellen denselben WebDriver-Endpunkt bereit wie ein Grid, der RemoteWebDriver-Code bleibt also identisch; nur URL und Capabilities ändern sich.