Im ersten Teil unserer Artikelreihe haben wir euch die Vorteile automatisierter Oberflächentests, die Besonderheiten des Test-Frameworks Selenium sowie das Vorgehen damit beim lokalen Testen dargelegt. Für weniger anspruchsvolle Zwecke sollte das bis dahin vermittelte Wissen auch ausreichend sein, um im kleinen Rahmen schnell und einfach eine erste Lösung aufzusetzen. Das volle Potenzial der Testautomatisierung kann sich jedoch erst in einem Selenium Grid am besten entfalten. Damit wird nämlich auch eine saubere Lösung in Richtung Continuous Delivery möglich.

Mit Selenium Grid verteilt und parallelisiert testen

Die Selenium Grid-Architektur baut im Prinzip auf einen Proxy-Ansatz auf, der vereinfacht ausgedrückt, die Weiterleitung der Tests von einem Punkt an entfernt liegende Punkte ermöglicht. Das Ziel dahinter ist, eine einfache Möglichkeit zu bieten, Tests verteilt und auf mehreren Rechnern parallel ausführbar zu machen.

Hub + Node(s) = Selenium Grid

Im Selenium Grid gibt es dazu die beiden Rollen Hub und Node, die ihre entsprechende Rolle beim Start einer Selenium-Instanz zugeteilt bekommen. Ein Selenium Hub wird dabei mit mehreren Selenium Nodes zu einem Grid zusammengefasst.

Der Hub ist der verwaltende Teil des Grids, d.h. er vermittelt die an ihn zugetragenen Testskripte ressourcen- und bedarfsgerecht an die ihm bekannte Nodes.
Die Nodes wiederum führen die vom Hub übermittelten Testskripte aus. Vorher jedoch registriert sich jeder Node direkt am Hub und teilt seine individuelle Testkonfiguration mit, wie z.B. welchen Browser und Browserversion er unterstützt oder welches Betriebssystem darauf installiert ist (siehe nachfolgende Abbildung).