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.

Alle CRM-Versionen mit Support seitens CURSOR werden durch das Test-Studio unterstützt.

Übersicht über benutzte Pfade und benötigte Dateirechte

Ort	Erklärung	Rechte für Nutzer TestMaintainer			Rechte für Nutzer TestExecutor
		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.
\\sInstall\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 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.

• 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.

Initiale Konfiguration

Verteilung des Test-Studios mittels Windows-Client

Die initiale Konfiguration ist nur notwendig, wenn das Test-Studio nicht mit dem Rich-Client ausgeliefert wird bzw. aus dessen Verzeichnis gestartet wurde.

Für die initiale Konfiguration des Test-Studios gibt es einen Assistenten. Dieser wird über CURSOR_TestStudio_setup.bat gestartet.

Gruppe	Name der Einstellung	Beschreibung
Truststore	Pfad	Pfad zum Truststore, der Public-Zertifikate enthält. Empfohlen ist, denselben Truststore wie der Windows-Client (Rich-Client) zu verwenden. (Die genaue Konfiguration kann der configuration.bat im Windows-Client Verzeichnis entnommen werden). Zertifikate im Browser Diese Konfiguration stellt keine Vertrauensstellung zwischen Server und Webbrowser (Google Chrome, Mozilla Firefox oder Microsoft Edge) her. Diese muss separat erfolgen – das ist aber bereits der Fall, wenn normal mit dem Web-Client gearbeitet wird.
	Passwort	Passwort für oben genannte Datei. Dieses Passwort schützt keine schützenswerten Informationen, sondern wird von Java technisch erzwungen: "Eine Truststore-Datei benötigt ein Passwort."

Speicherort der initialen Einstellungen

Alle initialen Einstellungen werden in der configuration.bat  im Test-Studio Installationsverzeichnis gespeichert und können zentral für alle Anwender vorgegeben werden.

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).

Installation

Batch-Datei windowsIntegration\assignFileTypes.bat als Administrator ausführen.

Deinstallation

Batch-Datei windowsIntegration\removeFileTypes.bat als Administrator ausführen.

Registrieren mittels .reg -Datei

Über das Test-Studio kann eine .reg -Datei für die Dateityp-Verknüpfung erzeugt werden. Diese muss anschließend importiert bzw. per Client-Management-Lösung (z.B. Gruppenrichtlinie) verteilt werden.

Updates einspielen

Verteilung des Test-Studios mittels Windows-Client

Wird das Test-Studio mit dem Windows-Client ("Rich-Client") verteilt, so wird es im Rahmen der normalen CRM-Patchtes ebenfalls aktualisiert. Dann kann dieser Schritt übersprungen werden.

Um das Update so einfach wie möglich zu gestalten, gibt es ein Skript CURSOR_TestStudio_update.bat, das den Patchvorgang übernimmt.

Voraussetzungen für ein Update

• Das CURSOR-Test-Studio muss geschlossen sein.

Durchführen des Updates

• Die zip-Datei mit der neuen Version des CURSOR-Test-Studios in das Installationsverzeichnis des CURSOR-Test-Studios kopieren.
  

  

• Das Update mit CURSOR_TestStudio_update.bat starten.

Bis auf configuration.bat und eigene weitere Dateien werden alle Dateien ausgetauscht.

• Nach dem Update erhält die zip Datei den Präfix processed_ und wird beim nächsten Update nicht mehr benutzt. Um das Update mit dieser Datei erneut durchzuführen, ist der Präfix zu entfernen.

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.

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://chromedriver.chromium.org/downloads

• Mozilla Firefox: https://github.com/mozilla/geckodriver/releases

Anschließend muss der Pfad zur exe -Datei in der customSettings.properties  eingetragen werden, die unter %WORKING_DIR% (definiert in configuration.bat ) liegt:

teststudio.engine.driver.chrome=D:/my/path/to/driver.exe
teststudio.engine.driver.firefox=D:/my/path/to/driver.exe
teststudio.engine.driver.edge=D:/my/path/to/driver.exe

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 kann nur auf der Windows Plattform betrieben werden.

• Benutzereinstellungen können (noch) nicht zentral vorgegeben werden.

• 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 ebenfalls 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.