Trabajo con entornos de pruebas personalizados en AWS Device Farm - AWS Device Farm

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Trabajo con entornos de pruebas personalizados en AWS Device Farm

AWS Device Farm permite configurar un entorno personalizado para las pruebas automatizadas (modo personalizado), que es el enfoque recomendado para todos los usuarios de Device Farm. Para obtener más información sobre los entornos de Device Farm, consulte Test environments (Entornos de prueba).

Entre las ventajas del modo personalizado, en comparación con el modo estándar, se incluyen las siguientes:

  • Ejecución end-to-end de pruebas más rápida: el paquete de pruebas no se analiza para detectar todas las pruebas de la suite, lo que evita la sobrecarga de preprocesamiento o posprocesamiento.

  • Registro y transmisión de vídeo en directo: los registros de pruebas y el vídeo del lado del cliente se transmiten en directo cuando se utiliza el modo personalizado. Esta característica no está disponible en el modo estándar.

  • Captura todos los artefactos: en el host y el dispositivo, el modo personalizado le permite capturar todos los artefactos de prueba. Es posible que esto no sea posible en el modo estándar.

  • Entorno local más coherente y replicable: en el modo estándar, se proporcionarán artefactos para cada prueba individual por separado, lo que puede resultar beneficioso en determinadas circunstancias. Sin embargo, el entorno de pruebas local puede diferir de la configuración original, ya que Device Farm gestiona cada prueba ejecutada de forma diferente.

    Por el contrario, el modo personalizado le permite hacer que su entorno de ejecución de pruebas de Device Farm esté en línea de forma coherente con su entorno de pruebas local.

Los entornos personalizados se configuran mediante un archivo de especificaciones de prueba (especificaciones de prueba) con formato YAML. Device Farm proporciona un archivo de especificaciones de prueba predeterminado para cada tipo de prueba compatible que se puede usar tal cual o se puede personalizar; se pueden añadir personalizaciones como filtros de prueba o archivos de configuración a la especificación de prueba. Las especificaciones de prueba editadas se pueden guardar para futuras pruebas.

Para obtener más información, consulte Carga de una especificación de prueba personalizada conAWS CLI y Crear una ejecución de prueba en Device Farm.

Sintaxis de la especificación de prueba

La estructura del archivo YAML de especificación de prueba es la siguiente:

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 especificación de prueba contiene lo siguiente:

version

Refleja la versión de la especificación de prueba de Device Farm compatible. El número de versión actual es 0.1.

phases

Esta sección contiene grupos de comandos que se ejecutan durante una ejecución de prueba.

Los nombres de las fases de prueba permitidos son:

install

Opcional.

Las dependencias predeterminadas de los marcos de pruebas compatibles con Device Farm ya están instaladas. Esta fase contiene los comandos adicionales, si procede, que Device Farm ejecuta durante la instalación.

pre_test

Opcional.

Comandos, si procede, que se ejecutan antes de la ejecución de prueba automatizada.

test

Opcional.

Comandos que se ejecutan durante de la ejecución de prueba automatizada. Si se produce un error en cualquiera de los comandos de la fase de prueba, la prueba se marca como no completada correctamente.

post_test

Opcional.

Comandos, si procede, que se ejecutan después de la ejecución de prueba automatizada.

artifacts

Opcional.

Device Farm recopila artefactos, como informes personalizados, archivos de registro e imágenes, de una ubicación que se especifica aquí. No se admiten los caracteres comodín dentro de la ubicación de un artefacto. Por consiguiente, debe especificar una ruta válida para cada ubicación.

Estos artefactos de prueba están disponibles para cada dispositivo de la ejecución de prueba. Para obtener información acerca de la recuperación de artefactos de prueba, consulte Uso de artefactos en un entorno de pruebas personalizado.

importante

Una especificación de prueba tener formato de archivo YAML válido. Si las sangrías o el espaciado de la especificación de prueba no son válidos, la ejecución de prueba puede no completarse correctamente. No se permiten los tabuladores en los archivos YAML. Puede utilizar un validador de YAML para comprobar si la especificación de prueba es un archivo YAML válido. Para obtener más información, consulte el sitio web de YAML.

Ejemplo de especificación de prueba

Este es un ejemplo de una especificación de prueba YAML en Device Farm que configura una ejecución de prueba de 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