Installation und Update

Einleitung

Das Test-Studio unterstützt Customizing-Arbeiten im CRM durch reproduzierbare Tests. Damit diese maximalen Nutzen generieren, ist es notwendig, diese regelmäßig, automatisiert auszuführen und die Ergebnisse ansprechend zugänglich zu machen. Dieses Dokument beschreibt eine solche Umgebung.

Systemlandschaft für das Test-Studio

Verschiedene Benutzer

In dieser Anleitung sind – sofern nicht anders dargestellt – alle Benutzer stets Windows-(Domänen)-Accounts.

Ein optimales Deployment des Test-Studios sieht wie folgt aus:

Legende

Kanten mit Datei: ... beziehen sich auf Dateirechte.
Kanten mit CRM: ... beziehen sich auf CRM-(Aktions-)Rechte

Benutzer und Server

In der Regel wird TestMaintainer das Test-Studio auf seinem lokalen PC ausführen; eine Nutzung in "Terminalserversitzungen" (Windows Remote Desktop Services (RDS) – server session-based desktops) ist prinzipiell möglich.
Die regelmäßige Testausführung sollte mit einem separaten Benutzer (hier TestExecutor ) auf einem separaten (Windows-)System passieren. Dieser Nutzer sollte mit minimalen Rechten ausgestattet werden.
Die gestrichelten Kanten vom TestMaintainer zu \\sReport\report sind optional, wenn die CRM-Rückführung nur für die nächtlichen Testläufe genutzt werden soll.
Der Installationspfad des Test-Studios und ggf. die WebDriver muss auf allen Systemen, auf denen Tests ausgeführt bzw. bearbeitet werden sollen, unter einem Laufwerksbuchstaben verfügbar sein; ein UNC-Pfad ist nicht geeignet.

CRM-Systeme

Die Tests werden auf dem "Test CRM" ausgeführt, in das "Report CRM" werden – sofern konfiguriert – die Ergebnisse hinterlegt. Diese Systeme können identisch sein; für die Testausführung und das Speichern der Ergebnisse können unterschiedliche CRM-Benutzer verwendet werden.

Für das Test-CRM ist ein CRM-Benutzer mit folgenden Eigenschaften anzulegen:

Dessen Konfiguration (u.a. Rechte, Konfigurationsgruppe, Benutzereinstellungen, Mitarbeiterdatensatz) bestimmt die "Umgebung", in der die Tests ausgeführt werden.
Das Aktionsrecht "GUI-Testfälle ausführen" muss gewährt werden.
Für den ausführenden Benutzer müssen zwingend Zen-Modus und Onboarding-Assistent deaktiviert sein.
Das Modul "Test-Studio" muss lizenziert sein.

Während der Testlauf durchgeführt wird, darf der verwendete CRM-User nicht über weitere Wege im System tätig sein, da dies zu Fehlern führen kann.

Übersicht über benutzte Pfade und benötigte Dateirechte

Ort	Erklärung	Rechte für Nutzer TestMaintainer			Rechte für Nutzer TestExecutor
Ort	Erklärung	Lesen	Schreiben	Ausführen	Lesen	Schreiben	Ausführen
`\\sReport\report`	Verzeichnis, in das Reports und Screenshots geschrieben werden, die für die Testergebnisse im Report-CRM benötigt werden. In das Report-CRM wird nur eine Zusammenfassung der Testergebnisse ("Welcher Schritt mit welchem Keyword hat nicht funktioniert?") geschrieben, aber keine Details ("Welche Keywords wurden alles ausgeführt?"). Diese Informationen werden in einem detaillierten Report (Datei mit Endung `teststudio_log`) gespeichert. Diese wird im Report-CRM als LINK-Dokumentendatensatz referenziert.		/
`\\sWorkspace\test`	Verzeichnis, das den Workspace mit allen Testfällen und Testschrittbibliotheken enthält. Testfälle können in (beliebig tief verschachtelte) Unterordner sortiert werden.
`\Client\jboss\teststudio`	Installationsverzeichnis des Test-Studios. Enthält grundlegende Konfiguration (u.a. Truststore).
`\\sInstall\testStudio\webDriver`	Enthält die WebDriver, wenn sie zentral bereitgestellt werden sollen. Das ist zu empfehlen, weil dies ausführbare Dateien sind und zum anderen die Wartbarkeit verbessert wird.
`%WORKING_DIR%`	Ein lokales Arbeitsverzeichnis pro Test-Studio Benutzer zur Ablage von Screenshots, Einstellungen und Protokollen.

Sicherheitsbetrachtungen

Die Test-Studio Sprache basiert auf groovy, d.h. Testfälle können theoretisch beliebigen Code enthalten, der während der Testausführung zur Ausführung kommt.

Damit könnte der Testersteller (TestMaintainer) (theoretisch) beliebigen Code im Kontext des Nutzers TestExecutor ausführen.

Das Einfügen belieben Codes in Testfällen wird von CURSOR nicht unterstützt.

Deshalb sollte TestExecutor mit minimalen Rechten ausgestattet sein.
Die vom Test-Studio gestartete WebDriver (vgl. Technischer Kommunikationsplan der CURSOR-Test-Studio Komponenten) horchen auf dem loopback Interface auf ihre Befehle, die der Browser ausführt. Siehe https://chromedriver.chromium.org/security-considerations , diese Empfehlungen gelten ebenso für GeckoDriver (Firefox) und EdgeDriver (Microsoft Edge).
Die WebDriver können über das Test-Studio automatisch aktualisiert werden (vgl. Technischer Kommunikationsplan der CURSOR-Test-Studio Komponenten). Diese Funktion lädt Programmkomponenten aus dem Internet herunter.

Einrichten der Dateityp-Verknüpfungen

Die Test-Studio Reports werden als Dateien mit der Endung .teststudio_log gespeichert. Dieser Dateityp sollte mit den Test-Studio registriert werden, damit sie aus dem Report CRM direkt geöffnet werden können (dort sind sie nur als LINK-Dokumente hinterlegt).

Registrieren mittels `.reg` -Datei

Über das Test-Studio kann eine .reg-Datei über "Einstellungen -> Verknüpfung von .teststudio.log Dateien mit dem Test-Studio" im Test-Studio für die Dateityp-Verknüpfung erzeugt werden. Diese muss anschließend importiert bzw. per Client-Management-Lösung (z.B. Gruppenrichtlinie) verteilt werden.

Update

Verteilung des Test-Studios mittels Windows-Client

Das Test-Studio wird mit dem Windows-Client ("Rich-Client") verteilt, so wird es im Rahmen der normalen CRM-Patchtes ebenfalls aktualisiert.

Bis auf configuration.bat und eigene weitere Dateien werden alle Dateien im Verzeichnis des Studios ausgetauscht.

Wird der Rich-Client nicht mittels Client-Update-Tool verteilt, so muss das Test-Studio nach jedem Update oder Patch des CRMs anderweitig aktualisiert werden.

WebDriver und Browser

Das Test-Studio unterstützt die Browser

Microsoft Edge,
Google Chrome,
Mozilla Firefox.

Um mit diesen kommunizieren zu können, benötigt das Test-Studio einen WebDriver (vgl. Technischer Kommunikationsplan der CURSOR-Test-Studio Komponenten). Dieser WebDriver ist browserspezifisch und ggf. abhängig von der Version des Browsers:

Microsoft Edge und Google Chrome benötigen einen WebDriver in der derselben Version wie die Hauptversion des Browsers. Ein älterer WebDriver funktioniert in der Regel übergangsweise; es treten aber sehr schnell Probleme auf.
Durch die hohe Updatefrequenz der Browser muss auch der WebDriver entsprechend häufig aktualisiert werden.
Der von Mozilla Firefox benötigte WebDriver arbeitet i.d.R. versionübergreifend, d.h. ein älterer WebDriver kann trotzdem einen neueren Firefox fernsteuern.

Das sollte berücksichtigt werden, wenn bspw. der Browser über eine zentrale Softwareverteilung automatisch aktualisiert wird.

Speicherort des WebDrivers

Standardmäßig wird der WebDriver im %WORKING_DIR% abgelegt, das in der configuration.bat hinterlegt ist. Dabei erwartet das Test-Studio folgende Namenskonvention:

Verwendeter Browser	Pfad des WebDrivers
Microsoft Edge	%WORKING_DIR%\webdriver_edge.exe
Mozilla Firefox	%WORKING_DIR%\webdriver_firefox.exe
Google Chrome	%WORKING_DIR%\webdriver_chrome.exe

Die Pfade können in der configuration.bat durch Aufnahme folgender Zeilen angepasst werden

CODE

SET TESTSTUDIO_ENGINE_DRIVER_CHROME=C:\my\chromedriver.exe
SET TESTSTUDIO_ENGINE_DRIVER_FIREFOX=C:\my\geckodriver.exe
SET TESTSTUDIO_ENGINE_DRIVER_EDGE=C:\my\edgedriver.exe

Alternativ kann die Konfiguration auch über die Administrative Vorgabe von Einstellungen erfolgen.

Automatisches Herunterladen des WebDrivers

Über das "WebDriver" Menü im Einstellungsdialog wird der aktuellste WebDriver heruntergeladen und für die Verwendung konfiguriert.

Manuelles Herunterladen des WebDrivers

Abhängig vom verwendeten Browser, ist der WebDriver herunterzuladen und zu entpacken:

Microsoft Edge: https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/
Google Chrome: https://googlechromelabs.github.io/chrome-for-testing/#stable
Auf der Seite gibt es sowohl das Binary „chrome“ für die Plattform „win32“, wie auch „chromedriver“. Nur das zweite Binary „chromedriver“ ist richtig!
Mozilla Firefox: https://github.com/mozilla/geckodriver/releases

Die Pfade, an denen der WebDriver gepeichert werden muss, sind unter Speicherort des WebDrivers beschrieben.

Regelmäßiges Ausführen der Tests

Siehe Regelmäßiges Ausführen der Tests .

Bekannte Einschränkungen

Die Bereitstellung des Test-Studios als Remoteanwendung (bspw. als RemoteApp aus Windows Remote Desktop Services (RDS)) wird nicht unterstützt. Das Test-Studio startet unter anderem den Browser zur Testausführung als untergeordneten Prozess ("child processes"). Das Browserfenster muss dem Testersteller für eine effiziente Testerstellung aber zugänglich sein.
Das Test-Studio wird nicht als Software-as-a-Service bereitgestellt. Das bedeutet, dass auch CRM-SaaS-Kunden das Test-Studio "lokal" installieren müssen.

Technische Hintergrundinformationen

Das Test-Studio speichert seine gesamte Konfiguration im WORKING_DIR, das in der configuration.bat eingestellt werden kann. Im Standard zeigt es auf %APPDATA%\CURSOR\testStudio
Alle Passwörter werden – sofern sie gespeichert werden sollen – maskiert bzw. verschleiert gespeichert. Das bedeutet, dass jeder, der Zugang zum Test-Studio hat, diese auslesen und benutzen kann. Es wird aber in einer für den Menschen nicht lesbaren Form gespeichert (z.B. oPjZxZLQ2tFGeLFfb6IDHQ==).
Alle Einstellungen (auch gespeicherte Passwörter) werden unter %WORKING_DIR%\customSettings.properties gespeichert.
Die WebDriver (Programme, die die Browser fernsteuern) liegen standardmäßig dort und müssen vom Test-Studio Benutzer ausgeführt werden können.
Der Ort der Log-Dateien kann über %WORKING_DIR%\additionalLogConfig.xml gesteuert werden.