Utilisation d'environnements de test personnalisés dans AWS Device Farm - AWS Device Farm

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.

Utilisation d'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.

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 évite les frais de prétraitement/post-traitement.

  • 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 et. Création d'un test dans Device Farm

Syntaxe des spécifications de test

Voici la structure du fichier de spécification de test YAML :

version: 0.1 phases: install: commands: - command - command pre_test: commands: - command - command test: commands: - command - command post_test: commands: - command - command artifacts: - location - location

La spécification de test contient les éléments suivants :

version

Reflète la version des spécifications de test prise en charge par Device Farm. Le numéro de version actuel est 0.1.

phases

Cette section contient les groupes de commandes exécutés au cours d'un test.

Les noms de phase de test autorisés sont :

install

Facultatif.

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

Facultatif.

Éventuelles commandes qui sont exécutées avant votre test automatisé.

test

Facultatif.

Commandes qui sont exécutées pendant votre test automatisé. Si une commande de la phase de test échoue, le test est marqué comme ayant échoué.

post_test

Facultatif.

Éventuelles commandes qui sont exécutées après votre test automatisé.

artifacts

Facultatif.

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 Utilisation d'artefacts dans un environnement de test personnalisé.

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.

Exemple de spécification de test

Voici un exemple de spécification de test YAML de Device Farm qui configure un test Appium Java TestNG :

version: 0.1 # This flag enables your test to run using Device Farm's Amazon Linux 2 test host when scheduled on # Android devices. By default, iOS device tests will always run on Device Farm's macOS test hosts. # For Android, you can explicitly select your test host to use our Amazon Linux 2 infrastructure. # For more information, please see: # https://docs.aws.amazon.com/devicefarm/latest/developerguide/amazon-linux-2.html android_test_host: amazon_linux_2 # Phases represent collections of commands that are executed during your test run on the test host. phases: # The install phase contains commands for installing dependencies to run your tests. # For your convenience, certain dependencies are preinstalled on the test host. # For Android tests running on the Amazon Linux 2 test host, many software libraries are available # from the test host using the devicefarm-cli tool. To learn more, please see: # https://docs.aws.amazon.com/devicefarm/latest/developerguide/amazon-linux-2-devicefarm-cli.html # For iOS tests, you can use the Node.JS tools nvm, npm, and avm to setup your environment. By # default, Node.js versions 16.20.2 and 14.19.3 are available on the test host. 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. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; then devicefarm-cli use node 16; else # For iOS, use "nvm use" to switch between the two preinstalled NodeJS versions 14 and 16, # and use "nvm install" to download a new version of your choice. nvm use 16; fi; - node --version # Use the devicefarm-cli to select a preinstalled major version of Appium on Android. # Use avm or npm to select Appium for iOS. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; then # For Android, the Device Farm service automatically 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 instead use NPM to install it: # npm install -g appium@2.1.3; devicefarm-cli use appium 2; else # For iOS, Appium versions 1.22.2 and 2.2.1 are preinstalled and selectable through avm. # For all other versions, please use npm to install them. For example: # npm install -g appium@2.1.3; # Note that, for iOS devices, Appium 2 is only supported on iOS version 14 and above using # NodeJS version 16 and above. avm 2.2.1; fi; - appium --version # For Appium version 2, for Android tests, Device Farm automatically updates the preinstalled # UIAutomator2 driver over time to incorporate the latest minor and patch versions for its major # version 2. If you want to install a specific 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; # For Appium version 2, for iOS tests, the XCUITest driver is preinstalled using version 5.7.0 # 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@5.8.1; # fi; # We recommend setting the Appium server's base path explicitly for accepting commands. - export APPIUM_BASE_PATH=/wd/hub # Install the NodeJS dependencies. - cd $DEVICEFARM_TEST_PACKAGE_PATH # First, install dependencies which were packaged with the test package using npm-bundle. - npm install *.tgz # Then, optionally, install any additional dependencies using npm install. # If you do run these commands, we strongly recommend that you include your package-lock.json # file with your test package so that the dependencies installed on Device Farm match # the dependencies you've installed locally. # - cd node_modules/* # - npm install # The pre-test phase contains commands for setting up your test environment. pre_test: commands: # Device farm provides different pre-built versions of WebDriverAgent, an essential Appium # dependency for iOS devices, and each version is suggested for different versions of Appium: # DEVICEFARM_WDA_DERIVED_DATA_PATH_V8: this version is suggested for Appium 2 # DEVICEFARM_WDA_DERIVED_DATA_PATH_V7: this version is suggested for Appium 1 # Additionally, for iOS versions 16 and below, the device unique identifier (UDID) needs # to be slightly modified for Appium tests. - |- if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then if [ $(appium --version | cut -d "." -f1) -ge 2 ]; then DEVICEFARM_WDA_DERIVED_DATA_PATH=$DEVICEFARM_WDA_DERIVED_DATA_PATH_V8; else DEVICEFARM_WDA_DERIVED_DATA_PATH=$DEVICEFARM_WDA_DERIVED_DATA_PATH_V7; fi; if [ $(echo $DEVICEFARM_DEVICE_OS_VERSION | cut -d "." -f 1) -le 16 ]; then DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$(echo $DEVICEFARM_DEVICE_UDID | tr -d "-"); else DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$DEVICEFARM_DEVICE_UDID; fi; fi; # Appium downloads Chromedriver using a feature that is considered insecure for multitenant # environments. This is not a problem for Device Farm because each test host is allocated # exclusively for one customer, then terminated entirely. For more information, please see # https://github.com/appium/appium/blob/master/packages/appium/docs/en/guides/security.md # 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:app\": \"$DEVICEFARM_APP_PATH\", \ \"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:app\": \"$DEVICEFARM_APP_PATH\", \ \"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 will 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. # When compiling with npm-bundle, the test folder can be found in the node_modules/*/ subdirectory. - cd $DEVICEFARM_TEST_PACKAGE_PATH/node_modules/* - echo "Starting the Appium NodeJS test" # Enter your command below to start the tests. The command should be the same command as the one # you use to run your tests locally from the command line. An example, "npm test", is given below: - npm test # 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. # 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