UI 테스트 ui-testing

사용자 정의 UI 테스트는 애플리케이션에 대한 UI 테스트를 만들고 자동으로 실행할 수 있는 선택적 기능입니다.

개요 custom-ui-testing

AEM은 사용자 정의 애플리케이션에 대한 원활한 업데이트를 보장하기 위해 통합된 Cloud Manager 품질 게이트 제품군을 제공합니다 특히 IT 테스트 게이트는 이미 AEM API를 사용한 사용자 정의 테스트의 만들기 및 자동화를 지원합니다.

UI 테스트는 언어 및 프레임워크(예: Cypress, Selenium, Java 및 Maven, JavaScript)에서 다양한 선택을 허용하도록 Docker 이미지에 패키징되어 있습니다. 또한 AEM Project Archetype.을(를) 사용하여 UI 테스트 프로젝트를 쉽게 생성할 수 있습니다.

Adobe는 실시간 리로딩 및 자동 대기 기능을 제공하여 테스트 중 시간을 절약하고 생산성을 향상시키는 데 도움이 되는 Cypress의 사용을 권장합니다. 또한 Cypress는 간단하고 직관적인 구문을 제공하므로 테스트를 처음 접하는 사용자도 쉽게 배우고 사용할 수 있습니다.

UI 테스트는 프로덕션 파이프라인 ​의사용자 정의 UI 테스트 단계를 통해 또는 선택적으로 비프로덕션 파이프라인의 같은 단계를 통해 각 Cloud Manager 파이프라인에 대한 특정 품질 게이트의 일부로 실행됩니다. 회귀 및 새로운 기능을 포함한 모든 UI 테스트를 통해 오류를 감지 및 보고할 수 있습니다.

Java로 작성된 HTTP 테스트인 사용자 정의 기능 테스트와 달리 UI 테스트는 UI 테스트 빌드 섹션에 정의된 컨벤션을 따르는 한 어떤 언어로든 작성할 수 있는 테스트가 담긴 Docker 이미지입니다.

UI 테스트 시작하기 get-started-ui-tests

이 섹션에서는 Cloud Manager에서 실행할 UI 테스트를 설정하는 데 필요한 단계를 설명합니다.

UI 테스트 빌드 building-ui-tests

Maven 프로젝트는 Docker 빌드 컨텍스트를 생성합니다. 이 Docker 빌드 컨텍스트는 UI 테스트가 포함된 Docker 이미지(Cloud Manager에서 이를 사용해 실제 UI 테스트가 포함된 Docker 이미지를 생성)를 만드는 방법을 설명합니다.

이 섹션에서는 UI 테스트 프로젝트를 저장소에 추가하는 데 필요한 단계를 설명합니다.

Docker 빌드 컨텍스트 생성 generate-docker-build-context

Docker 빌드 컨텍스트를 생성하려면 다음 작업을 수행하는 Maven 모듈이 필요합니다.

이를 수행하는 가장 간단한 방법은 Docker 빌드 컨텍스트 아카이브를 만들고 여기에 올바른 분류자를 할당하도록 Maven 어셈블리 플러그인을 구성하는 것입니다.

다양한 기술과 프레임워크를 사용하여 UI 테스트를 빌드할 수 있지만 이 섹션에서는 프로젝트가 다음과 유사한 방식으로 배치되어 있다고 가정합니다.

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

pom.xml 파일은 Maven 빌드를 처리합니다. 다음과 유사한 Maven 어셈블리 플러그인에 실행을 추가합니다.

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

이 실행은 Maven 어셈블리 플러그인이 플러그인 전문 용어로 어셈블리 설명자 ​라고 하는 assembly-ui-test-docker-context.xml에 포함된 지침을 기반으로 아카이브를 생성하도록 지시합니다. 어셈블리 설명자는 아카이브의 일부여야 하는 모든 파일을 나열합니다.

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

어셈블리 설명자는 플러그인에 .tar.gz 유형의 아카이브를 생성하고 ui-test-docker-context 분류자를 할당하도록 지시합니다. 또한 다음을 포함하여 아카이브에 포함해야 하는 파일을 나열합니다.

어셈블리 설명자는 UI 테스트를 로컬에서 실행하는 동안 생성될 수 있는 일부 파일도 제외합니다. 이를 통해 아카이브 크기는 작아지고 빌드 속도는 빨라집니다.

Docker 빌드 컨텍스트가 포함된 아카이브는 Cloud Manager에 의해 자동으로 선택되며, Cloud Manager는 배포 파이프라인 중에 테스트가 포함된 Docker 이미지를 빌드합니다. 결국 Cloud Manager는 Docker 이미지를 실행하여 애플리케이션에 대한 UI 테스트를 실행합니다.

빌드는 0개 또는 1개의 아카이브를 생성해야 합니다. 아카이브가 생성되지 않으면 테스트 단계가 기본적으로 통과합니다. 빌드가 둘 이상의 아카이브를 생성하는 경우 선택되는 아카이브는 비결정적입니다.

고객 옵트인 customer-opt-in

Cloud Manager가 UI 테스트를 빌드하고 실행하려면 저장소에 파일을 추가하여 이 기능을 선택해야 합니다.

이 파일이 없으면 UI 테스트 빌드 및 실행을 건너뜁니다.

빌드 아티팩트에 testing.properties 파일을 포함하려면 assembly-ui-test-docker-context.xml 파일에 include 문을 추가합니다.

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

Adobe에서 제공하는 샘플을 사용하는 경우 다음을 참조하십시오.

UI 테스트 작성 writing-ui-tests

이 섹션에서는 UI 테스트가 포함된 Docker 이미지가 따라야 하는 규칙에 대해 설명합니다. Docker 이미지는 이전 섹션에서 설명한 Docker 빌드 컨텍스트에서 빌드됩니다.

환경 변수 environment-variables

다음 환경 변수는 프레임워크에 따라 런타임 시 Docker 이미지로 전달됩니다.

Adobe 테스트 샘플은 구성 매개변수에 액세스하기 위한 도우미 기능을 제공합니다.

테스트 보고서 생성 generate-test-reports

Docker 이미지는 JUnit XML 형식으로 테스트 보고서를 생성하고 환경 변수 REPORTS_PATH에 지정된 경로에 저장해야 합니다. JUnit XML 형식은 테스트 결과를 보고하는 데 널리 사용되는 형식입니다. Docker 이미지가 Java 및 Maven을 사용하는 경우 Maven Surefire 플러그인 및 Maven Failsafe 플러그인과 같은 표준 테스트 모듈은 즉시 이러한 보고서를 생성할 수 있습니다

Docker 이미지가 다른 프로그래밍 언어 또는 테스트 실행자로 구현된 경우 선택한 도구에 대한 설명서에서 JUnit XML 보고서를 생성하는 방법을 확인하십시오.

사전 요구 사항 prerequisites

Selenium 관련 세부 정보

Selenium이 준비될 때까지 대기 waiting-for-selenium

테스트가 시작되기 전에 Selenium 서버가 실행 중인지 확인하는 것은 Docker 이미지의 책임입니다. Selenium 서비스 대기는 2단계 프로세스입니다.

Selenium의 상태 엔드포인트가 긍정 응답을 보내면 테스트를 시작할 수 있습니다.

Adobe UI 테스트 샘플은 wait-for-grid.sh 스크립트로 이를 처리하며, 해당 스크립트는 Docker 시작 시 실행되어 그리드가 준비된 후에만 실제 테스트 실행을 시작합니다.

스크린샷 및 비디오 캡처 capture-screenshots

Docker 이미지는 추가 테스트 출력(예: 스크린샷 또는 비디오)을 생성하고 환경 변수 REPORTS_PATH에 의해 지정된 경로에 저장할 수 있습니다. REPORTS_PATH 아래에 있는 모든 파일은 테스트 결과 아카이브에 포함됩니다.

기본적으로 Adobe에서 제공하는 테스트 샘플은 실패한 테스트에 대한 스크린샷을 만듭니다.

도우미 기능을 사용하여 테스트를 통해 스크린샷을 만들 수 있습니다.

UI 테스트 실행 중 테스트 결과 아카이브가 만들어지면 Cloud Manager에서 사용자 정의 UI 테스트 단계 아래의 Download Details 버튼을 사용해 아카이브를 다운로드할 수 있습니다.

파일 업로드 upload-files

경우에 따라 테스트 중인 애플리케이션에 파일을 업로드해야 합니다. 테스트에 비해 Selenium을 유연하게 배치하기 위해 자산을 Selenium에 직접 업로드할 수 없습니다. 대신 파일을 업로드하려면 다음 단계가 필요합니다.

Cypress 관련 세부 정보

HTTP 프록시 설정

도커 컨테이너의 진입점은 PROXY_HOST 환경 변수의 값을 확인해야 합니다.

이 값이 비어 있으면 추가 단계가 필요하지 않으며 HTTP 프록시를 사용하지 않고 테스트를 실행해야 합니다.

비어 있지 않으면 진입점 스크립트는 다음을 수행해야 합니다.

예제 구현은 GitHub.에 있는 Cypress 샘플 테스트 모듈의 진입점에서 찾을 수 있습니다.

극작가별 세부 정보

HTTP 프록시 설정

비어 있지 않은 PROXY_HOST 환경 변수가 제공된 경우 Cypress와 마찬가지로 테스트에서 HTTP 프록시를 사용해야 합니다.

이를 위해서는 다음과 같이 수정해야 합니다.

Dockerfile

cURL 및 libnss3-tools을(를) 설치합니다. certutil. 제공

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

진입점 스크립트

PROXY_HOST 환경 변수가 제공된 경우 다음을 수행하는 bash 스크립트를 포함합니다.

예제 구현:

# 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

극작가 구성

HTTP_PROXY 환경 변수가 설정된 경우 프록시를 사용하도록 극작가 구성(예: playwright.config.js에서)을 수정하십시오.

예제 구현:

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

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

로컬에서 UI 테스트 실행 run-ui-tests-locally

Cloud Manager 파이프라인에서 UI 테스트를 활성화하기 전에 AEM as a Cloud Service SDK 또는 실제 AEM as a Cloud Service 인스턴스에 대해 로컬에서 UI 테스트를 실행하는 것이 좋습니다.

Cypress 테스트 샘플 cypress-sample

JavaScript WebdriverIO 테스트 샘플 javascript-sample

Java Selenium WebDriver 테스트 샘플 java-sample