翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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 形式のテスト仕様 (test spec) ファイルを使用して構成されます。Device Farm には、サポートされているテストタイプごとにデフォルトのテスト仕様ファイルが用意されており、そのまま使用できますが、テストフィルタや構成ファイルなどをカスタマイズしてテスト仕様に追加することもできます。編集したテスト仕様は、future テスト実行のために保存できます。 詳細については、「[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` - 自動テストの実行中に実行されるコマンド。テストフェーズのいずれかのコマンドが失敗した場合 (つまり、ゼロ以外の終了コードを返す場合）、テストは失敗としてマークされます。 + `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～26 | **注記** 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 ``` ## カスタムテスト環境のテストホストの選択 Android および iOS テストホストは、[テスト仕様ファイルの](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax)適切な 変数`android_test_host`と `ios_test_host`変数で指定できます。 特定のデバイスプラットフォームにテストホストの選択を指定しない場合、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 ドライバーなど) など、各ソフトウェアバージョンで一般的に使用されるサポートツールも含まれています。これにより、サポートされているテストフレームワークと連携するのに必要なツールが確実に入手できます。 # カスタムテスト環境での 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 ``` **ヒント** ソフトウェアバージョンを選択すると、`devicefarm-cli` は、Python 用の `pip` や NodeJS 用の `npm` など、その言語のサポートツールも切り替えることに注意してください。 テストホストにプリインストールされているソフトウェアの詳細については、「」を参照してください[カスタムテスト環境内でサポートされているソフトウェア](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 から iOS 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 バージョン`devicefarm-cli`には、互換性のあるバージョンの iOS 用 XCUITest ドライバーがプリインストールされています。 さらに、 ` 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)。ほとんどのユースケースで、お客様はご使用のソフトウェアのバージョンを選択することが推奨されます。でソフトウェアバージョンを選択すると、予測可能で一貫したエクスペリエンス`devicefarm-cli`が得られ、Device Farm がテストホストからそのバージョンを削除する予定がある場合は、十分な警告が表示されます。 さらに、`nvm`、`pyenv`、` avm`、`rvm` などのソフトウェア選択ツールは削除され、新しい ` devicefarm-cli` ソフトウェア選択システムが採用されました。 + ** 利用可能なソフトウェアバージョン: ** 以前にプリインストールされたソフトウェアの多くのバージョンが削除され、多くの新しいバージョンが追加されました。そのため、`devicefarm-cli` を使用してソフトウェアバージョンを選択する際は、必ず[サポート対象バージョンリスト](custom-test-environments-hosts-software.md)にあるバージョンを選択してください。 + ツール**`libimobiledevice`スイートは、現在の iOS デバイスのテストと業界標準を追跡するために、新しい/ファーストパーティーツールを優先して削除されました**。iOS 17 以降では、ほとんどのコマンドを移行して、 と呼ばれる同様の Xcode ツールを使用できます`devicectl`。の詳細については`devicectl`、Xcode がインストールされたマシン`xcrun devicectl help`から を実行できます。 + 絶対**パスとしてレガシーホストのテスト仕様ファイルでハードコードされたファイル**パスは、新しいテストホストでは期待どおりに動作しない可能性が高く、通常はテスト仕様ファイルの使用には推奨されません。すべてのテスト仕様ファイルコードで相対パスと環境変数を使用することをお勧めします。詳細については、「」のトピックを参照してください[カスタムテスト環境実行のベストプラクティス](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 フレームワーク用の JAR ファイルが含まれていました (環境変数 経由`$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 つのジョブを含めることができ、それぞれに 0`$DEVICEFARM_JOB_NUMBER`～4 の一意の範囲があります。 ** `$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`フェーズで**、失敗時にコマンドがゼロ以外のコードを返**すことを確認します。`test` フェーズ中に呼び出された各シェルコマンドのゼロ以外の終了コードをチェックすることで、実行が失敗したかどうかを判断します。ロジックまたはテストフレームワークが、必要なすべてのシナリオに対してゼロ以外の終了コードを返すことを確認する必要があります。これには、追加の設定が必要になる場合があります。 たとえば、特定のテストフレームワーク (JUnit5 など) では、ゼロテストの実行が失敗と見なされないため、何も実行されていない場合でもテストが正常に実行されたことが検出されます。例として JUnit5 を使用すると、このシナリオがゼロ以外の終了コードで終了`--fail-if-no-tests`するようにコマンドラインオプションを指定する必要があります。 + **ソフトウェアのデバイス OS バージョンおよびテスト実行に使用するテストホストバージョンとの互換性を確認します**。例えば、テスト対象のデバイスのすべての OS バージョンで意図したとおりに動作しないソフトウェアフレームワーク (Appium) のテストには、特定の機能があります。 **セキュリティ** + ** テスト仕様ファイルに機密性の高い変数 (AWS キーなど) を保存またはログ記録することは避けてください。 **テスト仕様ファイル、テスト仕様生成スクリプト、およびテスト仕様スクリプトのログはすべて、テスト実行の最後にダウンロード可能なアーティファクトとして提供されます。これにより、テストランへの読み取りアクセス権を持つアカウント内の他のユーザーのシークレットが意図せず公開される可能性があります。 # 標準テスト環境からカスタムテスト環境へのテストの移行 AWS Device Farm では、標準テスト実行モードからカスタム実行モードに切り替えることができます。移行には主に 2 つの異なる実行形式が含まれます: 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 ファイルはシェルスクリプトに変換され、テストホストマシン上で実行されます。複数の yaml ファイルを保存し、実行をスケジュールする際に要件に応じて動的に 1 つを選択できます。 1. **ライブビデオとロギング**: 標準実行モードとカスタム実行モードの両方で、テスト用のビデオとログが表示されます。ただし、標準モードでは、テストが完了して初めて、テストのビデオと定義済みのログが取得されます。 これとは対照的に、カスタムモードではテストのビデオのライブストリームとクライアント側ログを提供します。さらに、テストの最後にビデオや他のアーティファクトをダウンロードすることもできます。 **ヒント** ユースケースに上記の要素のうち少なくとも 1 つが含まれる場合は、カスタム実行モードに切り替えることを強くお勧めします。 ## 移行手順 標準モードからカスタムモードに移行するには、次の操作を行います: 1. にサインイン AWS マネジメントコンソール し、[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)でテストを試す際の出発点として使用できます。次に、コンソールからテストが正しく動作していることを確認したら、API、CLI、および、Device Farm とのパイプライン統合を変更し、テスト実行をスケジュールする際にこのテスト仕様ファイルをパラメータとして使用できます。テスト仕様ファイルを実行用パラメータとして追加する方法については、「[API ガイド](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html)」の `ScheduleRun` API の「`testSpecArn` パラメータ」セクションを参照してください。 ## Appium フレームワーク カスタムテスト環境において、Device Farm は、Appium フレームワークテストでの Appium 機能の挿入または上書きを行いません。テストの Appium 機能は、テスト仕様 YAML ファイルまたはテストコードで指定する必要があります。 ## 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 でのテスト実行後の Webhook とその他の 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 機能を調整してください。例えば、以下では、`usePrebuildWDA` 機能を iOS テストスイートで `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` これらの 2 つの機能は互いに排他的となっており、各セッションの完了後に 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 のみ) 今設定されている PIN コードがないことを Appium に通知し、スクリーンオフイベントまたはその他のロックイベント後にテストを高速化します。 `webDriverAgentUrl` (iOS のみ) 重要な iOS 依存関係 `webDriverAgent` がすでに実行され、指定された URL で HTTP リクエストを受け付けることができると想定するように Appium に指示します。`webDriverAgent` がまだ起動していない場合、Appium がテストスイートの開始時に `webDriverAgent` を起動するまでに時間がかかることがあります。自分で`webDriverAgent` を起動して Appium の起動時に `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 でのテスト実行後の Webhook とその他の API の使用 **curl** を使用してすべてのテストスイートが終了した後は、Device Farm で Webhook を呼び出すことができます。これを行うプロセスは、宛先とフォーマットにより異なります。特定の Webhook については、その Webhook のドキュメンテーションを参照してください。次の例では、テストスイートの終了のたびにメッセージを Slack ウェブフックに投稿します: ``` 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* に置かれることになります)。 より実用的な例を挙げると、Appium TestNG ユーザーがテストに *testng.xml* ファイルを含めたい場合、以下のコマンドを使用してアーカイブに含めることができます: ``` $ 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)」を参照してください。