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
# ###########################################################################
# # 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
# 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 der 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_logDer Anwender öffnet den Report über den Dokumenten-Datensatz über
\\teststudioserver\reports\TESTSTUDIO_<Datum>/report.teststudio_log
Diese Szenario kann über folgende Konfiguration abgebildet werden:
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.
Sollte ein eigener TrustStore erforderlich sein, muss dieser in der Datei truststore.conf in Installationsordner hinterlegt werden:
TRUSTSTORE_PATH=/path/to/jboss/truststore.p12
TRUSTSTORE_PASSWORD=cursorRegelmäß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
systemctl enable teststudio-execute-tests.timer
systemctl start teststudio-execute-tests.timerbzw.
systemctl enable teststudio-update-driver.timer
systemctl start teststudio-update-driver.timeraktiviert werden und können mit systemctl list-timers kontrolliert werden.