Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Environnements de test personnalisés dans AWS Device Farm
AWS Device Farm permet de configurer un environnement personnalisé pour les tests automatisés (mode personnalisé), ce qui est l'approche recommandée pour tous les utilisateurs de Device Farm. Pour en savoir plus sur les environnements de Device Farm, consultez la section [Environnements de test](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html).
Les avantages du mode personnalisé par rapport au mode standard incluent :
+ **Exécution plus rapide des end-to-end tests** : le package de test n'est pas analysé pour détecter tous les tests de la suite, ce qui permet d'éviter des preprocessing/postprocessing frais supplémentaires.
+ **Journal en direct et diffusion vidéo** : vos journaux de test et vos vidéos côté client sont diffusés en direct lorsque vous utilisez le mode personnalisé. Cette fonctionnalité n'est pas disponible en mode standard.
+ **Capture tous les artefacts** : sur l'hôte et sur l'appareil, le mode personnalisé vous permet de capturer tous les artefacts de test. Cela peut ne pas être possible en mode standard.
+ **Environnement local plus cohérent et reproductible** : en mode standard, les artefacts seront fournis séparément pour chaque test individuel, ce qui peut être bénéfique dans certaines circonstances. Cependant, votre environnement de test local peut s'écarter de la configuration d'origine car Device Farm gère différemment chaque test exécuté.
En revanche, le mode personnalisé vous permet de faire en sorte que votre environnement d'exécution des tests Device Farm soit toujours conforme à votre environnement de test local.
Les environnements personnalisés sont configurés à l'aide d'un fichier de spécification de test au format YAML (spécification de test). Device Farm fournit un fichier de spécifications de test par défaut pour chaque type de test pris en charge, qui peut être utilisé tel quel ou personnalisé ; des personnalisations telles que des filtres de test ou des fichiers de configuration peuvent être ajoutées aux spécifications de test. Les spécifications de test modifiées peuvent être enregistrées pour les futurs tests.
Pour plus d'informations, consultez la section [Téléchargement d'une spécification de test personnalisée à l'aide du AWS CLI](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5) et. [Création d'un test dans Device Farm](how-to-create-test-run.md)
**Topics**
+ [Référence et syntaxe des spécifications de test](custom-test-environment-test-spec.md)
+ [Hôtes pour environnements de test personnalisés](custom-test-environments-hosts.md)
+ [Accédez aux ressources AWS à l'aide d'un rôle d'exécution IAM](custom-test-environments-iam-roles.md)
+ [Variables d'environnement pour les environnements de test personnalisés](custom-test-environment-variables.md)
+ [Bonnes pratiques pour l'exécution d'un environnement de test personnalisé](custom-test-environments-best-practices.md)
+ [Migration des tests d'un environnement de test standard vers un environnement de test personnalisé](custom-test-environment-migration.md)
+ [Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md)
# Référence et syntaxe des spécifications de test
La spécification de test (spécification de test) est un fichier que vous utilisez pour définir des environnements de test personnalisés dans Device Farm.
## Flux de travail des spécifications de test
La spécification de test Device Farm exécute les phases et leurs commandes dans un ordre prédéterminé, ce qui vous permet de personnaliser la façon dont votre environnement est préparé et exécuté. Lorsque chaque phase est exécutée, ses commandes sont exécutées dans l'ordre indiqué dans le fichier de spécifications de test. Les phases sont exécutées dans l'ordre suivant
1. `install`- C'est là que les actions telles que le téléchargement, l'installation et la configuration des outils doivent être définies.
1. `pre_test`- C'est là que les actions de pré-test, telles que le démarrage de processus en arrière-plan, doivent être définies.
1. `test`- C'est ici que la commande qui appelle votre test doit être définie.
1. `post_test`- C'est ici que doivent être définies toutes les tâches finales qui doivent être exécutées après la fin de votre test, telles que la génération de rapports de test et l'agrégation de fichiers d'artefacts.
## Syntaxe des spécifications de test
Le schéma YAML d'un fichier de spécifications de test est le suivant :
```
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` **
*(Obligatoire, numéro)*
Reflète la version des spécifications de test prise en charge par Device Farm. Le numéro de version actuel est` 0.1`.
** `android_test_host` **
*(Facultatif, chaîne)*
L'hôte de test qui sera sélectionné pour les tests effectués sur les appareils Android. Ce champ est obligatoire pour les tests sur les appareils Android. Pour de plus amples informations, veuillez consulter [Hôtes de test disponibles pour les environnements de test personnalisés](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `ios_test_host` **
*(Facultatif, chaîne)*
L'hôte de test qui sera sélectionné pour les tests effectués sur des appareils iOS. Ce champ est obligatoire pour les tests sur les appareils iOS dotés d'une version majeure supérieure à 26. Pour de plus amples informations, veuillez consulter [Hôtes de test disponibles pour les environnements de test personnalisés](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `phases` **
Cette section contient des groupes de commandes exécutées lors d'un essai, chaque phase étant facultative. Les noms de phase de test autorisés sont : `install``pre_test`,`test`, et`post_test`.
+ `install`- Les dépendances par défaut pour les frameworks de test pris en charge par Device Farm sont déjà installées. Cette phase contient des commandes supplémentaires, le cas échéant, que Device Farm exécute pendant l'installation.
+ `pre_test`- Les commandes, le cas échéant, exécutées avant votre test automatique.
+ `test`- Les commandes exécutées lors de votre test automatique. Si une commande de la phase de test échoue (c'est-à-dire qu'elle renvoie un code de sortie différent de zéro), le test est marqué comme ayant échoué
+ `post_test`- Les commandes, le cas échéant, exécutées après votre test automatique. Cela sera exécuté, que votre test réussisse ou non dans la `test` phase.
** `commands` **
*(Facultatif, Liste [chaîne])*
Une liste de chaînes à exécuter en tant que commande shell pendant la phase.
** `artifacts` **
*(Facultatif, Liste [chaîne])*
Device Farm collecte des artefacts tels que des rapports personnalisés, des fichiers journaux et des images à partir d'un emplacement spécifié ici. Les caractères génériques ne sont pas pris en charge dans le cadre d'un emplacement d'artefact. Par conséquent, vous devez spécifier un chemin d'accès valide pour chaque emplacement.
Ces artefacts de test sont disponibles pour chaque appareil de votre test. Pour plus d'informations sur la récupération de vos artefacts de test, consultez [Téléchargement d'artefacts dans un environnement de test personnalisé](using-artifacts-custom.md).
**Important**
Une spécification de test doit être mise en forme comme un fichier YAML valide. Si la mise en retrait ou l'espacement ne sont pas valides dans votre spécification de test, votre test peut échouer. Les tabulations ne sont pas autorisées dans les fichiers YAML. Vous pouvez utiliser un validateur YAML pour vérifier si votre spécification de test est un fichier YAML valide. Pour plus d'informations, consultez le [site web YAML](http://yaml.org/spec/1.2/spec.html).
## Exemples de spécifications de test
Les exemples suivants présentent les spécifications de test qui peuvent être exécutées sur Device Farm.
------
#### [ Simple Demo ]
Voici un exemple de fichier de spécifications de test qui se connecte simplement en `Hello world!` tant qu'artefact d'exécution d'un test.
```
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
```
------
#### [ Android Appium ]
Voici un exemple de fichier de spécifications de test qui configure un test Appium Java TestNG exécuté sur Android.
```
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 pour iOS ]
Voici un exemple de fichier de spécifications de test qui configure un test Appium Java TestNG exécuté sur iOS.
```
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) ]
Voici un exemple de fichier de spécifications de test qui configure un test Appium Java TestNG exécuté à la fois sur Android et iOS.
```
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
```
------
# Hôtes pour environnements de test personnalisés
Device Farm prend en charge un ensemble de systèmes d'exploitation dotés de logiciels préconfigurés grâce à l'utilisation d'un environnement hôte de test. Pendant l'exécution du test, Device Farm utilise des instances gérées par Amazon (hôtes) qui se connectent dynamiquement à l'appareil sélectionné en cours de test. Cette instance est entièrement nettoyée et n'est pas réutilisée entre les exécutions. Elle est interrompue avec les artefacts générés une fois le test terminé.
**Topics**
+ [Hôtes de test disponibles pour les environnements de test personnalisés](#custom-test-environments-hosts-available)
+ [Sélection d'un hôte de test pour les environnements de test personnalisés](#test-host-selection)
+ [Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md)
+ [Environnement de test pour appareils Android](custom-test-environments-hosts-android.md)
+ [Environnement de test pour appareils iOS](custom-test-environments-hosts-ios.md)
## Hôtes de test disponibles pour les environnements de test personnalisés
Les hôtes de test sont entièrement gérés par Device Farm. Le tableau suivant répertorie les hôtes de test Device Farm actuellement disponibles et pris en charge pour les environnements de test personnalisés.
| Plateforme d'appareils | Hôte du test | Système d’exploitation | Architecture (s) | Appareils pris en charge |
| --- | --- | --- | --- | --- |
| Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android6 et plus |
| iOS | macos\$1sequoia | macOS Sequoia(version 15) | arm64 | iOS15 à 26 |
**Note**
Device Farm ajoute régulièrement de nouveaux hôtes de test pour une plate-forme d'appareil afin de prendre en charge les nouvelles versions du système d'exploitation de l'appareil et ses dépendances. Dans ce cas, les anciens hôtes de test pour la plate-forme d'appareil concernée sont sujets à la fin du support.
### Version du système d'exploitation
Chaque hôte de test disponible utilise une version spécifique du système d'exploitation pris en charge par Device Farm à ce moment-là. Bien que nous essayions d'utiliser la dernière version du système d'exploitation, il se peut que ce ne soit pas la dernière version distribuée publiquement disponible. Device Farm mettra régulièrement à jour le système d'exploitation avec des mises à jour mineures et des correctifs de sécurité.
Pour connaître la version spécifique (y compris la version mineure) du système d'exploitation utilisée lors de votre exécution de test, vous pouvez ajouter l'extrait de code suivant à l'une des phases de votre fichier de spécifications de test.
**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
```
## Sélection d'un hôte de test pour les environnements de test personnalisés
Vous pouvez spécifier l'hôte de test Android et iOS dans les `ios_test_host` variables appropriées `android_test_host` de votre [fichier de spécifications de test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax).
Si vous ne spécifiez pas de sélection d'hôte de test pour la plate-forme d'appareil donnée, les tests seront exécutés sur l'hôte de test que Device Farm a défini par défaut pour le périphérique et la configuration de test spécifiés.
**Important**
Lors des tests sur iOS 18 et versions antérieures, un hôte de test existant sera utilisé lorsqu'aucun hôte n'est sélectionné. Pour plus d'informations, consultez la rubrique sur le[Ancien hôte de test iOS](custom-test-environments-hosts-ios.md#legacy-ios-host).
À titre d'exemple, consultez l'extrait de code suivant :
**Example**
```
version: 0.1
android_test_host: amazon_linux_2
ios_test_host: macos_sequoia
phases:
# ...
```
# Logiciels pris en charge dans des environnements de test personnalisés
Device Farm utilise des machines hôtes préinstallées avec de nombreuses bibliothèques logicielles nécessaires pour exécuter les frameworks de test pris en charge par notre service, fournissant ainsi un environnement de test prêt au lancement. Device Farm prend en charge plusieurs langues grâce à notre mécanisme de sélection de logiciels et mettra régulièrement à jour les versions des langues incluses dans l'environnement.
Pour tout autre logiciel requis, vous pouvez modifier le fichier de spécifications de test pour l'installer à partir de votre package de test, le télécharger depuis Internet ou accéder à des sources privées au sein de votre VPC (voir [VPC](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html) ENI pour plus d'informations). Pour de plus amples informations, veuillez consulter [Exemples de spécifications de test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example).
## Logiciel préconfiguré
Afin de faciliter le test des appareils sur chaque plate-forme, les outils suivants sont fournis sur l'hôte de test :
| Outils | Plate-forme (s) d'appareils |
| --- | --- |
| Android SDK Build-Tools | Android |
| Android SDK Platform-Tools(inclut`adb`) | Android |
| Xcode | iOS |
## Logiciel sélectionnable
Outre le logiciel préconfiguré sur l'hôte, Device Farm permet de sélectionner certaines versions des logiciels pris en charge via l'`devicefarm-cli`outillage.
Le tableau suivant répertorie les logiciels sélectionnables et les hôtes de test qui les contiennent.
| Logiciel/Outil | Hôtes compatibles avec ce logiciel | Commande à utiliser dans votre spécification de test |
| --- | --- | --- |
| 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` |
L'hôte de test inclut également des outils de support couramment utilisés pour chaque version du logiciel, tels que les gestionnaires de `npm` packages `pip` et (inclus respectivement avec Python et Node.js) et les dépendances (telles que le UIAutomator2 pilote Appium) pour des outils tels qu'Appium. Cela garantit que vous disposez des outils nécessaires pour travailler avec les frameworks de test pris en charge.
# Utilisation de l'outil devicefarm-cli dans des environnements de test personnalisés
L'hôte de test utilise un outil de gestion des versions normalisé appelé ` devicefarm-cli` à sélectionner les versions du logiciel. Cet outil est distinct de l'hôte de test Device Farm AWS CLI et n'est disponible que sur celui-ci. Avec`devicefarm-cli`, vous pouvez passer à n'importe quelle version logicielle préinstallée sur l'hôte de test. Cela fournit un moyen simple de gérer votre fichier de spécifications de test Device Farm au fil du temps et vous donne un mécanisme prévisible pour mettre à niveau les versions logicielles à l'avenir.
**Important**
Cet outil de ligne de commande n'est pas disponible sur les anciens hôtes iOS. Pour plus d'informations, consultez la rubrique sur le[Ancien hôte de test iOS](custom-test-environments-hosts-ios.md#legacy-ios-host).
L'extrait ci-dessous montre la `help` page de : `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.
```
Passons en revue quelques exemples d'utilisation de`devicefarm-cli`. Pour utiliser l'outil afin de modifier la version de Python de *3.10* à *3.9* dans votre fichier de spécifications de test, exécutez les commandes suivantes :
```
$ python --version
Python 3.10.12
$ devicefarm-cli use python 3.9
$ python --version
Python 3.9.17
```
Pour passer de la version d'Appium à *1* : *2*
```
$ appium --version
1.22.3
$ devicefarm-cli use appium 2
$ appium --version
2.1.2
```
**Astuce**
Notez que lorsque vous sélectionnez une version logicielle, vous `devicefarm-cli` changez également les outils de support pour ces langages, tels que `pip` Python et `npm` NodeJS.
Pour plus d'informations sur le logiciel préinstallé sur l'hôte de test, consultez[Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md).
# Environnement de test pour appareils Android
AWS Device Farm utilise les machines hôtes Amazon Elastic Compute Cloud (EC2) exécutant Amazon Linux 2 pour exécuter des tests Android. Lorsque vous planifiez un test, Device Farm alloue un hôte dédié à chaque appareil afin d'exécuter des tests de manière indépendante. Les machines hôtes s'arrêtent après le test, ainsi que tous les artefacts générés.
L'hôte Amazon Linux 2 offre plusieurs avantages :
+ **Tests plus rapides et plus fiables** : par rapport à l'ancien hôte, le nouvel hôte de test améliore considérablement la vitesse des tests, notamment en réduisant les temps de démarrage des tests. L'hôte Amazon Linux 2 fait également preuve d'une stabilité et d'une fiabilité accrues lors des tests.
+ **Accès à distance amélioré pour les tests manuels** : les mises à niveau vers le dernier hôte de test et les améliorations permettent de réduire la latence et d'améliorer les performances vidéo pour les tests manuels sur Android.
+ **Sélection de la version logicielle standard** : Device Farm normalise désormais la prise en charge des principaux langages de programmation sur l'hôte de test ainsi que sur les versions du framework Appium. Pour les langages pris en charge (actuellement Java, Python, Node.js et Ruby) et Appium, le nouvel hôte de test fournit des versions stables à long terme peu après le lancement. La gestion centralisée des versions via l'`devicefarm-cli`outil permet le développement de fichiers de spécifications de test avec une expérience cohérente dans tous les frameworks.
**Topics**
+ [Plages d'adresses IP prises en charge pour l'environnement de test Amazon Linux 2 dans Device Farm](amazon-linux-2-ip-ranges.md)
# Plages d'adresses IP prises en charge pour l'environnement de test Amazon Linux 2 dans Device Farm
Les clients ont souvent besoin de connaître la plage d'adresses IP d'où provient le trafic de Device Farm, notamment pour configurer leurs pare-feux et leurs paramètres de sécurité. Pour les hôtes de test Amazon EC2, la plage d'adresses IP couvre l'ensemble `us-west-2` de la région. Pour les hôtes de test Amazon Linux 2, qui est l'option par défaut pour les nouvelles versions d'Android, les plages ont été limitées. Le trafic provient désormais d'un ensemble spécifique de passerelles NAT, limitant la plage d'adresses IP aux adresses suivantes :
****
| Plages IP |
| --- |
| **44,236,137,143** |
| **52,13,151,244** |
| **52,35,189,191** |
| **54,201,250,26** |
Pour plus d'informations sur les environnements de test Android dans Device Farm, consultez[Environnement de test pour appareils Android](custom-test-environments-hosts-android.md).
# Environnement de test pour appareils iOS
Device Farm utilise des instances de macOS (hôtes) gérées par Amazon qui se connectent dynamiquement à l'appareil iOS pendant le test. Chaque hôte est préconfiguré avec un logiciel qui permet de tester les appareils sur diverses plateformes de test populaires, telles que XCTest UI et Appium.
L'itération actuelle de l'hôte de test iOS a amélioré l'expérience de test par rapport aux versions précédentes, notamment :
+ **Expérience cohérente du système d'exploitation hôte et de l'outillage pour iOS 15 à iOS 26** Auparavant, l'hôte de test était déterminé par l'appareil utilisé, ce qui entraînait un environnement logiciel fragmenté lors de l'exécution sur plusieurs versions d'iOS. L'expérience actuelle permet une sélection simple des hôtes afin de créer un environnement cohérent sur tous les appareils. Cela permettra à la même version de macOS et aux mêmes outils (tels que Xcode) d'être disponibles sur chaque appareil iOS.
+ **Améliorations des performances pour les tests iOS 15 et 16** Grâce à une infrastructure mise à jour, le temps de configuration s'est considérablement amélioré pour les tests iOS 15 et 16.
+ **Versions logicielles standardisées sélectionnables pour les dépendances prises en charge** Nous disposons désormais d'un système de sélection de `devicefarm-cli` logiciels sur les hôtes de test iOS et Android, qui vous permet de sélectionner votre version préférée de nos dépendances prises en charge. Pour les dépendances prises en charge (telles que Java, Python, Node.js, Ruby et Appium), les versions seront sélectionnables via la spécification de test. Pour avoir une idée du fonctionnement de cette fonctionnalité, consultez la rubrique sur[Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md).
**Important**
S'ils sont exécutés sur iOS 18 ou une version antérieure, vos tests s'exécuteront par défaut sur les anciens hôtes de test. Consultez la rubrique ci-dessous pour savoir comment migrer hors des hôtes existants.
## Ancien hôte de test iOS
Pour les tests existants sur iOS 18 et versions antérieures, les anciens hôtes de test sont sélectionnés par défaut pour les environnements de test personnalisés. Le tableau suivant indique la version de l'hôte de test exécutée avec la version de l'appareil iOS.
| Système d’exploitation | Architecture (s) | Par défaut pour les appareils |
| --- | --- | --- |
| macOS Sonoma(version 14) | arm64 | iOS 18 |
| macOS Ventura(version 13) | arm64 | iOS 17 |
| macOS Monterey(version 12) | x86\$164 | iOS 16et ci-dessous |
Pour sélectionner les nouveaux hôtes de test, consultez la rubrique concernant[Migration de vos environnements de test personnalisés vers les nouveaux hôtes de test iOS](ios-host-migration.md).
## Logiciels pris en charge pour les appareils iOS
Afin de prendre en charge les tests d'appareils iOS, les hôtes de test Device Farm pour appareils iOS sont préconfigurés avec Xcode et ses outils de ligne de commande associés. Pour les autres logiciels disponibles, veuillez consulter la rubrique concernant[Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md).
# Migration de vos environnements de test personnalisés vers les nouveaux hôtes de test iOS
Pour migrer les tests existants de l'ancien hôte vers le nouvel hôte de test macOS, vous devez développer de nouveaux fichiers de spécifications de test basés sur vos fichiers de spécifications préexistants.
L'approche recommandée consiste à commencer par l'exemple de fichier de spécifications de test pour les types de test souhaités, puis à migrer les commandes pertinentes de votre ancien fichier de spécifications de test vers le nouveau. Cela vous permet de tirer parti des nouvelles fonctionnalités et des optimisations de l'exemple de spécification de test pour le nouvel hôte tout en réutilisant des extraits de code existant.
**Topics**
+ [Tutoriel : Migration des fichiers de spécifications de test iOS avec la console](#ios-host-migration-console-tutorial)
+ [Différences entre les nouveaux hôtes de test et les anciens](#ios-host-migration-differences)
## Tutoriel : Migration des fichiers de spécifications de test iOS avec la console
Dans cet exemple, la console Device Farm sera utilisée pour intégrer une spécification de test d'appareil iOS existante afin d'utiliser le nouvel hôte de test.
### Étape 1 : Création de nouveaux fichiers de spécifications de test avec la console
1. Connectez-vous à la [console AWS Device Farm](https://console.aws.amazon.com/devicefarm).
1. Accédez au projet Device Farm contenant vos tests d'automatisation.
1. Téléchargez une copie des spécifications de test existantes que vous souhaitez utiliser.
1. Cliquez sur l'option « Paramètres du projet » et accédez à l'onglet **Téléchargements**.
1. Accédez au fichier de spécifications de test que vous souhaitez intégrer.
1. Cliquez sur le bouton **Télécharger** pour créer une copie locale de ce fichier.
1. Retournez à la page Projet et cliquez sur **Créer une exécution**.
1. Renseignez les options de l'assistant comme si vous deviez démarrer une nouvelle exécution, mais arrêtez-vous sur l'option **Sélectionner les spécifications de test**.
1. À l'aide de la spécification de test iOS sélectionnée par défaut, cliquez sur le bouton **Créer une spécification de test**.
1. Modifiez la spécification de test sélectionnée par *défaut* dans l'éditeur de texte.
1. S'il n'est pas déjà présent, modifiez le fichier de spécifications de test pour sélectionner le nouvel hôte en utilisant :
```
ios_test_host: macos_sequoia
```
1. À partir de la copie de votre spécification de test téléchargée lors d'une étape précédente, passez en revue chacune ` phase` d'elles.
1. Copiez les commandes des phases de l'ancienne spécification de test dans chaque phase respective de la nouvelle spécification de test, en ignorant les commandes liées à l'installation ou à la sélection de Java, Python, Node.js, Ruby, Appium ou Xcode.
1. Entrez un nouveau nom de fichier dans la zone de texte **Enregistrer sous**.
1. Cliquez sur le bouton **Enregistrer en tant que nouveau** pour enregistrer vos modifications.
Pour un exemple de fichier de spécifications de test que vous pouvez utiliser comme référence, consultez l'exemple fourni dans[Exemples de spécifications de test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example).
### Étape 2 : Sélection du logiciel préinstallé
Dans le nouvel hôte de test, les versions logicielles préinstallées sont sélectionnées à l'aide d'un nouvel outil de gestion des versions standardisé appelé`devicefarm-cli`. Cet outillage est désormais l'approche recommandée pour utiliser les différents logiciels que nous fournissons sur les hôtes de test.
Par exemple, vous devez ajouter la ligne suivante pour utiliser un JDK 17 différent dans votre environnement de test :
```
- devicefarm-cli use java 17
```
Pour plus d'informations sur les logiciels pris en charge disponibles, veuillez consulter :[Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md).
### Étape 3 : Utilisation d'Appium et de ses dépendances via l'outil de sélection de logiciels
Le nouvel hôte de test prend uniquement en charge Appium 2.x et versions ultérieures. Veuillez sélectionner explicitement la version d'Appium à l'aide du`devicefarm-cli`, tout en supprimant les outils existants tels que. ` avm` Par exemple :
```
# 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
```
La version d'Appium sélectionnée `devicefarm-cli` est préinstallée avec une version compatible du pilote XCUITest pour iOS.
De plus, vous devrez mettre à jour vos spécifications de test pour les utiliser au ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` lieu de` DEVICEFARM_WDA_DERIVED_DATA_PATH`. La nouvelle variable d'environnement indique une version prédéfinie de WebDriverAgent 9.x, qui est la dernière version prise en charge pour les tests Appium 2.
Pour plus d'informations, consultez [Sélection d'une WebDriverAgent version pour les tests iOS](test-types-appium.md#test-types-appium-select-wda) et[Variables d'environnement pour les tests Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium).
## Différences entre les nouveaux hôtes de test et les anciens
Lorsque vous modifiez votre fichier de spécifications de test pour utiliser le nouvel hôte de test iOS et que vous transférez vos tests depuis l'ancien hôte de test, tenez compte de ces principales différences d'environnement :
+ **Versions Xcode :** dans l'ancien environnement hôte de test, la version Xcode disponible était basée sur la version iOS de l'appareil utilisé pour les tests. Par exemple, les tests sur les appareils iOS 18 ont utilisé Xcode 16 dans l'ancien hôte, tandis que les tests sur iOS 17 ont utilisé Xcode 15. Dans le nouvel environnement hôte, tous les appareils peuvent accéder aux mêmes versions de Xcode, ce qui permet de disposer d'un environnement cohérent pour les tests sur des appareils dotés de versions différentes. Pour obtenir la liste des versions de Xcode actuellement disponibles, consultez[Logiciels pris en charge](custom-test-environments-hosts-software.md).
+ **Sélection des versions logicielles :** Dans de nombreux cas, les versions logicielles par défaut ont changé. Par conséquent, si vous ne sélectionniez pas explicitement votre version logicielle sur l'ancien hôte de test, vous souhaiterez peut-être la spécifier maintenant sur le nouvel hôte de test en utilisant [`devicefarm-cli`](custom-test-environments-hosts-software-cli.md). Dans la grande majorité des cas d'utilisation, nous recommandons aux clients de sélectionner explicitement les versions des logiciels qu'ils utilisent. En sélectionnant une version logicielle avec, `devicefarm-cli` vous bénéficierez d'une expérience prévisible et cohérente et recevrez de nombreux avertissements si Device Farm prévoit de supprimer cette version de l'hôte de test.
De plus, les outils de sélection de logiciels tels que `nvm` `pyenv`` avm`,, et `rvm` ont été supprimés au profit du nouveau système de sélection de ` devicefarm-cli` logiciels.
+ **Versions logicielles disponibles :** de nombreuses versions de logiciels précédemment préinstallés ont été supprimées et de nombreuses nouvelles versions ont été ajoutées. Assurez-vous donc que lorsque vous utilisez le `devicefarm-cli` pour sélectionner les versions de vos logiciels, vous sélectionnez les versions figurant dans la [liste des versions prises en charge](custom-test-environments-hosts-software.md).
+ **La `libimobiledevice` suite d'outils a été supprimée** au profit d'outils plus récents ou de première génération permettant de suivre les tests actuels des appareils iOS et les normes du secteur. Pour iOS 17 et versions ultérieures, vous pouvez migrer la plupart des commandes pour utiliser un outil Xcode similaire, appelé. `devicectl` Pour plus d'informations`devicectl`, vous pouvez exécuter `xcrun devicectl help` depuis une machine sur laquelle Xcode est installé.
+ **Les chemins de fichiers codés en dur** dans votre ancien fichier de spécifications de test d'hôte en tant que chemins absolus ne fonctionneront probablement pas comme prévu sur le nouvel hôte de test, et ils ne sont généralement pas recommandés pour l'utilisation des fichiers de spécifications de test. Nous vous recommandons d'utiliser des chemins relatifs et des variables d'environnement pour tout le code des fichiers de spécifications de test. Pour plus d'informations, consultez la rubrique sur[Bonnes pratiques pour l'exécution d'un environnement de test personnalisé](custom-test-environments-best-practices.md).
+ **Version et architecture du système d'exploitation :** Les anciens hôtes de test utilisaient diverses versions de macOS et architectures de processeur en fonction du périphérique attribué. Par conséquent, les utilisateurs peuvent remarquer certaines différences dans les bibliothèques système disponibles dans l'environnement. Pour plus d'informations sur la version précédente du système d'exploitation hôte, consultez[Ancien hôte de test iOS](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ **Pour les utilisateurs d'Appium**, la méthode de sélection WebDriverAgent a été remplacée par un préfixe de variable d'environnement use ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` au lieu de l'ancien préfixe. ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` Pour plus d'informations sur la variable mise à jour, consultez[Variables d'environnement pour les tests Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium).
+ **Pour les utilisateurs d'Appium Java**, le nouvel hôte de test ne contient aucun fichier JAR préinstallé dans son chemin de classe, alors que l'hôte précédent en contenait un pour le framework TestNG (via une variable d'environnement). `$DEVICEFARM_TESTNG_JAR` Nous recommandons aux clients d'intégrer les fichiers JAR nécessaires à leurs frameworks de test dans leur package de test et de supprimer les instances de la `$DEVICEFARM_TESTNG_JAR` variable de leurs fichiers de spécifications de test.
Nous vous recommandons de contacter l'équipe de service par le biais d'un dossier d'assistance si vous avez des commentaires ou des questions sur les différences entre les hôtes de test du point de vue logiciel.
# Accédez aux ressources AWS à l'aide d'un rôle d'exécution IAM
Device Farm permet de spécifier un rôle IAM qui sera assumé par l'environnement d'exécution de test personnalisé lors de l'exécution du test. Cette fonctionnalité permet à vos tests d'accéder en toute sécurité aux ressources AWS de votre compte, telles que les compartiments Amazon S3, les tables DynamoDB ou d'autres services AWS dont dépend votre application.
**Topics**
+ [Aperçu](#iam-execution-role-overview)
+ [Exigences relatives au rôle IAM](#iam-role-requirements)
+ [Configuration d'un rôle d'exécution IAM](#configuring-iam-execution-role)
+ [Bonnes pratiques](#iam-role-best-practices)
+ [Résolution des problèmes](#troubleshooting-iam-roles)
## Aperçu
Lorsque vous spécifiez un rôle d'exécution IAM, Device Farm assume ce rôle lors de l'exécution des tests, ce qui permet à vos tests d'interagir avec les services AWS en utilisant les autorisations définies dans le rôle.
Les cas d'utilisation courants des rôles d'exécution IAM incluent :
+ Accès aux données de test stockées dans des compartiments Amazon S3
+ Transférer des artefacts de test vers des compartiments Amazon S3
+ Récupération de la configuration d'une application depuis AWS AppConfig
+ Rédaction de journaux de test et de statistiques pour Amazon CloudWatch
+ Envoi de résultats de test ou de messages d'état aux files d'attente Amazon SQS
+ Appel de fonctions AWS Lambda dans le cadre de flux de travail de test
## Exigences relatives au rôle IAM
Pour utiliser un rôle d'exécution IAM avec Device Farm, votre rôle doit répondre aux exigences suivantes :
+ **Relation de confiance** : le responsable du service Device Farm doit être digne de confiance pour assumer ce rôle. La politique de confiance doit inclure `devicefarm.amazonaws.com` le fait d'être une entité de confiance.
+ **Autorisations** : le rôle doit disposer des autorisations nécessaires pour accéder aux ressources AWS dont vos tests ont besoin.
+ **Durée de session** : la durée maximale de session du rôle doit être au moins aussi longue que le délai d'expiration des tâches défini dans votre projet Device Farm. Par défaut, les projets Device Farm ont un délai d'expiration de 150 minutes. Votre rôle doit donc prendre en charge une durée de session d'au moins 150 minutes.
+ **Même exigence de compte** : le rôle IAM doit figurer sur le même compte AWS que celui utilisé pour appeler Device Farm. L'hypothèse de rôles entre comptes n'est pas prise en charge.
+ **PassRole autorisation** : l'appelant doit être autorisé à transmettre le rôle IAM par une politique autorisant l'`iam:PassRole`action sur le rôle d'exécution spécifié.
### Exemple de politique d’approbation
L'exemple suivant montre une politique de confiance qui permet à Device Farm d'assumer votre rôle d'exécution. Cette politique de confiance ne doit être attachée qu'au rôle IAM spécifique que vous avez l'intention d'utiliser avec Device Farm, et non aux autres rôles de votre compte :
**Example**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "devicefarm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
### Exemple de politique d’autorisations
L'exemple suivant montre une politique d'autorisation qui accorde l'accès aux services AWS courants utilisés lors des tests :
**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-*"
}
]
}
```
## Configuration d'un rôle d'exécution IAM
Vous pouvez spécifier un rôle d'exécution IAM au niveau du projet ou pour des tests individuels. Lorsqu'elles sont configurées au niveau du projet, toutes les exécutions au sein de ce projet hériteront du rôle d'exécution. Un rôle d'exécution configuré lors d'une exécution remplacera tout rôle configuré sur son projet parent.
Pour obtenir des instructions détaillées sur la configuration des rôles d'exécution, voir :
+ [Création d'un projet dans AWS Device Farm](how-to-create-project.md)- pour configurer les rôles d'exécution au niveau du projet
+ [Création d'un test dans Device Farm](how-to-create-test-run.md)- pour configurer les rôles d'exécution pour des exécutions individuelles
Vous pouvez également configurer les rôles d'exécution à l'aide de l'API Device Farm. Pour plus d'informations, consultez le [Device Farm API Reference](https://docs.aws.amazon.com/devicefarm/latest/APIReference/).
## Bonnes pratiques
Suivez ces bonnes pratiques lors de la configuration des rôles d'exécution IAM pour vos tests Device Farm :
+ **Principe du moindre privilège** : accordez uniquement les autorisations minimales nécessaires au bon fonctionnement de vos tests. Évitez d'utiliser des autorisations trop larges, telles que `*` des actions ou des ressources.
+ **Utiliser des autorisations spécifiques aux ressources** : dans la mesure du possible, limitez les autorisations à des ressources spécifiques (par exemple, des compartiments S3 ou des tables DynamoDB spécifiques) plutôt qu'à toutes les ressources d'un type.
+ **Ressources de test et de production distinctes** : utilisez des ressources et des rôles de test dédiés pour éviter d'affecter accidentellement les systèmes de production pendant les tests.
+ **Révision régulière des rôles** : passez régulièrement en revue et mettez à jour vos rôles d'exécution pour vous assurer qu'ils répondent toujours à vos besoins de test et respectent les meilleures pratiques en matière de sécurité.
+ **Utiliser des clés de condition** : pensez à utiliser des clés de condition IAM pour limiter davantage le moment et la manière dont le rôle peut être utilisé.
## Résolution des problèmes
Si vous rencontrez des problèmes avec les rôles d'exécution IAM, vérifiez les points suivants :
+ **Relation de confiance** : vérifiez que la politique de confiance du `devicefarm.amazonaws.com` rôle inclut un service de confiance.
+ **Autorisations** : vérifiez que le rôle dispose des autorisations nécessaires pour les services AWS auxquels vos tests tentent d'accéder.
+ **Journaux de test** : consultez les journaux d'exécution des tests pour détecter les messages d'erreur spécifiques liés aux appels d'API AWS ou aux refus d'autorisation.
# Variables d'environnement pour les environnements de test personnalisés
Device Farm configure dynamiquement plusieurs variables d'environnement à utiliser dans le cadre de l'exécution de votre environnement de test personnalisé.
**Topics**
+ [Variables d'environnement personnalisées](#custom-test-environment-variables-custom)
+ [Variables d'environnement communes](#custom-test-environment-variables-common)
+ [Variables d'environnement pour les tests Appium](#custom-test-environment-variables-appium)
+ [Variables d'environnement pour les XCUITest tests](#custom-test-environment-variables-xcuitest)
## Variables d'environnement personnalisées
Device Farm prend en charge la configuration de paires clé-valeur appliquées en tant que variables d'environnement sur l'hôte de test. Elles peuvent être configurées sur un projet Device Farm ou lors de la création d'une exécution ; toutes les variables configurées lors d'une exécution remplaceront celles qui peuvent être configurées sur son projet parent. Les restrictions suivantes s’appliquent :
+ Les variables d'environnement personnalisées ne sont pas prises en charge sur les anciens hôtes de test iOS. Pour de plus amples informations, veuillez consulter [Ancien hôte de test iOS](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ Les noms de variables commençant par `$DEVICEFARM_` sont réservés à un usage interne du service.
+ Les variables d'environnement personnalisées ne peuvent pas être utilisées pour configurer la sélection de calcul de l'hôte de test dans votre spécification de test.
## Variables d'environnement communes
Cette section décrit les variables d'environnement communes à tous les tests de Device Farm.
** `$DEVICEFARM_DEVICE_NAME` **
L'appareil sur lequel vos tests sont exécutés. Il représente l'identifiant unique de l'appareil (UDID).
** `$DEVICEFARM_DEVICE_UDID` **
Identifiant unique de l'appareil.
** `$DEVICEFARM_DEVICE_PLATFORM_NAME` **
Le nom de la plateforme de l'appareil. C'est l'un `Android` ou l'autre`iOS`.
** `$DEVICEFARM_DEVICE_OS_VERSION` **
Version du système d'exploitation de l'appareil.
** `$DEVICEFARM_APP_PATH` **
*(tests d'applications mobiles)*
Chemin de l'application mobile sur la machine hôte où les tests sont en cours d'exécution. Cette variable n'est pas disponible lors des tests Web.
** `$DEVICEFARM_LOG_DIR` **
Le chemin d'accès au répertoire par défaut dans lequel les journaux des clients, les artefacts et les autres fichiers souhaités seront stockés pour être récupérés ultérieurement. À l'aide d'un [exemple de spécification de test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example), les fichiers de ce répertoire sont archivés dans un fichier ZIP et mis à disposition sous forme d'artefact après votre test.
** `$DEVICEFARM_SCREENSHOT_PATH` **
Chemin des captures d'écran, le cas échéant, capturées au cours du test.
** `$DEVICEFARM_PROJECT_ARN` **
L'ARN du projet parent de la tâche.
** `$DEVICEFARM_RUN_ARN` **
L'ARN de l'exécution parent de la tâche.
** `$DEVICEFARM_DEVICE_ARN` **
L'ARN de l'appareil testé.
** `$DEVICEFARM_TOTAL_JOBS` **
Le nombre total de tâches associées à l'exécution de son Device Farm parent.
** `$DEVICEFARM_JOB_NUMBER` **
Le numéro de ce job se trouve à l'intérieur`$DEVICEFARM_TOTAL_JOBS`. Par exemple, une exécution peut contenir 5 tâches, chacune ayant un caractère unique `$DEVICEFARM_JOB_NUMBER` compris entre 0 et 4.
** `$AWS_REGION` **
Région AWS Le service le configurera pour qu'il corresponde à la région dans laquelle se trouve l'appareil testé. Elle peut être remplacée par une variable d'environnement personnalisée si nécessaire.
** `$ANDROID_HOME` **
*(Android uniquement)*
Le chemin d'accès au répertoire d'installation du SDK Android.
## Variables d'environnement pour les tests Appium
Cette section décrit les variables d'environnement utilisées par n'importe quel test Appium dans un environnement de test personnalisé dans Device Farm.
** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` **
*(Android uniquement)*
L'emplacement d'un répertoire contenant les ChromeDriver exécutables nécessaires à une utilisation dans les tests Web et hybrides d'Appium.
** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` **
*(iOS uniquement)*
Le chemin de données dérivé d'une version de Device Farm WebDriverAgent conçue pour fonctionner sur Device Farm. La numérotation de la variable correspondra à la version principale du WebDriverAgent. À titre d'exemple, `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` indiquera la WebDriverAgent version a de 9.x. Pour de plus amples informations, veuillez consulter [Sélection d'une WebDriverAgent version pour les tests iOS](test-types-appium.md#test-types-appium-select-wda).
Les variables d'`$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V`environnement ne sont présentes que sur les hôtes iOS non existants. Pour de plus amples informations, veuillez consulter [Ancien hôte de test iOS](custom-test-environments-hosts-ios.md#legacy-ios-host).
** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` **
*(iOS uniquement, obsolète)*
Le chemin de données dérivé d'une version de Device Farm WebDriverAgent conçue pour fonctionner sur Device Farm. Reportez-vous `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` au schéma de dénomination de remplacement.
## Variables d'environnement pour les XCUITest tests
Cette section décrit les variables d'environnement utilisées par le XCUITest test dans un environnement de test personnalisé dans Device Farm.
** `$DEVICEFARM_XCUITESTRUN_FILE` **
Le chemin d'accès au `.xctestun` fichier Device Farm. Il est généré à partir de vos packages d'application et de test.
** `$DEVICEFARM_DERIVED_DATA_PATH` **
Chemin attendu de la sortie xcodebuild de Device Farm.
** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` **
Chemin du contenu décompressé du fichier du package de test.
# Bonnes pratiques pour l'exécution d'un environnement de test personnalisé
Les rubriques suivantes présentent les meilleures pratiques recommandées pour l'utilisation de l'exécution de tests personnalisés avec Device Farm.
**Configuration d’exécution**
+ **Utilisez le logiciel géré par Device Farm et les fonctionnalités de l'API pour exécuter la configuration** dans la mesure du possible, au lieu d'appliquer des configurations similaires via des commandes shell dans le fichier de spécifications de test. Cela inclut la configuration de l'hôte de test et du périphérique, car elle sera plus durable et cohérente entre les hôtes de test et les appareils.
Device Farm vous encourage à personnaliser votre fichier de spécifications de test autant que nécessaire pour exécuter vos tests, mais le fichier de spécifications de test peut devenir difficile à gérer au fil du temps à mesure que des commandes plus personnalisées y sont ajoutées. Utilisation du logiciel géré par Device Farm (via des outils tels que ` devicefarm-cli` les outils disponibles par défaut dans le`$PATH`) et utilisation de fonctionnalités gérées (telles que le paramètre de [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)demande) pour simplifier le fichier de spécifications de test en transférant la responsabilité de la maintenance à Device Farm elle-même.
**Spécifications de test et code du package de test**
+ **N'utilisez pas de chemins absolus et ne vous fiez pas à des versions mineures spécifiques** dans votre fichier de spécifications de test ou le code de votre package de test. Device Farm applique des mises à jour de routine à l'hôte de test sélectionné et aux versions logicielles incluses. L'utilisation de chemins spécifiques ou absolus (par exemple ` /usr/local/bin/python` au lieu de`python`) ou l'exigence de versions mineures spécifiques (par exemple Node.js `20.3.1` au lieu de simplement` 20`) peuvent empêcher vos tests de localiser le fichier exécutable/requis.
Dans le cadre de l'exécution des tests personnalisés, Device Farm définit diverses variables d'environnement ainsi que la `$PATH` variable afin de garantir une expérience cohérente dans nos environnements dynamiques. Pour plus d’informations, consultez [Variables d'environnement pour les environnements de test personnalisés](custom-test-environment-variables.md) et [Logiciels pris en charge dans des environnements de test personnalisés](custom-test-environments-hosts-software.md).
+ **Enregistrez les fichiers générés ou copiés dans le répertoire temporaire pendant le test.** Aujourd'hui, nous nous assurons que le répertoire temporaire (`/tmp`) sera accessible à l'utilisateur pendant l'exécution du test (en plus des répertoires gérés, tels que le`$DEVICEFARM_LOG_DIR`). Les autres répertoires auxquels l'utilisateur a accès peuvent changer au fil du temps en fonction des besoins du service ou du système d'exploitation utilisé.
+ **Enregistrez vos journaux d'exécution des tests dans `$DEVICEFARM_LOG_DIR`**. Il s'agit du répertoire d'artefacts par défaut fourni à votre exécution pour y ajouter des journaux d'exécution ou des artefacts. Les [exemples de spécifications de test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) que nous fournissons utilisent chacun ce répertoire pour les artefacts par défaut.
+ **Assurez-vous que vos commandes renvoient un code différent de zéro en cas d'échec** pendant la `test` phase de votre spécification de test. Nous déterminons si votre exécution a échoué en vérifiant la présence d'un code de sortie différent de zéro pour chaque commande shell invoquée pendant la `test` phase. Vous devez vous assurer que votre logique ou votre infrastructure de test renverra un code de sortie différent de zéro pour tous les scénarios souhaités, qui peuvent nécessiter une configuration supplémentaire.
Par exemple, certains frameworks de test (tels que JUnit5) ne considèrent pas l'exécution d'un test comme un échec, ce qui entraînera la détection d'une exécution réussie de vos tests même si rien n'a été exécuté. À JUnit5 titre d'exemple, vous devez spécifier l'option de ligne de commande pour vous `--fail-if-no-tests` assurer que ce scénario se termine avec un code de sortie différent de zéro.
+ **Vérifiez la compatibilité du logiciel** avec la version du système d'exploitation de l'appareil et la version de l'hôte de test que vous utiliserez pour le test. Par exemple, certaines fonctionnalités des frameworks logiciels de test (par exemple : Appium) peuvent ne pas fonctionner comme prévu sur toutes les versions du système d'exploitation de l'appareil testé.
**Sécurité**
+ **Évitez de stocker ou de consigner des variables sensibles (comme les clés AWS) dans votre fichier de spécifications de test.** Les fichiers de spécifications de test, les scripts générés par les spécifications de test et les journaux des scripts de spécifications de test sont tous fournis sous forme d'artefacts téléchargeables à la fin de l'exécution du test. Cela peut entraîner la divulgation involontaire de secrets à d'autres utilisateurs de votre compte ayant un accès en lecture à votre test.
# Migration des tests d'un environnement de test standard vers un environnement de test personnalisé
Vous pouvez passer d'un mode d'exécution de test standard à un mode d'exécution personnalisé dans AWS Device Farm. La migration implique principalement deux formes d'exécution différentes :
1. **Mode standard** : ce mode d'exécution des tests est principalement conçu pour fournir aux clients des rapports granulaires et un environnement entièrement géré.
1. **Mode personnalisé** : ce mode d'exécution des tests est conçu pour différents cas d'utilisation nécessitant des tests plus rapides, la capacité de levage et de décalage pour atteindre la parité avec leur environnement local, ainsi que la diffusion vidéo en direct.
Pour plus d'informations sur les modes standard et personnalisé de Device Farm, reportez-vous [Environnements de test dans AWS Device Farm](test-environments.md) aux sections et[Environnements de test personnalisés dans AWS Device Farm](custom-test-environments.md).
## Considérations relatives à la migration
Cette section répertorie certains des principaux cas d'utilisation à prendre en compte lors de la migration vers le mode personnalisé :
1. **Rapidité** : dans le mode d'exécution standard, Device Farm analyse les métadonnées des tests que vous avez empaquetés et téléchargés à l'aide des instructions d'empaquetage correspondant à votre framework spécifique. L'analyse détecte le nombre de tests dans votre package. Device Farm exécute ensuite chaque test séparément et présente les journaux, les vidéos et les autres artefacts des résultats individuellement pour chaque test. Cependant, cela augmente régulièrement le temps total d'exécution des end-to-end tests, car il y a le pré-traitement et le post-traitement des tests et des artefacts de résultats du côté du service.
En revanche, le mode d'exécution personnalisé n'analyse pas votre package de test ; cela signifie qu'il n'y a aucun prétraitement et un post-traitement minimal pour les tests ou les artefacts de résultats. Cela se traduit par des temps end-to-end d'exécution totaux proches de ceux de votre configuration locale. Les tests sont exécutés dans le même format que s'ils étaient exécutés sur votre ou vos machines locales. Les résultats des tests sont identiques à ceux que vous obtenez localement et peuvent être téléchargés à la fin de l'exécution de la tâche.
1. **Personnalisation ou flexibilité** : le mode d'exécution standard analyse votre package de test pour détecter le nombre de tests, puis exécute chaque test séparément. Notez qu'il n'y a aucune garantie que les tests s'exécuteront dans l'ordre que vous avez spécifié. Par conséquent, les tests nécessitant une séquence d'exécution particulière peuvent ne pas fonctionner comme prévu. En outre, il n'existe aucun moyen de personnaliser l'environnement de la machine hôte ou de transmettre les fichiers de configuration qui peuvent être nécessaires pour exécuter vos tests d'une certaine manière.
En revanche, le mode personnalisé vous permet de configurer l'environnement de la machine hôte, notamment d'installer des logiciels supplémentaires, de transmettre des filtres à vos tests, de transmettre des fichiers de configuration et de contrôler la configuration d'exécution des tests. Pour ce faire, il utilise un fichier yaml (également appelé fichier testspec) que vous pouvez modifier en y ajoutant des commandes shell. Ce fichier yaml est converti en un script shell qui est exécuté sur la machine hôte de test. Vous pouvez enregistrer plusieurs fichiers yaml et en choisir un dynamiquement selon vos besoins lorsque vous planifiez une exécution.
1. **Vidéo en direct et journalisation** : les modes d'exécution standard et personnalisé vous fournissent des vidéos et des journaux pour vos tests. Cependant, en mode standard, vous n'obtenez la vidéo et les journaux prédéfinis de vos tests qu'une fois ceux-ci terminés.
En revanche, le mode personnalisé vous permet de diffuser en direct la vidéo et les journaux de vos tests côté client. De plus, vous pouvez télécharger la vidéo et d'autres artefacts à la fin du ou des tests.
**Astuce**
Si votre cas d'utilisation implique au moins l'un des facteurs ci-dessus, nous vous recommandons vivement de passer au mode d'exécution personnalisé.
## Étapes de la migration
Pour passer du mode standard au mode personnalisé, procédez comme suit :
1. Connectez-vous à la console Device Farm AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. Choisissez votre projet, puis lancez une nouvelle opération d'automatisation.
1. Téléchargez votre application (ou sélectionnez`web app`), choisissez votre type de framework de test, téléchargez votre package de test, puis sous le `Choose your execution environment` paramètre, choisissez l'option pour`Run your test in a custom environment`.
1. Par défaut, l'exemple de fichier de spécifications de test de Device Farm s'affiche pour que vous puissiez le consulter et le modifier. Ce fichier d'exemple peut être utilisé comme point de départ pour essayer vos tests en [mode environnement personnalisé](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html). Ensuite, une fois que vous avez vérifié que vos tests fonctionnent correctement depuis la console, vous pouvez modifier n'importe laquelle de vos intégrations d'API, de CLI ou de pipeline avec Device Farm pour utiliser ce fichier de spécifications de test en tant que paramètre lors de la planification des tests. Pour plus d'informations sur la façon d'ajouter un fichier de spécifications de test en tant que paramètre pour vos exécutions, consultez la section sur les `testSpecArn` paramètres de l'`ScheduleRun`API dans notre [guide des API](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html).
## Cadre Appium
Dans un environnement de test personnalisé, Device Farm n'insère ni ne remplace aucune fonctionnalité d'Appium dans vos tests de framework Appium. Vous devez spécifier les fonctionnalités Appium de votre test dans le fichier YAML de spécification de test ou dans votre code de test.
## Instrumentation Android
Vous n'avez pas besoin d'effectuer de modifications pour déplacer vos tests d'instrumentation Android vers un environnement de test personnalisé.
## iOS XCUITest
Il n'est pas nécessaire d'apporter des modifications pour déplacer vos XCUITest tests iOS vers un environnement de test personnalisé.
# Extension des environnements de test personnalisés dans Device Farm
AWS Device Farm permet de configurer un environnement personnalisé pour les tests automatisés (mode personnalisé), ce qui est l'approche recommandée pour tous les utilisateurs de Device Farm. Le mode personnalisé Device Farm vous permet d'exécuter bien plus que votre suite de tests. Dans cette section, vous découvrirez comment étendre votre suite de tests et optimiser vos tests.
Pour plus d'informations sur les environnements de test personnalisés dans Device Farm, consultez[Environnements de test personnalisés dans AWS Device Farm](custom-test-environments.md).
**Topics**
+ [Définition du code PIN d'un appareil lors de l'exécution de tests dans Device Farm](custom-test-environments-extending-set-pin.md)
+ [Accélérer les tests basés sur Appium dans Device Farm grâce aux fonctionnalités souhaitées](custom-test-environments-extending-speed.md)
+ [Utilisation de webhooks et autres APIs après l'exécution de vos tests dans Device Farm](custom-test-environments-extending-webhooks.md)
+ [Ajouter des fichiers supplémentaires à votre package de test dans Device Farm](custom-test-environments-extending-files.md)
# Définition du code PIN d'un appareil lors de l'exécution de tests dans Device Farm
Certaines applications nécessitent que vous définissiez un code PIN sur l'appareil. Device Farm ne prend pas en charge la définition native d'un code PIN sur les appareils. Cela est toutefois possible avec les mises en garde suivantes :
+ L'appareil doit fonctionner sous Android 8 ou une version ultérieure.
+ Le code PIN doit être retiré une fois le test terminé.
Pour définir le code PIN lors de vos tests, utilisez les `post_test` phases `pre_test` et pour définir et supprimer le code PIN, comme indiqué ci-dessous :
```
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"
```
Lorsque votre suite de tests démarre, le code PIN 1234 est défini. Une fois votre suite de tests terminée, le code PIN est supprimé.
**Avertissement**
Si vous ne supprimez pas le code PIN de l'appareil une fois le test terminé, l'appareil et votre compte seront mis en quarantaine.
Pour découvrir d'autres moyens d'étendre votre suite de tests et d'optimiser vos tests, consultez[Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md).
# Accélérer les tests basés sur Appium dans Device Farm grâce aux fonctionnalités souhaitées
Lorsque vous utilisez Appium, vous constaterez peut-être que la suite de tests en mode standard est très lente. Cela est dû au fait que Device Farm applique les paramètres par défaut et ne fait aucune hypothèse quant à la manière dont vous souhaitez utiliser l'environnement Appium. Bien que ces valeurs par défaut soient basées sur les meilleures pratiques du secteur, elles peuvent ne pas s'appliquer à votre situation. Pour affiner les paramètres du serveur Appium, vous pouvez ajuster les fonctionnalités Appium par défaut dans vos spécifications de test. Par exemple, ce qui suit définit la `usePrebuildWDA` fonctionnalité d'`true`une suite de tests iOS pour accélérer l'heure de démarrage initiale :
```
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 &
```
Les fonctionnalités d'Appium doivent être une structure JSON échappée au shell et entre guillemets.
Les fonctionnalités Appium suivantes sont des sources courantes d'amélioration des performances :
`noReset` et `fullReset`
Ces deux fonctionnalités, qui s'excluent mutuellement, décrivent le comportement d'Appium une fois chaque session terminée. Lorsqu'il `noReset` est défini sur`true`, le serveur Appium ne supprime pas les données de votre application lorsqu'une session Appium se termine, n'effectuant en fait aucun nettoyage. `fullReset`désinstalle et efface toutes les données d'application de l'appareil après la fermeture de la session. Pour plus d'informations, consultez [Reset Strategies](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/) dans la documentation d'Appium.
`ignoreUnimportantViews`(Android uniquement)
Demande à Appium de compresser la hiérarchie de l'interface utilisateur Android uniquement pour *les vues pertinentes* pour le test, ce qui accélère la recherche de certains éléments. Cependant, cela peut perturber certaines suites de tests XPath basées sur des données car la hiérarchie de la disposition de l'interface utilisateur a été modifiée.
`skipUnlock`(Android uniquement)
Informe Appium qu'aucun code PIN n'est actuellement défini, ce qui accélère les tests après un événement de fermeture d'écran ou un autre événement de verrouillage.
`webDriverAgentUrl`(iOS uniquement)
Demande à Appium de supposer qu'une dépendance iOS essentielle est déjà en cours d'exécution et disponible pour accepter les requêtes HTTP à l'URL spécifiée. `webDriverAgent` S'il `webDriverAgent` n'est pas déjà opérationnel, Appium peut mettre un certain temps au début d'une suite de tests pour démarrer le. `webDriverAgent` Si vous démarrez `webDriverAgent` vous-même et que vous le configurez `webDriverAgentUrl` au `http://localhost:8100` démarrage d'Appium, vous pouvez démarrer votre suite de tests plus rapidement. Notez que cette fonctionnalité ne doit jamais être utilisée en même temps que la `useNewWDA` fonctionnalité.
Vous pouvez utiliser le code suivant pour commencer à `webDriverAgent` partir de votre fichier de spécifications de test sur le port local de l'appareil`8100`, puis le transférer vers le port local de l'hôte de test `8100` (cela vous permet `webDriverAgentUrl` de définir la valeur sur`http://localhost:8100`). Ce code doit être exécuté pendant la phase d'installation une fois que tout code de configuration d'Appium et des variables d'`webDriverAgent`environnement a été défini :
```
# 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 &
```
Vous pouvez ensuite ajouter le code suivant à votre fichier de spécifications de test pour vous assurer que le `webDriverAgent` démarrage est réussi. Ce code doit être exécuté à la fin de la phase de pré-test après avoir vérifié le bon démarrage d'Appium :
```
# Wait for WebDriverAgent to start
- >-
start_wda_timeout=0;
while [ true ];
do
if [ $start_wda_timeout -gt 60 ];
then
echo "WebDriverAgent server never started in 60 seconds.";
exit 1;
fi;
grep -i "ServerURLHere" $DEVICEFARM_LOG_DIR/webdriveragent_log.txt >> /dev/null 2>&1;
if [ $? -eq 0 ];
then
echo "WebDriverAgent REST http interface listener started";
break;
else
echo "Waiting for WebDriverAgent server to start. Sleeping for 1 seconds";
sleep 1;
start_wda_timeout=$((start_wda_timeout+1));
fi;
done;
```
Pour plus d'informations sur les fonctionnalités prises en charge par Appium, consultez la section [Capacités souhaitées d'Appium](http://appium.io/docs/en/writing-running-appium/caps/) dans la documentation d'Appium.
Pour découvrir d'autres moyens d'étendre votre suite de tests et d'optimiser vos tests, consultez[Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md).
# Utilisation de webhooks et autres APIs après l'exécution de vos tests dans Device Farm
Device Farm peut appeler un webhook une fois que chaque suite de tests a fini d'être utilisée. **curl** La procédure à suivre varie en fonction de la destination et du formatage. Pour votre webhook spécifique, consultez la documentation de ce webhook. L'exemple suivant publie un message chaque fois qu'une suite de tests est terminée sur un webhook Slack :
```
phases:
post_test:
- curl -X POST -H 'Content-type: application/json' --data '{"text":"Tests on '$DEVICEFARM_DEVICE_NAME' have finished!"}' https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
```
Pour plus d'informations sur l'utilisation des webhooks avec Slack, consultez la section [Envoyer votre premier message Slack à l'aide de Webhook dans le guide de référence de l'API Slack](https://api.slack.com/tutorials/slack-apps-hello-world).
Pour découvrir d'autres moyens d'étendre votre suite de tests et d'optimiser vos tests, consultez[Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md).
Vous n'êtes pas limité à l'utilisation **curl** pour appeler des webhooks. Les packages de test peuvent inclure des scripts et des outils supplémentaires, à condition qu'ils soient compatibles avec l'environnement d'exécution de Device Farm. Par exemple, votre package de test peut inclure des scripts auxiliaires qui envoient des requêtes à d'autres APIs. Assurez-vous que tous les packages requis sont installés conformément aux exigences de votre suite de tests. Pour ajouter un script qui s'exécute une fois votre suite de tests terminée, incluez-le dans votre package de test et ajoutez ce qui suit à votre spécification de test :
```
phases:
post_test:
- python post_test.py
```
**Note**
La maintenance des clés d'API ou des autres jetons d'authentification utilisés dans votre package de test est de votre responsabilité. Nous vous recommandons de garder toute forme d'identification de sécurité hors du contrôle de la source, d'utiliser des informations d'identification avec le moins de privilèges possibles et d'utiliser des jetons révocables de courte durée dans la mesure du possible. Pour vérifier les exigences de sécurité, consultez la documentation du tiers APIs que vous utilisez.
Si vous prévoyez d'utiliser AWS des services dans le cadre de votre suite d'exécution de tests, vous devez utiliser des informations d'identification temporaires IAM, générées en dehors de votre suite de tests et incluses dans votre package de test. Ces informations d'identification doivent avoir le moins d'autorisations accordées et avoir une durée de vie la plus courte possible. Pour plus d'informations sur la création d'informations d'identification temporaires, consultez la section [Demande d'informations d'identification de sécurité temporaires](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html) dans le *guide de l'utilisateur IAM*.
Pour découvrir d'autres moyens d'étendre votre suite de tests et d'optimiser vos tests, consultez[Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md).
# Ajouter des fichiers supplémentaires à votre package de test dans Device Farm
Vous souhaiterez peut-être utiliser des fichiers supplémentaires dans le cadre de vos tests, soit en tant que fichiers de configuration supplémentaires, soit en tant que données de test supplémentaires. Vous pouvez ajouter ces fichiers supplémentaires à votre package de test avant de le télécharger AWS Device Farm, puis y accéder depuis le mode environnement personnalisé. Fondamentalement, tous les formats de téléchargement de packages de test (ZIP, IPA, APK, JAR, etc.) sont des formats d'archive de packages qui prennent en charge les opérations ZIP standard.
Vous pouvez ajouter des fichiers à votre archive de test avant de la télécharger à l'aide AWS Device Farm de la commande suivante :
```
$ zip zip-with-dependencies.zip extra_file
```
Pour un répertoire de fichiers supplémentaires :
```
$ zip -r zip-with-dependencies.zip extra_files/
```
Ces commandes fonctionnent comme prévu pour tous les formats de téléchargement de packages de test, à l'exception des fichiers IPA. Pour les fichiers IPA, en particulier lorsqu'ils sont utilisés avec XCUITests, nous vous recommandons de placer les fichiers supplémentaires dans un emplacement légèrement différent en raison de la manière dont les packages de test AWS Device Farm iOS sont résignés. Lors de la création de votre test iOS, le répertoire de l'application de test sera situé dans un autre répertoire nommé*Payload*.
Par exemple, voici à quoi peut ressembler un tel répertoire de test iOS :
```
$ tree
.
└── Payload
└── ADFiOSReferenceAppUITests-Runner.app
├── ADFiOSReferenceAppUITests-Runner
├── Frameworks
│ ├── XCTAutomationSupport.framework
│ │ ├── Info.plist
│ │ ├── XCTAutomationSupport
│ │ ├── _CodeSignature
│ │ │ └── CodeResources
│ │ └── version.plist
│ └── XCTest.framework
│ ├── Info.plist
│ ├── XCTest
│ ├── _CodeSignature
│ │ └── CodeResources
│ ├── en.lproj
│ │ └── InfoPlist.strings
│ └── version.plist
├── Info.plist
├── PkgInfo
├── PlugIns
│ ├── ADFiOSReferenceAppUITests.xctest
│ │ ├── ADFiOSReferenceAppUITests
│ │ ├── Info.plist
│ │ └── _CodeSignature
│ │ └── CodeResources
│ └── ADFiOSReferenceAppUITests.xctest.dSYM
│ └── Contents
│ ├── Info.plist
│ └── Resources
│ └── DWARF
│ └── ADFiOSReferenceAppUITests
├── _CodeSignature
│ └── CodeResources
└── embedded.mobileprovision
```
Pour ces XCUITest packages, ajoutez des fichiers supplémentaires dans le répertoire se terminant par « *.app* inside » du *Payload* répertoire. Par exemple, les commandes suivantes indiquent comment ajouter un fichier à ce package de test :
```
$ mv extra_file Payload/*.app/
$ zip -r my_xcui_tests.ipa Payload/
```
Lorsque vous ajoutez un fichier à votre package de test, vous pouvez vous attendre à un comportement d'interaction légèrement différent en AWS Device Farm fonction de son format de téléchargement. Si le téléchargement a utilisé l'extension de fichier ZIP, le téléchargement AWS Device Farm sera automatiquement décompressé avant le test et les fichiers décompressés resteront à l'emplacement où se trouve la variable d'environnement. *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* (Cela signifie que si vous ajoutiez un fichier appelé *extra\$1file* à la racine de l'archive comme dans le premier exemple, il sera localisé *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file* pendant le test).
Pour utiliser un exemple plus pratique, si vous êtes un utilisateur d'Appium TestNG qui souhaite inclure un *testng.xml* fichier dans votre test, vous pouvez l'inclure dans votre archive à l'aide de la commande suivante :
```
$ zip zip-with-dependencies.zip testng.xml
```
Vous pouvez ensuite modifier votre commande de test dans le mode d'environnement personnalisé comme suit :
```
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
```
Si l'extension de téléchargement de votre package de test n'est pas ZIP (par exemple, un fichier APK, IPA ou JAR), le fichier de package téléchargé se trouve à l'*\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH*adresse. Comme il s'agit toujours de fichiers au format archive, vous pouvez décompresser le fichier afin d'accéder aux fichiers supplémentaires de l'intérieur. Par exemple, la commande suivante décompressera le contenu du package de test (pour les fichiers APK, IPA ou JAR) dans le */tmp* répertoire :
```
unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp
```
Dans le cas d'un fichier APK ou JAR, vous trouverez vos fichiers supplémentaires décompressés */tmp* dans le répertoire (par exemple,*/tmp/extra\$1file*). Dans le cas d'un fichier IPA, comme expliqué précédemment, les fichiers supplémentaires se trouveraient à un emplacement légèrement différent dans le dossier se terminant par*.app*, qui se trouve à l'intérieur du *Payload* répertoire. Par exemple, sur la base de l'exemple IPA ci-dessus, le fichier se trouverait à l'emplacement */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file* (référençable en tant que). */tmp/Payload/\$1.app/extra\$1file*
Pour découvrir d'autres moyens d'étendre votre suite de tests et d'optimiser vos tests, consultez[Extension des environnements de test personnalisés dans Device Farm](custom-test-environments-extending.md).