Pruebas de IU ui-testing

La prueba de IU personalizada es una característica opcional que le permite crear y ejecutar automáticamente pruebas de IU para sus aplicaciones.

Información general custom-ui-testing

AEM ofrece un conjunto integrado de Puertas de calidad de Cloud Manager para garantizar actualizaciones sin problemas en las aplicaciones personalizadas. En concreto, las puertas de pruebas de TI ya admiten la creación y automatización de pruebas personalizadas mediante las API de AEM.

Las pruebas de IU se empaquetan en una imagen Docker para permitir una amplia variedad de lenguajes y marcos de trabajo (como Cypress, Selenium, Java y Maven, y JavaScript). Además, se puede generar fácilmente un proyecto de pruebas de interfaz de usuario utilizando AEM El arquetipo del proyecto de la.

El Adobe fomenta el uso de Cypress, ya que ofrece recarga en tiempo real y espera automática, lo que ayuda a ahorrar tiempo y mejora la productividad durante las pruebas. Cypress también proporciona una sintaxis sencilla e intuitiva, lo que facilita el aprendizaje y el uso, incluso para aquellos que son nuevos en las pruebas.

Las pruebas de la IU se ejecutan como parte de una puerta de calidad específica para cada canalización de Cloud Manager con una fase de Pruebas de IU personalizadas en canalizaciones de producción u opcionalmente canalizaciones que no sean de producción. Cualquier prueba de la IU, incluidas la regresión y las nuevas funcionalidades, permite detectar y notificar errores.

A diferencia de las pruebas funcionales personalizadas, que son pruebas HTTP escritas en Java, las pruebas de interfaz de usuario pueden ser una imagen de Docker con pruebas escritas en cualquier lenguaje, siempre y cuando sigan las convenciones definidas en la sección Generar pruebas de IU.

TIP
Adobe recomienda utilizar Cypress para las pruebas de IU, siguiendo el código proporcionado en el Repositorio de ejemplos de prueba de AEM.
Adobe también proporciona ejemplos del módulo de prueba de la IU basados en JavaScript con WebdriverIO (consulte el Tipo de archivo del proyecto AEM) y Java con WebDriver (consulte el Repositorio de ejemplos de prueba de AEM).

Introducción a las pruebas de IU get-started-ui-tests

En esta sección se describen los pasos necesarios para configurar las pruebas de IU para la ejecución en Cloud Manager.

  1. Decida el lenguaje de programación que desea utilizar.

  2. Asegúrese de que las pruebas de IU estén activadas según la sección Inclusión del cliente de este documento.

  3. Desarrolle sus casos de prueba y ejecute las pruebas localmente.

  4. Confirme su código en el repositorio de Cloud Manager y ejecute una canalización de Cloud Manager.

Generar pruebas de interfaz de usuario building-ui-tests

Un proyecto de Maven genera un contexto de generación de Docker. Este contexto de generación de Docker describe cómo crear una imagen de Docker que contenga las pruebas de IU, que Cloud Manager usa para generar una imagen de Docker que contenga las pruebas de IU reales.

En esta sección se describen los pasos necesarios para agregar un proyecto de pruebas de interfaz de usuario al repositorio.

TIP
El Arquetipo de proyecto de AEM puede generar un proyecto de pruebas de IU que cumpla con la siguiente descripción, si no tiene requisitos especiales para el lenguaje de programación.

Generar un contexto de generación de Docker generate-docker-build-context

Para generar un contexto de generación de Docker, necesita un módulo de Maven que:

  • Produzca un archivo que contenga un Dockerfile y todos los demás archivos necesarios para generar la imagen Docker con sus pruebas.
  • Etiqueta el archivo con el clasificador ui-test-docker-context.

La forma más sencilla de hacerlo es configurar el Complemento de Maven Assembly para crear el archivo de contexto de generación de Docker y asignarle el clasificador adecuado.

Puede crear pruebas de interfaz de usuario con diferentes tecnologías y marcos de trabajo, pero en esta sección se da por hecho que el diseño del proyecto es similar al siguiente.

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

El archivo pom.xml se encarga de la generación de Maven. Agregue una ejecución al complemento de Maven Assembly similar a la siguiente.

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

Esta ejecución ordena al complemento de Maven Assembly que cree un archivo basado en las instrucciones contenidas en assembly-ui-test-docker-context.xml, se denomina descriptor de ensamblado en la jerga del complemento. El descriptor de ensamblado enumera todos los archivos que deben formar parte del archivo.

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

El descriptor de ensamblado indica al complemento que cree un archivo de tipo .tar.gz y asigna el clasificador ui-test-docker-context para él. Además, enumera los archivos que deben incluirse en el archivo, incluidos los siguientes:

  • Un Dockerfile, obligatorio para crear la imagen Docker
  • El script wait-for-grid.sh, cuyos propósitos se describen a continuación
  • Las pruebas de interfaz de usuario reales, implementadas por un proyecto Node.js en la carpeta test-module

El descriptor de ensamblado también excluye algunos archivos que podrían generarse al ejecutar las pruebas de IU localmente. Esto garantiza un archivo más pequeño y generaciones más rápidas.

El archivo que contiene el contexto de generación de Docker se recoge automáticamente en Cloud Manager, que creará la imagen de Docker que contiene las pruebas durante sus canalizaciones de implementación. Al final, Cloud Manager ejecutará la imagen de Docker para ejecutar las pruebas de interfaz de usuario contra la aplicación.

La generación debe producir ningún o un archivo. Si no genera ningún archivo, el paso de prueba se aprobará de forma predeterminada. Si la generación produce más de un archivo, qué archivo se seleccione no es determinista.

Inclusión del cliente customer-opt-in

Para que Cloud Manager pueda generar y ejecutar sus pruebas de IU, debe incluirse en esta funcionalidad al agregar un archivo al repositorio.

  • El nombre del archivo debe ser testing.properties.
  • El contenido del archivo debe ser ui-tests.version=1.
  • El archivo debe estar en el módulo secundario de Maven para pruebas de IU junto al archivo pom.xml del módulo secundario de pruebas de IU.
  • El archivo debe estar en la raíz del archivo de generación tar.gz.

La generación de pruebas de interfaz de usuario y las ejecuciones se omite si este archivo no está presente.

Para incluir un archivo testing.properties en el artefacto de generación, agregue un enunciado include en el assembly-ui-test-docker-context.xml archivo.

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]
NOTE
Si el proyecto no incluye esta línea, edite el archivo para optar por la prueba de IU.
El archivo puede contener una línea que aconseje no editarlo. Esto se debe a que se introdujo en el proyecto antes de que se introdujera la prueba de IU de inclusión y los clientes no tenían la intención de editar el archivo. Se puede ignorar con seguridad.

Si está utilizando las muestras proporcionadas por Adobe:

  • Para la carpeta basada en JavaScript ui.tests generada a partir del Arquetipo de proyecto de AEM, puede ejecutar el siguiente comando y añadir la configuración necesaria.

    code language-shell
    echo "ui-tests.version=1" > testing.properties
    
    if ! grep -q "testing.properties" "assembly-ui-test-docker-context.xml"; then
      awk -v line='                <include>testing.properties</include>' '/<include>wait-for-grid.sh<\/include>/ { printf "%s\n%s\n", $0, line; next }; 1' assembly-ui-test-docker-context.xml > assembly-ui-test-docker-context.xml.new && mv assembly-ui-test-docker-context.xml.new assembly-ui-test-docker-context.xml
    fi
    
  • Las muestras de prueba de Cypress y Java Selenium proporcionadas por Adobe ya tienen el indicador de inclusión establecido.

Escribir pruebas de interfaz de usuario writing-ui-tests

En esta sección se describen las convenciones que debe seguir la imagen de Docker que contiene las pruebas de IU. La imagen Docker se crea a partir del contexto de generación de Docker descrito en la sección anterior.

Variables de entorno environment-variables

Las siguientes variables de entorno se pasan a la imagen de Docker en tiempo de ejecución, en función del marco de trabajo.

Variable
Ejemplos
Descripción
Marco trabajo de prueba
SELENIUM_BASE_URL
http://my-ip:4444
La URL del servidor de Selenium
Solo Selenium
SELENIUM_BROWSER
chrome
La implementación del explorador que utiliza el servidor de Selenium
Solo Selenium
AEM_AUTHOR_URL
http://my-ip:4502/context-path
La dirección URL de la instancia de autor de AEM
Todos
AEM_AUTHOR_USERNAME
admin
El nombre de usuario para iniciar sesión en la instancia de creación de AEM
Todos
AEM_AUTHOR_PASSWORD
admin
La contraseña para iniciar sesión en la instancia de creación de AEM
Todos
AEM_PUBLISH_URL
http://my-ip:4503/context-path
La URL de la instancia de publicación de AEM
Todos
AEM_PUBLISH_USERNAME
admin
El nombre de usuario para iniciar sesión en la instancia de publicación de AEM
Todos
AEM_PUBLISH_PASSWORD
admin
AEM Contraseña para iniciar sesión en la instancia de publicación de la
Todos
REPORTS_PATH
/usr/src/app/reports
La ruta en la que se debe guardar el informe XML de los resultados de la prueba
Todos
UPLOAD_URL
http://upload-host:9090/upload
Dirección URL donde se debe cargar el archivo para que sea accesible para el marco de prueba
Todos
PROXY_HOST
proxy-host
El nombre de host del proxy HTTP interno que se utilizará en el marco de prueba
Todos excepto Selenium
PROXY_HTTPS_PORT
8071
El puerto de escucha del servidor proxy para conexiones HTTPS (puede estar vacío)
Todos excepto Selenium
PROXY_HTTP_PORT
8070
El puerto de escucha del servidor proxy para conexiones HTTP (puede estar vacío)
Todos excepto Selenium
PROXY_CA_PATH
/path/to/root_ca.pem
Ruta al certificado de CA que utilizará el marco de pruebas
Todos excepto Selenium
PROXY_OBSERVABILITY_PORT
8081
El puerto de comprobación de estado HTTP del servidor proxy
Todos excepto Selenium
PROXY_RETRY_ATTEMPTS
12
Número sugerido de reintentos mientras se espera la preparación del servidor proxy
Todos excepto Selenium
PROXY_RETRY_DELAY
5
Retraso sugerido entre reintentos mientras se espera la preparación del servidor proxy
Todos excepto Selenium

Las muestras de prueba de Adobe proporcionan funciones de ayuda para acceder a los parámetros de configuración:

  • Cypress: utilizar la función estándar Cypress.env('VARIABLE_NAME')
  • JavaScript: consulte la lib/config.js módulo
  • Java: Consulte la Config clase

Generar informes de prueba generate-test-reports

La imagen Docker debe generar informes de prueba en formato XML JUnit y guardarlos en la ruta especificada por la variable de entorno REPORTS_PATH. El formato JUnit XML es un formato ampliamente utilizado para la creación de informes sobre los resultados de las pruebas. Si la imagen Docker utiliza Java y Maven, los módulos de prueba estándar como el complemento de Maven Surefire y el complemento de Maven Failesafe pueden generar estos informes de forma predeterminada.

Si la imagen Docker está implementada con otros lenguajes de programación o ejecutores de prueba, compruebe la documentación de las herramientas seleccionadas para generar informes XML de JUnit.

NOTE
El resultado del paso de prueba de la IU solo se evalúa en función de los informes de prueba. Asegúrese de generar el informe correspondiente para la ejecución de la prueba.
Utilice aserciones en lugar de registrar un error en STDERR o devolver un código de salida distinto de cero; para que la canalización de implementación pueda continuar normalmente.
Si se ha utilizado un proxy HTTP durante la ejecución de las pruebas, los resultados incluirán un request.log archivo.

Requisitos previos prerequisites

  • Las pruebas en Cloud Manager se ejecutan con un usuario administrador técnico.
NOTE
Para ejecutar las pruebas funcionales desde el equipo local, cree un usuario con permisos de tipo administrador para lograr el mismo comportamiento.
  • La infraestructura contenerizada que se contempla para las pruebas funcionales está limitada por los siguientes límites:
Tipo
Valor
Descripción
CPU
2.0
Cantidad de tiempo de CPU reservado por ejecución de prueba.
Memoria
1Gi
Cantidad de memoria asignada a la prueba, valor en gibibytes.
Tiempo de espera
30m
Duración tras la cual finaliza la prueba.
Duración recomendada
15m
Adobe recomienda escribir las pruebas para que no tarden más de este tiempo.
NOTE
Si necesita más recursos, cree un caso del Servicio de atención al cliente y describa su caso de uso; Adobe revisará su solicitud y le proporcionará la asistencia adecuada.

Detalles específicos de Selenium

NOTE
Esta sección solo se aplica cuando Selenium es la infraestructura de prueba elegida.

Esperando a que Selenium esté listo waiting-for-selenium

Antes de que comiencen las pruebas, es responsabilidad de la imagen Docker asegurarse de que el servidor Selenium funcione. Esperar por el servicio de Selenium es un proceso de dos pasos.

  1. Lea la URL del servicio de Selenium desde la SELENIUM_BASE_URL variable de entorno.
  2. Encuesta a intervalos regulares al extremo de estado expuesto por la API de Selenium.

Una vez que el extremo de estado de Selenium dé una respuesta positiva, las pruebas podrán comenzar.

Las muestras de prueba de la IU de Adobe lo gestionan con el script wait-for-grid.sh, que se ejecuta al abrir Docker e inicia la ejecución de prueba real solo cuando la cuadrícula está lista.

Captura de pantallas y vídeos capture-screenshots

La imagen del Docker puede generar resultados de prueba adicionales (por ejemplo, capturas de pantalla o vídeos) y guardarlos en la ruta especificada por la variable de entorno REPORTS_PATH. Cualquier archivo que se encuentre debajo de REPORTS_PATH se incluirá en el archivo de resultados de la prueba.

Las muestras de prueba proporcionadas por Adobe de forma predeterminada crean capturas de pantalla para cualquier prueba fallida.

Puede utilizar las funciones de ayuda para crear capturas de pantalla a través de las pruebas.

Si se crea un archivo de resultados durante la ejecución de una prueba de IU, puede descargarlo desde Cloud Manager mediante el botón Download Details, debajo del paso Pruebas de IU personalizadas.

Cargar archivos upload-files

Las pruebas a veces deben cargar archivos en la aplicación que se está probando. Para que la implementación de Selenium sea flexible con respecto a sus pruebas, no es posible cargar directamente un recurso a Selenium. En su lugar, la carga de un archivo requiere los siguientes pasos.

  1. Cargue el archivo en la dirección URL especificada por la UPLOAD_URL variable de entorno.

    • La carga debe realizarse en una solicitud de POST con un formulario de varias partes.

    • El formulario de varias partes debe tener un único campo de archivo.

    • Esto equivale a curl -X POST ${UPLOAD_URL} -F "data=@file.txt".

    • Consulte la documentación y las bibliotecas del lenguaje de programación utilizado en la imagen Docker para saber cómo realizar una solicitud HTTP de este tipo.

    • Las muestras de prueba de Adobe proporcionan funciones de ayuda para la carga de archivos:

  2. Si la carga se realiza correctamente, la solicitud devolverá una 200 OK respuesta del tipo text/plain.

    • El contenido de la respuesta es un controlador de archivo opaco.
    • Puede utilizar este identificador en lugar de una ruta de archivo en un elemento <input> para probar la carga de archivos en la aplicación.

Detalles específicos de Cypress

NOTE
Esta sección solo se aplica cuando Cypress es la infraestructura de prueba elegida.

Configuración del proxy HTTP

El punto de entrada del contenedor Docker debe comprobar el valor del PROXY_HOST variable de entorno.

Si este valor está vacío, no se requieren pasos adicionales y las pruebas deben ejecutarse sin utilizar el proxy HTTP.

Si no está vacío, el script de punto de entrada debe hacer lo siguiente:

  1. Configure una conexión proxy HTTP para ejecutar pruebas de interfaz de usuario. Esto se puede lograr exportando el HTTP_PROXY variable de entorno creada con los siguientes valores:

    • Host de proxy proporcionado por PROXY_HOST variable
    • Puerto Proxy, proporcionado por PROXY_HTTPS_PORT o PROXY_HTTP_PORT (se utilizará la variable con un valor que no esté vacío)
  2. Establezca el certificado de CA que se utilizará al conectarse al proxy HTTP. Su ubicación la proporciona PROXY_CA_PATH variable.

    • Esto se puede lograr exportando NODE_EXTRA_CA_CERTS variable de entorno.
  3. Espere hasta que el proxy HTTP esté listo.

    • Para comprobar la preparación, las variables de entorno PROXY_HOST, PROXY_OBSERVABILITY_PORT, PROXY_RETRY_ATTEMPTS y PROXY_RETRY_DELAY se puede utilizar.
    • Puede comprobarlo utilizando una solicitud cURL, asegurándose de instalar cURL en su Dockerfile.

Se puede encontrar una implementación de ejemplo en el punto de entrada del módulo de prueba de muestra de Cypress en GitHub.

Detalles específicos del dramaturgo

NOTE
Esta sección solo se aplica cuando Playwright es la infraestructura de prueba elegida.

Configuración del proxy HTTP

NOTE
En los ejemplos presentados, suponemos que Chrome se está utilizando como explorador de proyectos.

Al igual que Cypress, las pruebas deben utilizar el proxy HTTP si no está vacío PROXY_HOST se proporciona la variable de entorno.

Para ello, es necesario realizar las siguientes modificaciones.

Dockerfile

Instalar cURL y libnss3-tools, que proporciona certutil.

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

Script Entrypoint

Incluir un script bash que, en caso de PROXY_HOST Cuando se proporciona una variable de entorno, hace lo siguiente:

  1. Exportar variables relacionadas con proxy como HTTP_PROXY y NODE_EXTRA_CA_CERTS
  2. Uso certutil para instalar el certificado de CA proxy para chromium
  3. Espere hasta que el proxy HTTP esté listo (o salga si hay algún error).

Ejemplo de implementación:

# 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

Configuración del dramaturgo

Modifique la configuración del autor (por ejemplo, en playwright.config.js) para utilizar un proxy en caso de que el HTTP_PROXY variable de entorno está configurada.

Ejemplo de implementación:

const proxyServer = process.env.HTTP_PROXY || ''
// enable proxy if set
if (proxyServer !== '') {
 cfg.use.proxy = {
  server: proxyServer,
 }
}

Ejecución de pruebas de IU locales run-ui-tests-locally

Antes de activar pruebas de IU en una canalización de Cloud Manager, se recomienda ejecutar las pruebas de IU localmente en el SDK de AEM as a Cloud Service o en una instancia de AEM as a Cloud Service real.

Ejemplo de prueba de Cypress cypress-sample

  1. Abra un elemento shell y vaya a la carpeta ui.tests/test-module de su repositorio

  2. Instalar Cypress y otros requisitos previos

    code language-shell
    npm install
    
  3. Establecer las variables de entorno necesarias para la ejecución de pruebas

    code language-shell
    export AEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com
    export AEM_AUTHOR_USERNAME=<user>
    export AEM_AUTHOR_PASSWORD=<password>
    export AEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com
    export AEM_PUBLISH_USERNAME=<user>
    export AEM_PUBLISH_PASSWORD=<password>
    export REPORTS_PATH=target/
    
  4. Ejecute las pruebas con uno de los siguientes comandos

    code language-shell
    npm test              # Using default Cypress browser
    npm run test-chrome   # Using Google Chrome browser
    npm run test-firefox  # Using Firefox browser
    
NOTE
Los archivos de registro se almacenan en la carpeta target/ del repositorio.
Para obtener más información, consulte el repositorio de Muestras de pruebas de AEM.

Muestra de prueba de WebdriverIO de JavaScript javascript-sample

  1. Abra un elemento shell y vaya a la carpeta ui.tests de su repositorio

  2. Ejecute el siguiente comando para iniciar las pruebas con Maven

    code language-shell
    mvn verify -Pui-tests-local-execution \
     -DAEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com \
     -DAEM_AUTHOR_USERNAME=<user> \
     -DAEM_AUTHOR_PASSWORD=<password> \
     -DAEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \
     -DAEM_PUBLISH_USERNAME=<user> \
     -DAEM_PUBLISH_PASSWORD=<password>
    
NOTE
  • Esto inicia una instancia de Selenium independiente y ejecuta las pruebas correspondientes.
  • Los archivos de registro se almacenan en la carpeta target/reports de su repositorio
  • Debe asegurarse de que tiene la última versión de Chrome, ya que la prueba descarga la última versión de ChromeDriver automáticamente para realizar pruebas.
Para obtener más información, consulte el repositorio de Tipo de archivo del proyecto de AEM.

Ejemplo de prueba de Java Selenium WebDriver java-sample

  1. Abra un elemento shell y vaya a la carpeta ui.tests/test-module de su repositorio

  2. Ejecute el siguiente comando para iniciar las pruebas con Maven

    code language-shell
    # Start selenium docker image (for x64 CPUs)
    docker run --platform linux/amd64 -d -p 4444:4444 selenium/standalone-chrome-debug:latest
    
    # Start selenium docker image (for ARM CPUs)
    docker run -d -p 4444:4444 seleniarm/standalone-chromium
    
    # Run the tests using the previously started Selenium instance
    mvn verify -Pui-tests-local-execution -DSELENIUM_BASE_URL=http://<server>:4444
    
NOTE
Los archivos de registro se almacenan en la carpeta target/reports del repositorio.
Para obtener más información, consulte el Repositorio de muestras de pruebas de AEM.
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab