UI-testning ui-testing

Anpassad gränssnittstestning är en valfri funktion som gör att du kan skapa och automatiskt köra gränssnittstester för dina program.

Översikt custom-ui-testing

AEM innehåller en integrerad svit med Kvalitetsportar för Cloud Manager för smidiga uppdateringar av anpassade program. I synnerhet har IT-testportar redan stöd för att skapa och automatisera anpassade tester med AEM API:er.

Användargränssnittstester är paketerade i en Docker-bild för att ge ett brett val i språk och miljöer (som Cypress, Selenium, Java och Maven samt JavaScript). Ett UI-testprojekt kan också enkelt genereras med AEM Project Archetype.

Adobe uppmuntrar användningen av Cypress eftersom det ger realtidsladdning och automatisk väntetid, vilket sparar tid och förbättrar produktiviteten under testningen. Cypress har också en enkel och intuitiv syntax som gör det enkelt att lära sig och använda, även för dem som inte har testat tidigare.

Gränssnittstester utförs som en del av en viss kvalitetsgrind för varje Cloud Manager-pipeline med en Anpassade gränssnittstestningar steg in produktionsrörledningar eller valfritt rörledningar för icke-produktion. Alla gränssnittstester, inklusive regression och nya funktioner, gör att fel kan upptäckas och rapporteras.

Till skillnad från anpassade funktionstester, som är HTTP-tester skrivna i Java, kan gränssnittstester vara en dockningsbild med tester skrivna på vilket språk som helst, förutsatt att de följer konventionerna som definieras i avsnittet Skapar gränssnittstester.

Kom igång med gränssnittstester get-started-ui-tests

I det här avsnittet beskrivs stegen som krävs för att konfigurera gränssnittstester för körning i Cloud Manager.

Skapar gränssnittstester building-ui-tests

Ett Maven-projekt genererar ett Docker-byggsammanhang. I denna Docker build-kontext beskrivs hur du skapar en Docker-bild som innehåller gränssnittstester, som används i Cloud Manager för att generera en Docker-bild som innehåller de faktiska gränssnittstester.

I det här avsnittet beskrivs stegen som krävs för att lägga till ett UI-testprojekt i din databas.

Skapa en kontext för Docker Build generate-docker-build-context

För att skapa en Docker-byggkontext behöver du en Maven-modul som:

Det enklaste sättet att göra detta är att konfigurera Maven Assembly Plugin för att skapa kontextarkivet för Docker-bygget och tilldela rätt klassificerare till det.

Du kan skapa gränssnittstester med olika tekniker och ramverk, men i det här avsnittet förutsätts att ditt projekt är utformat på ett sätt som liknar följande.

├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│   ├── package.json
│   ├── index.js
│   └── wdio.conf.js
└── wait-for-grid.sh

The pom.xml filen tar hand om Maven-bygget. Lägg till en exekvering av Maven Assembly Plugin som liknar följande.

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

Den här exekveringen instruerar Maven Assembly Plugin att skapa ett arkiv baserat på instruktionerna i assembly-ui-test-docker-context.xml, som kallas sammansättningsbeskrivning i pluginens jargon. Sammansättningsbeskrivningen visar alla filer som måste ingå i arkivet.

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

Sammansättningsbeskrivningen instruerar plugin-programmet att skapa ett arkiv av typen .tar.gz och tilldelar ui-test-docker-context -klassificerare. Dessutom listas de filer som måste ingå i arkivet, inklusive följande:

Sammansättningsbeskrivningen utesluter också vissa filer som kan genereras när användargränssnittstesterna körs lokalt. Detta garanterar ett mindre arkiv och snabbare byggen.

Arkivet som innehåller Docker-byggkontexten hämtas automatiskt av Cloud Manager, som skapar Docker-bilden som innehåller testerna i samband med driftsättningen. Till slut körs Docker-avbildningen i Cloud Manager för att köra UI-testerna mot ditt program.

Bygget ska antingen producera noll eller ett arkiv. Om inga arkiv skapas godkänns teststeget som standard. Om bygget skapar mer än ett arkiv är det valda arkivet inte deterministiskt.

Kundens deltagande customer-opt-in

För att Cloud Manager ska kunna bygga och köra dina gränssnittstester måste du välja den här funktionen genom att lägga till en fil i databasen.

UI-testerna byggs och körningarna hoppas över om filen inte finns.

Ta med en testing.properties fil i build-artefakten, lägga till en include programsats i assembly-ui-test-docker-context.xml -fil.

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]

Om du använder exemplen från Adobe:

Skriver gränssnittstester writing-ui-tests

I det här avsnittet beskrivs de konventioner som Docker-bilden som innehåller dina gränssnittstester måste följa. Docker-bilden är inbyggd i Docker-konstruktionssammanhanget som beskrivs i föregående avsnitt.

Miljövariabler environment-variables

Följande miljövariabler skickas till din Docker-bild vid körning, beroende på ditt ramverk.

Provexemplen från Adobe ger hjälpfunktioner för att komma åt konfigurationsparametrarna:

Generera testrapporter generate-test-reports

Docker-bilden måste generera testrapporter i JUnit XML-format och spara dem i den sökväg som anges av systemvariabeln REPORTS_PATH. JUnit XML-formatet är ett format som ofta används för att rapportera testresultat. Om Docker-bilden använder Java och Maven, standardtestmoduler som Maven Surefire Plugin och Maven Failsafe Plugin kan generera sådana rapporter direkt.

Om Docker-bilden implementeras med andra programmeringsspråk eller testkörare bör du kontrollera i dokumentationen vilka verktyg som har valts för att skapa JUnit XML-rapporter.

Förutsättningar prerequisites

Selenumspecifik information

Väntar på att Selenium ska vara klart waiting-for-selenium

Innan testerna börjar är det dockningsbildens ansvar att säkerställa att Selenium-servern är igång. Att vänta på Selenium-tjänsten är en tvåstegsprocess.

När Seleniums statusendpoint svarar med ett positivt svar kan testerna börja.

Adobe UI-testexemplen hanterar detta med skriptet wait-for-grid.sh, som körs när Docker startar och startar den faktiska testkörningen först när rutnätet är klart.

Hämta skärmbilder och video capture-screenshots

Docker-bilden kan generera ytterligare testutdata (till exempel skärmbilder eller videoklipp) och spara dem i den sökväg som anges av systemvariabeln REPORTS_PATH. Alla filer som finns under REPORTS_PATH ingår i testresultatarkivet.

Testexemplen från Adobe skapar som standard skärmbilder för misslyckade tester.

Du kan använda hjälpfunktionerna för att skapa skärmbilder genom testerna.

Om ett testresultatarkiv skapas under en UI-testkörning kan du hämta det från Cloud Manager med Download Details knappen under Anpassade gränssnittstestningar steg.

Överför filer upload-files

Testerna ibland måste överföra filer till det program som testas. För att driftsättningen av Selenium ska vara flexibel i förhållande till dina tester går det inte att överföra en resurs direkt till Selenium. Om du vill överföra en fil måste du i stället utföra följande steg.

Köra gränssnittstester lokalt run-ui-tests-locally

Innan gränssnittstester aktiveras i en Cloud Manager-pipeline bör gränssnittstester köras lokalt mot AEM as a Cloud Service SDK eller mot en faktisk AEM as a Cloud Service instans.

Cypress-testexempel cypress-sample

JavaScript WebdriverIO-testexempel javascript-sample

Java Selenium WebDriver Test Sample java-sample