Tricentis Tosca ist ein sehr vielfältiges Testautomationswerkzeug, mit dem sich die verschiedensten Applikationen automatisieren lassen – unter anderem Webapplikationen. Hierbei benutzt Tosca zur lokalen Ausführung der Testfälle in einem Browser ein Browser-Plugin bzw. eine Extension. Dies ist sehr vorteilhaft, da ein Testfall nur einmal geschrieben werden muss und Tosca den so entwickelten Testfall über Testkonfigurationsparameter auf unterschiedlichen lokalen Browsern ausführen kann.

Um dieses Konzept der Wiederverwendung bereits entwickelter Testfälle mit verschiedenen Plattformen und Browsern fortzusetzen und zu erweitern, bietet es sich an, einen Cross-Browser Cloud-Anbieter wie Sauce Labs zur Testautomation an Tosca anzubinden. Die Vorteile einer solchen Lösung sind:

• Einfache Überprüfung des Responsive Design einer Webapplikation
• Reduktion von Aufwand und Kosten zur Pflege einer Geräte-Infrastruktur
• Teure Anschaffungskosten für Geräte werden vermieden
• Erreichen einer höheren Testabdeckung

Dieser Leitfaden soll als Anleitung zur Integration von Tosca an die Sauce Labs Plattform dienen, insbesondere aus einer Enterprise Umgebung mit Firewall und Web-Proxy. Zudem werden Best Practices bei der Einrichtung der Test Cases in Tosca aufgezeigt.

Schritt #1: Hello Sauce Labs – initiales Einrichten der Verbindung

Um eine gute Basis für das spätere Setup zu haben, empfiehlt es sich, für die erste Verbindung zur Sauce Labs Cloud einen Tosca Agenten zu verwenden, auf den wir vollen Zugriff haben und der möglichst nicht hinter einem Proxy oder einer Firmen-Firewall sitzt. Dieser Schritt mag zwar trivial erscheinen, jedoch können wir bei einer späteren Fehleranalyse zu jeder Zeit auf dieses Setup zurückgreifen und mögliche Fehler beim Verbindungszugriff ohne Einschränkungen analysieren und gegebenenfalls eingrenzen.

Das Ziel des ersten Schritts sieht so aus:

Wir verwenden einen simplen Testfall und stellen zuerst sicher, dass dieser auf dem lokalen Tosca Agenten korrekt im Scratchbook ausgeführt wird:

Als nächstes wird derselbe Testfall in der Sauce Labs Cloud ausgeführt. Wir verwenden beispielhaft das EU-Datacenter https://ondemand.eu-central-1.saucelabs.com/wd/hub (eine Übersicht über alle Data Center Endpoints findet sich hier: Data Center Endpoints | Sauce Labs Documentation).

Der Testkonfigurationsparameter «HubAddress» ist in Tosca nach folgendem Schema zu konfigurieren:

Durch die Verwendung des Parameters «HubAddress» wird der Testfall nicht mehr lokal, sondern in der Sauce Labs Cloud ausgeführt. Nach der Ausführung im Scratchbook sehen wir das Resultat in der Sauce Labs Cloud. Wie auf dem Bild oben zu sehen ist, reicht die Angabe des Parameters «Browser» zur Testausführung. Für das zu verwendende Betriebssystem und die Browserversion wird ein Standardwert verwendet.

Als nächstes implementieren wir die Ausführung mit Sauce Labs aus dem Firmennetz mit Web-Proxy heraus.

Schritt #2: Enterprise Setup – Ausführung mit Proxy-Verbindung einrichten

Um den Zugriff von Tosca innerhalb eines Firmennetzwerks mit Proxy-Server und Firewall auf die Sauce Labs Cloud einzurichten, müssen weitere Parameter in der Testkonfiguration hinzugefügt werden. Doch zuallererst sollte mit der IT geprüft werden, ob von den Tosca-Agenten aus ein Zugriff auf die Sauce Labs Cloud möglich ist. Eventuell sind bestimmte Firewallregeln anzupassen.

Das Setup sieht nun folgendermassen aus:

Sobald sichergestellt ist, dass der Web-Zugriff von den Tosca Agenten auf den Data Center Endpoint von Sauce Labs funktioniert, sind drei wichtige Testkonfigurationsparameter hinzuzufügen:

1. WebDriverHubProxyAddress: Adresse des Proxy-Servers mit Port
2. WebDriverProxyUsername: Benutzername zur Authentifizierung am Web-Proxy
3. WebDriverProxyPassword: Password zur Authentifizierung am Web-Proxy

Sobald diese Parameter in der Konfiguration ergänzt wurden, können wir die Ausführung erneut im Scratchbook starten und in Sauce Labs prüfen, ob der Testfall korrekt ausgeführt worden ist. Falls es bei der Ausführung Probleme gibt, sind diese mit der internen IT vertieft zu analysieren.

Im Sauce Labs Testrun sollte man nun die Metadaten der Session etwas genauer anschauen. Stellt man fest, dass das veraltete JWP WebDriver-Protokoll verwendet wurde, so sollte dies unbedingt korrigiert werden.

Schritt #3: Verwendung des korrekten WebDriver-Protokolls (W3C)

Die Verwendung des W3C-Protokolls ist von Sauce Labs genauer dokumentiert: W3C WebDriver Capabilities Support | Sauce Labs Documentation

Sauce Labs empfiehlt, das neuere W3C-Protokoll anstelle des JWP-Protokolls (JSON Wire Protocol) zu verwenden. Im Folgenden wird dargestellt, wie die beschriebenen Empfehlungen konkret mit Tosca umgesetzt werden können. Der Name der zu verwendenden Capabilities spielt eine entscheidende Rolle.

Durch den Parameter Webdriver_platformName wird die zu verwendende Plattform konfiguriert (der veraltete Wert «OperatingSystem» ist unbedingt zu vermeiden). Auf Sauce Labs wird nun das korrekte Protokoll verwendet. Dies kann auf der Sauce-Labs-Testausführung im Reiter «Metadata» überprüft werden.

Bis hierher konnten wir die korrekte Anbindung von Tosca an Sauce Labs einrichten und haben nun die Möglichkeit, alle relevanten Settings zur Steuerung des Tests in der Cloud zu konfigurieren. Sehr hilfreich hierbei ist auch der Sauce Labs Platform Configurator.

Schritt #4: Write Once / Use Many – Cross-Browser-Automation eines Tosca-Testfalls mit Sauce Labs umsetzen

Sauce Labs bietet ein sehr hilfreiches Tool an, um die Konfigurationsparameter der möglichen Varianten an Geräten und OS-Versionen sowie beispielsweise der Bildschirmauflösung zu generieren – den Platform Configurator (Sauce Labs - Platform Configurator):

Das oben gezeigte Setup (Windows 11 / Chrome Version 110 / Auflösung von 1920x1080 Pixeln) wird wie folgt in Tosca umgesetzt:

Zu beachten ist die Schreibweise der unterschiedlichen Parameter:

• WebDriver_browserVersion: Hier kann eine auf Sauce Labs verfügbare Version eingetragen werden. Mit dem Wert «latest» wird die jeweils neueste Version verwendet.
• WebDriver_platformName: zu verwendendes Betriebssystem
• WebDriver_sauce___screenResolution: Die Auflösung des Gerätes in Sauce Labs. Alle Sauce Labs spezifischen Parameter werden mit dem Schema «_sauce___optionName» angegeben (einmal den Unterstrich «_», gefolgt von «sauce» und dann dreimal ein Unterstrich «_»).

Mit dem oben gezeigten Setup lässt sich ein Testfall, der einmalig in Tosca entwickelt wurde, auf verschiedenen Plattformen in Sauce Labs ausführen:

Es empfiehlt sich, den Tosca Execution Bereich mit Ordnern gemäss den erforderlichen Setups zu strukturieren und die vorher angelegten Tosca Testkonfigurationen auf die entsprechenden Ordner anzuwenden:

Innerhalb der ExecutionLists kann nun derselbe Testfall mehrmals wiederverwendet und somit auf verschiedenen Setups ausgeführt werden.

Schritt #5: Fehleranalyse und Test-Result-Reporting

Tosca bietet bereits umfassende Möglichkeiten bezüglich Reporting und Fehleranalysen. Es wird empfohlen, das vorhandene Reporting aus den Testausführungen in Tosca weiterhin zu verwenden.

Sauce Labs bietet jedoch weitere Möglichkeiten zur Nachvollziehbarkeit der Testdurchführung. Insbesondere die Video-Aufnahmen der Testläufe bieten für Tester eine umfassende Möglichkeit bei der Fehleranalyse:

Die Commands auf der linken Seite können zusätzlich dazu verwendet werden, um bespielsweise Timing-Probleme zu analysieren.

Fazit

Die Anbindung an Sauce Labs aus Tosca ist ohne Probleme möglich, auch aus einer Enterprise Umgebung mit Proxy Authentifizierung. Die zu verwendenden Konfigurationsparameter sind jedoch nicht einheitlich benannt und es erweist sich teilweise als schwierig, die korrekten Parameter zur Anbindung zu finden.

Sobald die Parameter korrekt hinterlegt sind, hat man jedoch eine umfassende Erweiterung für die Tosca-Umgebung eingerichtet: Einmal geschriebene Testfälle lassen sich auf entfernten Geräten ausführen. Man erspart sich somit die teure Anschaffung und wartungsintensive Pflege der entsprechenden Infrastruktur.

Weiterhin kann die Sauce Labs Cloud dazu verwendet werden, Mobile-Apps auf virtuellen und realen Geräten automatisiert zu testen. Dies führt zu weiteren Kosteneinsparungen und letzendlich zu einer höheren Testabdeckung.

‍