UI 테스트

마지막 업데이트: 2023-11-17

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

개요

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

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

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

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

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

AEM 테스트 샘플 저장소에 제공된 코드에 따라 UI 테스트에 Cypress를 사용하는 것이 좋습니다.

또한 Adobe는 WebdriverIO(AEM Project Archetype 참조)가 포함된 JavaScript 및 WebDriver(AEM 테스트 샘플 저장소 참조)가 포함된 Java를 기반으로 하는 UI 테스트 모듈 예제를 제공합니다.

UI 테스트 시작하기

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

  1. 사용하려는 프로그래밍 언어를 결정합니다.

    • Cypress의 경우 AEM 테스트 샘플 저장소에 있는 샘플 코드를 사용하십시오.

    • JavaScript 및 WDIO의 경우 Cloud Manager 저장소의 ui.tests 폴더에서 자동으로 생성되는 샘플 코드를 사용합니다.

      노트

      Cloud Manager가 자동으로 ui.tests 폴더를 생성하기 전에 사용자 저장소가 생성되었다면 AEM Project Archetype을 사용해서 최신 버전도 생성할 수 있습니다.

    • Java 및 WebDriver의 경우 AEM 테스트 샘플 저장소에 있는 샘플 코드를 사용하십시오.

    • 다른 프로그래밍 언어의 경우, 이 문서의 UI 테스트 빌드 섹션을 참조하여 테스트 프로젝트를 설정합니다.

  2. 이 문서의 고객 옵트인 섹션에 따라 UI 테스트가 활성화되어 있는지 확인합니다.

  3. 자신의 테스트 케이스를 개발하고 테스트를 로컬로 실행하십시오.

  4. Cloud Manager 저장소에 코드를 커밋하고 Cloud Manager 파이프라인을 실행합니다.

UI 테스트 빌드

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

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

AEM Project Archetype은 프로그래밍 언어에 대한 특별한 요구 사항이 없는 사용자를 위해 다음 설명을 준수하는 UI 테스트 프로젝트를 생성할 수 있습니다.

Docker 빌드 컨텍스트 생성

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

  • 테스트로 Docker 이미지를 빌드하는 데 필요한 Dockerfile 및 기타 모든 파일을 포함하는 아카이브를 생성합니다.
  • 아카이브에 ui-test-docker-context 분류자로 태그를 지정합니다.

이를 수행하는 가장 간단한 방법은 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 분류자를 할당하도록 지시합니다. 또한 다음을 포함하여 아카이브에 포함되어야 하는 파일을 나열합니다.

  • Docker 이미지 빌드에 필수인 Dockerfile
  • 아래에 목적이 설명되어 있는 wait-for-grid.sh 스크립트
  • test-module 폴더의 Node.js 프로젝트에서 구현한 실제 UI 테스트

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

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

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

고객 옵트인

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

  • 파일 이름은 testing.properties여야 합니다.
  • 파일 콘텐츠는 ui-tests.version=1이어야 합니다.
  • 파일은 UI 테스트 하위 모듈의 pom.xml 파일 옆에 있는 UI 테스트용 maven 하위 모듈 아래에 있어야 합니다.
  • 파일은 빌드된 tar.gz 파일의 루트에 있어야 합니다.

이 파일이 없으면 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>
[...]
노트

프로젝트에 이 줄이 포함되지 않은 경우 UI 테스트를 선택하도록 파일을 편집합니다.

파일에 편집하지 말라는 내용의 줄이 포함될 수 있습니다. 이는 옵트인 UI 테스트가 도입되기 전에 프로젝트에 도입되었고 클라이언트가 파일을 편집할 의도가 없었기 때문입니다. 이 경고는 간단히 무시할 수 있습니다.

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

  • AEM Project Archetype으로 생성된 JavaScript 기반 ui.tests 폴더의 경우 아래 명령을 실행하여 필요한 구성을 추가할 수 있습니다.

    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
    
  • Adobe에서 제공하는 Cypress 및 Java Selenium 테스트 샘플에는 이미 옵트인 플래그가 설정되어 있습니다.

UI 테스트 작성

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

환경 변수

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

변수 설명 테스트 프레임워크
SELENIUM_BASE_URL http://my-ip:4444 Selenium 서버의 URL Selenium 전용
SELENIUM_BROWSER chrome Selenium 서버에서 사용하는 브라우저 구현 Selenium 전용
AEM_AUTHOR_URL http://my-ip:4502/context-path AEM 작성자 인스턴스의 URL 모두
AEM_AUTHOR_USERNAME admin AEM 작성자 인스턴스에 로그인하기 위한 사용자 이름 모두
AEM_AUTHOR_PASSWORD admin AEM 작성자 인스턴스에 로그인하기 위한 암호 모두
AEM_PUBLISH_URL http://my-ip:4503/context-path AEM 게시 인스턴스의 URL 모두
AEM_PUBLISH_USERNAME admin AEM 게시 인스턴스에 로그인하기 위한 사용자 이름 모두
AEM_PUBLISH_PASSWORD admin AEM 게시 인스턴스에 로그인하기 위한 암호 모두
REPORTS_PATH /usr/src/app/reports 테스트 결과의 XML 보고서를 저장해야 하는 경로 모두
UPLOAD_URL http://upload-host:9090/upload 테스트 프레임워크에 액세스할 수 있도록 파일을 업로드해야 하는 URL 모두

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

  • Cypress: 표준 기능 Cypress.env('VARIABLE_NAME') 사용
  • JavaScript: lib/config.js 모듈 참조
  • Java: Config 클래스 참조

테스트 보고서 생성

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

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

노트

UI 테스트 단계의 결과는 테스트 보고서만을 기반으로 평가됩니다. 테스트 실행에 맞게 보고서를 생성했는지 확인하십시오.

STDERR에 오류를 로깅하거나 0이 아닌 종료 코드를 반환하는 대신 어설션을 사용하십시오. 이렇게 하지 않으면 배포 파이프라인이 정상적으로 진행될 수 있습니다.

사전 요구 사항

  • Cloud Manager의 테스트는 기술 관리 사용자를 통해 실행됩니다.
노트

로컬 시스템에서 기능 테스트를 실행하려면 동일한 동작이 가능하도록 관리자와 유사한 권한을 가진 사용자를 만드십시오.

  • 기능 테스트 범위가 지정된 컨테이너화된 인프라는 다음 경계로 제한됩니다.
유형 설명
CPU 2.0 테스트 실행당 예약된 CPU 시간
메모리 1Gi 테스트에 할당된 메모리 양(기비바이트 값)
시간 초과 30m 테스트가 종료되기까지의 기간입니다.
권장 기간 15m 이 시간보다 오래 걸리지 않도록 테스트를 작성하는 것이 좋습니다.
노트

더 많은 리소스가 필요한 경우, 고객 지원 사례를 만들고 사용 사례를 설명하십시오. Adobe에서 귀하의 요청을 검토하고 적절한 지원을 제공할 것입니다.

Selenium 관련 세부 정보

노트

이 섹션은 Selenium이 테스트 인프라로 선택된 경우에만 적용됩니다.

Selenium이 준비될 때까지 대기

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

  1. SELENIUM_BASE_URL 환경 변수에서 Selenium 서비스의 URL을 읽습니다.
  2. Selenium API에 의해 노출된 상태 엔드포인트에 정기적으로 폴링합니다.

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

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

스크린샷 및 비디오 캡처

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

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

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

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

파일 업로드

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

  1. UPLOAD_URL 환경 변수로 지정된 URL에서 파일을 업로드합니다.
    • 업로드는 다중 부분 양식으로 된 하나의 POST 요청으로 수행되어야 합니다.
    • 다중 부분 양식에는 단일 파일 필드가 있어야 합니다.
    • 이는 curl -X POST ${UPLOAD_URL} -F "data=@file.txt"에 해당합니다.
    • 이러한 HTTP 요청을 수행하는 방법을 알아보려면 Docker 이미지에 사용된 프로그래밍 언어의 문서 및 라이브러리를 참조하십시오.
    • Adobe 테스트 샘플은 파일 업로드를 위한 도우미 기능을 제공합니다.
  2. 업로드가 성공하면 요청은 text/plain 유형의 200 OK 응답을 반환합니다.
    • 응답의 내용은 불투명한 파일 핸들입니다.
    • <input> 요소의 파일 경로 대신 이 핸들을 사용하여 애플리케이션에서 파일 업로드를 테스트할 수 있습니다.

로컬에서 UI 테스트 실행

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

Cypress 테스트 샘플

  1. 셸을 열고 저장소의 ui.tests/test-module 폴더로 이동합니다.

  2. Cypress 및 기타 사전 요구 사항 설치

    npm install
    
  3. 테스트 실행에 필요한 환경 변수 설정

    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. 다음 명령 중 하나로 테스트 실행

    npm test              # Using default Cypress browser
    npm run test-chrome   # Using Google Chrome browser
    npm run test-firefox  # Using Firefox browser
    
노트

로그 파일은 저장소의 target/ 폴더에 저장됩니다.

자세한 내용은 AEM 테스트 샘플 저장소를 참고하십시오.

JavaScript WebdriverIO 테스트 샘플

  1. 셸을 열고 저장소의 ui.tests 폴더로 이동합니다.

  2. 아래 명령을 실행하여 Maven을 사용해 테스트를 시작합니다.

    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>
    
노트
  • 독립 실행형 Selenium 인스턴스가 시작되고 그에 대한 테스트가 실행됩니다.
  • 로그 파일은 저장소의 target/reports 폴더에 저장됩니다.
  • 테스트에서 테스트를 위해 ChromeDriver의 최신 릴리스를 자동으로 다운로드하므로 최신 크롬 버전이 실행 중인지 확인해야 합니다.

자세한 내용은 AEM Project Archetype 저장소를 참고하십시오.

Java Selenium WebDriver 테스트 샘플

  1. 셸을 열고 저장소의 ui.tests/test-module 폴더로 이동합니다.

  2. 아래 명령을 실행하여 Maven을 사용해 테스트를 시작합니다.

    # 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
    
노트

로그 파일은 저장소의 target/reports 폴더에 저장됩니다.

자세한 내용은 AEM 테스트 샘플 저장소를 참고하십시오.

이 페이지에서는