Installation unter Linux

Einführung

Die Empfehlungen aus Installation und Update gelten auch für Linux. Somit stellt dies lediglich eine Ergänzung dar.

Das Test-Studio unterstützt unter Linux nur den Batch-Betrieb (Aktualisierungen von WebDrivers und Testausführung), aber keine Bearbeitung von Testfällen oder Betrachtung von Reports in der graphischen Oberfläche.

Der Batch-Betrieb unterstützt headless-server, d.h. es ist kein X-Server (oder Wayland) erforderlich, um Tests ausführen zu können.

Initiale Einrichtung und Konfiguration

Nach dem Entpacken des zip-Archivs muss mittels chmod +x *.bash das executable-Flag auf allen Skripten gesetzt werden.

Für den Batch-Betrieb wird empfohlen, das WORKING_DIR auf einen absoluten Pfad zu setzen, der unabhängig vom aktuellen (Unix-)User ist:

configuration.conf

BASH

# ###########################################################################
# # Begin of user configuration
# ###########################################################################

# Path to Java 17 x64
JAVA_HOME=/usr

# Working directory used; e.g. webdrivers will be downloaded here.
WORKING_DIR=/opt/teststudio/workingdir # default: ~/.cursor/testStudio

# ###########################################################################
# # End of user configuration
# ###########################################################################

# Enable remote debug on port 5005 (true); anything else will disable it
DEBUG=false

# Custom Opts if required, for example:
# CUSTOM_OPTS='"-Dwebclient.guitest.coloredAjaxIndicator=true" "-DmyOtherProperty=value with spaces"'
CUSTOM_OPTS=

# If to true, the associated console window of the java runtime is shown.
SHOW_CONSOLE=false

# Admin override file path if required, for example:
# ADMIN_CONFIG_OVERRIDE=$WORKING_DIR%/local_admin_override.properties
ADMIN_CONFIG_OVERRIDE=

Ausführen von ./CURSOR_Test-Studio.bash , um das WORKING_DIR zu initialisieren. Danach Erstellen und Anpassen der Basis-Test-Studio-Einstellungen innerhalb des WORKING_DIR :

$WORKING_DIR/customSettings.properties

GROOVY

# Created during manual installation
teststudio.customizing.username=<user name>
teststudio.customizing.password=<obfuscated password>
teststudio.customizing.url=<webclient url>

teststudio.engine.browser=CHROME|FIREFOX|EDGE
teststudio.engine.headless=true
teststudio.engine.timeout.seconds=20

# Alle teststudio.integration Einstellungen sind optional, wenn keine Integration der Testergebnisse in ein CRM gewünscht ist.
teststudio.integration.crm.username=<user name>
teststudio.integration.crm.password=<obfuscated passwords>
teststudio.integration.crm.url=<webclient url>

teststudio.integration.shared.document.dir=<directory as seen by humans who will open the report file>
# optional
#teststudio.integration.shared.document.dir.as.accessible.path=<directory as seen by teststudio process during test execution>

Das "Gemeinsame Verzeichnis für Reports"

Die Einstellung teststudio.integration.shared.document.dir entspricht dem "Gemeinsames Verzeichnis für die Reports, die ins CRM geschrieben werden" aus den Einstellungen in der graphischen Benutzeroberfläche. Allerdings können hier (gerade unter Linux) einige Probleme auftreten:

Da die Report-Dateien als Dokumente vom Typ LINK in das CRM geschrieben werden, müssen diese aus Sicht des Anwenders (bzw. dessen Windows-PC) zugänglich sein. Typischerweise wird dies eine Netzwerkfreigabe sein (entweder als UNC-Pfad \\myserver\myreports oder als "Verbundenes Netzlaufwerk" mit einem Laufwerksbuchstaben). Diese Pfade sind unter Linux in der Regel nicht auflösbar, deshalb kann mittels teststudio.integration.shared.document.dir.as.accessible.path dasselbe Verzeichnis aus "Linux-Sicht" angegeben werden.

Das Konzept ist identisch zum Transferverzeichnis der Massendatenserienbriefe, das im Administrations-Handbuch des CRM im Abschnitt "Serienbriefe auf dem Massendatenserver" beschrieben wird.

Beispiel:

Verzeichnis /opt/teststudio/reports , das via SAMBA als SMB-Share unter \\teststudioserver\reports verfügbar gemacht wurde:

Das Test-Studio schreibt den Report der Testausführung in das Verzeichnis als /opt/teststudio/reports/TESTSTUDIO_<Datum>/report.teststudio_log
Der Anwender öffnet den Report über den Dokumenten-Datensatz über \\teststudioserver\reports\TESTSTUDIO_<Datum>/report.teststudio_log

Diese Szenario kann über folgende Konfiguration abgebildet werden:

CODE

teststudio.integration.shared.document.dir=\\\\teststudioserver\\reports
#teststudio.integration.shared.document.dir.as.accessible.path=/opt/teststudio/reports

Bei den Pfadangaben ist ein \ als \\ zu schreiben

Maskiertes Passwort erstellen

In der customSettings.properties muss das Passwort als "Verschleiertes Passwort" angegeben werden: Dieses kann in einem beliebigen Test-Studio aus dem Klartext-Passwort erzeugt werden.

Abschließend muss noch der passende WebDriver heruntergeladen werden: ./CURSOR_Test-Studio_batch update-driver.

TrustStore

Sollte ein eigener TrustStore erforderlich sein, muss dieser in der Datei truststore.conf im Installationsordner hinterlegt werden:

CODE

TRUSTSTORE_PATH=/path/to/jboss/truststore.p12
TRUSTSTORE_PASSWORD=cursor

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.conf` 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.
Truststore	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."

Regelmäßige Ausführung der Tests

Für die regelmäßige Ausführung werden systemd units unter systemd bereitgestellt. Nach der Anpassung erfolgt die Installation durch Kopieren nach /usr/local/lib/systemd/system/ .

Der dort konfigurierte User muss über ein beschreibbares Home-Verzeichnis verfügen. (Insbesondere sind über useradd --no-create-home erstellte User ungeeignet).

Die Timer müssen mittels

BASH

systemctl enable teststudio-execute-tests.timer
systemctl start teststudio-execute-tests.timer

bzw.

BASH

systemctl enable teststudio-update-driver.timer
systemctl start teststudio-update-driver.timer

aktiviert werden und können mit systemctl list-timers kontrolliert werden.

Updates des Test-Studios

Da das Client-Update-Tool nicht unter Linux verfügbar ist, muss das Test-Studio nach jedem Update oder Patch des CRMs manuell bzw. aktualisiert werden.