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.

Ökning custom-ui-testing

AEM tillhandahåller en integrerad svit med Cloud Manager-kvalitetsportar för att säkerställa 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 urval på språk och i miljöer (t.ex. Cypress, Selenium, Java och Maven och JavaScript). Ett UI-testprojekt kan också enkelt genereras med den AEM projekttypen.

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 körs som en del av en viss kvalitetsport för varje Cloud Manager-pipeline med ett anpassat gränssnittstestningsstegi produktionspipelinjer eller eventuellt icke-produktionspipelinjer . 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 Byggnadens gränssnittstester.

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

I det här avsnittet beskrivs de steg 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 UI-testerna, som Cloud Manager använder för att generera en Docker-bild som innehåller de faktiska UI-testerna.

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

Generera en Docker-byggkontext generate-docker-build-context

Om du vill generera en Docker-byggkontext behöver du en Maven-modul som:

Det enklaste sättet att göra detta är att konfigurera plugin-programmet Maven Assembly 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

Filen pom.xml 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 körningen instruerar Maven Assembly Plugin att skapa ett arkiv baserat på instruktionerna i assembly-ui-test-docker-context.xml, som kallas sammansättningsbeskrivare i plugin-programmets 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 klassificeraren ui-test-docker-context till det. 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 kommer att skapa en Docker-bild som innehåller testerna i samband med driftsättningen. Så småningom kommer Cloud Manager att köra Docker-bilden 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.

Om du vill inkludera en testing.properties-fil i build-artefakten lägger du till en include -sats i filen assembly-ui-test-docker-context.xml.

[...]
<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.

* these values will be empty if there is no publish instance

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

Generera testrapporter generate-test-reports

Docker-avbildningen måste generera testrapporter i JUnit XML-format och spara dem i den sökväg som anges av miljövariabeln 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 kan standardtestmoduler som Maven Surefire Plugin och Maven Failsafe Plugin generera sådana rapporter direkt från paketet.

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 statusslutpunkt svarar med ett positivt svar kan testerna starta.

Testexemplen för Adobe UI hanterar detta med skriptet wait-for-grid.sh, som körs när Docker startas 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 miljövariabeln REPORTS_PATH. Alla filer som hittas under REPORTS_PATH inkluderas 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 testkörning av ett användargränssnitt kan du hämta det från Cloud Manager med knappen Download Details under steget Anpassad användargränssnittstestning.

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

Cypressspecifik information

Konfigurera HTTP-proxy

Docker-behållarens ingångspunkt måste kontrollera värdet för miljövariabeln PROXY_HOST.

Om det här värdet är tomt behövs inga ytterligare steg och testerna ska köras utan HTTP-proxy.

Om det inte är tomt måste entrypoint-skriptet:

Ett exempel på implementering finns i Insättningspunkten för provmodulen Cypress på GitHub.

Uppspelningsspecifik information

Konfigurera HTTP-proxy

På liknande sätt som för Cypress måste tester använda HTTP-proxyn om en PROXY_HOST-miljövariabel som inte är tom anges.

För att göra detta måste följande ändringar göras.

Dockerfile

Installera cURL och libnss3-tools, som tillhandahåller certutil.

RUN apt -y update \
    && apt -y --no-install-recommends install curl libnss3-tools \
    && rm -rf /var/lib/apt/lists/*

Skript för ingångspunkt

Inkludera ett basskript som, om miljövariabeln PROXY_HOST anges, gör följande:

Exempel på implementering:

# setup proxy environment variables and CA certificate
if [ -n "${PROXY_HOST:-}" ]; then
  if [ -n "${PROXY_HTTPS_PORT:-}" ]; then
    export HTTP_PROXY="https://${PROXY_HOST}:${PROXY_HTTPS_PORT}"
  elif [ -n "${PROXY_HTTP_PORT:-}" ]; then
    export HTTP_PROXY="http://${PROXY_HOST}:${PROXY_HTTP_PORT}"
  fi
  if [ -n "${PROXY_CA_PATH:-}" ]; then
    echo "installing certificate"
    mkdir -p $HOME/.pki/nssdb
    certutil -d sql:$HOME/.pki/nssdb -A -t "CT,c,c" -n "EaaS Client Proxy Root" -i $PROXY_CA_PATH
    export NODE_EXTRA_CA_CERTS=${PROXY_CA_PATH}
  fi
  if [ -n "${PROXY_OBSERVABILITY_PORT:-}" ] && [ -n "${HTTP_PROXY:-}" ]; then
    echo "waiting for proxy"
    curl --silent  --retry ${PROXY_RETRY_ATTEMPTS:-3} --retry-connrefused --retry-delay ${PROXY_RETRY_DELAY:-10} \
      --proxy ${HTTP_PROXY} --proxy-cacert ${PROXY_CA_PATH:-""} \
      ${PROXY_HOST}:${PROXY_OBSERVABILITY_PORT}
    if [ $? -ne 0 ]; then
      echo "proxy is not ready"
      exit 1
    fi
  fi
fi

Playright configuration

Ändra konfigurationen för uppspelningsrättigheten (till exempel i playwright.config.js) så att en proxy används om miljövariabeln HTTP_PROXY anges.

Exempel på implementering:

const proxyServer = process.env.HTTP_PROXY || ''

// enable proxy if set
if (proxyServer !== '') {
 cfg.use.proxy = {
  server: proxyServer,
 }
}

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

Innan du aktiverar gränssnittstester i en Cloud Manager-pipeline rekommenderar vi att du kör gränssnittstesterna lokalt mot AEM as a Cloud Service SDK eller mot en faktisk AEM as a Cloud Service instans.

Cypress Test Prov cypress-sample

Exempel på JavaScript WebdriverIO-test javascript-sample

Exempel på test av uppspelningsrätt playwright-sample

Java Selenium WebDriver Test Sample java-sample