Benutzerdefinierte UI-Tests sind eine optionale Funktion, mit der Sie Benutzeroberflächentests für Ihre Anwendungen erstellen und automatisch ausführen können.
AEM bietet eine integrierte Suite von Cloud Manager-Qualitätstests um eine reibungslose Aktualisierung benutzerdefinierter Programme zu gewährleisten. Insbesondere ermöglicht IT-Tests die bereits Erstellung und Automatisierung benutzerdefinierter Tests mithilfe von AEM-APIs.
Benutzeroberflächentests sind Selenium-basierte Tests, die in einem Docker-Image verpackt werden, um eine breite Auswahl an Sprachen und Frameworks zu ermöglichen (z. B. Java und Maven, Node und WebDriver.io oder alle anderen Frameworks und Technologien, die auf Selenium aufbauen). Zusätzlich kann ein UI-Test-Projekt einfach durch die Verwendung von den AEM Projektarchetyp.
UI-Tests werden als Teil eines bestimmten Qualitätstests für jede Cloud Manager-Pipeline mit einer dediziert Testen der benutzerdefinierten Benutzeroberfläche Schritt. Alle UI-Tests, einschließlich Regression und neuer Funktionen, ermöglichen die Erkennung und Meldung von Fehlern.
Im Gegensatz zu benutzerdefinierten Funktionstests, bei denen es sich um in Java geschriebene HTTP-Tests handelt, können UI-Tests ein Docker-Bild mit Tests sein, die in einer beliebigen Sprache geschrieben wurden, sofern sie den im Abschnitt definierten Konventionen entsprechen Erstellen von UI-Tests
Adobe empfiehlt, die in der Variablen AEM Projektarchetyp.
Damit Cloud Manager Ihre UI-Tests erstellen und ausführen kann, müssen Sie diese Funktion aktivieren, indem Sie eine Datei zu Ihrem Repository hinzufügen.
Der Dateiname muss testing.properties
lauten.
Der Dateiinhalt muss ui-tests.version=1
.
Die Datei muss sich für UI-Tests neben dem Maven-Untermodul befinden. pom.xml
-Datei des UI-Tests-Untermoduls.
Die Datei muss sich im Stammverzeichnis des erstellten tar.gz
-Datei.
Der Build und die Ausführungen der Benutzeroberflächentests werden übersprungen, wenn diese Datei nicht vorhanden ist.
So fügen Sie eine testing.properties
-Datei im Build-Artefakt ein include
-Anweisung assembly-ui-test-docker-context.xml
-Datei.
[...]
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
<include>testing.properties</include> <!- opt-in test module in Cloud Manager -->
</includes>
[...]
Wenn Ihr Projekt diese Zeile nicht enthält, müssen Sie die Datei bearbeiten, um UI-Tests zu aktivieren.
Die Datei kann eine Zeile enthalten, die darauf hinweist, sie nicht zu bearbeiten. Dies liegt daran, dass sie in Ihr Projekt eingeführt wurde, bevor Opt-in-UI-Tests eingeführt wurden und die des Kunden nicht dazu bestimmt war, die Datei zu bearbeiten. Dies kann ignoriert werden.
Ein Maven-Projekt generiert einen Docker-Build-Kontext. In diesem Docker-Build-Kontext wird beschrieben, wie Sie ein Docker-Bild erstellen, das die UI-Tests enthält und von den Cloud Manager-Benutzern ein Docker-Bild mit den tatsächlichen UI-Tests generieren kann.
In diesem Abschnitt werden die Schritte beschrieben, die zum Hinzufügen eines UI-Test-Projekts zu Ihrem Repository erforderlich sind.
Die AEM Projektarchetyp Sie können ein UI-Tests-Projekt erstellen, für das Sie keine speziellen Anforderungen an die Programmiersprache haben.
Um einen Docker-Build-Kontext zu generieren, benötigen Sie ein Maven-Modul, das:
Dockerfile
und jede andere Datei enthält, die zum Erstellen des Docker-Images mit Ihren Tests erforderlich ist.ui-test-docker-context
-Klassifikator markiert.Am einfachsten ist es, die Maven Assembly-Plugin , um das Docker-Build-Kontextarchiv zu erstellen und ihm den richtigen Klassifizierer zuzuweisen.
Sie können Benutzeroberflächentests mit verschiedenen Technologien und Frameworks erstellen. In diesem Abschnitt wird jedoch davon ausgegangen, dass Ihr Projekt ähnlich wie folgt aufgebaut ist.
├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│ ├── package.json
│ ├── index.js
│ └── wdio.conf.js
└── wait-for-grid.sh
Die pom.xml
-Datei übernimmt den Maven-Build. Fügen Sie dem Maven Assembly-Plug-in eine Ausführung hinzu, die der folgenden ähnelt.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Diese Ausführung weist das Maven Assembly-Plugin an, ein Archiv zu erstellen, das auf den Anweisungen in assembly-ui-test-docker-context.xml
, die Assemblydeskriptor im Jargon des Plug-ins. Der Assembly-Deskriptor listet alle Dateien auf, die Teil des Archivs sein müssen.
<assembly>
<id>ui-test-docker-context</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${basedir}</directory>
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
</includes>
</fileSet>
<fileSet>
<directory>${basedir}/test-module</directory>
<excludes>
<exclude>node/**</exclude>
<exclude>node_modules/**</exclude>
<exclude>reports/**</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
Der Assembly-Deskriptor weist das Plug-in an, ein Archiv des Typs .tar.gz
zu erstellen, und weist ihm den Klassifikator ui-test-docker-context
zu. Außerdem werden die Dateien aufgelistet, die im Archiv enthalten sein müssen, einschließlich der folgenden.
Dockerfile
, obligatorisch für das Erstellen des Docker-Imageswait-for-grid.sh
, dessen Zwecke unten beschrieben werdentest-module
implementiert wurdenDer Assembly-Deskriptor schließt auch einige Dateien aus, die beim lokalen Ausführen der Benutzeroberflächentests generiert werden könnten. Dies garantiert ein kleineres Archiv und schnellere Builds.
Das Archiv, das den Docker-Build-Kontext enthält, wird automatisch von Cloud Manager abgerufen, das das Docker-Bild erstellt, das Ihre Tests während der Implementierungs-Pipelines enthält. Schließlich führt Cloud Manager das Docker-Image aus, um die Benutzeroberflächentests für das Programm auszuführen.
Der Build sollte entweder 0 oder 1 Archiv erzeugen. Wenn keine Archive erzeugt werden, wird der Testschritt standardmäßig durchgeführt. Wenn der Build mehr als ein Archiv erzeugt, ist das ausgewählte Archiv nicht deterministisch.
In diesem Abschnitt werden die Konventionen beschrieben, denen das Docker-Image mit Ihren Benutzeroberflächentests folgen muss. Das Docker-Image basiert auf dem im vorherigen Abschnitt beschriebenen Docker-Build-Kontext.
Die folgenden Umgebungsvariablen werden zur Laufzeit an Ihr Docker-Image übergeben.
Variable | Beispiele | Beschreibung |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
Die URL des Selenium-Servers |
SELENIUM_BROWSER |
chrome |
Die vom Selenium-Server verwendete Browser-Implementierung |
AEM_AUTHOR_URL |
http://my-ip:4502/context-path |
Die URL der AEM-Autoreninstanz |
AEM_AUTHOR_USERNAME |
admin |
Der Benutzername, der bei der AEM Autoreninstanz angemeldet werden soll |
AEM_AUTHOR_PASSWORD |
admin |
Das Passwort für die Anmeldung bei der AEM-Autoreninstanz |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
Die URL der AEM-Veröffentlichungsinstanz |
AEM_PUBLISH_USERNAME |
admin |
Der Benutzername, der bei der AEM Veröffentlichungsinstanz angemeldet werden soll |
AEM_PUBLISH_PASSWORD |
admin |
Das Passwort für die Anmeldung bei der AEM-Veröffentlichungsinstanz |
REPORTS_PATH |
/usr/src/app/reports |
Der Pfad, in dem der XML-Bericht der Testergebnisse gespeichert werden muss |
UPLOAD_URL |
http://upload-host:9090/upload |
Die URL, unter der die Datei hochgeladen werden muss, um sie für Selenium zugänglich zu machen |
Bevor die Tests beginnen, muss das Docker-Image sicherstellen, dass der Selenium-Server betriebsbereit ist. Das Warten auf den Selenium-Service erfolgt in zwei Schritten.
SELENIUM_BASE_URL
.Sobald der Status-Endpunkt von Selenium mit einer positiven Antwort antwortet, können die Tests beginnen.
Das Docker-Image muss Testberichte im JUnit-XML-Format generieren und in dem von der Umgebungsvariablen REPORTS_PATH
angegebenen Pfad speichern. Das JUnit XML-Format ist ein häufig verwendetes Format für die Berichterstellung über die Testergebnisse. Wenn das Docker-Bild Java und Maven verwendet, werden Standardtestmodule wie Maven Surefire-Plug-in und Maven Failsafe-Plug-in kann solche Berichte standardmäßig generieren.
Wenn das Docker-Bild mit anderen Programmiersprachen oder Test-Läufern implementiert ist, finden Sie in der Dokumentation die ausgewählten Tools zum Generieren von JUnit XML-Berichten.
Tests müssen manchmal Dateien in die getestete Anwendung hochladen. Um die Bereitstellung von Selenium relativ zu Ihren Tests flexibel zu halten, ist es nicht möglich, ein Asset direkt in Selenium hochzuladen. Stattdessen sind für das Hochladen einer Datei die folgenden Schritte erforderlich.
UPLOAD_URL
angegebenen URL hoch.
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
.200 OK
-Antwort vom Typ text/plain
zurück.
<input>
-Element anstelle eines Dateipfads verwenden, um das Hochladen von Dateien in Ihrem Programm zu testen.