기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS Device Farm의 사용자 지정 테스트 환경 AWS Device Farm을 사용하면 모든 Device Farm 사용자에게 권장되는 접근 방식인 자동 테스트(사용자 지정 모드)를 위한 사용자 지정 환경을 구성할 수 있습니다. Device Farm의 환경에 대해 자세히 알아보려면 [테스트 환경](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html)을 참조하세요. 표준 모드와 달리 사용자 지정 모드의 이점은 다음과 같습니다. + **더 빠른 엔드 투 엔드 테스트 실행**: 테스트 패키지가 스위트의 모든 테스트를 탐지하도록 파싱되지 않으므로 사전 처리/사후 처리 오버헤드를 피할 수 있습니다. + **라이브 로그 및 비디오 스트리밍**: 사용자 지정 모드를 사용하면 클라이언트 측 테스트 로그와 비디오가 실시간 스트리밍됩니다. 이 기능은 표준 모드의 경우 사용할 수 없습니다. + **모든 아티팩트 캡처**: 호스트 및 장치에서 사용자 지정 모드를 사용하면 모든 테스트 아티팩트를 캡처할 수 있습니다. 표준 모드에서는 불가능할 수 있습니다. + **보다 일관되고 복제 가능한 로컬 환경**: 표준 모드에서는 개별 테스트마다 아티팩트가 별도로 제공되므로 특정 상황에서 유용할 수 있습니다. 하지만 Device Farm이 실행된 각 테스트를 다르게 처리하므로 로컬 테스트 환경이 원래 구성과 다를 수 있습니다. 반면 사용자 지정 모드를 사용하면 Device Farm 테스트 실행 환경을 로컬 테스트 환경에 맞게 일관되게 만들 수 있습니다. 사용자 지정 환경은 YAML 형식의 테스트 사양(테스트 사양) 파일을 사용하여 구성됩니다. Device Farm은 지원되는 각 테스트 유형에 대해 있는 그대로 사용하거나 사용자 지정할 수 있는 기본 테스트 사양 파일을 제공합니다. 테스트 필터 또는 구성 파일과 같은 사용자 지정을 테스트 사양에 추가할 수 있습니다. 편집된 테스트 사양은 향후 테스트 실행을 위해 저장할 수 있습니다. 자세한 정보는 [AWS CLI를 사용하여 사용자 지정 테스트 사양 업로드](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5) 및 [Device Farm에서 테스트 실행 생성](how-to-create-test-run.md) 단원을 참조하세요. **Topics** + [테스트 사양 참조 및 구문](custom-test-environment-test-spec.md) + [사용자 지정 테스트 환경을 위한 호스트](custom-test-environments-hosts.md) + [IAM 실행 역할을 사용하여 AWS 리소스에 액세스](custom-test-environments-iam-roles.md) + [사용자 지정 테스트 환경을 위한 환경 변수](custom-test-environment-variables.md) + [사용자 지정 테스트 환경 실행 모범 사례](custom-test-environments-best-practices.md) + [표준 환경에서 사용자 지정 테스트 환경으로 테스트 마이그레이션](custom-test-environment-migration.md) + [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) # 테스트 사양 참조 및 구문 테스트 사양(테스트 사양)은 Device Farm에서 사용자 지정 테스트 환경을 정의하는 데 사용하는 파일입니다. ## 사양 테스트 워크플로 Device Farm 테스트 사양은 단계와 명령을 미리 결정된 순서로 실행하므로 환경이 준비되고 실행되는 방식을 사용자 지정할 수 있습니다. 각 단계가 실행되면 해당 명령은 테스트 사양 파일 내에 나열된 순서대로 실행됩니다. 단계는 다음 순서로 실행됩니다. 1. `install` - 여기에서 도구 다운로드, 설치 및 설정과 같은 작업을 정의해야 합니다. 1. `pre_test` - 백그라운드 프로세스 시작과 같은 사전 테스트 작업을 정의해야 하는 곳입니다. 1. `test` - 테스트를 호출하는 명령을 정의해야 하는 곳입니다. 1. `post_test` - 테스트 보고서 생성 및 아티팩트 파일 집계와 같이 테스트 종료 후 실행해야 하는 모든 최종 작업을 정의해야 하는 곳입니다. ## 테스트 사양 구문 다음은 테스트 사양 파일의 YAML 스키마입니다. ``` version: 0.1 android_test_host: "string" ios_test_host: "string" phases: install: commands: - "string" - "string" pre_test: commands: - "string" - "string" test: commands: - "string" - "string" post_test: commands: - "string" - "string" artifacts: - "string" - "string" ``` ** `version` ** *(필수, 숫자)* Device Farm에서 지원하는 테스트 사양 버전을 반영합니다. 현재 버전 번호는 입니다` 0.1`. ** `android_test_host` ** *(선택 사항, 문자열)* Android 디바이스에서 수행되는 테스트 실행에 대해 선택될 테스트 호스트입니다. 이 필드는 Android 디바이스의 테스트 실행에 필요합니다. 자세한 내용은 [사용자 지정 테스트 환경에 사용 가능한 테스트 호스트](custom-test-environments-hosts.md#custom-test-environments-hosts-available) 단원을 참조하십시오. ** `ios_test_host` ** *(선택 사항, 문자열)* iOS 디바이스에서 수행되는 테스트 실행에 대해 선택될 테스트 호스트입니다. 이 필드는 메이저 버전이 26보다 큰 iOS 디바이스에서 테스트 실행을 수행하는 데 필요합니다. 자세한 내용은 [사용자 지정 테스트 환경에 사용 가능한 테스트 호스트](custom-test-environments-hosts.md#custom-test-environments-hosts-available) 단원을 참조하십시오. ** `phases` ** 이 섹션에는 테스트 실행 중에 실행되는 명령 그룹이 포함되어 있습니다. 여기서 각 단계는 선택 사항입니다. 허용되는 테스트 단계 이름은 `install`, `pre_test` , 및 `test`입니다`post_test`. + `install` - Device Farm에서 지원하는 프레임워크를 테스트하기 위한 기본 종속성이 이미 설치되어 있습니다. 이 단계에는 Device Farm이 설치 중에 실행하는 추가 명령(있는 경우)이 포함되어 있습니다. + `pre_test` - 자동 테스트 전에 실행되는 명령이 있는 경우 + `test` - 자동 테스트 실행 중에 실행되는 명령입니다. 테스트 단계의 명령이 실패하면(0이 아닌 종료 코드를 반환함을 의미) 테스트가 실패로 표시됩니다. + `post_test` - 자동 테스트 실행 후 실행되는 명령이 있는 경우 단계의 테스트 `test` 성공 또는 실패 여부에 관계없이 실행됩니다. ** `commands` ** *(선택 사항, List[string])* 단계 중에 셸 명령으로 실행할 문자열 목록입니다. ** `artifacts` ** *(선택 사항, List[string])* Device Farm은 여기에 지정된 위치에서 사용자 지정 보고서, 로그 파일 및 이미지 등의 아티팩트를 수집합니다. 와일드카드 문자는 아티팩트 위치의 일부로 지원되지 않으므로 각 위치의 올바른 경로를 지정해야 합니다. 이러한 테스트 아티팩트는 테스트 실행에서 각 디바이스에 사용할 수 있습니다. 테스트 아티팩트 검색에 대한 자세한 내용은 [사용자 지정 테스트 환경에서 아티팩트 다운로드](using-artifacts-custom.md) 단원을 참조하세요. **중요** 테스트 사양은 올바른 YAML 파일 형식으로 지정해야 합니다. 테스트 사양에서 들여쓰기 또는 공백이 잘못된 경우 테스트 실행이 실패할 수 있습니다. YAML 파일에서 탭은 허용되지 않습니다. YAML 검사기를 사용하여 테스트 사양이 올바른 YAML 파일인지 여부를 테스트할 수 있습니다. 자세한 내용은 [YAML 웹 사이트](http://yaml.org/spec/1.2/spec.html)를 참조하세요. ## 테스트 사양 예제 다음 예제는 Device Farm에서 실행할 수 있는 테스트 사양을 보여줍니다. ------ #### [ Simple Demo ] 다음은 테스트 실행 아티팩트로 로깅하는 테스트 사양 파일의 `Hello world!` 예입니다. ``` version: 0.1 android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: install: commands: # Setup your environment by installing and/or validating software - devicefarm-cli use python 3.11 - python --version pre_test: commands: # Setup your tests by starting background tasks or setting up # additional environment variables. - OUTPUT_FILE="/tmp/hello.log" test: commands: # Run your tests within this phase. - python -c 'print("Hello world!")' &> $OUTPUT_FILE post_test: commands: # Perform any remaining tasks within this phase, such as copying # artifacts to the DEVICEFARM_LOG_DIR for upload - cp $OUTPUT_FILE $DEVICEFARM_LOG_DIR artifacts: # By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory. - $DEVICEFARM_LOG_DIR ``` ------ #### [ Appium Android ] 다음은 Android에서 Appium Java TestNG 테스트 실행을 구성하는 테스트 사양 파일의 예입니다. ``` version: 0.1 # The following fields(s) allow you to select which Device Farm test host is used for your test run. android_test_host: amazon_linux_2 phases: # The install phase contains commands for installing dependencies to run your tests. # Certain frequently used dependencies are preinstalled on the test host to accelerate and # simplify your test setup. To find these dependencies, versions supported and additional # software installation please see: # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html install: commands: # The Appium server is written using Node.js. In order to run your desired version of Appium, # you first need to set up a Node.js environment that is compatible with your version of Appium. - devicefarm-cli use node 20 - node --version # Use the devicefarm-cli to select a preinstalled major version of Appium. - devicefarm-cli use appium 2 - appium --version # The Device Farm service periodically updates the preinstalled Appium versions over time to # incorporate the latest minor and patch versions for each major version. If you wish to # select a specific version of Appium, you can use NPM to install it. # - npm install -g appium@2.19.0 # When running Android tests with Appium version 2, the uiautomator2 driver is preinstalled using driver # version 2.44.1 for Appium 2.5.1 If you want to install a different version of the driver, # you can use the Appium extension CLI to uninstall the existing uiautomator2 driver # and install your desired version: # - |- # if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; # then # appium driver uninstall uiautomator2; # appium driver install uiautomator2@2.34.0; # fi; # Based on Appium framework's recommendation, we recommend setting the Appium server's # base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub, # please set it here. - export APPIUM_BASE_PATH= # Use the devicefarm-cli to setup a Java environment, with which you can run your test suite. - devicefarm-cli use java 17 - java -version # The pre-test phase contains commands for setting up your test environment. pre_test: commands: # Setup the CLASSPATH so that Java knows where to find your test classes. - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/* - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/* # We recommend starting the Appium server process in the background using the command below. # The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory. # The environment variables passed as capabilities to the server will be automatically assigned # during your test run based on your test's specific device. # For more information about which environment variables are set and how they're set, please see # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html - |- appium --base-path=$APPIUM_BASE_PATH --log-timestamp \ --log-no-colors --relaxed-security --default-capabilities \ "{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \ \"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \ \"appium:udid\":\"$DEVICEFARM_DEVICE_UDID\", \ \"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \ \"appium:chromedriverExecutableDir\": \"$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR\", \ \"appium:automationName\": \"UiAutomator2\"}" \ >> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &; # This code snippet is to wait until the Appium server starts. - |- appium_initialization_time=0; until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do if [[ $appium_initialization_time -gt 30 ]]; then echo "Appium did not start within 30 seconds. Exiting..."; exit 1; fi; appium_initialization_time=$((appium_initialization_time + 1)); echo "Waiting for Appium to start on port 4723..."; sleep 1; done; # The test phase contains commands for running your tests. test: commands: # Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory. - echo "Navigate to test package directory" - cd $DEVICEFARM_TEST_PACKAGE_PATH - echo "Starting the Appium TestNG test" # The following command runs your Appium Java TestNG test. # For more information, please see TestNG's documentation here: # https://testng.org/#_running_testng - |- java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # To run your tests with a testng.xml file that is a part of your test package, # use the following commands instead: # - echo "Unzipping the tests JAR file" # - unzip *-tests.jar # - |- # java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ # testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # The post-test phase contains commands that are run after your tests have completed. # If you need to run any commands to generating logs and reports on how your test performed, # we recommend adding them to this section. post_test: commands: # Artifacts are a list of paths on the filesystem where you can store test output and reports. # All files in these paths will be collected by Device Farm, with certain limits (see limit details # here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits). # These files will be available through the ListArtifacts API as your "Customer Artifacts". artifacts: # By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory. - $DEVICEFARM_LOG_DIR ``` ------ #### [ Appium iOS ] 다음은 iOS에서 Appium Java TestNG 테스트 실행을 구성하는 테스트 사양 파일의 예입니다. ``` version: 0.1 # The following fields(s) allow you to select which Device Farm test host is used for your test run. ios_test_host: macos_sequoia phases: # The install phase contains commands for installing dependencies to run your tests. # Certain frequently used dependencies are preinstalled on the test host to accelerate and # simplify your test setup. To find these dependencies, versions supported and additional # software installation please see: # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html install: commands: # The Appium server is written using Node.js. In order to run your desired version of Appium, # you first need to set up a Node.js environment that is compatible with your version of Appium. - devicefarm-cli use node 20 - node --version # Use the devicefarm-cli to select a preinstalled major version of Appium. - devicefarm-cli use appium 2 - appium --version # The Device Farm service periodically updates the preinstalled Appium versions over time to # incorporate the latest minor and patch versions for each major version. If you wish to # select a specific version of Appium, you can use NPM to install it. # - npm install -g appium@2.19.0 # When running iOS tests with Appium version 2, the XCUITest driver is preinstalled using driver # version 9.10.5 for Appium 2.5.4. If you want to install a different version of the driver, # you can use the Appium extension CLI to uninstall the existing XCUITest driver # and install your desired version: # - |- # if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; # then # appium driver uninstall xcuitest; # appium driver install xcuitest@10.0.0; # fi; # Based on Appium framework's recommendation, we recommend setting the Appium server's # base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub, # please set it here. - export APPIUM_BASE_PATH= # Use the devicefarm-cli to setup a Java environment, with which you can run your test suite. - devicefarm-cli use java 17 - java -version # The pre-test phase contains commands for setting up your test environment. pre_test: commands: # Setup the CLASSPATH so that Java knows where to find your test classes. - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/* - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/* # Device Farm provides multiple pre-built versions of WebDriverAgent (WDA), a required # Appium dependency for iOS, where each version corresponds to the XCUITest driver version selected. # If Device Farm cannot find a corresponding version of WDA for your XCUITest driver, # the latest available version is selected by default. - |- APPIUM_DRIVER_VERSION=$(appium driver list --installed --json | jq -r ".xcuitest.version" | cut -d "." -f 1); CORRESPONDING_APPIUM_WDA=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V${APPIUM_DRIVER_VERSION}") if [[ ! -z "$APPIUM_DRIVER_VERSION" ]] && [[ ! -z "$CORRESPONDING_APPIUM_WDA" ]]; then echo "Using Device Farm's prebuilt WDA version ${APPIUM_DRIVER_VERSION}.x, which corresponds with your driver"; DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $CORRESPONDING_APPIUM_WDA | cut -d "=" -f2) else LATEST_SUPPORTED_WDA_VERSION=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V" | sort -V -r | head -n 1) echo "Unknown driver version $APPIUM_DRIVER_VERSION; falling back to the Device Farm default version of $LATEST_SUPPORTED_WDA_VERSION"; DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $LATEST_SUPPORTED_WDA_VERSION | cut -d "=" -f2) fi; # For iOS versions 16 and below only, the device unique identifier (UDID) needs to modified for Appium tests # on Device Farm to remove the hypens. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$DEVICEFARM_DEVICE_UDID; if [ $(echo $DEVICEFARM_DEVICE_OS_VERSION | cut -d "." -f 1) -le 16 ]; then DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$(echo $DEVICEFARM_DEVICE_UDID | tr -d "-"); fi; fi; # We recommend starting the Appium server process in the background using the command below. # The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory. # The environment variables passed as capabilities to the server will be automatically assigned # during your test run based on your test's specific device. # For more information about which environment variables are set and how they're set, please see # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html - |- appium --base-path=$APPIUM_BASE_PATH --log-timestamp \ --log-no-colors --relaxed-security --default-capabilities \ "{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \ \"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \ \"appium:app\": \"$DEVICEFARM_APP_PATH\", \ \"appium:udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \ \"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \ \"appium:derivedDataPath\": \"$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH\", \ \"appium:usePrebuiltWDA\": true, \ \"appium:automationName\": \"XCUITest\"}" \ >> $DEVICEFARM_LOG_DIR/appium.log 2>&1 & # This code snippet is to wait until the Appium server starts. - |- appium_initialization_time=0; until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do if [[ $appium_initialization_time -gt 30 ]]; then echo "Appium did not start within 30 seconds. Exiting..."; exit 1; fi; appium_initialization_time=$((appium_initialization_time + 1)); echo "Waiting for Appium to start on port 4723..."; sleep 1; done; # The test phase contains commands for running your tests. test: commands: # Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory. - echo "Navigate to test package directory" - cd $DEVICEFARM_TEST_PACKAGE_PATH - echo "Starting the Appium TestNG test" # The following command runs your Appium Java TestNG test. # For more information, please see TestNG's documentation here: # https://testng.org/#_running_testng - |- java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # To run your tests with a testng.xml file that is a part of your test package, # use the following commands instead: # - echo "Unzipping the tests JAR file" # - unzip *-tests.jar # - |- # java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ # testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # The post-test phase contains commands that are run after your tests have completed. # If you need to run any commands to generating logs and reports on how your test performed, # we recommend adding them to this section. post_test: commands: # Artifacts are a list of paths on the filesystem where you can store test output and reports. # All files in these paths will be collected by Device Farm, with certain limits (see limit details # here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits). # These files will be available through the ListArtifacts API as your "Customer Artifacts". artifacts: # By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory. - $DEVICEFARM_LOG_DIR ``` ------ #### [ Appium (Both Platforms) ] 다음은 Android와 iOS 모두에서 Appium Java TestNG 테스트 실행을 구성하는 테스트 사양 파일의 예입니다. ``` version: 0.1 # The following fields(s) allow you to select which Device Farm test host is used for your test run. android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: # The install phase contains commands for installing dependencies to run your tests. # Certain frequently used dependencies are preinstalled on the test host to accelerate and # simplify your test setup. To find these dependencies, versions supported and additional # software installation please see: # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html install: commands: # The Appium server is written using Node.js. In order to run your desired version of Appium, # you first need to set up a Node.js environment that is compatible with your version of Appium. - devicefarm-cli use node 20 - node --version # Use the devicefarm-cli to select a preinstalled major version of Appium. - devicefarm-cli use appium 2 - appium --version # The Device Farm service periodically updates the preinstalled Appium versions over time to # incorporate the latest minor and patch versions for each major version. If you wish to # select a specific version of Appium, you can use NPM to install it. # - npm install -g appium@2.19.0 # When running Android tests with Appium version 2, the uiautomator2 driver is preinstalled using driver # version 2.44.1 for Appium 2.5.1 If you want to install a different version of the driver, # you can use the Appium extension CLI to uninstall the existing uiautomator2 driver # and install your desired version: # - |- # if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; # then # appium driver uninstall uiautomator2; # appium driver install uiautomator2@2.34.0; # fi; # When running iOS tests with Appium version 2, the XCUITest driver is preinstalled using driver # version 9.10.5 for Appium 2.5.4. If you want to install a different version of the driver, # you can use the Appium extension CLI to uninstall the existing XCUITest driver # and install your desired version: # - |- # if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; # then # appium driver uninstall xcuitest; # appium driver install xcuitest@10.0.0; # fi; # Based on Appium framework's recommendation, we recommend setting the Appium server's # base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub, # please set it here. - export APPIUM_BASE_PATH= # Use the devicefarm-cli to setup a Java environment, with which you can run your test suite. - devicefarm-cli use java 17 - java -version # The pre-test phase contains commands for setting up your test environment. pre_test: commands: # Setup the CLASSPATH so that Java knows where to find your test classes. - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/* - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/* # Device Farm provides multiple pre-built versions of WebDriverAgent (WDA), a required # Appium dependency for iOS, where each version corresponds to the XCUITest driver version selected. # If Device Farm cannot find a corresponding version of WDA for your XCUITest driver, # the latest available version is selected by default. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then APPIUM_DRIVER_VERSION=$(appium driver list --installed --json | jq -r ".xcuitest.version" | cut -d "." -f 1); CORRESPONDING_APPIUM_WDA=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V${APPIUM_DRIVER_VERSION}") if [[ ! -z "$APPIUM_DRIVER_VERSION" ]] && [[ ! -z "$CORRESPONDING_APPIUM_WDA" ]]; then echo "Using Device Farm's prebuilt WDA version ${APPIUM_DRIVER_VERSION}.x, which corresponds with your driver"; DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $CORRESPONDING_APPIUM_WDA | cut -d "=" -f2) else LATEST_SUPPORTED_WDA_VERSION=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V" | sort -V -r | head -n 1) echo "Unknown driver version $APPIUM_DRIVER_VERSION; falling back to the Device Farm default version of $LATEST_SUPPORTED_WDA_VERSION"; DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $LATEST_SUPPORTED_WDA_VERSION | cut -d "=" -f2) fi; fi; # For iOS versions 16 and below only, the device unique identifier (UDID) needs to modified for Appium tests # on Device Farm to remove the hypens. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$DEVICEFARM_DEVICE_UDID; if [ $(echo $DEVICEFARM_DEVICE_OS_VERSION | cut -d "." -f 1) -le 16 ]; then DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$(echo $DEVICEFARM_DEVICE_UDID | tr -d "-"); fi; fi; # We recommend starting the Appium server process in the background using the command below. # The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory. # The environment variables passed as capabilities to the server will be automatically assigned # during your test run based on your test's specific device. # For more information about which environment variables are set and how they're set, please see # https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; then appium --base-path=$APPIUM_BASE_PATH --log-timestamp \ --log-no-colors --relaxed-security --default-capabilities \ "{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \ \"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \ \"appium:udid\":\"$DEVICEFARM_DEVICE_UDID\", \ \"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \ \"appium:chromedriverExecutableDir\": \"$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR\", \ \"appium:automationName\": \"UiAutomator2\"}" \ >> $DEVICEFARM_LOG_DIR/appium.log 2>&1 & else appium --base-path=$APPIUM_BASE_PATH --log-timestamp \ --log-no-colors --relaxed-security --default-capabilities \ "{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \ \"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \ \"appium:udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \ \"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \ \"appium:derivedDataPath\": \"$DEVICEFARM_WDA_DERIVED_DATA_PATH\", \ \"appium:usePrebuiltWDA\": true, \ \"appium:automationName\": \"XCUITest\"}" \ >> $DEVICEFARM_LOG_DIR/appium.log 2>&1 & fi; # This code snippet is to wait until the Appium server starts. - |- appium_initialization_time=0; until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do if [[ $appium_initialization_time -gt 30 ]]; then echo "Appium did not start within 30 seconds. Exiting..."; exit 1; fi; appium_initialization_time=$((appium_initialization_time + 1)); echo "Waiting for Appium to start on port 4723..."; sleep 1; done; # The test phase contains commands for running your tests. test: commands: # Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory. - echo "Navigate to test package directory" - cd $DEVICEFARM_TEST_PACKAGE_PATH - echo "Starting the Appium TestNG test" # The following command runs your Appium Java TestNG test. # For more information, please see TestNG's documentation here: # https://testng.org/#_running_testng - |- java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # To run your tests with a testng.xml file that is a part of your test package, # use the following commands instead: # - echo "Unzipping the tests JAR file" # - unzip *-tests.jar # - |- # java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \ # testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10 # The post-test phase contains commands that are run after your tests have completed. # If you need to run any commands to generating logs and reports on how your test performed, # we recommend adding them to this section. post_test: commands: # Artifacts are a list of paths on the filesystem where you can store test output and reports. # All files in these paths will be collected by Device Farm, with certain limits (see limit details # here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits). # These files will be available through the ListArtifacts API as your "Customer Artifacts". artifacts: # By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory. - $DEVICEFARM_LOG_DIR ``` ------ # 사용자 지정 테스트 환경을 위한 호스트 Device Farm은 테스트 호스트 환경을 사용하여 사전 구성된 소프트웨어가 있는 운영 체제 세트를 지원합니다. 테스트 실행 중에 Device Farm은 테스트 중인 선택한 디바이스에 동적으로 연결하는 Amazon 관리형 인스턴스(호스트)를 활용합니다. 이 인스턴스는 완전히 정리되고 실행 간에 재사용되지 않으며 테스트 실행이 종료된 후 생성된 아티팩트로 종료됩니다. **Topics** + [사용자 지정 테스트 환경에 사용 가능한 테스트 호스트](#custom-test-environments-hosts-available) + [사용자 지정 테스트 환경을 위한 테스트 호스트 선택](#test-host-selection) + [사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md) + [Android 디바이스용 테스트 환경](custom-test-environments-hosts-android.md) + [iOS 디바이스용 테스트 환경](custom-test-environments-hosts-ios.md) ## 사용자 지정 테스트 환경에 사용 가능한 테스트 호스트 테스트 호스트는 Device Farm에서 완벽하게 관리합니다. 다음 표에는 사용자 지정 테스트 환경에 대해 현재 사용 가능하고 지원되는 Device Farm 테스트 호스트가 나열되어 있습니다. | 디바이스 플랫폼 | 호스트 테스트 | 운영 체제 | 아키텍처(들) | 지원되는 디바이스 | | --- | --- | --- | --- | --- | | Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android 6 이상 | | iOS | macos\$1sequoia | macOS Sequoia (버전 15) | arm64 | iOS 15\$126 | **참고** Device Farm은 정기적으로 디바이스 플랫폼에 대한 새 테스트 호스트를 추가하여 최신 디바이스 OS 버전 및 해당 종속성을 지원합니다. 이 경우 각 디바이스 플랫폼의 이전 테스트 호스트에 대한 지원이 종료됩니다. ### 운영 체제 버전 사용 가능한 각 테스트 호스트는 현재 Device Farm에서 지원되는 특정 버전의 운영 체제를 사용합니다. 최신 OS 버전을 사용하려고 하지만 공개적으로 배포된 최신 버전이 아닐 수 있습니다. Device Farm은 마이너 버전 업데이트 및 보안 패치를 사용하여 운영 체제를 주기적으로 업데이트합니다. 테스트 실행 중에 사용 중인 운영 체제의 특정 버전(마이너 버전 포함)을 확인하려면 테스트 사양 파일의 단계에 다음 코드 조각을 추가할 수 있습니다. **Example** ``` phases: install: commands: # The following example prints the instance's operating system version details - |- if [[ "Darwin" == "$(uname)" ]]; then echo "$(sw_vers --productName) $(sw_vers --productVersion) ($(sw_vers --buildVersion))"; else echo "$(. /etc/os-release && echo $PRETTY_NAME) ($(uname -r))"; fi ``` ## 사용자 지정 테스트 환경을 위한 테스트 호스트 선택 테스트 사양 파일의 적절한 및 `ios_test_host` 변수에서 Android `android_test_host` 및 iOS 테스트 호스트를 지정할 수 있습니다. [테스트 사양 구문](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax) 지정된 디바이스 플랫폼에 대해 테스트 호스트 선택을 지정하지 않으면 Device Farm이 지정된 디바이스 및 테스트 구성의 기본값으로 설정한 테스트 호스트에서 테스트가 실행됩니다. **중요** iOS 18 이하에서 테스트할 때 호스트를 선택하지 않으면 레거시 테스트 호스트가 사용됩니다. 자세한 내용은의 주제를 참조하세요[레거시 iOS 테스트 호스트](custom-test-environments-hosts-ios.md#legacy-ios-host). 예를 들어 다음 코드 조각을 검토합니다. **Example** ``` version: 0.1 android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: # ... ``` # 사용자 지정 테스트 환경 내에서 지원되는 소프트웨어 Device Farm은 필요한 많은 소프트웨어 라이브러리가 사전 설치된 호스트 시스템을 사용하여 서비스에서 지원되는 테스트 프레임워크를 실행하여 시작 시 준비된 테스트 환경을 제공합니다. Device Farm은 소프트웨어 선택 메커니즘을 사용하여 여러 언어를 지원하며 환경에 포함된 언어의 버전을 주기적으로 업데이트합니다. 기타 필수 소프트웨어의 경우 테스트 패키지에서 설치, 인터넷에서 다운로드, VPC 내 프라이빗 소스에 액세스하도록 테스트 사양 파일을 수정할 수 있습니다(자세한 내용은 [VPC ENI](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html) 참조). 자세한 내용은 [테스트 사양 예제](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) 단원을 참조하십시오. ## 사전 구성된 소프트웨어 각 플랫폼에서 디바이스 테스트를 용이하게 하기 위해 테스트 호스트에 다음 도구가 제공됩니다. | 도구 | 디바이스 플랫폼(들) | | --- | --- | | Android SDK Build-Tools | Android | | Android SDK Platform-Tools ( 포함`adb`) | Android | | Xcode | iOS | ## 선택 가능한 소프트웨어 호스트에 사전 구성된 소프트웨어 외에도 Device Farm은 `devicefarm-cli` 도구를 통해 지원되는 소프트웨어의 특정 버전을 선택할 수 있는 방법을 제공합니다. 다음 표에는 선택 가능한 소프트웨어와 해당 소프트웨어가 포함된 테스트 호스트가 나와 있습니다. | 소프트웨어/도구 | 이 소프트웨어를 지원하는 호스트 | 테스트 사양에 사용할 명령 | | --- | --- | --- | | Java 17 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 17` | | Java 11 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 11` | | Java 8 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 8` | | Node.js 20 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use node 20` | | Node.js 18 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use node 18` | | Node.js 16 | amazon\$1linux\$12 | `devicefarm-cli use node 16` | | Python 3.11 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.11` | | Python 3.10 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.10` | | Python 3.9 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.9` | | Python 3.8 | amazon\$1linux\$12 | `devicefarm-cli use python 3.8` | | Ruby 3.2 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use ruby 3.2` | | Ruby 2.7 | amazon\$1linux\$12 | `devicefarm-cli use ruby 2.7` | | Appium 3 | amazon\$1linux\$12 | `devicefarm-cli use appium 3` | | Appium 2 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use appium 2` | | Appium 1 | amazon\$1linux\$12 | `devicefarm-cli use appium 1` | | Xcode 26 | macos\$1sequoia | `devicefarm-cli use xcode 26` | | Xcode 16 | macos\$1sequoia | `devicefarm-cli use xcode 16` | 테스트 호스트에는 `pip` 및 `npm` 패키지 관리자(Python과 Node.js 각각 포함)와 같은 개별 소프트웨어 버전에 일반적으로 지원되는 툴과 Appium과 같은 툴을 위한 의존성(예: Appium UIAutomator2 Driver) 역시 포함합니다. 따라서 지원되는 테스트 프레임워크를 사용하는 데 필요한 도구가 보장됩니다. # 사용자 지정 테스트 환경에서 devicefarm-cli 도구 사용 테스트 호스트는 라는 표준화된 버전 관리 도구를 사용하여 소프트웨어 버전을 ` devicefarm-cli` 선택합니다. 이 도구는 AWS CLI 와 별개이며 Device Farm 테스트 호스트에서만 사용할 수 있습니다. `devicefarm-cli`를 사용하면 테스트 호스트에 사전 설치된 소프트웨어 버전으로 전환할 수 있습니다. 이를 통해 시간이 지나도 Device Farm 테스트 사양 파일을 관리할 수 있는 명확한 방법을 제공하고 예측 가능한 메커니즘을 주어 향후 소프트웨어 버전을 업그레이드할 수 있도록 합니다. **중요** 레거시 iOS 호스트에서는이 명령줄 도구를 사용할 수 없습니다. 자세한 내용은의 주제를 참조하세요[레거시 iOS 테스트 호스트](custom-test-environments-hosts-ios.md#legacy-ios-host). 아래 스니펫은 `devicefarm-cli`의 `help` 페이지를 보여줍니다. ``` $ devicefarm-cli help Usage: devicefarm-cli COMMAND [ARGS] Commands: help Prints this usage message. list Lists all versions of software configurable via this CLI. use Configures the software for usage within the current shell's environment. ``` `devicefarm-cli`를 사용하여 몇 가지 예를 살펴봅시다. 이 도구를 사용하여 테스트 사양 파일에서 Python 버전을 *3.10*에서 *3.9*로 변경하려면 다음 명령을 실행하세요. ``` $ python --version Python 3.10.12 $ devicefarm-cli use python 3.9 $ python --version Python 3.9.17 ``` Appium 버전을 *1*에서 *2*로 변경하려면 다음과 같습니다. ``` $ appium --version 1.22.3 $ devicefarm-cli use appium 2 $ appium --version 2.1.2 ``` **작은 정보** 소프트웨어 버전을 선택하면 Python을 위한 `pip`, NodeJS를 위한 `npm`과 같이 `devicefarm-cli` 또한 해당 언어에 대한 지원 도구로 전환한다는 점을 유의하세요. 테스트 호스트에 사전 설치된 소프트웨어에 대한 자세한 내용은 섹션을 참조하세요[사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md). # Android 디바이스용 테스트 환경 AWS Device Farm은 Amazon Linux 2를 실행하는 Amazon Elastic Compute Cloud(EC2) 호스트 머신을 활용하여 Android 테스트를 실행합니다. 테스트 실행을 예약하면 Device Farm은 각 디바이스에 전용 호스트를 할당하여 독립적으로 테스트를 실행합니다. 테스트 실행 후 생성된 아티팩트와 함께 호스트 컴퓨터가 종료됩니다. Amazon Linux 2 호스트는 다음과 같은 장점이 있습니다. + **더 빠르고 안정적인 테스트**: 레거시 호스트에 비해 새 테스트 호스트는 테스트 속도를 크게 향상시키며 특히 테스트 시작 시간을 단축합니다. Amazon Linux 2 호스트는 테스트 중에 더 뛰어난 안정성과 신뢰성 역시 보여줍니다. + **수동 테스트를 위한 향상된 원격 액세스**: 최신 테스트 호스트로 업그레이드하면 Android 수동 테스트의 지연 시간이 줄어들고 비디오 성능이 향상됩니다. + **표준 소프트웨어 버전 선택**: Device Farm은 이제 Appium 프레임워크 버전 뿐만 아니라 테스트 호스트의 주요 프로그래밍 언어 지원을 표준화합니다. 지원되는 언어(현재 Java, Python, Node.js, Ruby) 및 Appium의 경우 새 테스트 호스트는 출시 직후 장기간 안정적인 릴리스를 제공합니다. `devicefarm-cli` 툴을 이용한 중앙 집중식 버전 관리로 프레임워크 전반에서 일관되게 테스트 사양 파일을 개발할 수 있습니다. **Topics** + [Device Farm에서 Amazon Linux 2 테스트 환경에 지원되는 IP 범위](amazon-linux-2-ip-ranges.md) # Device Farm에서 Amazon Linux 2 테스트 환경에 지원되는 IP 범위 고객은 특히 방화벽 및 보안 설정을 구성하기 위해 Device Farm의 트래픽이 발생하는 IP 범위를 알아야 하는 경우가 많습니다. Amazon EC2 테스트 호스트의 경우 IP 범위는 전체 `us-west-2` 리전을 포함합니다. 새 Android 실행의 기본 옵션인 Amazon Linux 2 테스트 호스트의 경우 범위가 제한되었습니다. 이제 트래픽은 특정 NAT 게이트웨이 집합에서 시작되어 IP 범위를 다음 주소로 제한합니다. **** | IP 범위 | | --- | | **44.236.137.143** | | **52.13.151.244** | | **52.35.189.191** | | **54.201.250.26** | Device Farm의 Android 테스트 환경에 대한 자세한 내용은 [Android 디바이스용 테스트 환경](custom-test-environments-hosts-android.md) 섹션을 참조하세요. # iOS 디바이스용 테스트 환경 Device Farm은 테스트 실행 중에 iOS 디바이스에 동적으로 연결하는 Amazon 관리형 macOS 인스턴스(호스트)를 활용합니다. 각 호스트는 XCTestUI 및 Appium과 같은 널리 사용되는 다양한 테스트 플랫폼에서 디바이스 테스트를 지원하는 소프트웨어로 사전 구성되어 있습니다. iOS 테스트 호스트의 현재 반복은 다음을 포함하여 이전 버전과 비교할 때 테스트 환경을 개선했습니다. + ** iOS 15\$1iOS 26에 대한 일관된 호스트 OS 및 도구 사용 이전 ** 테스트 호스트는 사용 중인 디바이스에 의해 결정되어 여러 iOS 버전에서를 실행할 때 조각화된 소프트웨어 환경이 됩니다. 현재 경험을 통해 간단한 호스트 선택을 통해 디바이스 간에 일관된 환경을 구현할 수 있습니다. 이렇게 하면 각 iOS 디바이스에서 동일한 macOS 버전 및 도구(예: Xcode)를 사용할 수 있습니다. + ** iOS 15 및 16 테스트의 성능 개선 ** 업데이트된 인프라를 사용하여 iOS 15 및 16 테스트의 설정 시간이 크게 개선되었습니다. + ** 지원되는 종속성을 위한 선택 가능한 소프트웨어 버전 이제 ** iOS 및 Android 테스트 호스트 모두에 `devicefarm-cli` 소프트웨어 선택 시스템이 있으므로 지원되는 종속성을 원하는 버전으로 선택할 수 있습니다. 지원되는 종속성(예: Java, Python, Node.js, Ruby 및 Appium)의 경우 테스트 사양을 통해 버전을 선택할 수 있습니다. 이 기능의 작동 방식에 대한 자세한 내용은의 주제를 참조하세요[사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md). **중요** iOS 18 이하에서를 실행하는 경우 기본적으로 레거시 테스트 호스트에서 테스트가 실행됩니다. 레거시 호스트에서 마이그레이션하는 방법은 아래 주제를 참조하세요. ## 레거시 iOS 테스트 호스트 iOS 18 이하의 기존 테스트의 경우 사용자 지정 테스트 환경에 대해 레거시 테스트 호스트가 기본적으로 선택됩니다. 다음 표에는 iOS 디바이스 버전에서를 사용하여 실행되는 테스트 호스트 버전이 나와 있습니다. | 운영 체제 | 아키텍처(들) | 디바이스의 기본값 | | --- | --- | --- | | macOS Sonoma (버전 14) | arm64 | iOS 18 | | macOS Ventura (버전 13) | arm64 | iOS 17 | | macOS Monterey (버전 12) | x86\$164 | iOS 16 이하 | 최신 테스트 호스트를 선택하려면 관련 주제를 참조하세요[사용자 지정 테스트 환경을 새 iOS 테스트 호스트로 마이그레이션](ios-host-migration.md). ## iOS 디바이스에 지원되는 소프트웨어 iOS 디바이스 테스트를 지원하기 위해 iOS 디바이스용 Device Farm 테스트 호스트는 Xcode 및 관련 명령줄 도구로 사전 구성되어 있습니다. 사용 가능한 다른 소프트웨어는 관련 주제를 검토하세요[사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md). # 사용자 지정 테스트 환경을 새 iOS 테스트 호스트로 마이그레이션 기존 테스트를 레거시 호스트에서 새 macOS 테스트 호스트로 마이그레이션하려면 기존 테스트 사양 파일을 기반으로 새 테스트 사양 파일을 개발해야 합니다. 권장 접근 방식은 원하는 테스트 유형에 대한 예제 테스트 사양 파일로 시작한 다음 이전 테스트 사양 파일에서 새 테스트 사양 파일로 관련 명령을 마이그레이션하는 것입니다. 이를 통해 기존 코드 조각을 재사용하는 동안 새 호스트에 대한 예제 테스트 사양의 새로운 기능과 최적화를 활용할 수 있습니다. **Topics** + [자습서: 콘솔을 사용하여 iOS 테스트 사양 파일 마이그레이션](#ios-host-migration-console-tutorial) + [새 테스트 호스트와 레거시 테스트 호스트 간의 차이점](#ios-host-migration-differences) ## 자습서: 콘솔을 사용하여 iOS 테스트 사양 파일 마이그레이션 이 예제에서는 Device Farm 콘솔을 사용하여 기존 iOS 디바이스 테스트 사양을 온보딩하고 새 테스트 호스트를 사용합니다. ### 1단계: 콘솔을 사용하여 새 테스트 사양 파일 생성 1. [AWS Device Farm 콘솔](https://console.aws.amazon.com/devicefarm)에 로그인합니다. 1. 자동화 테스트가 포함된 Device Farm 프로젝트로 이동하세요. 1. 온보딩하려는 기존 테스트 사양의 사본을 다운로드합니다. 1. "프로젝트 설정" 옵션을 클릭하고 **업로드** 탭으로 이동합니다. 1. 온보딩하려는 테스트 사양 파일로 이동합니다. 1. **다운로드** 버튼을 클릭하여이 파일의 로컬 사본을 만듭니다. 1. 프로젝트 페이지로 돌아가서 **실행 생성을** 클릭합니다. 1. 새 실행을 시작하는 것처럼 마법사의 옵션을 채우고 **테스트 사양 선택** 옵션에서 중지합니다. 1. 기본적으로 선택한 iOS 테스트 사양을 사용하여 **테스트 사양 생성** 버튼을 클릭합니다. 1. 텍스트 편집기에서 *기본적으로* 선택한 테스트 사양을 수정합니다. 1. 아직 없는 경우 다음을 사용하여 새 호스트를 선택하도록 테스트 사양 파일을 수정합니다. ``` ios_test_host: macos_sequoia ``` 1. 이전 단계에서 다운로드한 테스트 사양 사본에서 각를 검토합니다` phase`. 1. 이전 테스트 사양 단계의 명령을 새 테스트 사양의 각 단계로 복사하고 Java, Python, Node.js, Ruby, Appium 또는 Xcode 설치 또는 선택과 관련된 명령은 무시합니다. 1. **다른 이름으로 저장** 텍스트 상자에 새 파일 이름을 입력합니다. 1. **새 이름으로 저장** 버튼을 클릭하여 변경 사항을 저장합니다. 참조로 사용할 수 있는 테스트 사양 파일의 예는에 제공된 예제를 참조하세요[테스트 사양 예제](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example). ### 2단계: 소프트웨어 사전 설치 소프트웨어 선택 새 테스트 호스트에서 사전 설치된 소프트웨어 버전은 라는 새로운 표준화된 버전 관리 도구를 사용하여 선택됩니다`devicefarm-cli`. 이제이 도구는 테스트 호스트에서 제공하는 다양한 소프트웨어를 사용하기 위한 권장 접근 방식입니다. 예를 들어 테스트 환경의 다른 JDK 17을 사용하려면 다음 줄을 추가합니다. ``` - devicefarm-cli use java 17 ``` 지원되는 소프트웨어에 대한 자세한 내용은 단원을 참조하십시오[사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md). ### 3단계: 소프트웨어 선택 도구를 통해 Appium 및 해당 종속성 사용 새 테스트 호스트는 Appium 2.x 이상만 지원합니다. 와 같은 레거시 도구를 제거하는 `devicefarm-cli`동안를 사용하여 Appium 버전을 명시적으로 선택하십시오` avm`. 예제: ``` # This line using 'avm' should be removed # - avm 2.3.1 # And the following lines should be added - devicefarm-cli use appium 2 # Selects the version - appium --version # Prints the version ``` 에서 선택한 Appium 버전에는 호환되는 버전의 iOS용 XCUITest 드라이버가 사전 설치되어 `devicefarm-cli` 있습니다. 또한 ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` 대신를 사용하도록 테스트 사양을 업데이트해야 합니다` DEVICEFARM_WDA_DERIVED_DATA_PATH`. 새 환경 변수는 Appium 2 테스트에 지원되는 최신 버전인 WebDriverAgent 9.x의 사전 빌드 버전을 가리킵니다. 자세한 내용은 [iOS 테스트를 위한 WebDriverAgent 버전 선택](test-types-appium.md#test-types-appium-select-wda) 및 단원을 참조하십시오[Appium 테스트를 위한 환경 변수](custom-test-environment-variables.md#custom-test-environment-variables-appium). ## 새 테스트 호스트와 레거시 테스트 호스트 간의 차이점 새 iOS 테스트 호스트를 사용하도록 테스트 사양 파일을 편집하고 레거시 테스트 호스트에서 테스트를 전환할 때는 다음과 같은 주요 환경 차이점에 유의하세요. + ** Xcode 버전: ** 레거시 테스트 호스트 환경에서 사용 가능한 Xcode 버전은 테스트에 사용된 디바이스의 iOS 버전을 기반으로 했습니다. 예를 들어 iOS 18 디바이스의 테스트는 레거시 호스트에서 Xcode 16을 사용한 반면 iOS 17의 테스트는 Xcode 15를 사용했습니다. 새 호스트 환경에서는 모든 디바이스가 동일한 버전의 Xcode에 액세스할 수 있으므로 버전이 다른 디바이스에 대한 테스트를 위한 일관된 환경이 가능합니다. 현재 사용 가능한 Xcode 버전 목록은 섹션을 참조하세요[지원 소프트웨어](custom-test-environments-hosts-software.md). + ** 소프트웨어 버전 선택: ** 대부분의 경우 기본 소프트웨어 버전이 변경되었으므로 이전에 레거시 테스트 호스트에서 소프트웨어 버전을 명시적으로 선택하지 않은 경우를 사용하여 새 테스트 호스트에서 소프트웨어 버전을 지정할 수 있습니다[`devicefarm-cli`](custom-test-environments-hosts-software-cli.md). 대부분의 사용 사례에서 고객이 사용하는 소프트웨어 버전을 명시적으로 선택하는 것을 권장합니다. 를 사용하여 소프트웨어 버전을 선택하면 예측 가능하고 일관된 경험을 할 수 있으며 Device Farm`devicefarm-cli`이 테스트 호스트에서 해당 버전을 제거하려는 경우 충분한 양의 경고를 받을 수 있습니다. 또한, 새로운 ` devicefarm-cli` 소프트웨어 선택 시스템을 위해 `nvm`, `pyenv`, ` avm`, `rvm`과 같은 소프트웨어 선택 도구가 제거되었습니다. + ** 사용 가능한 소프트웨어 버전: ** 이전에 사전 설치된 소프트웨어의 많은 버전이 제거되었으며 많은 새 버전이 추가되었습니다. 따라서 `devicefarm-cli`를 사용하여 소프트웨어 버전을 선택할 때는 [지원되는 버전 목록](custom-test-environments-hosts-software.md)에 있는 버전을 선택해야 합니다. + 최신 iOS 디바이스 테스트 및 업계 표준을 추적하기 위한 최신/일방 도구를 위해** 도구 `libimobiledevice` 모음이 제거되었습니다**. iOS 17 이상의 경우 대부분의 명령을 마이그레이션하여 라는 유사한 Xcode 도구를 사용할 수 있습니다`devicectl`. 에 대한 자세한 내용은 Xcode`xcrun devicectl help`가 설치된 시스템에서 실행할 `devicectl`수 있습니다. + 레거시 호스트 테스트 사양 파일에서 절대** 경로로 하드 코딩된 ** 파일 경로는 새 테스트 호스트에서 예상대로 작동하지 않을 가능성이 높으며 일반적으로 테스트 사양 파일 사용에 권장되지 않습니다. 모든 테스트 사양 파일 코드에 상대 경로와 환경 변수를 사용하는 것이 좋습니다. 자세한 내용은의 주제를 검토하세요[사용자 지정 테스트 환경 실행 모범 사례](custom-test-environments-best-practices.md). + ** 운영 체제 버전 및 아키텍처: ** 레거시 테스트 호스트는 할당된 디바이스를 기반으로 다양한 macOS 버전 및 CPU 아키텍처를 사용하고 있었습니다. 따라서 사용자는 환경에서 사용 가능한 시스템 라이브러리에서 몇 가지 차이를 발견할 수 있습니다. 이전 호스트 OS 버전에 대한 자세한 내용은 단원을 참조하십시오[레거시 iOS 테스트 호스트](custom-test-environments-hosts-ios.md#legacy-ios-host). + **Appium 사용자의 경우** WebDriverAgent를 선택하는 방법이 이전 접두사 ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` 대신 사용 환경 변수 ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` 접두사로 변경되었습니다. 업데이트된 변수에 대한 자세한 내용은 단원을 참조하십시오[Appium 테스트를 위한 환경 변수](custom-test-environment-variables.md#custom-test-environment-variables-appium). + **Appium Java 사용자의 경우** 새 테스트 호스트는 클래스 경로에 사전 설치된 JAR 파일을 포함하지 않는 반면, 이전 호스트는 TestNG 프레임워크용 파일을 포함합니다(환경 변수를 통해`$DEVICEFARM_TESTNG_JAR`). 테스트 프레임워크에 필요한 JAR 파일을 테스트 패키지 내에 패키징하고 테스트 사양 파일에서 `$DEVICEFARM_TESTNG_JAR` 변수 인스턴스를 제거하는 것이 좋습니다. 소프트웨어 관점에서 테스트 호스트 간의 차이점에 대한 피드백이나 질문이 있는 경우 지원 사례를 통해 서비스 팀에 문의하는 것이 좋습니다. # IAM 실행 역할을 사용하여 AWS 리소스에 액세스 Device Farm은 테스트 실행 중에 사용자 지정 테스트 런타임 환경에서 수임할 IAM 역할 지정을 지원합니다. 이 기능을 사용하면 테스트가 Amazon S3 버킷, DynamoDB 테이블 또는 애플리케이션이 의존하는 기타 AWS 서비스와 같은 계정의 AWS 리소스에 안전하게 액세스할 수 있습니다. **Topics** + [개요](#iam-execution-role-overview) + [IAM 역할 요구 사항](#iam-role-requirements) + [IAM 실행 역할 구성](#configuring-iam-execution-role) + [모범 사례](#iam-role-best-practices) + [문제 해결](#troubleshooting-iam-roles) ## 개요 IAM 실행 역할을 지정하면 Device Farm은 테스트 실행 중에이 역할을 수임하여 테스트가 역할에 정의된 권한을 사용하여 AWS 서비스와 상호 작용할 수 있도록 합니다. IAM 실행 역할의 일반적인 사용 사례는 다음과 같습니다. + Amazon S3 버킷에 저장된 테스트 데이터 액세스 + Amazon S3 버킷에 테스트 아티팩트 푸시 + AWS AppConfig에서 애플리케이션 구성 검색 + Amazon CloudWatch에 테스트 로그 및 지표 작성 + Amazon SQS 대기열로 테스트 결과 또는 상태 메시지 전송 + 테스트 워크플로의 일부로 AWS Lambda 함수 호출 ## IAM 역할 요구 사항 Device Farm에서 IAM 실행 역할을 사용하려면 역할이 다음 요구 사항을 충족해야 합니다. + **신뢰 관계**: 역할을 수임하려면 Device Farm 서비스 보안 주체를 신뢰해야 합니다. 신뢰 정책은를 신뢰할 수 있는 엔`devicefarm.amazonaws.com`터티로 포함해야 합니다. + **권한**: 역할에는 테스트에 필요한 AWS 리소스에 액세스하는 데 필요한 권한이 있어야 합니다. + **세션 기간**: 역할의 최대 세션 기간은 Device Farm 프로젝트의 작업 제한 시간 설정보다 길어야 합니다. 기본적으로 Device Farm 프로젝트의 작업 제한 시간은 150분이므로 역할은 최소 150분의 세션 기간을 지원해야 합니다. + **동일한 계정 요구 사항**: IAM 역할은 Device Farm을 호출하는 데 사용된 것과 동일한 AWS 계정에 있어야 합니다. 교차 계정 역할 가정은 지원되지 않습니다. + **PassRole 권한**: 호출자는 지정된 실행 역할에 대한 `iam:PassRole` 작업을 허용하는 정책을 통해 IAM 역할을 전달할 권한이 있어야 합니다. ### 신뢰 정책 예제 다음 예제에서는 Device Farm이 실행 역할을 수임하도록 허용하는 신뢰 정책을 보여줍니다. 이 신뢰 정책은 Device Farm과 함께 사용하려는 특정 IAM 역할에만 연결되어야 하며 계정의 다른 역할에는 연결되지 않아야 합니다. **Example** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "devicefarm.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ### 권한 정책 예 다음 예제는 테스트에 사용되는 일반적인 AWS 서비스에 대한 액세스 권한을 부여하는 권한 정책을 보여줍니다. **Example** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-test-bucket", "arn:aws:s3:::my-test-bucket/*" ] }, { "Effect": "Allow", "Action": [ "appconfig:GetConfiguration", "appconfig:StartConfigurationSession" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/devicefarm/test-*" }, { "Effect": "Allow", "Action": [ "sqs:SendMessage", "sqs:GetQueueUrl" ], "Resource": "arn:aws:sqs:*:*:test-results-*" } ] } ``` ## IAM 실행 역할 구성 프로젝트 수준에서 또는 개별 테스트 실행에 대해 IAM 실행 역할을 지정할 수 있습니다. 프로젝트 수준에서 구성하면 해당 프로젝트 내의 모든 실행이 실행 역할을 상속합니다. 실행에 구성된 실행 역할은 상위 프로젝트에 구성된를 대체합니다. 실행 역할 구성에 대한 자세한 지침은 다음을 참조하세요. + [AWS Device Farm에서 프로젝트 생성](how-to-create-project.md) - 프로젝트 수준에서 실행 역할 구성 + [Device Farm에서 테스트 실행 생성](how-to-create-test-run.md) - 개별 실행에 대한 실행 역할 구성 Device Farm API를 사용하여 실행 역할을 구성할 수도 있습니다. 자세한 내용은 [Device Farm API](https://docs.aws.amazon.com/devicefarm/latest/APIReference/) 참조를 참조하세요. ## 모범 사례 Device Farm 테스트에 대한 IAM 실행 역할을 구성할 때 다음 모범 사례를 따르세요. + **최소 권한 원칙**: 테스트가 작동하는 데 필요한 최소 권한만 부여합니다. `*` 작업이나 리소스와 같이 지나치게 광범위한 권한을 사용하지 마세요. + **리소스별 권한 사용**: 가능하면 유형의 모든 리소스가 아닌 특정 리소스(예: 특정 S3 버킷 또는 DynamoDB 테이블)로 권한을 제한합니다. + **별도의 테스트 및 프로덕션 리소스**: 전용 테스트 리소스와 역할을 사용하여 테스트 중에 실수로 프로덕션 시스템에 영향을 미치지 않도록 합니다. + **정기적인 역할 검토**: 실행 역할을 정기적으로 검토하고 업데이트하여 테스트 요구 사항을 여전히 충족하고 보안 모범 사례를 따르도록 합니다. + **조건 키 사용**: IAM 조건 키를 사용하여 역할을 사용할 수 있는 시기와 방법을 추가로 제한하는 것이 좋습니다. ## 문제 해결 IAM 실행 역할에 문제가 발생하면 다음을 확인하세요. + **신뢰 관계**: 역할의 신뢰 정책에가 신뢰할 `devicefarm.amazonaws.com` 수 있는 서비스로 포함되어 있는지 확인합니다. + **권한**: 역할에 테스트가 액세스하려는 AWS 서비스에 필요한 권한이 있는지 확인합니다. + **테스트 로그**: 테스트 실행 로그에서 AWS API 호출 또는 권한 거부와 관련된 특정 오류 메시지를 검토합니다. # 사용자 지정 테스트 환경을 위한 환경 변수 Device Farm은 사용자 지정 테스트 환경 실행의 일부로 사용할 수 있도록 여러 환경 변수를 동적으로 구성합니다. **Topics** + [사용자 지정 환경 변수](#custom-test-environment-variables-custom) + [공통 환경 변수](#custom-test-environment-variables-common) + [Appium 테스트를 위한 환경 변수](#custom-test-environment-variables-appium) + [XCUITest 테스트를 위한 환경 변수](#custom-test-environment-variables-xcuitest) ## 사용자 지정 환경 변수 Device Farm은 테스트 호스트에서 환경 변수로 적용되는 키-값 페어의 구성을 지원합니다. 이는 Device Farm 프로젝트 또는 실행 생성 중에 구성할 수 있습니다. 실행에 구성된 모든 변수는 상위 프로젝트에 구성될 수 있는 모든 변수를 대체합니다. 다음과 같은 제한 사항이 있습니다. + 사용자 지정 환경 변수는 레거시 iOS 테스트 호스트에서 지원되지 않습니다. 자세한 내용은 [레거시 iOS 테스트 호스트](custom-test-environments-hosts-ios.md#legacy-ios-host) 단원을 참조하십시오. + 로 시작하는 변수 이름은 내부 서비스용으로 예약`$DEVICEFARM_`되어 있습니다. + 사용자 지정 환경 변수는 테스트 사양에서 테스트 호스트 컴퓨팅 선택을 구성하는 데 사용되지 않을 수 있습니다. ## 공통 환경 변수 이 섹션에서는 Device Farm의 모든 테스트에 공통적인 환경 변수를 설명합니다. ** `$DEVICEFARM_DEVICE_NAME` ** 테스트가 실행되는 디바이스입니다. 디바이스의 고유 디바이스 식별자(UDID)를 나타냅니다. ** `$DEVICEFARM_DEVICE_UDID` ** 디바이스의 고유 식별자입니다. ** `$DEVICEFARM_DEVICE_PLATFORM_NAME` ** 디바이스의 플랫폼 이름입니다. `Android` 또는 입니다`iOS`. ** `$DEVICEFARM_DEVICE_OS_VERSION` ** 디바이스의 OS 버전입니다. ** `$DEVICEFARM_APP_PATH` ** *(모바일 앱 테스트)* 테스트가 실행되고 있는 호스트 머신의 모바일 앱 경로 웹 테스트 중에는이 변수를 사용할 수 없습니다. ** `$DEVICEFARM_LOG_DIR` ** 고객 로그, 아티팩트 및 기타 원하는 파일이 나중에 검색할 수 있도록 저장되는 기본 디렉터리의 경로입니다. [예제 테스트 사양을](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) 사용하면이 디렉터리의 파일이 ZIP 파일에 아카이브되고 테스트 실행 후 아티팩트로 사용할 수 있습니다. ** `$DEVICEFARM_SCREENSHOT_PATH` ** 테스트 실행 중에 캡처되는 스크린샷이 있는 경우의 경로입니다. ** `$DEVICEFARM_PROJECT_ARN` ** 작업의 상위 프로젝트의 ARN입니다. ** `$DEVICEFARM_RUN_ARN` ** 작업 상위 실행의 ARN입니다. ** `$DEVICEFARM_DEVICE_ARN` ** 테스트 중인 디바이스의 ARN입니다. ** `$DEVICEFARM_TOTAL_JOBS` ** 상위 Device Farm 실행과 연결된 총 작업 수입니다. ** `$DEVICEFARM_JOB_NUMBER` ** 내이 작업의 번호입니다`$DEVICEFARM_TOTAL_JOBS`. 예를 들어 실행에는 5개의 작업이 포함될 수 있으며 각 작업의 고유한 `$DEVICEFARM_JOB_NUMBER` 범위는 0\$14입니다. ** `$AWS_REGION` ** AWS 리전입니다. 서비스는 테스트 중인 디바이스가 위치한 리전과 일치하도록 이를 설정합니다. 필요한 경우 사용자 지정 환경 변수로 재정의할 수 있습니다. ** `$ANDROID_HOME` ** *(Android만 해당)* Android SDK 설치 디렉터리의 경로 ## Appium 테스트를 위한 환경 변수 이 섹션에서는 Device Farm의 사용자 지정 테스트 환경에서 모든 Appium 테스트에 사용되는 환경 변수를 설명합니다. ** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` ** *(Android만 해당)* Appium 웹 및 하이브리드 테스트에 사용하는 데 필요한 ChromeDriver 실행 파일이 포함된 디렉터리의 위치입니다. ** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` ** *(iOS만 해당)* Device Farm에서 실행되도록 구축된 WebDriverAgent 버전의 파생 데이터 경로입니다. 변수의 번호는 WebDriverAgent의 메이저 버전에 해당합니다. 예를 들어 `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9`는 WebDriverAgent 버전 9.x를 가리킵니다. 자세한 내용은 [iOS 테스트를 위한 WebDriverAgent 버전 선택](test-types-appium.md#test-types-appium-select-wda) 단원을 참조하십시오. `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` 환경 변수는 레거시가 아닌 iOS 호스트에만 존재합니다. 자세한 내용은 [레거시 iOS 테스트 호스트](custom-test-environments-hosts-ios.md#legacy-ios-host) 단원을 참조하십시오. ** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` ** *(iOS 전용, 더 이상 사용되지 않음)* Device Farm에서 실행되도록 구축된 WebDriverAgent 버전의 파생 데이터 경로입니다. 대체 이름 지정 체계는 섹션을 참조`$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V`하세요. ## XCUITest 테스트를 위한 환경 변수 이 섹션에서는 Device Farm의 사용자 지정 테스트 환경에서 XCUITest 테스트에 사용되는 환경 변수를 설명합니다. ** `$DEVICEFARM_XCUITESTRUN_FILE` ** Device Farm `.xctestun` 파일의 경로입니다. 앱 및 테스트 패키지에서 생성됩니다. ** `$DEVICEFARM_DERIVED_DATA_PATH` ** Device Farm xcodebuild 출력의 예상되는 경로 ** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` ** 테스트 패키지 파일의 압축을 푼 콘텐츠의 경로 # 사용자 지정 테스트 환경 실행 모범 사례 다음 주제에서는 Device Farm에서 사용자 지정 테스트 실행을 사용하기 위한 권장 모범 사례를 다룹니다. **실행 구성** + 테스트 사양 파일의 셸 명령을 통해 유사한** 구성을 적용하는 대신 가능한 경우 실행 구성을 위해 Device Farm 관리형 소프트웨어 및 API 기능을 사용합니다**. 여기에는 테스트 호스트 및 디바이스의 구성이 포함됩니다. 테스트 호스트 및 디바이스에서 더 지속 가능하고 일관되기 때문입니다. Device Farm은 테스트를 실행하는 데 필요한 만큼 테스트 사양 파일을 사용자 지정하는 것을 권장하지만, 사용자 지정 명령이 추가되면 시간이 지남에 따라 테스트 사양 파일을 유지하기 어려울 수 있습니다. Device Farm 관리형 소프트웨어 사용(와 같은 도구 ` devicefarm-cli` 및에서 사용 가능한 기본 도구를 통해`$PATH`) 및 관리형 기능(예: [https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy) 요청 파라미터)을 사용하여 유지 관리 책임을 Device Farm 자체로 전환하여 테스트 사양 파일을 간소화합니다. **테스트 사양 및 테스트 패키지 코드** + **절대 경로를 사용하거나 테스트 사양 파일 또는 테스트 패키지 코드의 특정 마이너 버전에 의존하지 마십시오**. Device Farm은 선택한 테스트 호스트와 포함된 소프트웨어 버전에 정기 업데이트를 적용합니다. 특정 또는 절대 경로(예: ` /usr/local/bin/python` 대신`python`)를 사용하거나 특정 마이너 버전(예: Node.js `20.3.1` 대신)을 요구하면 테스트에서 필요한 실행 파일/파일을 찾지 못할 ` 20`수 있습니다. 사용자 지정 테스트 실행의 일환으로 Device Farm은 다양한 환경 변수와 `$PATH` 변수를 설정하여 테스트가 동적 환경 내에서 일관된 경험을 갖도록 합니다. 자세한 내용은 [사용자 지정 테스트 환경을 위한 환경 변수](custom-test-environment-variables.md) 및 [사용자 지정 테스트 환경 내에서 지원되는 소프트웨어](custom-test-environments-hosts-software.md) 섹션을 참조하세요. + **테스트 실행 중에 생성되거나 복사된 파일을 임시 디렉터리 내에 저장합니다. ** 오늘은 테스트 실행 중에 사용자가 임시 디렉터리(`/tmp`)에 액세스할 수 있도록 합니다(와 같은 관리형 디렉터리 제외`$DEVICEFARM_LOG_DIR`). 사용자가 액세스할 수 있는 다른 디렉터리는 사용 중인 서비스 또는 운영 체제의 요구로 인해 시간이 지남에 따라 변경될 수 있습니다. + **테스트 실행 로그를에 저장합니다`$DEVICEFARM_LOG_DIR`**. 실행 로그/아티팩트를 추가하기 위해 실행에 제공되는 기본 아티팩트 디렉터리입니다. 제공하는 [예제 테스트 사양](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example)은 기본적으로 아티팩트에이 디렉터리를 사용합니다. + 테스트 사양 `test` 단계에서 **명령이 실패 시 0이 아닌 코드를 반환하는지 확인합니다**. `test` 단계 중에 호출된 각 셸 명령의 0이 아닌 종료 코드를 확인하여 실행이 실패했는지 확인합니다. 로직 또는 테스트 프레임워크가 원하는 모든 시나리오에 대해 0이 아닌 종료 코드를 반환하는지 확인해야 합니다. 그러면 추가 구성이 필요할 수 있습니다. 예를 들어 특정 테스트 프레임워크(예: JUnit5)는 제로 테스트 실행을 실패로 간주하지 않으므로 실행된 테스트가 없더라도 테스트가 성공적으로 실행된 것으로 감지됩니다. JUnit5를 예제로 사용하면이 시나리오가 0이 아닌 종료 코드로 종료`--fail-if-no-tests`되도록 명령줄 옵션을 지정해야 합니다. + 테스트 실행에 사용할 디바이스 OS 버전 및 테스트 호스트 버전과 **소프트웨어의 호환성을 검토합니다**. 예를 들어 소프트웨어 프레임워크(예: Appium)를 테스트할 때 테스트 중인 디바이스의 모든 OS 버전에서 의도한 대로 작동하지 않을 수 있는 특정 기능이 있습니다. **보안** + ** 테스트 사양 파일에 민감한 변수(예: AWS 키)를 저장하거나 로깅하지 마세요. ** 테스트 사양 파일, 테스트 사양 생성 스크립트 및 테스트 사양 스크립트의 로그는 모두 테스트 실행이 끝날 때 다운로드 가능한 아티팩트로 제공됩니다. 이로 인해 테스트 실행에 대한 읽기 액세스 권한이 있는 계정의 다른 사용자에게 의도하지 않은 보안 암호가 노출될 수 있습니다. # 표준 환경에서 사용자 지정 테스트 환경으로 테스트 마이그레이션 AWS Device Farm에서 표준 테스트 실행 모드에서 사용자 지정 실행 모드로 전환할 수 있습니다. 마이그레이션에는 주로 두 가지 다른 형태의 실행이 포함됩니다. 1. **표준 모드**: 이 테스트 실행 모드는 주로 고객에게 세분화된 보고 및 완전히 관리되는 환경을 제공하기 위해 구축되었습니다. 1. **사용자 지정 모드**: 이 테스트 실행 모드는 더 빠른 테스트 실행, 리프트 앤 시프트 기능, 로컬 환경과 동등한 수준 달성, 라이브 비디오 스트리밍이 필요한 다양한 사용 사례에 맞게 구축되었습니다. Device Farm의 표준 및 사용자 지정 모드에 대한 자세한 내용은 [AWS Device Farm의 테스트 환경](test-environments.md) 및 [AWS Device Farm의 사용자 지정 테스트 환경](custom-test-environments.md) 섹션을 참조하세요. ## 마이그레이션 시 고려 사항 이 섹션에는 사용자 지정 모드로 마이그레이션할 때 고려해야 할 몇 가지 주요 사용 사례가 나열되어 있습니다. 1. **속도**: 표준 실행 모드에서 Device Farm은 특정 프레임워크의 패키징 지침을 사용하여 패키징하고 업로드한 테스트의 메타데이터를 파싱합니다. 파싱은 패키지의 테스트 수를 감지합니다. 이후 Device Farm은 각 테스트를 개별적으로 실행하고 각 테스트에 대한 로그, 비디오 및 기타 결과 아티팩트를 개별적으로 표시합니다. 하지만 서비스 측에서 테스트 및 결과 아티팩트를 사전 및 사후 처리해야 하므로 전체 엔드 투 엔드 테스트 실행 시간이 꾸준히 늘어납니다. 반대로 사용자 지정 실행 모드는 테스트 패키지를 파싱하지 않으므로 테스트 또는 결과 아티팩트에 대한 사전 처리가 필요 없고 사후 처리가 최소화됩니다. 따라서 엔드 투 엔드 총 실행 시간이 로컬 설정과 비슷해집니다. 테스트는 로컬 시스템에서 실행할 때와 동일한 형식으로 실행됩니다. 테스트 결과는 로컬에서 얻은 결과와 동일하며 작업 실행 종료 시 다운로드할 수 있습니다. 1. **사용자 지정 또는 유연성**: 표준 실행 모드는 테스트 패키지를 파싱하여 테스트 수를 감지한 다음 각 테스트를 개별적으로 실행합니다. 단, 테스트가 지정한 순서대로 실행된다는 보장은 없습니다. 따라서 특정 실행 시퀀스가 필요한 테스트는 예상대로 작동하지 않을 수 있습니다. 또한 호스트 컴퓨터 환경을 사용자 지정하거나 특정 방식으로 테스트를 실행하는 데 필요할 수 있는 구성 파일을 전달할 방법도 없습니다. 반면 사용자 지정 모드에서는 추가 소프트웨어 설치, 테스트에 필터 전달, 구성 파일 전달, 테스트 실행 설정 제어 등의 기능을 비롯한 호스트 컴퓨터 환경을 구성할 수 있습니다. 이 작업은 YAML 파일(testspec 파일이라고도 함)을 통해 수행되며, 이 파일에 쉘 명령을 추가하여 수정할 수 있습니다. 이 YAML 파일은 테스트 호스트 시스템에서 실행되는 쉘 스크립트로 변환됩니다. 여러 YAML 파일을 저장하고 실행을 예약할 때 요구 사항에 따라 동적으로 하나를 선택할 수 있습니다. 1. **라이브 비디오 및 로깅**: 표준 실행 모드와 사용자 지정 실행 모드 모두 테스트에 필요한 비디오와 로그를 제공합니다. 하지만 표준 모드에서는 테스트가 완료된 후에만 테스트의 비디오 및 사전 정의된 로그를 얻을 수 있습니다. 반면 사용자 지정 모드에서는 비디오의 실시간 스트림과 테스트의 클라이언트 측 로그를 제공합니다. 또한 테스트 종료 시 비디오 및 기타 아티팩트를 다운로드할 수 있습니다. **작은 정보** 사용 사례에 위의 요인 중 하나 이상이 포함되는 경우 사용자 지정 실행 모드로 전환하는 것이 좋습니다. ## 마이그레이션 단계 표준 모드에서 사용자 지정 모드로 마이그레이션하려면 다음을 수행합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/) Device Farm 콘솔을 엽니다. 1. 프로젝트를 선택한 다음 새 자동화 실행을 시작하세요. 1. 앱을 업로드(또는 `web app`을 선택)하고 테스트 프레임워크 유형을 선정하여 테스트 패키지를 업로드한 다음, `Choose your execution environment` 파라미터 아래에서 옵션을 `Run your test in a custom environment`로 선택합니다. 1. 기본적으로 Device Farm의 예제 테스트 사양 파일이 표시되어 보고 편집할 수 있습니다. 이 예제 파일은 [사용자 지정 환경 모드](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html)에서 테스트를 시험해 보기 위한 출발점으로 사용할 수 있습니다. 그런 다음 콘솔에서 테스트가 제대로 작동하는지 확인한 후에는 Device Farm과의 API, CLI 및 파이프라인 통합을 변경하여 테스트 실행을 예약할 때 이 테스트 사양 파일을 파라미터로 사용할 수 있습니다. 테스트 사양 파일을 실행용 파라미터로 추가하는 방법에 대한 자세한 내용은 [API 가이드](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html)의 `ScheduleRun` API용 `testSpecArn` 파라미터 섹션을 참조하세요. ## Appium 프레임워크 사용자 지정 테스트 환경에서 Device Farm은 Appium 프레임워크 테스트에 Appium 기능을 삽입하거나 재정의하지 않습니다. 테스트 사양 YAML 파일 또는 테스트 코드에서 테스트의 Appium 기능을 지정해야 합니다. ## Android 계측 Android 계측 테스트를 사용자 지정 테스트 환경으로 이동할 때 변경이 필요하지 않습니다. ## iOS XCUITest iOS XCUITest 테스트를 사용자 지정 테스트 환경으로 이동할 때 변경이 필요하지 않습니다. # Device Farm의 사용자 지정 테스트 환경 확장 AWS Device Farm을 사용하면 모든 Device Farm 사용자에게 권장되는 접근 방식인 자동 테스트(사용자 지정 모드)를 위한 사용자 지정 환경을 구성할 수 있습니다. Device Farm 사용자 지정 모드를 사용하면 테스트 제품군 외에도 다양한 기능을 실행할 수 있습니다. 이 단원에서는 테스트 스위트를 확장하고 테스트를 최적화하는 방법을 알아봅니다. Device Farm의 사용자 지정 테스트 환경에 관한 자세한 내용은 [AWS Device Farm의 사용자 지정 테스트 환경](custom-test-environments.md) 섹션을 참조하세요. **Topics** + [Device Farm에서 테스트를 실행할 때 디바이스 PIN 설정](custom-test-environments-extending-set-pin.md) + [원하는 기능을 통해 Device Farm에서 Appium 기반 테스트 속도 향상](custom-test-environments-extending-speed.md) + [Device Farm에서 테스트 실행 후 Webhooks 및 기타 API 사용](custom-test-environments-extending-webhooks.md) + [Device Farm에서 테스트 패키지에 추가 파일 추가](custom-test-environments-extending-files.md) # Device Farm에서 테스트를 실행할 때 디바이스 PIN 설정 일부 응용 프로그램에서는 장치에 PIN을 설정해야 합니다. Device Farm은 기본적으로 장치에 PIN 설정을 지원하지 않습니다. 하지만 다음과 같은 경고 사항과 함께 가능합니다. + 디바이스는 Android 8 이상을 실행해야 합니다. + 테스트가 완료된 후 PIN을 제거해야 합니다. 테스트에서 PIN을 설정하려면 다음과 같이 `pre_test` 및 `post_test` 단계를 사용하여 PIN을 설정하고 제거합니다. ``` phases: pre_test: - # ... among your pre_test commands - DEVICE_PIN_CODE="1234" - adb shell locksettings set-pin "$DEVICE_PIN_CODE" post_test: - # ... Among your post_test commands - adb shell locksettings clear --old "$DEVICE_PIN_CODE" ``` 테스트 스위트가 시작되면 PIN 1234가 설정됩니다. 테스트 스위트가 종료되면 PIN이 제거됩니다. **주의** 테스트가 완료된 후 디바이스에서 PIN을 제거하지 않으면 디바이스와 계정이 격리됩니다. 테스트 제품군을 확장하고 테스트를 최적화하는 자세한 방법은 [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) 섹션을 참조하세요. # 원하는 기능을 통해 Device Farm에서 Appium 기반 테스트 속도 향상 Appium을 사용할 때 표준 모드 테스트 스위트가 매우 느릴 수 있습니다. 이는 Device Farm이 기본 설정을 적용하고 Appium 환경 사용 방법에 대해 어떠한 가정도 하지 않기 때문입니다. 이러한 기본값은 업계 모범 사례를 기반으로 구축되었지만 사용 상황에 따라 적용되지 않을 수 있습니다. Appium 서버의 파라미터를 미세 조정하려면 테스트 사양에서 기본 Appium 기능을 조정할 수 있습니다. 예를 들어 다음은 iOS 테스트 스위트에서 초기 시작 시간을 단축하기 위해 `usePrebuildWDA` 기능을 `true`로 설정합니다. ``` phases: pre_test: - # ... Start up Appium - >- appium --log-timestamp --default-capabilities "{\"usePrebuiltWDA\": true, \"derivedDataPath\":\"$DEVICEFARM_WDA_DERIVED_DATA_PATH\", \"deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \"platformName\":\"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \"app\":\"$DEVICEFARM_APP_PATH\", \"automationName\":\"XCUITest\", \"udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \"platformVersion\":\"$DEVICEFARM_DEVICE_OS_VERSION\"}" >> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 & ``` Appium 기능은 쉘로 이스케이프 처리되고 인용된 JSON 구조여야 합니다. 다음과 같은 Appium 기능은 성능 향상의 일반적인 출처입니다. `noReset` 및 `fullReset` 상호 배타적인 이 두 기능은 각 세션이 완료된 후 Appium의 동작을 설명합니다. `noReset`을 `true`로 설정하면 Appium 세션이 종료될 때 Appium 서버가 애플리케이션에서 데이터를 제거하지 않으므로 사실상 어떤 정리 작업도 수행하지 않습니다. `fullReset`은 세션이 종료된 후 장치에서 모든 애플리케이션 데이터를 제거하고 지웁니다. 자세한 내용은 Appium 설명서의 [재설정 전략](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/)을 참조하세요. `ignoreUnimportantViews`(Android만 해당) Appium에 Android UI 계층 구조를 테스트와 관련된 뷰로만 압축하여 특정 요소 조회 속도를 높이도록 지시합니다.** 하지만 이렇게 하면 UI 레이아웃의 계층 구조가 변경되어 일부 XPath 기반 테스트 스위트가 손상될 수 있습니다. `skipUnlock`(Android만 해당) Appium에 현재 설정된 PIN 코드가 없음을 알립니다. 이렇게 하면 화면 끄기 이벤트 또는 기타 잠금 이벤트 후 테스트 속도가 빨라집니다. `webDriverAgentUrl`(iOS만 해당) `webDriverAgent`인 필수 iOS 종속 항목이 이미 실행 중이고 지정된 URL에서 HTTP 요청을 수락할 수 있다고 가정하도록 Appium에 지시합니다. 아직 `webDriverAgent`가 실행되지 않은 경우 Appium의 테스트 스위트 초기에 `webDriverAgent`를 시작하는 데 시간이 걸릴 수 있습니다. Appium을 시작할 때 `webDriverAgent`를 직접 시작하고 `webDriverAgentUrl`을 `http://localhost:8100`로 설정하면 테스트 스위트를 더 빠르게 부팅할 수 있습니다. 참고로 이 기능을 `useNewWDA` 기능과 함께 사용해서는 안 됩니다. 다음 코드를 사용하여 디바이스의 로컬 포트 `8100`에 있는 테스트 사양 파일에서 `webDriverAgent`를 시작한 다음 테스트 호스트의 로컬 포트 `8100`로 전달할 수 있습니다(이렇게 하면 `webDriverAgentUrl` 값을 `http://localhost:8100`로 설정할 수 있음). 이 코드는 Appium 및 `webDriverAgent` 환경 변수를 설정하기 위한 코드를 정의한 후 설치 단계에서 실행해야 합니다. ``` # Start WebDriverAgent and iProxy - >- xcodebuild test-without-building -project /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -derivedDataPath $DEVICEFARM_WDA_DERIVED_DATA_PATH -destination id=$DEVICEFARM_DEVICE_UDID_FOR_APPIUM IPHONEOS_DEPLOYMENT_TARGET=$DEVICEFARM_DEVICE_OS_VERSION GCC_TREAT_WARNINGS_AS_ERRORS=0 COMPILER_INDEX_STORE_ENABLE=NO >> $DEVICEFARM_LOG_DIR/webdriveragent_log.txt 2>&1 & iproxy 8100 8100 >> $DEVICEFARM_LOG_DIR/iproxy_log.txt 2>&1 & ``` 그런 다음 테스트 사양 파일에 다음 코드를 추가하여 `webDriverAgent`가 성공적으로 시작되었는지 확인할 수 있습니다. Appium이 성공적으로 시작되었는지 확인한 후 사전 테스트 단계가 끝날 때 이 코드를 실행해야 합니다. ``` # Wait for WebDriverAgent to start - >- start_wda_timeout=0; while [ true ]; do if [ $start_wda_timeout -gt 60 ]; then echo "WebDriverAgent server never started in 60 seconds."; exit 1; fi; grep -i "ServerURLHere" $DEVICEFARM_LOG_DIR/webdriveragent_log.txt >> /dev/null 2>&1; if [ $? -eq 0 ]; then echo "WebDriverAgent REST http interface listener started"; break; else echo "Waiting for WebDriverAgent server to start. Sleeping for 1 seconds"; sleep 1; start_wda_timeout=$((start_wda_timeout+1)); fi; done; ``` Appium이 지원하는 기능에 대한 자세한 내용은 Appium 설명서의 [Appium 필요한 기능](http://appium.io/docs/en/writing-running-appium/caps/)을 참조하세요. 테스트 제품군을 확장하고 테스트를 최적화하는 자세한 방법은 [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) 섹션을 참조하세요. # Device Farm에서 테스트 실행 후 Webhooks 및 기타 API 사용 모든 테스트 스위트의 **curl** 사용이 완료된 후 Device Farm이 webhook을 호출하도록 할 수 있습니다. 이 작업을 수행하는 프로세스는 대상 및 형식에 따라 다릅니다. 특정 webhook에 대해서는 해당 Webhook의 설명서를 참조하세요. 다음 예제는 테스트 스위트가 완료될 때마다 Slack webhook에 메시지를 게시합니다. ``` phases: post_test: - curl -X POST -H 'Content-type: application/json' --data '{"text":"Tests on '$DEVICEFARM_DEVICE_NAME' have finished!"}' https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX ``` Slack에서 webhook를 사용하는 방법에 대한 자세한 내용은 Slack API 참조의 [Webhook을 사용하여 첫 번째 Slack 메시지 보내기](https://api.slack.com/tutorials/slack-apps-hello-world)를 참조하세요. 테스트 제품군을 확장하고 테스트를 최적화하는 자세한 방법은 [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) 섹션을 참조하세요. Webhook을 호출하는 용도로만 **curl**을 사용할 수 있는 것은 아닙니다. 테스트 패키지는 Device Farm 실행 환경과 호환되는 한 추가 스크립트 및 도구를 포함할 수 있습니다. 예를 들어 테스트 패키지에는 다른 API에 요청을 하는 보조 스크립트가 포함될 수 있습니다. 모든 필수 패키지가 테스트 스위트의 요구 사항과 함께 설치되어 있는지 확인하세요. 테스트 스위트가 완성된 후 실행되는 스크립트를 추가하려면 테스트 패키지에 스크립트를 포함하고 테스트 사양에 다음을 추가하세요. ``` phases: post_test: - python post_test.py ``` **참고** 테스트 패키지에 사용된 API 키 또는 기타 인증 토큰을 유지 관리하는 것은 사용자의 책임입니다. 모든 형태의 보안 인증 정보를 소스 제어에서 제외시키고, 권한이 가장 적은 자격 증명을 사용하며, 가능하면 취소 가능하고 수명이 짧은 토큰을 사용하는 것이 좋습니다. 보안 요구 사항을 확인하려면 사용하는 타사 API의 설명서를 참조하세요. 테스트 실행 제품군의 일부로 AWS 서비스를 사용하려는 경우 테스트 제품군 외부에서 생성되고 테스트 패키지에 포함된 IAM 임시 자격 증명을 사용해야 합니다. 이러한 자격 증명은 부여된 권한이 가장 적고 수명이 가장 짧아야 합니다. 임시 보안 인증 생성에 대한 자세한 내용은 IAM 사용 설명서의 [임시 보안 인증 요청](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html) 단원을 참조하세요.** 테스트 제품군을 확장하고 테스트를 최적화하는 자세한 방법은 [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) 섹션을 참조하세요. # Device Farm에서 테스트 패키지에 추가 파일 추가 추가 파일을 추가 구성 파일 또는 추가 테스트 데이터인 테스트 파일의 일부로 사용할 수 있습니다. AWS Device Farm에 업로드하기 전에 테스트 패키지에 이러한 추가 파일을 추가한 다음 사용자 지정 환경 모드에서 액세스할 수 있습니다. 기본적으로 모든 테스트 패키지 업로드 형식(ZIP, IPA, APK, JAR 등)은 표준 ZIP 작업을 지원하는 패키지 아카이브 형식입니다. 다음 명령을 AWS Device Farm 사용하여에 업로드하기 전에 테스트 아카이브에 파일을 추가할 수 있습니다. ``` $ zip zip-with-dependencies.zip extra_file ``` 추가 파일이 있는 디렉터리의 경우 ``` $ zip -r zip-with-dependencies.zip extra_files/ ``` 이 명령은 IPA 파일을 제외한 모든 테스트 패키지 업로드 형식에서 예상대로 작동합니다. IPA 파일의 경우, 특히 XCUITests와 함께 사용하는 경우가 iOS 테스트 패키지를 AWS Device Farm 해지하는 방식 때문에 추가 파일을 약간 다른 위치에 두는 것이 좋습니다. iOS 테스트를 빌드할 때 테스트 애플리케이션 디렉터리는 *Payload*라는 다른 디렉터리 내에 위치합니다. 예를 들어, iOS 테스트 디렉터리 중 하나는 다음과 같습니다. ``` $ tree . └── Payload └── ADFiOSReferenceAppUITests-Runner.app ├── ADFiOSReferenceAppUITests-Runner ├── Frameworks │ ├── XCTAutomationSupport.framework │ │ ├── Info.plist │ │ ├── XCTAutomationSupport │ │ ├── _CodeSignature │ │ │ └── CodeResources │ │ └── version.plist │ └── XCTest.framework │ ├── Info.plist │ ├── XCTest │ ├── _CodeSignature │ │ └── CodeResources │ ├── en.lproj │ │ └── InfoPlist.strings │ └── version.plist ├── Info.plist ├── PkgInfo ├── PlugIns │ ├── ADFiOSReferenceAppUITests.xctest │ │ ├── ADFiOSReferenceAppUITests │ │ ├── Info.plist │ │ └── _CodeSignature │ │ └── CodeResources │ └── ADFiOSReferenceAppUITests.xctest.dSYM │ └── Contents │ ├── Info.plist │ └── Resources │ └── DWARF │ └── ADFiOSReferenceAppUITests ├── _CodeSignature │ └── CodeResources └── embedded.mobileprovision ``` 이러한 XCUITest 패키지의 경우 *Payload* 디렉터리 안의 *.app*으로 끝나는 디렉터리에 추가 파일을 추가합니다. 예를 들어, 다음 명령은 이 테스트 패키지에 파일을 추가하는 방법을 보여줍니다. ``` $ mv extra_file Payload/*.app/ $ zip -r my_xcui_tests.ipa Payload/ ``` 테스트 패키지에 파일을 추가하면 업로드 형식에 따라 AWS Device Farm 에서 상호 작용 동작이 약간 다를 수 있습니다. 업로드에서 ZIP 파일 확장자를 사용한 경우 AWS Device Farm 이 테스트 전에 업로드의 압축을 자동으로 풀고 *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* 환경 변수가 있는 위치에 압축을 푼 파일을 둡니다. (즉, 첫 번째 예제에서처럼 아카이브의 루트에 *extra\$1file*이라는 파일을 추가하면 테스트 중에 해당 파일은 *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file*에 위치하게 됩니다). 좀 더 실용적인 예제를 사용하려면 테스트에 *testng.xml* 파일을 포함하려는 Appium TestNG 사용자인 경우 다음 명령을 사용하여 아카이브에 포함시킬 수 있습니다. ``` $ zip zip-with-dependencies.zip testng.xml ``` 그런 다음 사용자 지정 환경 모드에서 테스트 명령을 다음과 같이 변경할 수 있습니다. ``` java -D appium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output $DEVICEFARM_TEST_PACKAGE_PATH/testng.xml ``` 테스트 패키지 업로드 확장자가 ZIP이 아닌 경우(예: APK, IPA 또는 JAR 파일) 업로드된 패키지 파일 자체는 *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH*에서 찾을 수 있습니다. 이러한 파일은 여전히 아카이브 형식 파일이므로 파일 압축을 풀어 내에서 추가 파일에 액세스할 수 있습니다. 예를 들어 다음 명령은 테스트 패키지의 콘텐츠(APK, IPA 또는 JAR 파일용)를 */tmp* 디렉터리에 압축 해제합니다. ``` unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp ``` APK 또는 JAR 파일의 경우 */tmp 디렉터리*(예: */tmp/extra\$1file*)에 추가 파일이 압축 해제되어 있는 것을 확인할 수 있습니다. IPA 파일의 경우 앞서 설명한 것처럼 *Payload* 디렉터리 내에 있는 *.app*으로 끝나는 폴더 내에서는 추가 파일이 약간 다른 위치에 있게 됩니다. 예를 들어 위의 IPA 예를 기반으로 하면 파일은 */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file*(*/tmp/Payload/\$1.app/extra\$1file*로 참조 가능) 위치에서 찾을 수 있습니다. 테스트 제품군을 확장하고 테스트를 최적화하는 자세한 방법은 [Device Farm의 사용자 지정 테스트 환경 확장](custom-test-environments-extending.md) 섹션을 참조하세요.