Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Benutzerdefinierte Testumgebungen in AWS Device Farm
AWS Device Farm ermöglicht die Konfiguration einer benutzerdefinierten Umgebung für automatisierte Tests (benutzerdefinierter Modus). Dies ist der empfohlene Ansatz für alle Device Farm Farm-Benutzer. Weitere Informationen zu Umgebungen in Device Farm finden Sie unter [Testumgebungen](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html).
Der benutzerdefinierte Modus bietet im Vergleich zum Standardmodus unter anderem folgende Vorteile:
+ **Schnellere end-to-end Testausführung**: Das Testpaket wird nicht analysiert, um jeden Test in der Suite zu erkennen, wodurch preprocessing/postprocessing Overhead vermieden wird.
+ **Live-Protokoll und Videostreaming**: Ihre clientseitigen Testprotokolle und Videos werden live gestreamt, wenn Sie den benutzerdefinierten Modus verwenden. Diese Funktion ist im Standardmodus nicht verfügbar.
+ **Erfasst alle Artefakte**: Auf dem Host und dem Gerät können Sie im benutzerdefinierten Modus alle Testartefakte erfassen. Dies ist im Standardmodus möglicherweise nicht möglich.
+ **Konsistentere und replizierbarere lokale Umgebung**: Im Standardmodus werden Artefakte für jeden einzelnen Test separat bereitgestellt, was unter bestimmten Umständen von Vorteil sein kann. Ihre lokale Testumgebung kann jedoch von der ursprünglichen Konfiguration abweichen, da Device Farm jeden ausgeführten Test unterschiedlich behandelt.
Im Gegensatz dazu können Sie im benutzerdefinierten Modus Ihre Device Farm Farm-Testausführungsumgebung konsistent an Ihre lokale Testumgebung anpassen.
Benutzerdefinierte Umgebungen werden mithilfe einer Testspezifikationsdatei (Testspezifikation) im YAML-Format konfiguriert. Device Farm stellt für jeden unterstützten Testtyp eine Standardtestspezifikationsdatei bereit, die unverändert oder angepasst verwendet werden kann. Anpassungen wie Testfilter oder Konfigurationsdateien können der Testspezifikation hinzugefügt werden. Bearbeitete Testspezifikationen können für future Testläufe gespeichert werden.
Weitere Informationen finden Sie unter [Hochladen einer benutzerdefinierten Testspezifikation mit dem AWS CLI](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5) und. [Einen Testlauf in Device Farm erstellen](how-to-create-test-run.md)
**Topics**
+ [Referenz und Syntax der Testspezifikation](custom-test-environment-test-spec.md)
+ [Hosts für benutzerdefinierte Testumgebungen](custom-test-environments-hosts.md)
+ [Greifen Sie mithilfe einer IAM-Ausführungsrolle auf AWS-Ressourcen zu](custom-test-environments-iam-roles.md)
+ [Umgebungsvariablen für benutzerdefinierte Testumgebungen](custom-test-environment-variables.md)
+ [Bewährte Methoden für die Ausführung benutzerdefinierter Testumgebungen](custom-test-environments-best-practices.md)
+ [Migrieren von Tests von einer Standard- zu einer benutzerdefinierten Testumgebung](custom-test-environment-migration.md)
+ [Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md)
# Referenz und Syntax der Testspezifikation
Die Testspezifikation (Testspezifikation) ist eine Datei, mit der Sie benutzerdefinierte Testumgebungen in Device Farm definieren.
## Arbeitsablauf für Testspezifikationen
Die Device Farm Farm-Testspezifikation führt Phasen und ihre Befehle in einer vordefinierten Reihenfolge aus, sodass Sie die Art und Weise, wie Ihre Umgebung vorbereitet und ausgeführt wird, anpassen können. Wenn jede Phase ausgeführt wird, werden ihre Befehle in der Reihenfolge ausgeführt, die in der Testspezifikationsdatei aufgeführt ist. Die Phasen werden in der folgenden Reihenfolge ausgeführt
1. `install`- Hier sollten Aktionen wie das Herunterladen, Installieren und Einrichten von Tools definiert werden.
1. `pre_test`- Hier sollten Aktionen vor dem Test definiert werden, z. B. das Starten von Hintergrundprozessen.
1. `test`- Hier sollte der Befehl definiert werden, der Ihren Test aufruft.
1. `post_test`- Hier sollten alle letzten Aufgaben definiert werden, die nach Abschluss Ihres Tests ausgeführt werden müssen, z. B. die Generierung von Testberichten und die Aggregation von Artefaktdateien.
## Syntax der Testspezifikationen
Das Folgende ist das YAML-Schema für eine Testspezifikationsdatei
```
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` **
*(Erforderlich, Nummer)*
Spiegelt die von Device Farm unterstützte Version der Testspezifikation wider. Die aktuelle Versionsnummer lautet` 0.1`.
** `android_test_host` **
*(Optional, Zeichenfolge)*
Der Testhost, der für Testläufe auf Android-Geräten ausgewählt wird. Dieses Feld ist für Testläufe auf Android-Geräten erforderlich. Weitere Informationen finden Sie unter [Verfügbare Testhosts für benutzerdefinierte Testumgebungen](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `ios_test_host` **
*(Optional, Zeichenfolge)*
Der Testhost, der für Testläufe auf iOS-Geräten ausgewählt wird. Dieses Feld ist für Testläufe auf iOS-Geräten mit einer Hauptversion größer als 26 erforderlich. Weitere Informationen finden Sie unter [Verfügbare Testhosts für benutzerdefinierte Testumgebungen](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `phases` **
Dieser Abschnitt enthält Gruppen von Befehlen, die während eines Testlaufs ausgeführt werden, wobei jede Phase optional ist. Die zulässigen Namen der Testphasen `install` lauten:`pre_test`,`test`, und`post_test`.
+ `install`- Standardabhängigkeiten für Test-Frameworks, die von Device Farm unterstützt werden, sind bereits installiert. Diese Phase enthält gegebenenfalls zusätzliche Befehle, die Device Farm während der Installation ausführt.
+ `pre_test`- Die Befehle, falls vorhanden, wurden vor dem automatisierten Test ausgeführt.
+ `test`- Die Befehle, die während Ihres automatisierten Testlaufs ausgeführt wurden. Wenn ein Befehl in der Testphase fehlschlägt (was bedeutet, dass er einen Exit-Code ungleich Null zurückgibt), wird der Test als fehlgeschlagen markiert
+ `post_test`- Die Befehle, falls vorhanden, werden nach Ihrem automatisierten Testlauf ausgeführt. Dies wird unabhängig davon ausgeführt, ob Ihr Test in der `test` Phase erfolgreich ist oder nicht.
** `commands` **
*(Optional, Liste [Zeichenfolge])*
Eine Liste von Zeichenketten, die während der Phase als Shell-Befehl ausgeführt werden sollen.
** `artifacts` **
*(Optional, Liste [Zeichenfolge])*
Device Farm sammelt Artefakte wie benutzerdefinierte Berichte, Protokolldateien und Bilder von einem hier angegebenen Speicherort. Platzhalterzeichen werden als Teil eines Artefakt-Speicherortes nicht unterstützt. Sie müssen einen gültigen Pfad für jeden Speicherort eingeben.
Diese Testartefakte sind für jedes Gerät in Ihrem Testlauf verfügbar. Weitere Informationen zum Abrufen Ihrer Testartefakte finden Sie unter [Artefakte werden in einer benutzerdefinierten Testumgebung heruntergeladen](using-artifacts-custom.md).
**Wichtig**
Eine Testspezifikation muss als gültige YAML-Datei formatiert werden. Wenn die Einrückungen oder Leerstellen in Ihrer Testspezifikation ungültig sind, kann Ihr Testlauf fehlschlagen. Registerkarten sind in YAML-Dateien nicht zulässig. Sie können mit einem YAML-Validator testen, ob Ihre Testspezifikation eine gültige YAML-Datei ist. Weitere Informationen finden Sie auf der [YAML-Website](http://yaml.org/spec/1.2/spec.html).
## Beispiele für Testspezifikationen
Die folgenden Beispiele zeigen Testspezifikationen, die auf Device Farm ausgeführt werden können.
------
#### [ Simple Demo ]
Im Folgenden finden Sie ein Beispiel für eine Testspezifikationsdatei, die einfach `Hello world!` als Testlaufartefakt protokolliert wird.
```
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 ]
Im Folgenden finden Sie ein Beispiel für eine Testspezifikationsdatei, mit der ein Appium Java TestNG-Testlauf auf Android konfiguriert wird.
```
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 ]
Im Folgenden finden Sie ein Beispiel für eine Testspezifikationsdatei, mit der ein Appium Java TestNG-Testlauf unter iOS konfiguriert wird.
```
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) ]
Im Folgenden finden Sie ein Beispiel für eine Testspezifikationsdatei, mit der ein Appium Java TestNG-Testlauf auf Android und iOS konfiguriert wird.
```
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
```
------
# Hosts für benutzerdefinierte Testumgebungen
Device Farm unterstützt eine Reihe von Betriebssystemen mit vorkonfigurierter Software mithilfe einer Testhostumgebung. Während der Testausführung verwendet Device Farm von Amazon verwaltete Instanzen (Hosts), die sich dynamisch mit dem ausgewählten Testgerät verbinden. Diese Instanz wird vollständig bereinigt und zwischen den Testläufen nicht wiederverwendet. Nach Abschluss des Testlaufs wird sie mit den generierten Artefakten beendet.
**Topics**
+ [Verfügbare Testhosts für benutzerdefinierte Testumgebungen](#custom-test-environments-hosts-available)
+ [Auswahl eines Testhosts für benutzerdefinierte Testumgebungen](#test-host-selection)
+ [Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md)
+ [Testumgebung für Android-Geräte](custom-test-environments-hosts-android.md)
+ [Testumgebung für iOS-Geräte](custom-test-environments-hosts-ios.md)
## Verfügbare Testhosts für benutzerdefinierte Testumgebungen
Die Testhosts werden vollständig von Device Farm verwaltet. In der folgenden Tabelle sind die derzeit verfügbaren und unterstützten Device Farm Farm-Testhosts für benutzerdefinierte Testumgebungen aufgeführt.
| Geräteplattform | Host testen | Betriebssystem | Architektur (en) | Unterstützte Geräte |
| --- | --- | --- | --- | --- |
| Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android6 und höher |
| iOS | macos\$1sequoia | macOS Sequoia(Version 15) | arm64 | iOS15 bis 26 |
**Anmerkung**
In regelmäßigen Abständen fügt Device Farm neue Testhosts für eine Geräteplattform hinzu, um neuere Gerätebetriebssystemversionen und deren Abhängigkeiten zu unterstützen. In diesem Fall läuft der Support für ältere Testhosts für die jeweilige Geräteplattform ab.
### Version des Betriebssystems
Jeder verfügbare Testhost verwendet eine bestimmte Version des Betriebssystems, das zu diesem Zeitpunkt auf Device Farm unterstützt wird. Obwohl wir versuchen, die neueste Betriebssystemversion zu verwenden, ist dies möglicherweise nicht die neueste öffentlich verfügbare Version. Device Farm aktualisiert das Betriebssystem regelmäßig mit kleineren Versionsupdates und Sicherheitspatches.
Um die spezifische Version (einschließlich der Nebenversion) des Betriebssystems zu ermitteln, die während des Testlaufs verwendet wurde, können Sie den folgenden Codeausschnitt zu jeder Phase Ihrer Testspezifikationsdatei hinzufügen.
**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
```
## Auswahl eines Testhosts für benutzerdefinierte Testumgebungen
Sie können den Android- und iOS-Testhost in den entsprechenden `ios_test_host` Variablen `android_test_host` und Ihrer [Testspezifikationsdatei](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax) angeben.
Wenn Sie keine Testhostauswahl für die angegebene Geräteplattform angeben, werden Tests auf dem Testhost ausgeführt, den Device Farm als Standard für das angegebene Gerät und die angegebene Testkonfiguration festgelegt hat.
**Wichtig**
Beim Testen auf iOS 18 und niedriger wird ein älterer Testhost verwendet, wenn kein Host ausgewählt ist. Weitere Informationen finden Sie im Thema auf der[Legacy-iOS-Testhost](custom-test-environments-hosts-ios.md#legacy-ios-host).
Sehen Sie sich als Beispiel den folgenden Codeausschnitt an:
**Example**
```
version: 0.1
android_test_host: amazon_linux_2
ios_test_host: macos_sequoia
phases:
# ...
```
# Unterstützte Software in benutzerdefinierten Testumgebungen
Device Farm verwendet Host-Computer, auf denen viele der erforderlichen Softwarebibliotheken vorinstalliert sind, um Test-Frameworks auszuführen, die von unserem Service unterstützt werden, und bietet beim Start eine einsatzbereite Testumgebung. Device Farm unterstützt mithilfe unseres Softwareauswahlmechanismus mehrere Sprachen und aktualisiert regelmäßig die Versionen der in der Umgebung enthaltenen Sprachen.
Für jede andere erforderliche Software können Sie die Testspezifikationsdatei so ändern, dass sie von Ihrem Testpaket aus installiert, aus dem Internet heruntergeladen oder auf private Quellen in Ihrer VPC zugegriffen wird (weitere Informationen finden Sie unter [VPC ENI](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html)). Weitere Informationen finden Sie unter [Beispiele für Testspezifikationen](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example).
## Vorkonfigurierte Software
Um das Testen von Geräten auf jeder Plattform zu erleichtern, stehen auf dem Testhost die folgenden Tools zur Verfügung:
| Tools | Geräteplattform (en) |
| --- | --- |
| Android SDK Build-Tools | Android |
| Android SDK Platform-Tools(beinhaltet`adb`) | Android |
| Xcode | iOS |
## Wählbare Software
Zusätzlich zur vorkonfigurierten Software auf dem Host bietet Device Farm die Möglichkeit, bestimmte Versionen unterstützter Software über das `devicefarm-cli` Tooling auszuwählen.
Die folgende Tabelle enthält die auswählbare Software und die Testhosts, die sie enthalten.
| Software/Tool | Hosts, die diese Software unterstützen | Befehl zur Verwendung in Ihrer Testspezifikation |
| --- | --- | --- |
| 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` |
Der Testhost enthält auch häufig verwendete Unterstützungstools für jede Softwareversion, wie z. B. die `npm` Paketmanager `pip` und die Paketmanager (jeweils in Python und Node.js enthalten) und Abhängigkeiten (wie den UIAutomator2 Appium-Treiber) für Tools wie Appium. Dadurch wird sichergestellt, dass Sie über die Tools verfügen, die Sie für die Arbeit mit den unterstützten Test-Frameworks benötigen.
# Verwenden des Devicefarm-cli-Tools in benutzerdefinierten Testumgebungen
Der Testhost verwendet ein standardisiertes Versionsverwaltungstool, das ` devicefarm-cli` zur Auswahl von Softwareversionen aufgerufen wird. Dieses Tool ist unabhängig vom Device Farm-Testhost AWS CLI und nur auf dem Device Farm Farm-Testhost verfügbar. Mit `devicefarm-cli` können Sie zu einer beliebigen vorinstallierten Softwareversion auf dem Testhost wechseln. Dies bietet eine einfache Möglichkeit, Ihre Device Farm Farm-Testspezifikationsdatei im Laufe der Zeit zu verwalten, und bietet Ihnen einen vorhersehbaren Mechanismus, um Softwareversionen in future zu aktualisieren.
**Wichtig**
Dieses Befehlszeilentool ist auf älteren iOS-Hosts nicht verfügbar. Weitere Informationen finden Sie im Thema auf der[Legacy-iOS-Testhost](custom-test-environments-hosts-ios.md#legacy-ios-host).
Der folgende Ausschnitt zeigt die `help` Seite von: `devicefarm-cli`
```
$ 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.
```
Sehen wir uns einige Beispiele mit an. `devicefarm-cli` Führen Sie die folgenden Befehle aus, um das Tool *3.10* zum Ändern der Python-Version von zu *3.9* in Ihrer Testspezifikationsdatei zu verwenden:
```
$ python --version
Python 3.10.12
$ devicefarm-cli use python 3.9
$ python --version
Python 3.9.17
```
So ändern Sie die Appium-Version von *1* zu: *2*
```
$ appium --version
1.22.3
$ devicefarm-cli use appium 2
$ appium --version
2.1.2
```
**Tipp**
Beachten Sie, dass bei der Auswahl einer Softwareversion `devicefarm-cli` auch die unterstützenden Tools für diese Sprachen, z. B. `pip` für Python und NodeJS, `npm` gewechselt werden.
Weitere Informationen zur vorinstallierten Software auf dem Testhost finden Sie unter. [Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md)
# Testumgebung für Android-Geräte
AWS Device Farm verwendet Amazon Elastic Compute Cloud (EC2) -Hostmaschinen, auf denen Amazon Linux 2 ausgeführt wird, um Android-Tests auszuführen. Wenn Sie einen Testlauf planen, weist Device Farm jedem Gerät einen eigenen Host zu, damit die Tests unabhängig voneinander ausgeführt werden können. Die Hostcomputer werden nach dem Testlauf zusammen mit allen generierten Artefakten beendet.
Der Amazon Linux 2-Host bietet mehrere Vorteile:
+ **Schnelleres, zuverlässigeres Testen**: Im Vergleich zum alten Host verbessert der neue Testhost die Testgeschwindigkeit erheblich und reduziert insbesondere die Teststartzeiten. Der Amazon Linux 2-Host weist auch beim Testen eine höhere Stabilität und Zuverlässigkeit auf.
+ **Verbesserter Fernzugriff für manuelle Tests**: Upgrades auf den neuesten Testhost und Verbesserungen führen zu einer geringeren Latenz und einer besseren Videoleistung für manuelle Android-Tests.
+ **Auswahl der Standard-Softwareversion**: Device Farm standardisiert jetzt die Unterstützung wichtiger Programmiersprachen auf dem Testhost sowie die Appium-Framework-Versionen. Für unterstützte Sprachen (derzeit Java, Python, Node.js und Ruby) und Appium bietet der neue Testhost bald nach dem Start langfristige stabile Releases. Die zentralisierte Versionsverwaltung über das `devicefarm-cli` Tool ermöglicht die Entwicklung von Testspezifikationsdateien mit einer konsistenten Erfahrung in allen Frameworks.
**Topics**
+ [Unterstützte IP-Bereiche für die Amazon Linux 2-Testumgebung in Device Farm](amazon-linux-2-ip-ranges.md)
# Unterstützte IP-Bereiche für die Amazon Linux 2-Testumgebung in Device Farm
Kunden müssen häufig den IP-Bereich kennen, aus dem der Traffic von Device Farm stammt, insbesondere für die Konfiguration ihrer Firewalls und Sicherheitseinstellungen. Bei Amazon EC2-Testhosts umfasst der IP-Bereich die gesamte `us-west-2` Region. Für Amazon Linux 2-Testhosts, die Standardoption für neue Android-Läufe, wurden die Bereiche eingeschränkt. Der Datenverkehr stammt jetzt von einer bestimmten Gruppe von NAT-Gateways, wodurch der IP-Bereich auf die folgenden Adressen beschränkt ist:
****
| IP-Bereiche |
| --- |
| **44.236.137.143** |
| **52,13,151,244** |
| **522,35,189,191** |
| **54,201,250,26** |
Weitere Informationen zu Android-Testumgebungen in Device Farm finden Sie unter[Testumgebung für Android-Geräte](custom-test-environments-hosts-android.md).
# Testumgebung für iOS-Geräte
Device Farm verwendet von Amazon verwaltete macOS-Instanzen (Hosts), die sich während des Testlaufs dynamisch mit dem iOS-Gerät verbinden. Jeder Host ist mit Software vorkonfiguriert, die Gerätetests auf verschiedenen gängigen Testplattformen wie XCTest UI und Appium ermöglicht.
Die aktuelle Version des iOS-Testhosts hat das Testerlebnis im Vergleich zu früheren Versionen verbessert, darunter:
+ **Konsistente Host-Betriebssystem- und Tooling-Erfahrung für iOS 15 bis iOS 26** Bisher wurde der Testhost vom verwendeten Gerät bestimmt, was bei der Ausführung auf mehreren iOS-Versionen zu einer fragmentierten Softwareumgebung führte. Die derzeitige Erfahrung ermöglicht eine einfache Hostauswahl, um eine konsistente Umgebung auf allen Geräten zu gewährleisten. Dadurch können dieselbe macOS-Version und dieselben Tools (wie Xcode) auf jedem iOS-Gerät verfügbar sein.
+ **Leistungsverbesserungen für iOS 15- und 16-Tests** Mithilfe der aktualisierten Infrastruktur hat sich die Einrichtungszeit für iOS 15- und 16-Tests erheblich verbessert.
+ **Standardisierte auswählbare Softwareversionen für unterstützte Abhängigkeiten** Wir haben jetzt das `devicefarm-cli` Softwareauswahlsystem sowohl auf iOS- als auch auf Android-Testhosts, sodass Sie Ihre bevorzugte Version unserer unterstützten Abhängigkeiten auswählen können. Für unterstützte Abhängigkeiten (wie Java, Python, Node.js, Ruby und Appium) können Versionen über die Testspezifikation ausgewählt werden. Eine Vorstellung davon, wie diese Funktion funktioniert, finden Sie im Thema unter. [Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md)
**Wichtig**
Wenn Sie auf iOS 18 und niedriger ausgeführt werden, werden Ihre Tests standardmäßig auf älteren Testhosts ausgeführt. Im folgenden Thema erfahren Sie, wie Sie von Legacy-Hosts weg migrieren können.
## Legacy-iOS-Testhost
Für bestehende Tests unter iOS 18 und niedriger werden die Legacy-Testhosts standardmäßig für benutzerdefinierte Testumgebungen ausgewählt. Die folgende Tabelle enthält die Test-Host-Version, mit der die iOS-Geräteversion ausgeführt wird.
| Betriebssystem | Architektur (en) | Standard für Geräte |
| --- | --- | --- |
| macOS Sonoma(Version 14) | arm64 | iOS 18 |
| macOS Ventura(Ausführung 13) | arm64 | iOS 17 |
| macOS Monterey(Ausführung 12) | x86\$164 | iOS 16und darunter |
Informationen zur Auswahl der neueren Testhosts finden Sie im entsprechenden Thema[Migrieren Sie Ihre benutzerdefinierten Testumgebungen auf die neuen iOS-Testhosts](ios-host-migration.md).
## Unterstützte Software für iOS-Geräte
Um iOS-Gerätetests zu unterstützen, sind Device Farm Farm-Testhosts für iOS-Geräte mit Xcode und den zugehörigen Befehlszeilentools vorkonfiguriert. Weitere verfügbare Software finden Sie im folgenden Thema. [Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md)
# Migrieren Sie Ihre benutzerdefinierten Testumgebungen auf die neuen iOS-Testhosts
Um bestehende Tests vom Legacy-Host auf den neuen macOS-Testhost zu migrieren, müssen Sie neue Testspezifikationsdateien entwickeln, die auf Ihren bereits vorhandenen basieren.
Der empfohlene Ansatz besteht darin, mit der Beispieltestspezifikationsdatei für die gewünschten Testtypen zu beginnen und dann relevante Befehle von Ihrer alten Testspezifikationsdatei auf die neue zu migrieren. Auf diese Weise können Sie neue Funktionen und Optimierungen der Beispieltestspezifikation für den neuen Host nutzen und gleichzeitig Ausschnitte aus Ihrem vorhandenen Code wiederverwenden.
**Topics**
+ [Tutorial: Migrieren von iOS-Testspezifikationsdateien mit der Konsole](#ios-host-migration-console-tutorial)
+ [Unterschiede zwischen den neuen und den älteren Testhosts](#ios-host-migration-differences)
## Tutorial: Migrieren von iOS-Testspezifikationsdateien mit der Konsole
In diesem Beispiel wird die Device Farm Farm-Konsole verwendet, um eine bestehende iOS-Gerätetestspezifikation zu integrieren, um den neuen Testhost zu verwenden.
### Schritt 1: Erstellen neuer Testspezifikationsdateien mit der Konsole
1. Melden Sie sich bei der [AWS Device Farm Farm-Konsole](https://console.aws.amazon.com/devicefarm) an.
1. Navigieren Sie zum Device Farm Farm-Projekt, das Ihre Automatisierungstests enthält.
1. Laden Sie eine Kopie der vorhandenen Testspezifikation herunter, die Sie verwenden möchten.
1. Klicken Sie auf die Option „Projekteinstellungen“ und navigieren Sie zur Registerkarte **Uploads**.
1. Navigieren Sie zu der Testspezifikationsdatei, die Sie verwenden möchten.
1. Klicken Sie auf die Schaltfläche **Herunterladen**, um eine lokale Kopie dieser Datei zu erstellen.
1. Gehen Sie zurück zur Projektseite und klicken Sie auf **Ausführung erstellen**.
1. Füllen Sie die Optionen im Assistenten so aus, als ob Sie einen neuen Lauf starten würden, halten Sie aber bei der Option **Testspezifikation auswählen** an.
1. Verwenden Sie die standardmäßig ausgewählte iOS-Testspezifikation und klicken Sie auf die Schaltfläche **Testspezifikation erstellen**.
1. Ändern Sie die Testspezifikation, die *standardmäßig* im Texteditor ausgewählt wurde.
1. Falls noch nicht vorhanden, ändern Sie die Testspezifikationsdatei, um den neuen Host auszuwählen. Verwenden Sie dazu:
```
ios_test_host: macos_sequoia
```
1. Überprüfen Sie jede Kopie Ihrer Testspezifikation, die Sie in einem vorherigen Schritt heruntergeladen haben. ` phase`
1. Kopiert Befehle aus den Phasen der alten Testspezifikation in die jeweiligen Phasen der neuen Testspezifikation und ignoriert dabei Befehle, die sich auf die Installation oder Auswahl von Java, Python, Node.js, Ruby, Appium oder Xcode beziehen.
1. **Geben Sie einen neuen Dateinamen in das Textfeld Speichern unter ein.**
1. Klicken Sie auf die Schaltfläche **Als neu** speichern, um Ihre Änderungen zu speichern.
Ein Beispiel für eine Testspezifikationsdatei, die Sie als Referenz verwenden können, finden Sie im [Beispiele für Testspezifikationen](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) Beispiel unter.
### Schritt 2: Auswahl der vorinstallierten Software
Auf dem neuen Testhost werden vorinstallierte Softwareversionen mithilfe eines neuen standardisierten Versionsverwaltungstools namens ausgewählt. `devicefarm-cli` Dieses Tool ist jetzt der empfohlene Ansatz für die Verwendung der verschiedenen Software, die wir auf den Testhosts bereitstellen.
Als Beispiel würden Sie die folgende Zeile hinzufügen, um ein anderes JDK 17 in Ihrer Testumgebung zu verwenden:
```
- devicefarm-cli use java 17
```
Weitere Informationen zur unterstützten und verfügbaren Software finden Sie unter:[Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md).
### Schritt 3: Verwenden von Appium und seinen Abhängigkeiten über das Softwareauswahltool
Der neue Testhost unterstützt nur Appium 2.x und höher. Bitte wählen Sie explizit die Appium-Version mit dem `devicefarm-cli` aus und entfernen Sie dabei ältere Tools wie. ` avm` Beispiel:
```
# 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
```
Die mit ausgewählte Appium-Version `devicefarm-cli` ist mit einer kompatiblen Version des XCUITest Treibers für iOS vorinstalliert.
Darüber hinaus müssen Sie Ihre Testspezifikation aktualisieren, um sie anstelle von zu verwenden` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9`. ` DEVICEFARM_WDA_DERIVED_DATA_PATH` Die neue Umgebungsvariable verweist auf eine vorgefertigte Version von WebDriverAgent 9.x, der neuesten unterstützten Version für Appium 2-Tests.
Weitere Informationen finden Sie unter und. [Auswahl einer WebDriverAgent Version für iOS-Tests](test-types-appium.md#test-types-appium-select-wda) [Umgebungsvariablen für Appium-Tests](custom-test-environment-variables.md#custom-test-environment-variables-appium)
## Unterschiede zwischen den neuen und den älteren Testhosts
Wenn Sie Ihre Testspezifikationsdatei bearbeiten, um den neuen iOS-Testhost zu verwenden, und Ihre Tests vom alten Testhost umstellen, sollten Sie sich der folgenden wichtigen Umgebungsunterschiede bewusst sein:
+ **Xcode-Versionen:** In der Legacy-Testhostumgebung basierte die verfügbare Xcode-Version auf der iOS-Version des zum Testen verwendeten Geräts. Beispielsweise verwendeten Tests auf iOS 18-Geräten Xcode 16 im Legacy-Host, wohingegen Tests auf iOS 17 Xcode 15 verwendeten. In der neuen Host-Umgebung können alle Geräte auf dieselben Versionen von Xcode zugreifen, was eine konsistente Umgebung für Tests auf Geräten mit unterschiedlichen Versionen ermöglicht. Eine Liste der derzeit verfügbaren Xcode-Versionen finden Sie unter. [Unterstützte Software](custom-test-environments-hosts-software.md)
+ **Softwareversionen auswählen:** In vielen Fällen haben sich die Standard-Softwareversionen geändert. Wenn Sie also Ihre Softwareversion auf dem älteren Testhost nicht explizit ausgewählt haben, möchten Sie sie jetzt vielleicht auf dem neuen Testhost mit [`devicefarm-cli`](custom-test-environments-hosts-software-cli.md)angeben. In den allermeisten Anwendungsfällen empfehlen wir Kunden, explizit die Softwareversionen auszuwählen, die sie verwenden. Wenn Sie eine Softwareversion mit auswählen, haben `devicefarm-cli` Sie eine vorhersehbare und konsistente Erfahrung damit und erhalten zahlreiche Warnungen, wenn Device Farm plant, diese Version vom Testhost zu entfernen.
Darüber hinaus `rvm` wurden Tools zur Softwareauswahl wie `nvm` `pyenv`` avm`,, und zugunsten des neuen ` devicefarm-cli` Softwareauswahlsystems entfernt.
+ **Verfügbare Softwareversionen:** Viele Versionen zuvor vorinstallierter Software wurden entfernt und viele neue Versionen hinzugefügt. Stellen Sie daher sicher, dass Sie bei der `devicefarm-cli` Auswahl Ihrer Softwareversionen Versionen auswählen, die in der [Liste der unterstützten Versionen enthalten](custom-test-environments-hosts-software.md) sind.
+ **Die `libimobiledevice` Toolsuite wurde zugunsten neuerer Tools bzw. Tools von Erstanbietern entfernt**, um aktuelle iOS-Gerätetests und Industriestandards nachzuverfolgen. Für iOS 17 und höher können Sie die meisten Befehle migrieren, um ähnliche Xcode-Tools zu verwenden, genannt. `devicectl` Informationen dazu finden Sie unter: Sie können das Programm `xcrun devicectl help` von einem Computer aus ausführen`devicectl`, auf dem Xcode installiert ist.
+ **Dateipfade, die in Ihrer alten Host-Testspezifikationsdatei als absolute Pfade fest codiert sind**, funktionieren auf dem neuen Testhost höchstwahrscheinlich nicht wie erwartet und werden im Allgemeinen nicht für die Verwendung von Testspezifikationsdateien empfohlen. Wir empfehlen, relative Pfade und Umgebungsvariablen für den gesamten Code der Testspezifikationsdatei zu verwenden. Weitere Informationen finden Sie im Thema unter[Bewährte Methoden für die Ausführung benutzerdefinierter Testumgebungen](custom-test-environments-best-practices.md).
+ **Betriebssystemversion und Architektur:** Die älteren Testhosts verwendeten eine Vielzahl von macOS-Versionen und CPU-Architekturen, die auf dem zugewiesenen Gerät basierten. Daher stellen Benutzer möglicherweise einige Unterschiede in den verfügbaren Systembibliotheken fest, die in der Umgebung verfügbar sind. Weitere Informationen zur vorherigen Host-Betriebssystemversion finden Sie unter[Legacy-iOS-Testhost](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ **Für Appium-Benutzer** WebDriverAgent wurde die Art der Auswahl von dahingehend geändert, dass ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` anstelle des alten ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` Präfixes ein Präfix für die Verwendung einer Umgebungsvariablen verwendet wird. Weitere Informationen zur aktualisierten Variablen finden Sie [Umgebungsvariablen für Appium-Tests](custom-test-environment-variables.md#custom-test-environment-variables-appium) unter.
+ **Für Appium Java-Benutzer** enthält der neue Testhost keine vorinstallierten JAR-Dateien in seinem Klassenpfad, wohingegen der vorherige Host eine für das TestNG-Framework (über eine Umgebungsvariable) enthielt. `$DEVICEFARM_TESTNG_JAR` Wir empfehlen Kunden, die erforderlichen JAR-Dateien für ihre Testframeworks in ihr Testpaket zu packen und Instanzen der `$DEVICEFARM_TESTNG_JAR` Variablen aus ihren Testspezifikationsdateien zu entfernen.
Wir empfehlen, sich über einen Support-Fall an das Serviceteam zu wenden, wenn Sie Feedback oder Fragen zu den Unterschieden zwischen den Testhosts aus Sicht der Software haben.
# Greifen Sie mithilfe einer IAM-Ausführungsrolle auf AWS-Ressourcen zu
Device Farm unterstützt die Angabe einer IAM-Rolle, die während der Testausführung von der benutzerdefinierten Testlaufzeitumgebung übernommen wird. Mit dieser Funktion können Ihre Tests sicher auf AWS-Ressourcen in Ihrem Konto zugreifen, z. B. Amazon S3 S3-Buckets, DynamoDB-Tabellen oder andere AWS-Services, von denen Ihre Anwendung abhängt.
**Topics**
+ [Übersicht](#iam-execution-role-overview)
+ [IAM-Rollenanforderungen](#iam-role-requirements)
+ [Konfiguration einer IAM-Ausführungsrolle](#configuring-iam-execution-role)
+ [Best Practices](#iam-role-best-practices)
+ [Fehlerbehebung](#troubleshooting-iam-roles)
## Übersicht
Wenn Sie eine IAM-Ausführungsrolle angeben, übernimmt Device Farm diese Rolle während der Testausführung, sodass Ihre Tests mithilfe der in der Rolle definierten Berechtigungen mit AWS-Services interagieren können.
Zu den häufigsten Anwendungsfällen für IAM-Ausführungsrollen gehören:
+ Zugreifen auf Testdaten, die in Amazon S3 S3-Buckets gespeichert sind
+ Testartefakte in Amazon S3 S3-Buckets übertragen
+ Anwendungskonfiguration von AWS abrufen AppConfig
+ Schreiben von Testprotokollen und Metriken auf Amazon CloudWatch
+ Senden von Testergebnissen oder Statusmeldungen an Amazon SQS SQS-Warteschlangen
+ Aufrufen von AWS Lambda Lambda-Funktionen als Teil von Test-Workflows
## IAM-Rollenanforderungen
Um eine IAM-Ausführungsrolle mit Device Farm verwenden zu können, muss Ihre Rolle die folgenden Anforderungen erfüllen:
+ **Vertrauensverhältnis**: Dem Device Farm Farm-Dienstprinzipal muss vertraut werden, um die Rolle übernehmen zu können. Die Vertrauensrichtlinie muss eine `devicefarm.amazonaws.com` vertrauenswürdige Entität beinhalten.
+ **Berechtigungen**: Die Rolle muss über die erforderlichen Berechtigungen für den Zugriff auf die AWS-Ressourcen verfügen, die für Ihre Tests erforderlich sind.
+ **Sitzungsdauer**: Die maximale Sitzungsdauer der Rolle muss mindestens so lang sein wie die Job-Timeout-Einstellung Ihres Device Farm Farm-Projekts. Standardmäßig haben Device Farm Farm-Projekte ein Job-Timeout von 150 Minuten, sodass Ihre Rolle eine Sitzungsdauer von mindestens 150 Minuten unterstützen muss.
+ **Gleiche Kontoanforderung**: Die IAM-Rolle muss sich in demselben AWS-Konto befinden wie das, mit dem Device Farm aufgerufen wurde. Die kontoübergreifende Übernahme von Rollen wird nicht unterstützt.
+ **PassRole Berechtigung**: Der Aufrufer muss gemäß einer Richtlinie autorisiert sein, die IAM-Rolle zu übergeben, sodass die `iam:PassRole` Aktion für die angegebene Ausführungsrolle zulässig ist.
### Beispiel für eine Treuhand-Police
Das folgende Beispiel zeigt eine Vertrauensrichtlinie, die es Device Farm ermöglicht, Ihre Ausführungsrolle zu übernehmen. Diese Vertrauensrichtlinie sollte nur der spezifischen IAM-Rolle zugewiesen werden, die Sie mit Device Farm verwenden möchten, nicht anderen Rollen in Ihrem Konto:
**Example**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "devicefarm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
### Beispiel für eine Berechtigungsrichtlinie
Das folgende Beispiel zeigt eine Berechtigungsrichtlinie, die Zugriff auf allgemeine AWS-Services gewährt, die beim Testen verwendet werden:
**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-*"
}
]
}
```
## Konfiguration einer IAM-Ausführungsrolle
Sie können eine IAM-Ausführungsrolle auf Projektebene oder für einzelne Testläufe angeben. Bei der Konfiguration auf Projektebene erben alle Läufe innerhalb dieses Projekts die Ausführungsrolle. Eine bei einem Lauf konfigurierte Ausführungsrolle ersetzt alle in ihrem übergeordneten Projekt konfigurierten Rollen.
Detaillierte Anweisungen zur Konfiguration von Ausführungsrollen finden Sie unter:
+ [Ein Projekt in AWS Device Farm erstellen](how-to-create-project.md)- zur Konfiguration von Ausführungsrollen auf Projektebene
+ [Einen Testlauf in Device Farm erstellen](how-to-create-test-run.md)- zur Konfiguration von Ausführungsrollen für einzelne Läufe
Sie können Ausführungsrollen auch mithilfe der Device Farm API konfigurieren. Weitere Informationen finden Sie in der [Device Farm API-Referenz](https://docs.aws.amazon.com/devicefarm/latest/APIReference/).
## Best Practices
Folgen Sie diesen bewährten Methoden, wenn Sie IAM-Ausführungsrollen für Ihre Device Farm Farm-Tests konfigurieren:
+ **Prinzip der geringsten Rechte**: Gewähren Sie nur die Mindestberechtigungen, die für das Funktionieren Ihrer Tests erforderlich sind. Vermeiden Sie die Verwendung zu weit gefasster Berechtigungen wie `*` Aktionen oder Ressourcen.
+ **Verwenden Sie ressourcenspezifische Berechtigungen**: Beschränken Sie die Berechtigungen nach Möglichkeit auf bestimmte Ressourcen (z. B. bestimmte S3-Buckets oder DynamoDB-Tabellen) und nicht auf alle Ressourcen eines Typs.
+ **Separate Test- und Produktionsressourcen**: Verwenden Sie spezielle Testressourcen und Rollen, um zu verhindern, dass während des Tests versehentlich Produktionssysteme beeinträchtigt werden.
+ **Regelmäßige Rollenüberprüfung**: Überprüfen und aktualisieren Sie Ihre Ausführungsrollen regelmäßig, um sicherzustellen, dass sie weiterhin Ihren Testanforderungen entsprechen und den bewährten Sicherheitsmethoden entsprechen.
+ **Verwenden Sie Bedingungsschlüssel**: Erwägen Sie die Verwendung von IAM-Bedingungsschlüsseln, um weiter einzuschränken, wann und wie die Rolle verwendet werden kann.
## Fehlerbehebung
Wenn Sie Probleme mit IAM-Ausführungsrollen haben, überprüfen Sie Folgendes:
+ **Vertrauensverhältnis**: Stellen Sie sicher, dass die Vertrauensrichtlinie der Rolle einen vertrauenswürdigen Dienst beinhaltet`devicefarm.amazonaws.com`.
+ **Berechtigungen**: Stellen Sie sicher, dass die Rolle über die erforderlichen Berechtigungen für die AWS-Services verfügt, auf die Ihre Tests zugreifen möchten.
+ **Testprotokolle**: Überprüfen Sie die Testausführungsprotokolle auf spezifische Fehlermeldungen im Zusammenhang mit AWS-API-Aufrufen oder Verweigerungen von Berechtigungen.
# Umgebungsvariablen für benutzerdefinierte Testumgebungen
Device Farm konfiguriert dynamisch mehrere Umgebungsvariablen für die Verwendung als Teil Ihrer benutzerdefinierten Testumgebung.
**Topics**
+ [Benutzerdefinierte Umgebungsvariablen](#custom-test-environment-variables-custom)
+ [Allgemeine Umgebungsvariablen](#custom-test-environment-variables-common)
+ [Umgebungsvariablen für Appium-Tests](#custom-test-environment-variables-appium)
+ [Umgebungsvariablen für XCUITest Tests](#custom-test-environment-variables-xcuitest)
## Benutzerdefinierte Umgebungsvariablen
Device Farm unterstützt die Konfiguration von Schlüssel-Wert-Paaren, die als Umgebungsvariablen auf dem Testhost angewendet werden. Diese können in einem Device Farm Farm-Projekt oder während der Lauferstellung konfiguriert werden. Alle Variablen, die bei einem Lauf konfiguriert wurden, ersetzen alle Variablen, die für das übergeordnete Projekt konfiguriert wurden. Beachten Sie die folgenden Einschränkungen:
+ Benutzerdefinierte Umgebungsvariablen werden auf älteren iOS-Testhosts nicht unterstützt. Weitere Informationen finden Sie unter [Legacy-iOS-Testhost](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ Variablennamen, die mit beginnen, `$DEVICEFARM_` sind für die interne Verwendung durch Dienste reserviert.
+ Benutzerdefinierte Umgebungsvariablen dürfen nicht verwendet werden, um die Computerauswahl für den Testhost in Ihrer Testspezifikation zu konfigurieren.
## Allgemeine Umgebungsvariablen
In diesem Abschnitt werden Umgebungsvariablen beschrieben, die allen Tests in Device Farm gemeinsam sind.
** `$DEVICEFARM_DEVICE_NAME` **
Das Gerät, auf dem Ihre Tests ausgeführt werden. Es stellt die eindeutige Gerätekennung (UDID) des Geräts dar.
** `$DEVICEFARM_DEVICE_UDID` **
Die eindeutige Kennung des Geräts.
** `$DEVICEFARM_DEVICE_PLATFORM_NAME` **
Der Plattformname des Geräts. Es ist entweder `Android` oder`iOS`.
** `$DEVICEFARM_DEVICE_OS_VERSION` **
Die Betriebssystemversion des Geräts.
** `$DEVICEFARM_APP_PATH` **
*(Tests für mobile Apps)*
Der Pfad zur mobilen App auf dem Host-Computer, auf dem die Tests ausgeführt werden. Diese Variable ist bei Webtests nicht verfügbar.
** `$DEVICEFARM_LOG_DIR` **
Der Pfad zum Standardverzeichnis, in dem Kundenprotokolle, Artefakte und andere benötigte Dateien für den späteren Abruf gespeichert werden. Anhand einer [Beispieltestspezifikation](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) werden Dateien in diesem Verzeichnis in einer ZIP-Datei archiviert und nach dem Testlauf als Artefakt zur Verfügung gestellt.
** `$DEVICEFARM_SCREENSHOT_PATH` **
Der Pfad zu den Screenshots, die ggf. während des Testlaufs erfasst werden.
** `$DEVICEFARM_PROJECT_ARN` **
Der ARN des übergeordneten Projekts des Jobs.
** `$DEVICEFARM_RUN_ARN` **
Der ARN der übergeordneten Ausführung des Jobs.
** `$DEVICEFARM_DEVICE_ARN` **
Der ARN des zu testenden Geräts.
** `$DEVICEFARM_TOTAL_JOBS` **
Die Gesamtzahl der Jobs, die mit der Ausführung der übergeordneten Device Farm verknüpft sind.
** `$DEVICEFARM_JOB_NUMBER` **
Die Nummer dieses Jobs ist darin enthalten`$DEVICEFARM_TOTAL_JOBS`. Ein Lauf kann beispielsweise 5 Jobs enthalten, von denen jeder einen eindeutigen Wert `$DEVICEFARM_JOB_NUMBER` zwischen 0 und 4 hat.
** `$AWS_REGION` **
Die AWS-Region Der Dienst stellt dies so ein, dass es der Region entspricht, in der sich das zu testende Gerät befindet. Sie kann bei Bedarf durch eine benutzerdefinierte Umgebungsvariable überschrieben werden.
** `$ANDROID_HOME` **
*(Nur Android)*
Der Pfad zum Android SDK-Installationsverzeichnis.
## Umgebungsvariablen für Appium-Tests
In diesem Abschnitt werden Umgebungsvariablen beschrieben, die von jedem Appium-Test in einer benutzerdefinierten Testumgebung in Device Farm verwendet werden.
** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` **
*(Nur Android)*
Der Speicherort eines Verzeichnisses, das die erforderlichen ChromeDriver ausführbaren Dateien für die Verwendung in Appium-Web- und Hybridtests enthält.
** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` **
*(nur iOS)*
Der abgeleitete Datenpfad einer Version von, die für die Ausführung auf Device Farm WebDriverAgent erstellt wurde. Die Nummerierung der Variablen entspricht der Hauptversion von. WebDriverAgent Als Beispiel `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` wird auf die WebDriverAgent A-Version von 9.x verwiesen. Weitere Informationen finden Sie unter [Auswahl einer WebDriverAgent Version für iOS-Tests](test-types-appium.md#test-types-appium-select-wda).
Die `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` Umgebungsvariablen sind nur auf Nicht-Legacy-iOS-Hosts vorhanden. Weitere Informationen finden Sie unter [Legacy-iOS-Testhost](custom-test-environments-hosts-ios.md#legacy-ios-host).
** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` **
*(Nur iOS, veraltet)*
Der abgeleitete Datenpfad einer Version von, die für die Ausführung auf Device Farm WebDriverAgent erstellt wurde. Das Ersatzbenennungsschema finden Sie unter. `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V`
## Umgebungsvariablen für XCUITest Tests
In diesem Abschnitt werden Umgebungsvariablen beschrieben, die vom XCUITest Test in einer benutzerdefinierten Testumgebung in Device Farm verwendet werden.
** `$DEVICEFARM_XCUITESTRUN_FILE` **
Der Pfad zur Device Farm `.xctestun` Farm-Datei. Wird über Ihre App und aus Testpaketen erstellt.
** `$DEVICEFARM_DERIVED_DATA_PATH` **
Erwarteter Pfad der Xcodebuild-Ausgabe von Device Farm.
** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` **
Der Pfad zum entpackten Inhalt der Test-Paketdatei.
# Bewährte Methoden für die Ausführung benutzerdefinierter Testumgebungen
In den folgenden Themen werden empfohlene bewährte Methoden für die Verwendung der benutzerdefinierten Testausführung mit Device Farm behandelt.
**Ausführungskonfiguration**
+ **Verlassen Sie sich bei der Ausführungskonfiguration wo immer möglich auf von Device Farm verwaltete Software und API-Funktionen**, anstatt ähnliche Konfigurationen über Shell-Befehle in der Testspezifikationsdatei anzuwenden. Dazu gehört auch die Konfiguration des Testhosts und des Geräts, da diese auf allen Testhosts und Geräten nachhaltiger und konsistenter sein wird.
Device Farm empfiehlt Ihnen zwar, Ihre Testspezifikationsdatei so weit anzupassen, wie Sie es für die Ausführung Ihrer Tests benötigen, aber die Verwaltung der Testspezifikationsdatei kann im Laufe der Zeit schwierig werden, da ihr mehr benutzerdefinierte Befehle hinzugefügt werden. Verwenden von Device Farm-verwalteter Software (über Tools wie ` devicefarm-cli` und die verfügbaren Standardtools in`$PATH`) und mithilfe verwalteter Funktionen (wie dem [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)Anforderungsparameter) zur Vereinfachung der Testspezifikationsdatei, indem die Verantwortung für die Wartung auf Device Farm selbst verlagert wird.
**Testspezifikation und Testpaketcode**
+ **Verwenden Sie keine absoluten Pfade und verlassen Sie sich nicht auf bestimmte Nebenversionen** in Ihrer Testspezifikationsdatei oder Ihrem Testpaketcode. Device Farm wendet routinemäßige Updates auf den ausgewählten Testhost und die enthaltenen Softwareversionen an. Die Verwendung bestimmter oder absoluter Pfade (z. B. ` /usr/local/bin/python` anstelle von`python`) oder die Anforderung bestimmter Nebenversionen (z. B. Node.js `20.3.1` statt nur` 20`) kann dazu führen, dass Ihre Tests die erforderliche ausführbare Datei/nicht finden können.
Im Rahmen der benutzerdefinierten Testausführung richtet Device Farm verschiedene Umgebungsvariablen und die `$PATH` Variable ein, um sicherzustellen, dass die Tests in unseren dynamischen Umgebungen konsistent ausgeführt werden. Weitere Informationen finden Sie unter [Umgebungsvariablen für benutzerdefinierte Testumgebungen](custom-test-environment-variables.md) und [Unterstützte Software in benutzerdefinierten Testumgebungen](custom-test-environments-hosts-software.md).
+ **Speichern Sie während des Testlaufs generierte oder kopierte Dateien im temporären Verzeichnis.** Heute stellen wir sicher, dass der Benutzer während der Testausführung auf das temporäre Verzeichnis (`/tmp`) zugreifen kann (neben verwalteten Verzeichnissen wie dem`$DEVICEFARM_LOG_DIR`). Andere Verzeichnisse, auf die der Benutzer Zugriff hat, können sich im Laufe der Zeit aufgrund der Anforderungen des Dienstes oder des verwendeten Betriebssystems ändern.
+ **Speichern Sie Ihre Testausführungsprotokolle** unter`$DEVICEFARM_LOG_DIR`. Dies ist das Standardartefaktverzeichnis, das für Ihre Ausführung bereitgestellt wird, um Ausführungslogs/Artefakte hinzuzufügen. Die von uns bereitgestellten [Beispieltestspezifikationen](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) verwenden standardmäßig dieses Verzeichnis für Artefakte.
+ **Stellen Sie sicher, dass Ihre Befehle bei einem Fehler während der `test` Phase Ihrer Testspezifikation einen Code ungleich Null zurückgeben**. Wir ermitteln, ob Ihre Ausführung fehlgeschlagen ist, indem wir für jeden Shell-Befehl, der während der Phase aufgerufen wurde, nach einem Exit-Code ungleich Null suchen. `test` Sie sollten sicherstellen, dass Ihr Logik- oder Testframework für alle gewünschten Szenarien einen Exit-Code ungleich Null zurückgibt, was möglicherweise eine zusätzliche Konfiguration erfordert.
Beispielsweise betrachten bestimmte Test-Frameworks (wie JUnit5), dass keine Tests ausgeführt wurden, nicht als Fehler, sodass festgestellt wird, dass Ihre Tests erfolgreich ausgeführt wurden, auch wenn nichts ausgeführt wurde. JUnit5 Als Beispiel müssten Sie die Befehlszeilenoption angeben, `--fail-if-no-tests` um sicherzustellen, dass dieses Szenario mit einem Exit-Code ungleich Null beendet wird.
+ **Überprüfen Sie die Kompatibilität der Software** mit der Betriebssystemversion des Geräts und der Testhostversion, die Sie für den Testlauf verwenden werden. Beispielsweise gibt es beim Testen von Software-Frameworks (z. B. Appium) bestimmte Funktionen, die möglicherweise nicht auf allen Betriebssystemversionen des getesteten Geräts wie vorgesehen funktionieren.
**Sicherheit**
+ **Vermeiden Sie es, sensible Variablen (wie AWS-Schlüssel) in Ihrer Testspezifikationsdatei zu speichern oder zu protokollieren.** Die Testspezifikationsdateien, die von der Testspezifikation generierten Skripte und die Protokolle des Testspezifikationsskripts werden am Ende der Testausführung alle als herunterladbare Artefakte bereitgestellt. Dies kann zur unbeabsichtigten Offenlegung von Geheimnissen für andere Benutzer in Ihrem Konto mit Lesezugriff auf Ihren Testlauf führen.
# Migrieren von Tests von einer Standard- zu einer benutzerdefinierten Testumgebung
Sie können in AWS Device Farm von einem standardmäßigen Testausführungsmodus zu einem benutzerdefinierten Ausführungsmodus wechseln. Die Migration umfasst hauptsächlich zwei verschiedene Ausführungsformen:
1. **Standardmodus**: Dieser Testausführungsmodus ist in erster Linie darauf ausgelegt, Kunden detaillierte Berichte und eine vollständig verwaltete Umgebung zu bieten.
1. **Benutzerdefinierter Modus**: Dieser Testausführungsmodus wurde für verschiedene Anwendungsfälle entwickelt, die schnellere Testläufe, die Möglichkeit zum Lift-and-Shift-Verfahren und zur Erreichung der Parität mit der lokalen Umgebung sowie Live-Videostreaming erfordern.
Weitere Informationen zu den standardmäßigen und benutzerdefinierten Modi in Device Farm finden Sie unter [Testumgebungen in AWS Device Farm](test-environments.md) und[Benutzerdefinierte Testumgebungen in AWS Device Farm](custom-test-environments.md).
## Überlegungen zur Migration
In diesem Abschnitt sind einige der wichtigsten Anwendungsfälle aufgeführt, die bei der Migration zum benutzerdefinierten Modus zu berücksichtigen sind:
1. **Geschwindigkeit**: Im Standardmodus analysiert Device Farm die Metadaten der Tests, die Sie gepackt und hochgeladen haben, anhand der Paketierungsanweisungen für Ihr spezielles Framework. Beim Parsen wird die Anzahl der Tests in Ihrem Paket erkannt. Danach führt Device Farm jeden Test separat aus und präsentiert die Protokolle, Videos und andere Ergebnisartefakte für jeden Test einzeln. Dies erhöht jedoch kontinuierlich die gesamte end-to-end Testausführungszeit, da die Tests und Ergebnisartefakte auf der Serviceseite vor- und nachbearbeitet werden.
Im Gegensatz dazu analysiert der benutzerdefinierte Ausführungsmodus Ihr Testpaket nicht. Dies bedeutet, dass keine Vorverarbeitung und nur minimale Nachbearbeitung für Tests oder Ergebnisartefakte erforderlich ist. Dies führt zu einer end-to-end Gesamtausführungszeit, die Ihrer lokalen Konfiguration sehr nahe kommt. Die Tests werden in demselben Format ausgeführt, in dem sie ausgeführt würden, wenn sie auf Ihren lokalen Computern ausgeführt würden. Die Ergebnisse der Tests entsprechen denen, die Sie lokal erhalten, und stehen am Ende der Jobausführung zum Download zur Verfügung.
1. **Anpassung oder Flexibilität**: Der Standardausführungsmodus analysiert Ihr Testpaket, um die Anzahl der Tests zu ermitteln, und führt dann jeden Test separat aus. Beachten Sie, dass es keine Garantie dafür gibt, dass die Tests in der von Ihnen angegebenen Reihenfolge ausgeführt werden. Daher funktionieren Tests, die eine bestimmte Ausführungsreihenfolge erfordern, möglicherweise nicht wie erwartet. Darüber hinaus gibt es keine Möglichkeit, die Host-Computerumgebung anzupassen oder Konfigurationsdateien zu übergeben, die möglicherweise erforderlich sind, um Ihre Tests auf eine bestimmte Weise auszuführen.
Im benutzerdefinierten Modus können Sie dagegen die Host-Computerumgebung konfigurieren, einschließlich der Möglichkeit, zusätzliche Software zu installieren, Filter an Ihre Tests zu übergeben, Konfigurationsdateien zu übergeben und die Einrichtung der Testausführung zu steuern. Dies wird über eine Yaml-Datei (auch als Testspec-Datei bezeichnet) erreicht, die Sie ändern können, indem Sie ihr Shell-Befehle hinzufügen. Diese Yaml-Datei wird in ein Shell-Skript konvertiert, das auf dem Test-Host-Computer ausgeführt wird. Sie können mehrere Yaml-Dateien speichern und eine dynamisch gemäß Ihren Anforderungen auswählen, wenn Sie einen Lauf planen.
1. **Live-Video und Protokollierung**: Sowohl der Standard- als auch der benutzerdefinierte Ausführungsmodus bieten Ihnen Videos und Protokolle für Ihre Tests. Im Standardmodus erhalten Sie das Video und die vordefinierten Protokolle Ihrer Tests jedoch erst, nachdem Ihre Tests abgeschlossen sind.
Im benutzerdefinierten Modus erhalten Sie dagegen einen Live-Stream mit dem Video und den clientseitigen Protokollen Ihrer Tests. Darüber hinaus können Sie das Video und andere Artefakte am Ende der Tests herunterladen.
**Tipp**
Wenn Ihr Anwendungsfall mindestens einen der oben genannten Faktoren beinhaltet, empfehlen wir dringend, zum benutzerdefinierten Ausführungsmodus zu wechseln.
## Schritte zur Migration
Gehen Sie wie folgt vor, um vom Standardmodus zum benutzerdefinierten Modus zu migrieren:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Device Farm Farm-Konsole unter [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. Wählen Sie Ihr Projekt aus und starten Sie dann einen neuen Automatisierungslauf.
1. Laden Sie Ihre App hoch (oder wählen Sie sie aus`web app`), wählen Sie Ihren Testframework-Typ aus, laden Sie Ihr Testpaket hoch und wählen Sie dann unter dem `Choose your execution environment` Parameter die Option für`Run your test in a custom environment`.
1. Standardmäßig wird die Beispieldatei mit den Testspezifikationen von Device Farm angezeigt, sodass Sie sie ansehen und bearbeiten können. Diese Beispieldatei kann als Ausgangspunkt verwendet werden, um Ihre Tests im [benutzerdefinierten Umgebungsmodus](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html) auszuprobieren. Sobald Sie dann von der Konsole aus überprüft haben, dass Ihre Tests ordnungsgemäß funktionieren, können Sie jede Ihrer API-, CLI- und Pipeline-Integrationen mit Device Farm ändern, um diese Testspezifikationsdatei als Parameter bei der Planung von Testläufen zu verwenden. [Informationen zum Hinzufügen einer Testspezifikationsdatei als Parameter für Ihre Läufe finden Sie im `testSpecArn` Parameterabschnitt für die `ScheduleRun` API in unserem API-Leitfaden.](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html)
## Appium-Framework
In einer benutzerdefinierten Testumgebung fügt Device Farm keine Appium-Funktionen in Ihre Appium-Framework-Tests ein oder überschreibt sie. Sie müssen die Appium-Funktionen Ihres Tests entweder in der YAML-Datei der Testspezifikation oder im Testcode angeben.
## Android-Instrumentierung
Für die Migration Ihrer Android-Instrumentierungstests auf eine benutzerdefinierte Testumgebung müssen Sie keine Änderungen vornehmen.
## iOS XCUITest
Sie müssen keine Änderungen vornehmen, um Ihre XCUITest iOS-Tests in eine benutzerdefinierte Testumgebung zu verschieben.
# Erweiterung benutzerdefinierter Testumgebungen in Device Farm
AWS Device Farm ermöglicht die Konfiguration einer benutzerdefinierten Umgebung für automatisierte Tests (benutzerdefinierter Modus). Dies ist der empfohlene Ansatz für alle Device Farm Farm-Benutzer. Im benutzerdefinierten Modus von Device Farm können Sie mehr als nur Ihre Testsuite ausführen. In diesem Abschnitt erfahren Sie, wie Sie Ihre Testsuite erweitern und Ihre Tests optimieren können.
Weitere Informationen zu benutzerdefinierten Testumgebungen in Device Farm finden Sie unter[Benutzerdefinierte Testumgebungen in AWS Device Farm](custom-test-environments.md).
**Topics**
+ [Einstellung einer Geräte-PIN beim Ausführen von Tests in Device Farm](custom-test-environments-extending-set-pin.md)
+ [Beschleunigung von Appium-basierten Tests in Device Farm durch die gewünschten Funktionen](custom-test-environments-extending-speed.md)
+ [Verwenden von Webhooks und anderen, APIs nachdem Ihre Tests in Device Farm ausgeführt wurden](custom-test-environments-extending-webhooks.md)
+ [Hinzufügen zusätzlicher Dateien zu Ihrem Testpaket in Device Farm](custom-test-environments-extending-files.md)
# Einstellung einer Geräte-PIN beim Ausführen von Tests in Device Farm
Bei einigen Anwendungen müssen Sie eine PIN auf dem Gerät festlegen. Device Farm unterstützt das native Einstellen einer PIN auf Geräten nicht. Dies ist jedoch mit den folgenden Einschränkungen möglich:
+ Auf dem Gerät muss Android 8 oder höher ausgeführt werden.
+ Die PIN muss nach Abschluss des Tests entfernt werden.
Um die PIN in Ihren Tests festzulegen, verwenden Sie die `post_test` Phasen `pre_test` und, um die PIN festzulegen und zu entfernen, wie im Folgenden gezeigt:
```
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"
```
Wenn Ihre Testsuite beginnt, ist die PIN 1234 festgelegt. Nach dem Beenden Ihrer Testsuite wird die PIN entfernt.
**Warnung**
Wenn Sie die PIN nach Abschluss des Tests nicht vom Gerät entfernen, werden das Gerät und Ihr Konto unter Quarantäne gestellt.
Weitere Möglichkeiten, Ihre Testsuite zu erweitern und Ihre Tests zu optimieren, finden Sie unter. [Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md)
# Beschleunigung von Appium-basierten Tests in Device Farm durch die gewünschten Funktionen
Wenn Sie Appium verwenden, stellen Sie möglicherweise fest, dass die Testsuite im Standardmodus sehr langsam ist. Dies liegt daran, dass Device Farm die Standardeinstellungen anwendet und keine Annahmen darüber trifft, wie Sie die Appium-Umgebung verwenden möchten. Diese Standardeinstellungen basieren zwar auf den bewährten Methoden der Branche, gelten jedoch möglicherweise nicht für Ihre Situation. Um die Parameter des Appium-Servers zu optimieren, können Sie die Standardfunktionen von Appium in Ihrer Testspezifikation anpassen. Im Folgenden wird beispielsweise die `usePrebuildWDA` Fähigkeit `true` in einer iOS-Testsuite auf festgelegt, um die anfängliche Startzeit zu beschleunigen:
```
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 &
```
Bei Appium-Fähigkeiten muss es sich um eine JSON-Struktur mit Shell-Escape-Code in Anführungszeichen handeln.
Die folgenden Appium-Funktionen sind häufig Quellen für Leistungsverbesserungen:
`noReset` und `fullReset`
Diese beiden Funktionen, die sich gegenseitig ausschließen, beschreiben das Verhalten von Appium nach Abschluss jeder Sitzung. Wenn auf gesetzt `noReset` ist`true`, entfernt der Appium-Server keine Daten aus Ihrer Anwendung, wenn eine Appium-Sitzung endet, und führt praktisch keine Bereinigung durch. `fullReset`deinstalliert und löscht alle Anwendungsdaten vom Gerät, nachdem die Sitzung geschlossen wurde. Weitere Informationen finden Sie unter [Reset-Strategien](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/) in der Appium-Dokumentation.
`ignoreUnimportantViews`(Nur Android)
Weist Appium an, die Hierarchie der Android-Benutzeroberfläche nur auf die für den Test *relevanten* Ansichten zu komprimieren, wodurch die Suche nach bestimmten Elementen beschleunigt wird. Dies kann jedoch einige XPath basierte Testsuiten beschädigen, da die Hierarchie des UI-Layouts geändert wurde.
`skipUnlock`(Nur Android)
Informiert Appium darüber, dass derzeit kein PIN-Code festgelegt ist, was Tests nach einem Ausschalten des Bildschirms oder einem anderen Sperrenereignis beschleunigt.
`webDriverAgentUrl`(nur iOS)
Weist Appium an, davon auszugehen, dass eine wichtige iOS-Abhängigkeit,`webDriverAgent`, bereits läuft und für die Annahme von HTTP-Anfragen an der angegebenen URL verfügbar ist. Wenn Appium noch `webDriverAgent` nicht aktiv ist, kann es zu Beginn einer Testsuite einige Zeit dauern, bis Appium gestartet ist. `webDriverAgent` Wenn Sie `webDriverAgent` selbst starten und `http://localhost:8100` beim Start von Appium `webDriverAgentUrl` auf einstellen, können Sie Ihre Testsuite schneller starten. Beachten Sie, dass diese Funktion niemals zusammen mit der `useNewWDA` Funktion verwendet werden sollte.
Sie können den folgenden Code verwenden, um mit Ihrer Testspezifikationsdatei am lokalen Port `8100` des Geräts zu beginnen `webDriverAgent` und sie dann an den lokalen Port des Testhosts weiterzuleiten `8100` (auf diese Weise können Sie den Wert auf setzen `webDriverAgentUrl``http://localhost:8100`). Dieser Code sollte während der Installationsphase ausgeführt werden, nachdem der Code für die Einrichtung des Appium und der `webDriverAgent` Umgebungsvariablen definiert wurde:
```
# 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 &
```
Anschließend können Sie Ihrer Testspezifikationsdatei den folgenden Code hinzufügen, um sicherzustellen, dass sie erfolgreich `webDriverAgent` gestartet wurde. Dieser Code sollte am Ende der Vortestphase ausgeführt werden, nachdem sichergestellt wurde, dass Appium erfolgreich gestartet wurde:
```
# 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;
```
Weitere Informationen zu den Funktionen, die Appium unterstützt, finden Sie unter Appium [Desired Capabilities in der Appium-Dokumentation](http://appium.io/docs/en/writing-running-appium/caps/).
Weitere Möglichkeiten, Ihre Testsuite zu erweitern und Ihre Tests zu optimieren, finden Sie unter. [Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md)
# Verwenden von Webhooks und anderen, APIs nachdem Ihre Tests in Device Farm ausgeführt wurden
Sie können Device Farm einen Webhook aufrufen lassen, nachdem die Verwendung **curl** jeder Testsuite abgeschlossen ist. Der dazu erforderliche Vorgang hängt vom Ziel und der Formatierung ab. Informationen zu Ihrem spezifischen Webhook finden Sie in der Dokumentation zu diesem Webhook. Im folgenden Beispiel wird jedes Mal, wenn eine Testsuite fertig ist, eine Nachricht an einen Slack-Webhook gesendet:
```
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
```
Weitere Informationen zur Verwendung von Webhooks mit Slack findest du unter [Deine erste Slack-Nachricht mit Webhook versenden in der Slack-API-Referenz](https://api.slack.com/tutorials/slack-apps-hello-world).
Weitere Möglichkeiten, deine Testsuite zu erweitern und deine Tests zu optimieren, findest du unter. [Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md)
Sie sind nicht darauf beschränkt, Webhooks **curl** aufzurufen. Testpakete können zusätzliche Skripts und Tools enthalten, sofern sie mit der Device Farm Farm-Ausführungsumgebung kompatibel sind. Ihr Testpaket kann beispielsweise Hilfsskripten enthalten, die Anfragen an andere richten APIs. Stellen Sie sicher, dass alle erforderlichen Pakete zusammen mit den Anforderungen Ihrer Testsuite installiert sind. Um ein Skript hinzuzufügen, das ausgeführt wird, nachdem Ihre Testsuite fertiggestellt ist, nehmen Sie das Skript in Ihr Testpaket auf und fügen Sie Ihrer Testspezifikation Folgendes hinzu:
```
phases:
post_test:
- python post_test.py
```
**Anmerkung**
Die Verwaltung aller API-Schlüssel oder anderer Authentifizierungstoken, die in Ihrem Testpaket verwendet werden, liegt in Ihrer Verantwortung. Wir empfehlen Ihnen, jegliche Form von Sicherheitsanmeldedaten außerhalb der Quellcodeverwaltung aufzubewahren, Anmeldeinformationen mit möglichst wenigen Rechten zu verwenden und wann immer möglich widerrufbare, kurzlebige Token zu verwenden. Informationen zur Überprüfung der Sicherheitsanforderungen finden Sie in der Dokumentation des Drittanbieters, den Sie verwenden. APIs
Wenn Sie beabsichtigen, AWS Dienste als Teil Ihrer Testausführungssuite zu verwenden, sollten Sie temporäre IAM-Anmeldeinformationen verwenden, die außerhalb Ihrer Testsuite generiert wurden und in Ihrem Testpaket enthalten sind. Für diese Anmeldeinformationen sollten so wenige Berechtigungen wie möglich erteilt werden und die Lebensdauer sollte so kurz wie möglich sein. Weitere Informationen zum Erstellen temporärer Anmeldeinformationen finden Sie unter [Temporäre Sicherheitsanmeldeinformationen anfordern](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html) im *IAM-Benutzerhandbuch*.
Weitere Möglichkeiten, Ihre Testsuite zu erweitern und Ihre Tests zu optimieren, finden Sie unter[Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md).
# Hinzufügen zusätzlicher Dateien zu Ihrem Testpaket in Device Farm
Möglicherweise möchten Sie zusätzliche Dateien als Teil Ihrer Tests verwenden, entweder als zusätzliche Konfigurationsdateien oder als zusätzliche Testdaten. Sie können diese zusätzlichen Dateien Ihrem Testpaket hinzufügen, bevor Sie es hochladen AWS Device Farm, und dann im benutzerdefinierten Umgebungsmodus darauf zugreifen. Grundsätzlich handelt es sich bei allen Uploadformaten für Testpakete (ZIP, IPA, APK, JAR usw.) um Paketarchivformate, die standardmäßige ZIP-Operationen unterstützen.
Sie können Ihrem Testarchiv Dateien hinzufügen, bevor Sie es hochladen, AWS Device Farm indem Sie den folgenden Befehl verwenden:
```
$ zip zip-with-dependencies.zip extra_file
```
Für ein Verzeichnis mit zusätzlichen Dateien:
```
$ zip -r zip-with-dependencies.zip extra_files/
```
Diese Befehle funktionieren erwartungsgemäß für alle Upload-Formate von Testpaketen mit Ausnahme von IPA-Dateien. Für IPA-Dateien, insbesondere wenn sie mit verwendet werden, empfehlen wir XCUITests, dass Sie alle zusätzlichen Dateien aufgrund der Art und Weise, wie AWS Device Farm iOS-Testpakete entworfen werden, an einem etwas anderen Speicherort ablegen. Beim Erstellen Ihres iOS-Tests befindet sich das Testanwendungsverzeichnis in einem anderen Verzeichnis mit dem Namen*Payload*.
So könnte beispielsweise ein solches iOS-Testverzeichnis aussehen:
```
$ 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
```
Fügen Sie für diese XCUITest Pakete alle zusätzlichen Dateien zu dem Verzeichnis hinzu, das *.app* innerhalb des *Payload* Verzeichnisses endet. Die folgenden Befehle zeigen beispielsweise, wie Sie diesem Testpaket eine Datei hinzufügen können:
```
$ mv extra_file Payload/*.app/
$ zip -r my_xcui_tests.ipa Payload/
```
Wenn Sie Ihrem Testpaket eine Datei hinzufügen, können Sie AWS Device Farm je nach Upload-Format ein leicht unterschiedliches Interaktionsverhalten erwarten. Wenn für den Upload die ZIP-Dateierweiterung verwendet wurde, AWS Device Farm wird der Upload vor dem Test automatisch entpackt und die entpackten Dateien werden an dem Speicherort mit der *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* Umgebungsvariablen belassen. (Das heißt, wenn Sie wie im ersten Beispiel eine Datei mit dem Namen *extra\$1file* zum Stammverzeichnis des Archivs hinzufügen würden, würde sie sich *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file* während des Tests unter befinden).
Um ein praktischeres Beispiel zu verwenden: Wenn Sie ein Appium TestNG-Benutzer sind und eine *testng.xml* Datei in Ihren Test aufnehmen möchten, können Sie sie mit dem folgenden Befehl in Ihr Archiv aufnehmen:
```
$ zip zip-with-dependencies.zip testng.xml
```
Anschließend können Sie Ihren Testbefehl im benutzerdefinierten Umgebungsmodus wie folgt ändern:
```
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
```
Wenn Ihre Upload-Erweiterung für das Testpaket nicht ZIP ist (z. B. APK-, IPA- oder JAR-Datei), finden Sie die hochgeladene Paketdatei selbst unter*\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH*. Da es sich immer noch um Dateien im Archivformat handelt, können Sie die Datei entpacken, um von innen auf die zusätzlichen Dateien zuzugreifen. Mit dem folgenden Befehl wird beispielsweise der Inhalt des Testpakets (für APK-, IPA- oder JAR-Dateien) in das Verzeichnis entpackt: */tmp*
```
unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp
```
Im Fall einer APK- oder JAR-Datei würden Sie feststellen, dass Ihre zusätzlichen Dateien in das */tmp* Verzeichnis entpackt wurden (z. B.). */tmp/extra\$1file* Im Fall einer IPA-Datei würden sich zusätzliche Dateien, wie bereits erläutert, an einem etwas anderen Ort innerhalb des Ordners befinden, der auf*.app*, endet und sich innerhalb des Verzeichnisses befindet. *Payload* Basierend auf dem obigen IPA-Beispiel würde sich die Datei beispielsweise an dem Speicherort befinden */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file* (referenzierbar als). */tmp/Payload/\$1.app/extra\$1file*
Weitere Möglichkeiten, Ihre Testsuite zu erweitern und Ihre Tests zu optimieren, finden Sie unter. [Erweiterung benutzerdefinierter Testumgebungen in Device Farm](custom-test-environments-extending.md)