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:
![](../../../__attachments/38174751/image-20231122-180310.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
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 | ||
| 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 |
| |||||
| Verzeichnis, das den Workspace mit allen Testfällen und Testschrittbibliotheken enthält. Testfälle können in (beliebig tief verschachtelte) Unterordner sortiert werden. | ||||||
| Installationsverzeichnis des Test-Studios. Enthält grundlegende Konfiguration (u.a. Truststore). | ||||||
| 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. | ||||||
| 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.
![](../../../__attachments/38174751/image2020-3-6_8-39-17.png?inst-v=01ce9f95-f40d-424e-a7da-0f3a4bad5824)
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 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 derconfiguration.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.