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. # Personalización del entorno de pruebas personalizado 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)](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html). 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 preprocessing/postprocessing sobrecarga. + **Registro y transmisión de video en directo**: los registros de pruebas y el video 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 con la AWS CLI](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5) y [Creación de una ejecución de prueba en Device Farm](how-to-create-test-run.md). **Topics** + [Pruebe la referencia y la sintaxis de las especificaciones](custom-test-environment-test-spec.md) + [Hosts para entornos de prueba personalizados](custom-test-environments-hosts.md) + [Acceda a los recursos de AWS mediante un rol de ejecución de IAM](custom-test-environments-iam-roles.md) + [Variables de entorno para entornos de prueba personalizados](custom-test-environment-variables.md) + [Mejores prácticas para la ejecución de entornos de pruebas personalizados](custom-test-environments-best-practices.md) + [Migración de pruebas de un entorno de pruebas estándar a uno personalizado](custom-test-environment-migration.md) + [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md) # Pruebe la referencia y la sintaxis de las especificaciones La especificación de prueba (especificación de prueba) es un archivo que se utiliza para definir entornos de prueba personalizados en Device Farm. ## Flujo de trabajo de especificaciones de prueba La especificación de prueba de Device Farm ejecuta las fases y sus comandos en un orden predeterminado, lo que le permite personalizar la forma en que se prepara y ejecuta su entorno. Cuando se ejecuta cada fase, sus comandos se ejecutan en el orden indicado en el archivo de especificaciones de la prueba. Las fases se ejecutan en la siguiente secuencia 1. `install`- Aquí es donde se deben definir acciones como descargar, instalar y configurar las herramientas. 1. `pre_test`- Aquí es donde deben definirse las acciones previas a las pruebas, como iniciar procesos en segundo plano. 1. `test`- Aquí es donde debe definirse el comando que invoca la prueba. 1. `post_test`- Aquí es donde se deben definir las tareas finales que deban ejecutarse una vez finalizada la prueba, como la generación del informe de la prueba y la agregación de archivos de artefactos. ## Sintaxis de la especificación de prueba El siguiente es el esquema YAML para un archivo de especificaciones de prueba ``` 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` ** *(Obligatorio, número)* Refleja la versión de la especificación de prueba de Device Farm compatible. El número de versión actual es` 0.1`. ** `android_test_host` ** *(Opcional, cadena)* El host de prueba que se seleccionará para las pruebas que se realicen en dispositivos Android. Este campo es obligatorio para las pruebas realizadas en dispositivos Android. Para obtener más información, consulte [Hosts de prueba disponibles para entornos de prueba personalizados](custom-test-environments-hosts.md#custom-test-environments-hosts-available). ** `ios_test_host` ** *(Opcional, cadena)* El host de prueba que se seleccionará para las ejecuciones de prueba realizadas en dispositivos iOS. Este campo es obligatorio para las pruebas realizadas en dispositivos iOS con una versión principal superior a la 26. Para obtener más información, consulte [Hosts de prueba disponibles para entornos de prueba personalizados](custom-test-environments-hosts.md#custom-test-environments-hosts-available). ** `phases` ** Esta sección contiene grupos de comandos ejecutados durante una ejecución de prueba, donde cada fase es opcional. Los nombres de las fases de prueba permitidos son: `install``pre_test`,`test`, y`post_test`. + `install`- Las dependencias predeterminadas para 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`- Los comandos, si los hubiera, se ejecutaron antes de la prueba automatizada. + `test`- Los comandos ejecutados durante la ejecución de la prueba automatizada. Si algún comando de la fase de prueba falla (es decir, devuelve un código de salida distinto de cero), la prueba se marca como fallida + `post_test`- Los comandos, si los hay, se ejecutan después de la ejecución de la prueba automatizada. Esto se ejecutará independientemente de que la prueba de la `test` fase tenga éxito o no. ** `commands` ** *(Opcional, lista [cadena])* Una lista de cadenas para ejecutar como un comando de shell durante la fase. ** `artifacts` ** *(Opcional, lista [cadena])* 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 [Descarga de artefactos en un entorno de prueba personalizado](using-artifacts-custom.md). **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](http://yaml.org/spec/1.2/spec.html). ## Ejemplos de especificaciones de prueba Los siguientes ejemplos muestran las especificaciones de prueba que se pueden ejecutar en Device Farm. ------ #### [ Simple Demo ] El siguiente es un ejemplo de archivo de especificaciones de prueba que simplemente se registra `Hello world!` como un artefacto de ejecución de prueba. ``` version: 0.1 android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: install: commands: # Setup your environment by installing and/or validating software - devicefarm-cli use python 3.11 - python --version pre_test: commands: # Setup your tests by starting background tasks or setting up # additional environment variables. - OUTPUT_FILE="/tmp/hello.log" test: commands: # Run your tests within this phase. - python -c 'print("Hello world!")' &> $OUTPUT_FILE post_test: commands: # Perform any remaining tasks within this phase, such as copying # artifacts to the DEVICEFARM_LOG_DIR for upload - cp $OUTPUT_FILE $DEVICEFARM_LOG_DIR artifacts: # By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory. - $DEVICEFARM_LOG_DIR ``` ------ #### [ Appium Android ] El siguiente es un ejemplo de archivo de especificaciones de prueba que configura una ejecución de prueba de Appium Java TestNG en 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 iOS ] El siguiente es un ejemplo de archivo de especificaciones de prueba que configura una ejecución de prueba de Appium Java TestNG en 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) ] El siguiente es un ejemplo de archivo de especificaciones de prueba que configura una ejecución de prueba de Appium Java TestNG tanto en Android como en 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 ``` ------ # Hosts para entornos de prueba personalizados Device Farm admite un conjunto de sistemas operativos con software preconfigurado mediante el uso de un entorno host de prueba. Durante la ejecución de la prueba, Device Farm utiliza instancias gestionadas por Amazon (hosts) que se conectan dinámicamente al dispositivo seleccionado que se está probando. Esta instancia se limpia por completo y no se reutiliza entre ejecuciones, y se termina con los artefactos generados una vez finalizada la ejecución de la prueba. **Topics** + [Hosts de prueba disponibles para entornos de prueba personalizados](#custom-test-environments-hosts-available) + [Selección de un host de pruebas para entornos de prueba personalizados](#test-host-selection) + [Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md) + [Entorno de pruebas para dispositivos Android](custom-test-environments-hosts-android.md) + [Entorno de pruebas para dispositivos iOS](custom-test-environments-hosts-ios.md) ## Hosts de prueba disponibles para entornos de prueba personalizados Device Farm administra completamente los hosts de prueba. En la siguiente tabla se enumeran los hosts de prueba de Device Farm actualmente disponibles y compatibles para entornos de prueba personalizados. | Plataforma de dispositivos | Host de prueba | Sistema operativo | Arquitectura (es) | Dispositivos admitidos | | --- | --- | --- | --- | --- | | Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android6 y superior | | iOS | macos\$1sequoia | macOS Sequoia(versión 15) | arm64 | iOS15 a 26 | **nota** Periódicamente, Device Farm agrega nuevos hosts de prueba para una plataforma de dispositivos a fin de admitir las versiones más recientes del sistema operativo del dispositivo y sus dependencias. Cuando esto ocurre, los hosts de prueba más antiguos para la plataforma de dispositivo correspondiente están sujetos a la finalización del soporte. ### Versión del sistema operativo Cada host de prueba disponible utiliza una versión específica del sistema operativo compatible con Device Farm en ese momento. Aunque intentamos tener la última versión del sistema operativo, puede que no sea la última versión de distribución pública disponible. Device Farm actualizará periódicamente el sistema operativo con actualizaciones de versiones menores y parches de seguridad. Para conocer la versión específica (incluida la versión secundaria) del sistema operativo que se utiliza durante la ejecución de la prueba, puede añadir el siguiente fragmento de código a cualquiera de las fases del archivo de especificaciones de la prueba. **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 ``` ## Selección de un host de pruebas para entornos de prueba personalizados Puede especificar el host de pruebas de Android e iOS en las `ios_test_host` variables correspondientes `android_test_host` de su [archivo de especificaciones de prueba](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax). Si no especifica una selección de host de prueba para la plataforma de dispositivo determinada, las pruebas se ejecutarán en el host de prueba que Device Farm haya establecido como predeterminado para el dispositivo y la configuración de prueba especificados. **importante** Al realizar las pruebas en iOS 18 y versiones anteriores, se utilizará un host de prueba antiguo cuando no se seleccione ningún anfitrión. Para obtener más información, consulta el tema sobre[Host de pruebas de iOS antiguo](custom-test-environments-hosts-ios.md#legacy-ios-host). Como ejemplo, revise el siguiente fragmento de código: **Example** ``` version: 0.1 android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: # ... ``` # Software compatible en entornos de prueba personalizados Device Farm utiliza máquinas host que vienen preinstaladas con muchas de las bibliotecas de software necesarias para ejecutar los marcos de pruebas compatibles con nuestro servicio, lo que proporciona un entorno de pruebas listo para el lanzamiento. Device Farm admite varios idiomas mediante el uso de nuestro mecanismo de selección de software y actualizará periódicamente las versiones de los idiomas incluidos en el entorno. Para cualquier otro software necesario, puede modificar el archivo de especificaciones de prueba para instalarlo desde su paquete de prueba, descargarlo de Internet o acceder a fuentes privadas dentro de su VPC (consulte [VPC ENI](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html) para obtener más información). Para obtener más información, consulte [Ejemplos de especificaciones de prueba](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example). ## Software preconfigurado Para facilitar las pruebas de los dispositivos en cada plataforma, se proporcionan las siguientes herramientas en el host de prueba: | Tools (Herramientas) | Plataforma (s) de dispositivos | | --- | --- | | Android SDK Build-Tools | Android | | Android SDK Platform-Tools(incluye`adb`) | Android | | Xcode | iOS | ## Software seleccionable Además del software preconfigurado en el host, Device Farm ofrece una forma de seleccionar determinadas versiones del software compatible mediante las `devicefarm-cli` herramientas. La siguiente tabla contiene el software seleccionable y los hosts de prueba que lo contienen. | Software/herramienta | Hosts que admiten este software | Comando para usar en la especificación de prueba | | --- | --- | --- | | 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` | El host de pruebas también incluye herramientas de soporte de uso común para cada versión de software, como los `pip` administradores de `npm` paquetes (incluidos con Python y Node.js respectivamente) y las dependencias (como el UIAutomator2 controlador Appium) para herramientas como Appium. Esto garantiza que dispone de las herramientas necesarias para trabajar con los marcos de prueba compatibles. # Uso de la herramienta devicefarm-cli en entornos de prueba personalizados El anfitrión de la prueba utiliza una herramienta de administración de versiones estandarizada llamada ` devicefarm-cli` para seleccionar las versiones de software. Esta herramienta es independiente del host de pruebas de Device Farm AWS CLI y solo está disponible en él. Con `devicefarm-cli`, puede cambiar a cualquier versión de software preinstalada en el host de prueba. Esto proporciona una forma sencilla de mantener su archivo de especificaciones de prueba de Device Farm a lo largo del tiempo y le proporciona un mecanismo predecible para actualizar las versiones de software en el futuro. **importante** Esta herramienta de línea de comandos no está disponible en los hosts iOS antiguos. Para obtener más información, consulte el tema sobre[Host de pruebas de iOS antiguo](custom-test-environments-hosts-ios.md#legacy-ios-host). El siguiente fragmento muestra la página `help` 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. ``` Repasemos un par de ejemplos que utilizan `devicefarm-cli`. Para usar la herramienta para cambiar la versión de Python de *3.10* a *3.9* en su archivo de especificaciones de prueba, ejecute los siguientes comandos: ``` $ python --version Python 3.10.12 $ devicefarm-cli use python 3.9 $ python --version Python 3.9.17 ``` Para cambiar la versión de Appium de a: *1* *2* ``` $ appium --version 1.22.3 $ devicefarm-cli use appium 2 $ appium --version 2.1.2 ``` **sugerencia** Tenga en cuenta que cuando selecciona una versión de software, `devicefarm-cli` también cambia las herramientas compatibles con esos lenguajes, como `pip` para Python y `npm` para NodeJS. Para obtener más información sobre el software preinstalado en el host de prueba, consulte. [Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md) # Entorno de pruebas para dispositivos Android AWS Device Farm utiliza máquinas host de Amazon Elastic Compute Cloud (EC2) que ejecutan Amazon Linux 2 para ejecutar pruebas de Android. Al programar una ejecución de prueba, Device Farm asigna un host dedicado a cada dispositivo para ejecutar las pruebas de forma independiente. Las máquinas host finalizan después de la ejecución de la prueba, junto con cualquier artefacto generado. El host Amazon Linux 2 ofrece varias ventajas: + **Pruebas más rápidas y fiables**: en comparación con el host anterior, el nuevo host de pruebas mejora significativamente la velocidad de las pruebas, lo que reduce especialmente los tiempos de inicio de las pruebas. El host Amazon Linux 2 también demuestra una mayor estabilidad y fiabilidad durante las pruebas. + **Acceso remoto mejorado para las pruebas manuales**: las actualizaciones al último host de pruebas y las mejoras permiten reducir la latencia y mejorar el rendimiento del video en las pruebas manuales de Android. + **Selección de versiones de software estándar**: Device Farm ahora estandariza el soporte de los principales lenguajes de programación en el host de prueba, así como en las versiones del marco de Appium. Para los lenguajes compatibles (actualmente Java, Python, Node.js y Ruby) y Appium, el nuevo host de pruebas ofrece versiones estables a largo plazo poco después del lanzamiento. La administración centralizada de versiones a través de la herramienta `devicefarm-cli` permite desarrollar archivos con especificaciones de prueba con una experiencia uniforme en todos los marcos. **Topics** + [Intervalos de IP admitidos para el entorno de pruebas de Amazon Linux 2 en Device Farm](amazon-linux-2-ip-ranges.md) # Intervalos de IP admitidos para el entorno de pruebas de Amazon Linux 2 en Device Farm Los clientes necesitan saber el rango de IP desde el que se origina el tráfico de Device Farm, especialmente para configurar sus firewalls y los ajustes de seguridad. En el caso de los hosts de prueba de Amazon EC2, el rango de IP abarca toda la región `us-west-2`. Para los hosts de prueba de Amazon Linux 2, que es la opción predeterminada para las nuevas ejecuciones de Android, se han restringido los rangos. El tráfico ahora se origina en un conjunto específico de puertas de enlace NAT, lo que restringe el rango de IP a las siguientes direcciones: **** | Rangos de IP | | --- | | **44.236.137.143** | | **52,13,151,244** | | **52,35189,191** | | **54,201,250,26** | Para obtener más información acerca de los entornos de pruebas de Android en Device Farm, consulte [Entorno de pruebas para dispositivos Android](custom-test-environments-hosts-android.md). # Entorno de pruebas para dispositivos iOS Device Farm utiliza instancias macOS (hosts) gestionadas por Amazon que se conectan dinámicamente al dispositivo iOS durante la ejecución de la prueba. Cada host viene preconfigurado con un software que permite realizar pruebas de dispositivos en varias plataformas de prueba populares, como XCTest UI y Appium. La versión actual del host de pruebas de iOS ha mejorado la experiencia de prueba en comparación con las versiones anteriores, incluidas las siguientes: + **Experiencia uniforme con el sistema operativo anfitrión y las herramientas para iOS 15 e iOS 26** Antes, el anfitrión de la prueba lo determinaba el dispositivo en uso, lo que generaba un entorno de software fragmentado cuando se ejecutaba en varias versiones de iOS. La experiencia actual permite seleccionar el host de forma sencilla para crear un entorno uniforme en todos los dispositivos. Esto permitirá que la misma versión y herramientas de macOS (como Xcode) estén disponibles en todos los dispositivos iOS. + **Mejoras de rendimiento en las pruebas de iOS 15 y 16** Gracias a la infraestructura actualizada, el tiempo de configuración ha mejorado considerablemente en las pruebas de iOS 15 y 16. + **Versiones de software seleccionables estandarizadas para las dependencias compatibles** Ahora tenemos el sistema de selección de `devicefarm-cli` software en los hosts de prueba de iOS y Android, lo que le permite seleccionar la versión que prefiera de nuestras dependencias compatibles. Para las dependencias compatibles (como Java, Python, Node.js, Ruby y Appium), las versiones se podrán seleccionar mediante la especificación de prueba. Para hacerse una idea de cómo funciona esta función, consulte el tema sobre. [Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md) **importante** Si se ejecuta en iOS 18 o versiones anteriores, las pruebas se ejecutarán en los hosts de prueba antiguos de forma predeterminada. Consulta el tema siguiente sobre cómo migrar desde los hosts antiguos. ## Host de pruebas de iOS antiguo Para las pruebas existentes en iOS 18 y versiones anteriores, los anfitriones de pruebas antiguos se seleccionan de forma predeterminada para los entornos de prueba personalizados. La siguiente tabla contiene la versión del host de prueba con la que se ejecuta la versión del dispositivo iOS. | Sistema operativo | Arquitecturas | Predeterminado para los dispositivos | | --- | --- | --- | | macOS Sonoma(versión 14) | arm64 | iOS 18 | | macOS Ventura(versión 13) | arm64 | iOS 17 | | macOS Monterey(versión 12) | x86\$164 | iOS 16y más abajo | Para seleccionar los hosts de prueba más nuevos, consulte el tema correspondiente[Migración de sus entornos de prueba personalizados a los nuevos hosts de prueba de iOS](ios-host-migration.md). ## Software compatible para dispositivos iOS Para permitir las pruebas de dispositivos iOS, los hosts de prueba de Device Farm para dispositivos iOS vienen preconfigurados con Xcode y sus herramientas de línea de comandos asociadas. Para ver otro software disponible, consulta el tema correspondiente. [Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md) # Migración de sus entornos de prueba personalizados a los nuevos hosts de prueba de iOS Para migrar las pruebas existentes del host anterior al nuevo host de pruebas de macOS, tendrás que desarrollar nuevos archivos de especificaciones de prueba basados en los ya existentes. El enfoque recomendado es empezar con el archivo de especificaciones de prueba de ejemplo para los tipos de prueba que desees y, a continuación, migrar los comandos pertinentes del archivo de especificaciones de prueba anterior al nuevo. Esto le permite aprovechar las nuevas funciones y optimizaciones de la especificación de prueba del ejemplo para el nuevo host y, al mismo tiempo, reutilizar fragmentos de código existentes. **Topics** + [Tutorial: Migración de archivos de especificaciones de prueba de iOS con la consola](#ios-host-migration-console-tutorial) + [Diferencias entre los hosts de prueba nuevos y antiguos](#ios-host-migration-differences) ## Tutorial: Migración de archivos de especificaciones de prueba de iOS con la consola En este ejemplo, la consola Device Farm se usará para incorporar una especificación de prueba de un dispositivo iOS existente para usar el nuevo host de prueba. ### Paso 1: Crear un nuevo archivo de especificaciones de prueba con la consola 1. Inicie sesión en la [consola de AWS Device Farm](https://console.aws.amazon.com/devicefarm). 1. Navegue hasta el proyecto Device Farm que contiene sus pruebas de automatización. 1. Descargue una copia de la especificación de prueba existente con la que desee incorporarla. 1. Haz clic en la opción «Configuración del proyecto» y dirígete a la pestaña **Cargas.** 1. Navega hasta el archivo de especificaciones de la prueba con el que deseas incorporarla. 1. Haga clic en el botón **Descargar** para hacer una copia local de este archivo. 1. Vuelva a la página del proyecto y haga clic en **Crear ejecución**. 1. Complete las opciones del asistente como si fuera a iniciar una nueva ejecución, pero deténgase en la opción **Seleccionar especificación de prueba**. 1. Con la especificación de prueba de iOS seleccionada de forma predeterminada, haz clic en el botón **Crear una especificación de prueba**. 1. Modifique la especificación de prueba que se seleccionó de *forma predeterminada* en el editor de texto. 1. Si aún no está presente, modifique el archivo de especificaciones de la prueba para seleccionar el nuevo host mediante: ``` ios_test_host: macos_sequoia ``` 1. De la copia de las especificaciones de prueba descargada en un paso anterior, revise cada una de ellas. ` phase` 1. Copie los comandos de las fases de la especificación de prueba anterior en cada fase correspondiente de la nueva especificación de prueba, ignorando los comandos relacionados con la instalación o la selección de Java, Python, Node.js, Ruby, Appium o Xcode. 1. **Introduzca un nombre de archivo nuevo en el cuadro de texto Guardar como.** 1. Haga clic en el botón **Guardar como nuevo** para guardar los cambios. Para ver un ejemplo de un archivo de especificaciones de prueba que puede utilizar como referencia, consulte el ejemplo que se proporciona en[Ejemplos de especificaciones de prueba](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example). ### Paso 2: Selección del software (software preinstalado) En el nuevo host de prueba, las versiones de software preinstaladas se seleccionan mediante una nueva herramienta estandarizada de administración de versiones denominada. `devicefarm-cli` Estas herramientas son ahora el enfoque recomendado para usar los distintos programas que ofrecemos en los hosts de prueba. Como ejemplo, añadiría la siguiente línea para usar un JDK 17 diferente en su entorno de prueba: ``` - devicefarm-cli use java 17 ``` Para obtener más información sobre el software compatible disponible, consulte:[Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md). ### Paso 3: Uso de Appium y sus dependencias a través de las herramientas de selección de software El nuevo host de prueba solo es compatible con Appium 2.x y versiones posteriores. Seleccione explícitamente la versión de Appium utilizando la y, al mismo tiempo`devicefarm-cli`, elimine las herramientas antiguas, como. ` avm` Por ejemplo: ``` # 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 versión de Appium seleccionada `devicefarm-cli` viene preinstalada con una versión compatible del controlador XCUITest para iOS. Además, tendrás que actualizar las especificaciones de prueba para utilizarlas en lugar de. ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` ` DEVICEFARM_WDA_DERIVED_DATA_PATH` La nueva variable de entorno apunta a una versión prediseñada de WebDriverAgent 9.x, que es la última versión compatible con las pruebas de Appium 2. Para obtener más información, consulte y. [Selección de una WebDriverAgent versión para las pruebas de iOS](test-types-appium.md#test-types-appium-select-wda) [Variables de entorno para las pruebas de Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium) ## Diferencias entre los hosts de prueba nuevos y antiguos Al editar el archivo de especificaciones de las pruebas para usar el nuevo host de pruebas de iOS y al realizar la transición de las pruebas desde el host de pruebas anterior, ten en cuenta estas diferencias clave del entorno: + **Versiones de Xcode:** en el entorno de host de pruebas antiguo, la versión de Xcode disponible se basaba en la versión iOS del dispositivo utilizada para las pruebas. Por ejemplo, las pruebas en dispositivos iOS 18 usaron Xcode 16 en el host anterior, mientras que las pruebas en iOS 17 usaron Xcode 15. En el nuevo entorno anfitrión, todos los dispositivos pueden acceder a las mismas versiones de Xcode, lo que permite disponer de un entorno uniforme para las pruebas en dispositivos con diferentes versiones. Para obtener una lista de las versiones de Xcode disponibles actualmente, consulte. [Software compatible](custom-test-environments-hosts-software.md) + **Selección de versiones de software:** en muchos casos, las versiones de software predeterminadas han cambiado, por lo que si antes no seleccionaba explícitamente su versión de software en el host de prueba anterior, puede que desee especificarla ahora en el nuevo host de prueba mediante [`devicefarm-cli`](custom-test-environments-hosts-software-cli.md). En la gran mayoría de los casos de uso, recomendamos que los clientes seleccionen de forma explícita las versiones del software que utilizan. Si selecciona una versión de software, `devicefarm-cli` tendrá una experiencia predecible y coherente con ella y recibirá una gran cantidad de advertencias si Device Farm planea eliminar esa versión del host de prueba. Además, herramientas de selección de software como `nvm`, `pyenv`, ` avm`, y `rvm` se han eliminado en favor del nuevo sistema de selección de software ` devicefarm-cli`. + **Versiones de software disponibles:** se han eliminado muchas versiones del software previamente preinstalado y se han agregado muchas versiones nuevas. Por lo tanto, asegúrese de que cuando utilice `devicefarm-cli` para seleccionar las versiones de software, seleccione las que estén en la [lista de versiones compatibles](custom-test-environments-hosts-software.md). + **El `libimobiledevice` conjunto de herramientas se ha eliminado** en favor de herramientas más nuevas o propias para realizar un seguimiento de las pruebas actuales de los dispositivos iOS y los estándares de la industria. Para iOS 17 y versiones posteriores, puedes migrar la mayoría de los comandos para usar herramientas de Xcode similares, llamadas. `devicectl` Para obtener información al respecto`devicectl`, puedes ejecutarlo `xcrun devicectl help` desde una máquina con Xcode instalado. + Las **rutas de archivos que están codificadas** en el archivo de especificaciones de prueba del host anterior como rutas absolutas probablemente no funcionen como se espera en el nuevo host de prueba y, por lo general, no se recomiendan para el uso de archivos de especificaciones de prueba. Le recomendamos que utilice rutas relativas y variables de entorno para todo el código del archivo de especificaciones de prueba. Para obtener más información, consulte el tema sobre. [Mejores prácticas para la ejecución de entornos de pruebas personalizados](custom-test-environments-best-practices.md) + **Versión y arquitectura del sistema operativo:** los hosts de prueba antiguos utilizaban diversas versiones de macOS y arquitecturas de CPU basadas en el dispositivo asignado. Como resultado, es posible que los usuarios observen algunas diferencias en las bibliotecas de sistemas disponibles en el entorno. Para obtener más información sobre la versión anterior del sistema operativo anfitrión, consulte[Host de pruebas de iOS antiguo](custom-test-environments-hosts-ios.md#legacy-ios-host). + **Para los usuarios de Appium**, la forma de seleccionar el prefijo WebDriverAgent ha cambiado a utilizar el prefijo de la variable de entorno ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` en lugar del prefijo anterior. ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` Para obtener más información sobre la variable actualizada, consulte. [Variables de entorno para las pruebas de Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium) + **Para los usuarios de Appium Java**, el nuevo host de prueba no contiene ningún archivo JAR preinstalado en su ruta de clases, mientras que el host anterior contenía uno para el marco TestNG (a través de una variable de entorno). `$DEVICEFARM_TESTNG_JAR` Recomendamos a los clientes que incluyan los archivos JAR necesarios para sus marcos de pruebas dentro de su paquete de pruebas y que eliminen las instancias de la variable `$DEVICEFARM_TESTNG_JAR` de sus archivos de especificaciones de prueba. Le recomendamos que contacte con el equipo de servicio a través de un servicio de asistencia si tiene algún comentario o pregunta sobre las diferencias entre los hosts de prueba desde el punto de vista del software. # Acceda a los recursos de AWS mediante un rol de ejecución de IAM Device Farm admite la especificación de una función de IAM que asumirá el entorno de ejecución de la prueba personalizado durante la ejecución de la prueba. Esta función permite que sus pruebas accedan de forma segura a los recursos de AWS de su cuenta, como los buckets de Amazon S3, las tablas de DynamoDB u otros servicios de AWS de los que dependa su aplicación. **Topics** + [Descripción general de](#iam-execution-role-overview) + [Requisitos de rol de IAM](#iam-role-requirements) + [Configuración de una función de ejecución de IAM](#configuring-iam-execution-role) + [Prácticas recomendadas](#iam-role-best-practices) + [Resolución de problemas](#troubleshooting-iam-roles) ## Descripción general de Al especificar una función de ejecución de IAM, Device Farm asume esta función durante la ejecución de la prueba, lo que permite que las pruebas interactúen con los servicios de AWS mediante los permisos definidos en la función. Entre los casos de uso habituales de las funciones de ejecución de IAM se incluyen los siguientes: + Acceso a los datos de prueba almacenados en los buckets de Amazon S3 + Trasladar los artefactos de prueba a los buckets de Amazon S3 + Recuperación de la configuración de la aplicación de AWS AppConfig + Escribir registros y métricas de pruebas en Amazon CloudWatch + Envío de resultados de pruebas o mensajes de estado a las colas de Amazon SQS + Llamar a las funciones de AWS Lambda como parte de los flujos de trabajo de prueba ## Requisitos de rol de IAM Para utilizar una función de ejecución de IAM con Device Farm, su función debe cumplir los siguientes requisitos: + **Relación de confianza**: se debe confiar en el director del servicio Device Farm para que asuma la función. La política de confianza debe incluirse `devicefarm.amazonaws.com` como entidad de confianza. + **Permisos**: el rol debe tener los permisos necesarios para acceder a los recursos de AWS que requieren sus pruebas. + **Duración de la sesión**: la duración máxima de la sesión del rol debe ser como mínimo igual a la configuración de tiempo de espera del trabajo del proyecto de Device Farm. De forma predeterminada, los proyectos de Device Farm tienen un tiempo de espera de trabajo de 150 minutos, por lo que su función debe admitir una duración de sesión de al menos 150 minutos. + El **mismo requisito de cuenta**: la función de IAM debe estar en la misma cuenta de AWS que la utilizada para llamar a Device Farm. No se admite la suposición de roles entre cuentas. + **PassRole permiso**: la persona que llama debe estar autorizada a pasar la función de IAM mediante una política que permita realizar `iam:PassRole` acciones en la función de ejecución especificada. ### Política de confianza de ejemplo El siguiente ejemplo muestra una política de confianza que permite a Device Farm asumir su función de ejecución. Esta política de confianza solo debe adjuntarse a la función de IAM específica que pretenda utilizar con Device Farm, no a otras funciones de su cuenta: **Example** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "devicefarm.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ### Ejemplo de política de permisos El siguiente ejemplo muestra una política de permisos que concede acceso a los servicios de AWS más comunes que se utilizan en las pruebas: **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-*" } ] } ``` ## Configuración de una función de ejecución de IAM Puede especificar una función de ejecución de IAM a nivel de proyecto o para pruebas individuales. Cuando se configura a nivel de proyecto, todas las ejecuciones de ese proyecto heredarán la función de ejecución. Una función de ejecución configurada en una ejecución sustituirá a cualquier función configurada en su proyecto principal. Para obtener instrucciones detalladas sobre la configuración de las funciones de ejecución, consulte: + [Creación de un proyecto en AWS Device Farm](how-to-create-project.md)- para configurar las funciones de ejecución a nivel de proyecto + [Creación de una ejecución de prueba en Device Farm](how-to-create-test-run.md)- para configurar las funciones de ejecución para ejecuciones individuales También puede configurar las funciones de ejecución mediante la API Device Farm. Para obtener más información, consulte la [referencia de la API de Device Farm](https://docs.aws.amazon.com/devicefarm/latest/APIReference/). ## Prácticas recomendadas Siga estas prácticas recomendadas al configurar las funciones de ejecución de IAM para sus pruebas de Device Farm: + **Principio del mínimo privilegio**: conceda solo los permisos mínimos necesarios para que las pruebas funcionen. Evita usar permisos demasiado amplios, como `*` acciones o recursos. + **Utilice permisos específicos para cada recurso**: cuando sea posible, limite los permisos a recursos específicos (p. ej., cubos de S3 específicos o tablas de DynamoDB) en lugar de a todos los recursos de un mismo tipo. + Recursos **de prueba y de producción separados: utilice funciones y recursos** de prueba específicos para evitar que los sistemas de producción se vean afectados accidentalmente durante las pruebas. + **Revisión periódica de las funciones**: revise y actualice periódicamente sus funciones de ejecución para asegurarse de que siguen satisfaciendo sus necesidades de pruebas y siguiendo las mejores prácticas de seguridad. + **Use claves de condición**: considere la posibilidad de usar claves de condición de IAM para restringir aún más cuándo y cómo se puede usar el rol. ## Resolución de problemas Si tiene problemas con las funciones de ejecución de IAM, compruebe lo siguiente: + **Relación de confianza**: compruebe que la política de confianza del rol se incluya `devicefarm.amazonaws.com` como un servicio de confianza. + **Permisos**: compruebe que el rol tiene los permisos necesarios para los servicios de AWS a los que están intentando acceder las pruebas. + **Registros de pruebas**: revise los registros de ejecución de las pruebas para ver mensajes de error específicos relacionados con las llamadas a las API de AWS o las denegaciones de permisos. # Variables de entorno para entornos de prueba personalizados Device Farm configura dinámicamente varias variables de entorno para usarlas como parte de la ejecución de un entorno de pruebas personalizado. **Topics** + [Variables de entorno personalizadas](#custom-test-environment-variables-custom) + [Variables de entorno comunes](#custom-test-environment-variables-common) + [Variables de entorno para las pruebas de Appium](#custom-test-environment-variables-appium) + [Variables de entorno para XCUITest las pruebas](#custom-test-environment-variables-xcuitest) ## Variables de entorno personalizadas Device Farm admite la configuración de pares clave-valor que se aplican como variables de entorno en el host de prueba. Se pueden configurar en un proyecto de Device Farm o durante la creación de una ejecución; cualquier variable configurada en una ejecución sustituirá a las que se hayan configurado en su proyecto principal. Se aplican las siguientes restricciones: + Las variables de entorno personalizadas no se admiten en los hosts de prueba de iOS antiguos. Para obtener más información, consulte [Host de pruebas de iOS antiguo](custom-test-environments-hosts-ios.md#legacy-ios-host). + Los nombres de variables que comiencen por `$DEVICEFARM_` están reservados para el uso del servicio interno. + Las variables de entorno personalizadas no se pueden usar para configurar la selección de cómputo del host de prueba en la especificación de la prueba. ## Variables de entorno comunes En esta sección se describen las variables de entorno comunes a todas las pruebas de Device Farm. ** `$DEVICEFARM_DEVICE_NAME` ** El dispositivo en el que se ejecutan las pruebas. Representa el identificador de dispositivo único (UDID) del dispositivo. ** `$DEVICEFARM_DEVICE_UDID` ** El identificador único del dispositivo. ** `$DEVICEFARM_DEVICE_PLATFORM_NAME` ** El nombre de la plataforma del dispositivo. Es `Android` o `iOS`. ** `$DEVICEFARM_DEVICE_OS_VERSION` ** La versión del sistema operativo del dispositivo. ** `$DEVICEFARM_APP_PATH` ** *(pruebas de aplicaciones móviles)* La ruta a la aplicación móvil en la máquina host donde se ejecutan las pruebas. Esta variable no está disponible durante las pruebas web. ** `$DEVICEFARM_LOG_DIR` ** La ruta al directorio predeterminado donde se almacenarán los registros de los clientes, los artefactos y otros archivos necesarios para su posterior recuperación. Utilizando un [ejemplo de especificación de prueba](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example), los archivos de este directorio se archivan en un archivo ZIP y están disponibles como artefactos tras la ejecución de la prueba. ** `$DEVICEFARM_SCREENSHOT_PATH` ** Ruta a las capturas de pantalla, si procede, capturadas durante la ejecución de prueba. ** `$DEVICEFARM_PROJECT_ARN` ** El ARN del proyecto principal del trabajo. ** `$DEVICEFARM_RUN_ARN` ** El ARN de la carrera principal del trabajo. ** `$DEVICEFARM_DEVICE_ARN` ** El ARN del dispositivo que se está probando. ** `$DEVICEFARM_TOTAL_JOBS` ** El número total de trabajos asociados a su ejecución principal de Device Farm. ** `$DEVICEFARM_JOB_NUMBER` ** El número de este trabajo está dentro de`$DEVICEFARM_TOTAL_JOBS`. Por ejemplo, una ejecución puede contener 5 trabajos y cada uno tendrá un `$DEVICEFARM_JOB_NUMBER` intervalo único de 0 a 4. ** `$AWS_REGION` ** La región de AWS. El servicio lo configurará para que coincida con la región en la que se encuentra el dispositivo que se está probando. Si es necesario, se puede anular mediante una variable de entorno personalizada. ** `$ANDROID_HOME` ** *(Solo Android)* La ruta al directorio de instalación del SDK de Android. ## Variables de entorno para las pruebas de Appium En esta sección se describen las variables de entorno utilizadas por cualquier prueba de Appium en un entorno de pruebas personalizado en Device Farm. ** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` ** *(Solo Android)* La ubicación de un directorio que contiene los ChromeDriver ejecutables necesarios para su uso en las pruebas web e híbridas de Appium. ** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` ** *(solo iOS)* La ruta de datos derivada de una versión de WebDriverAgent creada para ejecutarse en Device Farm. La numeración de la variable corresponderá a la versión principal de WebDriverAgent. Como ejemplo, `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` apuntará a una WebDriverAgent versión de 9.x. Para obtener más información, consulte [Selección de una WebDriverAgent versión para las pruebas de iOS](test-types-appium.md#test-types-appium-select-wda). Las variables de `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` entorno solo están presentes en los hosts iOS que no son antiguos. Para obtener más información, consulte [Host de pruebas de iOS antiguo](custom-test-environments-hosts-ios.md#legacy-ios-host). ** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` ** *(solo para iOS, obsoleto)* La ruta de datos derivada de una versión de WebDriverAgent creada para ejecutarse en Device Farm. Consulte el esquema `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` de nombres de reemplazo. ## Variables de entorno para XCUITest las pruebas En esta sección, se describen las variables de entorno que utiliza la XCUITest prueba en un entorno de prueba personalizado en Device Farm. ** `$DEVICEFARM_XCUITESTRUN_FILE` ** La ruta al `.xctestun` archivo Device Farm. Se genera a partir de los paquetes de prueba y de la aplicación. ** `$DEVICEFARM_DERIVED_DATA_PATH` ** Ruta esperada de salida de xcodebuild de Device Farm. ** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` ** Ruta al contenido descomprimido del archivo del paquete de prueba. # Mejores prácticas para la ejecución de entornos de pruebas personalizados En los temas siguientes se describen las prácticas recomendadas para utilizar la ejecución de pruebas personalizadas con Device Farm. **Ejecutar configuración** + **Confíe en el software gestionado por Device Farm y en las funciones de la API para ejecutar la configuración** siempre que sea posible, en lugar de aplicar configuraciones similares mediante comandos de shell en el archivo de especificaciones de prueba. Esto incluye la configuración del host de prueba y del dispositivo, ya que será más sostenible y coherente en todos los hosts y dispositivos de prueba. Si bien Device Farm lo alienta a personalizar el archivo de especificaciones de prueba tanto como necesite para ejecutar las pruebas, el archivo de especificaciones de prueba puede resultar difícil de mantener con el tiempo a medida que se le agreguen más comandos personalizados. Utilizar el software gestionado Device Farm (a través de herramientas como ` devicefarm-cli` las herramientas predeterminadas disponibles en el`$PATH`) y utilizar funciones gestionadas (como el parámetro 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)solicitud) para simplificar el archivo de especificaciones de las pruebas al transferir la responsabilidad del mantenimiento al propio Device Farm. **Pruebe las especificaciones y el código del paquete** + **No utilice rutas absolutas ni confíe en versiones secundarias específicas** del archivo de especificaciones de prueba o del código del paquete de prueba. Device Farm aplica actualizaciones de rutina al host de prueba seleccionado y a las versiones de software incluidas. El uso de rutas específicas o absolutas (por ejemplo, ` /usr/local/bin/python` en lugar de`python`) o la exigencia de versiones secundarias específicas (por ejemplo, Node.js `20.3.1` en lugar de solo` 20`) puede provocar que las pruebas no localicen el archivo o ejecutable requerido. Como parte de la ejecución de las pruebas personalizadas, Device Farm configura varias variables de entorno y la `$PATH` variable para garantizar que las pruebas tengan una experiencia coherente en nuestros entornos dinámicos. Para obtener más información, consulte [Variables de entorno para entornos de prueba personalizados](custom-test-environment-variables.md) y [Software compatible en entornos de prueba personalizados](custom-test-environments-hosts-software.md). + **Guarde los archivos generados o copiados en el directorio temporal durante la ejecución de la prueba.** Hoy nos aseguramos de que el usuario pueda acceder al directorio temporal (`/tmp`) durante la ejecución de la prueba (además de los directorios gestionados, como el`$DEVICEFARM_LOG_DIR`). Otros directorios a los que el usuario tiene acceso pueden cambiar con el tiempo debido a las necesidades del servicio o del sistema operativo utilizado. + **Guarde los registros de ejecución de las pruebas en `$DEVICEFARM_LOG_DIR`**. Este es el directorio de artefactos predeterminado que se proporciona para que la ejecución añada registros de ejecución o artefactos. Cada uno de los [ejemplos de especificaciones de prueba](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) que proporcionamos utiliza este directorio para los artefactos de forma predeterminada. + **Asegúrese de que sus comandos devuelvan un código distinto de cero en caso de error** durante la `test` fase de la especificación de prueba. Determinamos si la ejecución ha fallado comprobando si hay un código de salida distinto de cero en cada comando de shell invocado durante la fase. `test` Debe asegurarse de que su estructura lógica o de prueba devuelva un código de salida distinto de cero para todos los escenarios deseados, que pueden requerir una configuración adicional. Por ejemplo, algunos marcos de pruebas (por ejemplo JUnit5) no consideran que la ejecución de cero pruebas sea un error, lo que provocará que se detecte que las pruebas se han ejecutado correctamente aunque no se haya ejecutado nada. JUnit5 Como ejemplo, tendría que especificar la opción de línea de comandos `--fail-if-no-tests` para garantizar que este escenario se cierre con un código de salida distinto de cero. + **Revise la compatibilidad del software** con la versión del sistema operativo del dispositivo y la versión del host que utilizará para la ejecución de la prueba. Por ejemplo, hay ciertas características de los marcos de software de prueba (por ejemplo, Appium) que pueden no funcionar según lo previsto en todas las versiones del sistema operativo del dispositivo que se está probando. **Seguridad** + **Evite almacenar o registrar variables sensibles (como las claves de AWS) en el archivo de especificaciones de la prueba.** Los archivos de especificaciones de prueba, los scripts generados por las especificaciones de prueba y los registros del script de especificaciones de prueba se proporcionan como elementos descargables al final de la ejecución de la prueba. Esto puede provocar que otros usuarios de tu cuenta que tengan acceso de lectura a la prueba revelen información secreta de forma no intencionada. # Migración de pruebas de un entorno de pruebas estándar a uno personalizado Puede cambiar de un modo de ejecución de pruebas estándar a un modo de ejecución personalizado en AWS Device Farm. La migración implica principalmente dos formas diferentes de ejecución: 1. **Modo estándar**: este modo de ejecución de pruebas está diseñado principalmente para proporcionar a los clientes informes detallados y un entorno totalmente gestionado. 1. **Modo personalizado**: este modo de ejecución de pruebas está diseñado para diferentes casos de uso que requieren ejecuciones de pruebas más rápidas, la capacidad de migrar mediante lift-and-shift y lograr la paridad con su entorno local y la transmisión de video en directo. Para obtener más información sobre los modos estándar y personalizado de Device Farm, consulte [Entornos de prueba de AWS Device Farm](test-environments.md) y [Personalización del entorno de pruebas personalizado en AWS Device Farm.](custom-test-environments.md). ## Consideraciones a la hora de migrar En esta sección se enumeran algunos de los casos de uso más destacados que se deben tener en cuenta al migrar al modo personalizado: 1. **Velocidad**: en el modo de ejecución estándar, Device Farm analiza los metadatos de las pruebas que ha empaquetado y cargado siguiendo las instrucciones de empaquetado de su marco particular. El análisis detecta el número de pruebas del paquete. A partir de entonces, Device Farm ejecuta cada prueba por separado y presenta los registros, videos y otros artefactos de resultados de forma individual para cada prueba. Sin embargo, esto aumenta de manera constante el tiempo total de ejecución de las end-to-end pruebas, ya que el procesamiento previo y posterior de las pruebas y los resultados se ven alterados por parte del servicio. Por el contrario, el modo de ejecución personalizado no analiza su paquete de pruebas; esto significa que no hay preprocesamiento y que el postprocesamiento de las pruebas o de los artefactos resultantes es mínimo. Esto se traduce en tiempos totales end-to-end de ejecución cercanos a los de su configuración local. Las pruebas se ejecutan en el mismo formato que si se ejecutaran en los equipos locales. Los resultados de las pruebas son los mismos que los que se obtienen localmente y están disponibles para su descarga al final de la ejecución del trabajo. 1. **Personalización o flexibilidad**: el modo de ejecución estándar analiza el paquete de pruebas para detectar el número de pruebas y, a continuación, ejecuta cada prueba por separado. Tenga en cuenta que no hay garantía de que las pruebas se ejecuten en el orden que especificó. Como resultado, es posible que las pruebas que requieren una secuencia de ejecución determinada no funcionen según lo esperado. Además, no hay forma de personalizar el entorno de la máquina host ni de pasar los archivos de configuración que puedan ser necesarios para ejecutar las pruebas de una forma determinada. Por el contrario, el modo personalizado le permite configurar el entorno de la máquina host, incluida la posibilidad de instalar software adicional, pasar filtros a las pruebas, transferir archivos de configuración y controlar la configuración de ejecución de las pruebas. Lo consigue mediante un archivo yaml (también denominado archivo testspec) que puede modificar añadiéndole comandos de intérprete de comandos. Este archivo yaml se convierte en un script de intérprete de comandos que se ejecuta en el equipo host de prueba. Puede guardar varios archivos yaml y elegir uno de forma dinámica según sus necesidades al programar una ejecución. 1. **Video en directo y registro**: los modos de ejecución estándar y personalizado le proporcionan videos y registros para sus pruebas. Sin embargo, en el modo estándar, solo obtendrá el video y los registros predefinidos de las pruebas una vez finalizadas las pruebas. Por el contrario, el modo personalizado te ofrece una transmisión en directo del video y de los registros de sus pruebas desde el lado del cliente. Además, podrá descargar el video y otros artefactos al final de las pruebas. **sugerencia** Si su caso de uso implica al menos uno de los factores anteriores, le recomendamos encarecidamente que cambie al modo de ejecución personalizado. ## Pasos para realizar la migración Para migrar del modo estándar al modo personalizado, haga lo siguiente: 1. Inicie sesión en la consola Device Farm Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/). 1. Seleccione su proyecto y, a continuación, inicie una nueva ejecución de automatización. 1. Cargue su aplicación (o `web app` selecciónela), seleccione el tipo de marco de prueba, cargue su paquete de prueba y, a continuación, en el parámetro `Choose your execution environment`, seleccione la opción para `Run your test in a custom environment`. 1. De forma predeterminada, aparecerá el ejemplo del archivo de especificaciones de prueba de Device Farm para que lo vea y lo edite. Este archivo de ejemplo se puede utilizar como punto de partida para probar las pruebas en el [modo de entorno personalizado](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html). A continuación, una vez que haya comprobado que las pruebas funcionan correctamente desde la consola, podrá modificar cualquiera de sus integraciones de API, CLI y canalización con Device Farm para utilizar este archivo de especificaciones de prueba como parámetro al programar las ejecuciones de las pruebas. Para obtener información sobre cómo añadir un archivo de especificaciones de prueba como parámetro para tus ejecuciones, consulte la sección de parámetros de `testSpecArn` de la API `ScheduleRun` en nuestra [guía de API.](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html) ## Marco de Appium En un entorno de pruebas personalizado, Device Farm no inserta ni anula ninguna capacidad de Appium en las pruebas del marco de Appium. Es preciso especificar las capacidades de Appium de la prueba en el archivo YAML de la especificación de prueba o en el código de la prueba. ## Instrumentación para Android No es preciso realizar cambios para mover las pruebas de instrumentación para Android a un entorno de pruebas personalizado. ## iOS XCUITest No es necesario realizar cambios para mover las XCUITest pruebas de iOS a un entorno de pruebas personalizado. # Ampliación de los entornos de prueba personalizados en 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. El modo personalizado de Device Farm le permite ejecutar algo más que su conjunto de pruebas. En esta sección, aprenderá a ampliar su conjunto de pruebas y a optimizar sus pruebas. Para obtener más información acerca de los entornos de pruebas personalizados en Device Farm, consulte [Personalización del entorno de pruebas personalizado en AWS Device Farm.](custom-test-environments.md). **Topics** + [Configuración de un PIN de dispositivo al ejecutar pruebas en Device Farm](custom-test-environments-extending-set-pin.md) + [Agilización de las pruebas basadas en Appium en Device Farm con las capacidades deseadas](custom-test-environments-extending-speed.md) + [Uso de Webhooks y otros APIs después de ejecutar las pruebas en Device Farm](custom-test-environments-extending-webhooks.md) + [Adición de archivos adicionales a su paquete de pruebas en Device Farm](custom-test-environments-extending-files.md) # Configuración de un PIN de dispositivo al ejecutar pruebas en Device Farm Algunas aplicaciones requieren que establezca un PIN en el dispositivo. Device Farm no admite la configuración de un PIN en los dispositivos de forma nativa. Sin embargo, esto es posible con las siguientes advertencias: + El dispositivo debe ejecutar Android 8 o superior. + El PIN debe eliminarse una vez finalizada la prueba. Para configurar el PIN en las pruebas, utilice las fases `pre_test` y `post_test` para configurar y eliminar el PIN, tal y como se muestra a continuación: ``` 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" ``` Cuando comience el conjunto de pruebas, se establecerá el PIN 1234. Al salir de la sala de pruebas, se elimina el PIN. **aviso** Si no elimina el PIN del dispositivo una vez finalizada la prueba, el dispositivo y su cuenta se pondrán en cuarentena. Para ver otras maneras de ampliar el conjunto de pruebas y optimizar las pruebas, consulte [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md). # Agilización de las pruebas basadas en Appium en Device Farm con las capacidades deseadas Cuando se utiliza Appium, se puede encontrar que el conjunto de pruebas de modo estándar es muy lento. Esto se debe a que Device Farm aplica la configuración predeterminada y no hace suposiciones sobre cómo desea utilizar el entorno de Appium. Si bien estos valores predeterminados se basan en las prácticas recomendadas del sector, es posible que no se apliquen a su situación. Para ajustar los parámetros del servidor Appium, puede ajustar las capacidades predeterminadas de Appium en sus especificaciones de prueba. Por ejemplo, lo siguiente establece la capacidad de `usePrebuildWDA` en `true` de un conjunto de pruebas de iOS para acelerar el tiempo de inicio inicial: ``` 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 & ``` Las capacidades de Appium deben ser una estructura JSON entrecomillada con intérprete de comandos de escape. Las siguientes capacidades de Appium son fuentes comunes de mejoras en el rendimiento: `noReset` y `fullReset` Estas dos capacidades, que se excluyen mutuamente, describen el comportamiento de Appium una vez finalizada cada sesión. Cuando `noReset` está configurado en la opción `true`, el servidor de Appium no elimina los datos de la aplicación al finalizar una sesión de Appium, por lo que no realiza ningún tipo de limpieza. `fullReset`desinstala y borra todos los datos de la aplicación del dispositivo una vez cerrada la sesión. Para obtener más información, consulte [Restablecer estrategias](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/) en la documentación de Appium. `ignoreUnimportantViews` (solo para Android) Indica a Appium que comprima la jerarquía de la interfaz de usuario de Android solo para incluir las vistas *relevantes* para la prueba, lo que acelera las búsquedas de ciertos elementos. Sin embargo, esto puede dañar algunos conjuntos de pruebas XPath basados porque se ha cambiado la jerarquía del diseño de la interfaz de usuario. `skipUnlock` (solo para Android) Informa a Appium de que actualmente no hay ningún código PIN configurado, lo que acelera las pruebas después de que se apague la pantalla o se bloquee. `webDriverAgentUrl` (solo iOS) Indica a Appium que asuma que una dependencia esencial de iOS, `webDriverAgent`, ya está en ejecución y disponible para aceptar solicitudes HTTP en la URL especificada. Si `webDriverAgent` aún no está en funcionamiento, Appium puede tardar algún tiempo al principio de un conjunto de pruebas en iniciar el `webDriverAgent`. Si inicia `webDriverAgent` usted mismo y configura `webDriverAgentUrl` como `http://localhost:8100` al iniciar Appium, podrá arrancar su conjunto de pruebas más rápido. Tenga en cuenta que esta capacidad nunca debe usarse junto con la capacidad `useNewWDA`. Puede usar el siguiente código para empezar `webDriverAgent` desde el archivo de especificaciones de prueba en el puerto local del dispositivo `8100` y, a continuación, reenviarlo al puerto local del host de la prueba `8100` (esto te permite establecer el valor de `webDriverAgentUrl` como `http://localhost:8100`). Este código debe ejecutarse durante la fase de instalación, una vez que se haya definido cualquier código para configurar las variables de Appium y de entorno `webDriverAgent`: ``` # Start WebDriverAgent and iProxy - >- xcodebuild test-without-building -project /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -derivedDataPath $DEVICEFARM_WDA_DERIVED_DATA_PATH -destination id=$DEVICEFARM_DEVICE_UDID_FOR_APPIUM IPHONEOS_DEPLOYMENT_TARGET=$DEVICEFARM_DEVICE_OS_VERSION GCC_TREAT_WARNINGS_AS_ERRORS=0 COMPILER_INDEX_STORE_ENABLE=NO >> $DEVICEFARM_LOG_DIR/webdriveragent_log.txt 2>&1 & iproxy 8100 8100 >> $DEVICEFARM_LOG_DIR/iproxy_log.txt 2>&1 & ``` Luego, puede añadir el siguiente código a su archivo de especificaciones de prueba para asegurarse de que `webDriverAgent` se haya iniciado correctamente. Este código debe ejecutarse al final de la fase de prueba previa después de garantizar que Appium se haya iniciado correctamente: ``` # 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; ``` Para obtener más información sobre las capacidades que admite Appium, consulte las [capacidades deseadas de Appium](http://appium.io/docs/en/writing-running-appium/caps/) en la documentación de Appium. Para ver otras maneras de ampliar el conjunto de pruebas y optimizar las pruebas, consulte [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md). # Uso de Webhooks y otros APIs después de ejecutar las pruebas en Device Farm Puede hacer que Device Farm llame a un webhook después de que cada conjunto de pruebas termine de usar **curl**. El proceso para hacerlo varía según el destino y el formato. Para su webhook específico, consulte la documentación de ese webhook. En el siguiente ejemplo, se publica un mensaje en un webhook de Slack cada vez que un conjunto de pruebas finaliza: ``` 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 ``` Para obtener más información sobre el uso de webhooks con Slack, consulte [Cómo enviar su primer mensaje de Slack mediante Webhook](https://api.slack.com/tutorials/slack-apps-hello-world) en la referencia de la API de Slack. Para ver otras maneras de ampliar el conjunto de pruebas y optimizar las pruebas, consulte [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md). No está limitado a utilizar **curl** para llamar a los webhooks. Los paquetes de prueba pueden incluir scripts y herramientas adicionales, siempre que sean compatibles con el entorno de ejecución de Device Farm. Por ejemplo, su paquete de prueba puede incluir scripts auxiliares que realizan solicitudes a otros APIs. Asegúrese de que todos los paquetes necesarios estén instalados junto con los requisitos de su conjunto de pruebas. Para añadir un script que se ejecute una vez finalizado el conjunto de pruebas, inclúyalo en el paquete de prueba y añada lo siguiente a las especificaciones de la prueba: ``` phases: post_test: - python post_test.py ``` **nota** El mantenimiento de las claves de API u otros tokens de autenticación utilizados en su paquete de prueba es su responsabilidad. Le recomendamos que mantenga cualquier tipo de credencial de seguridad fuera del control de código fuente, que utilice credenciales con el menor número de privilegios posible y que utilice tokens revocables y de corta duración siempre que sea posible. Para comprobar los requisitos de seguridad, consulta la documentación del tercero APIs que utilices. Si planea usar los AWS servicios como parte de su conjunto de ejecución de pruebas, debe usar las credenciales temporales de IAM, generadas fuera de su conjunto de pruebas e incluidas en su paquete de pruebas. Estas credenciales deben tener el menor número de permisos concedidos y una vida útil lo más corta posible. Para obtener más información acerca de la creación de credenciales temporales, consulte [Solicitud de credenciales de seguridad temporales](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html) en la *Guía del usuario de IAM*. Para ver otras maneras de ampliar el conjunto de pruebas y optimizar las pruebas, consulte [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md). # Adición de archivos adicionales a su paquete de pruebas en Device Farm Es posible que desee utilizar archivos adicionales como parte de sus pruebas, ya sea como archivos de configuración adicionales o como datos de prueba adicionales. Puede añadir estos archivos adicionales a su paquete de prueba antes de cargarlo en AWS Device Farm y, a continuación, acceder a ellos desde el modo de entorno personalizado. Básicamente, todos los formatos de carga de paquetes de prueba (ZIP, IPA, APK, JAR, etc.) son formatos de archivo de paquetes que admiten las operaciones ZIP estándar. Puedes añadir archivos a tu archivo de prueba antes de cargarlo AWS Device Farm mediante el siguiente comando: ``` $ zip zip-with-dependencies.zip extra_file ``` Para un directorio de archivos adicionales: ``` $ zip -r zip-with-dependencies.zip extra_files/ ``` Estos comandos funcionan según lo previsto en todos los formatos de carga de paquetes de prueba, excepto en los archivos IPA. En el caso de los archivos IPA, especialmente cuando se utilizan con XCUITests ellos, le recomendamos que coloque los archivos adicionales en una ubicación ligeramente diferente debido a la forma en que se diseñan los AWS Device Farm paquetes de prueba de iOS. Al crear la prueba de iOS, el directorio de la aplicación de prueba se ubicará dentro de otro directorio denominado*Payload*. Por ejemplo, este es el aspecto que puede tener uno de esos directorios de prueba de 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 ``` Para estos XCUITest paquetes, agrega cualquier archivo adicional al directorio que termine *.app* dentro del *Payload* directorio. Por ejemplo, los siguientes comandos muestran cómo se puede añadir un archivo a este paquete de prueba: ``` $ mv extra_file Payload/*.app/ $ zip -r my_xcui_tests.ipa Payload/ ``` Al añadir un archivo a su paquete de prueba, puede esperar un comportamiento de interacción ligeramente diferente en AWS Device Farm en función del formato de carga. Si la carga utilizó la extensión de archivo ZIP, la AWS Device Farm descomprimirá automáticamente antes de la prueba y dejará los archivos descomprimidos en la ubicación con la *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* variable de entorno. (Esto significa que si agregas un archivo llamado *extra\$1file* a la raíz del archivo, como en el primer ejemplo, se ubicará allí *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file* durante la prueba). Para usar un ejemplo más práctico, si eres un usuario de Appium TestNG que quiere incluir un *testng.xml* archivo con tu prueba, puedes incluirlo en tu archivo usando el siguiente comando: ``` $ zip zip-with-dependencies.zip testng.xml ``` Luego, puede cambiar su comando de prueba en el modo de entorno personalizado por el siguiente: ``` 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 la extensión de carga del paquete de prueba no es ZIP (por ejemplo, un archivo APK, IPA o JAR), el propio archivo del paquete cargado se encuentra en. *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* Como siguen siendo archivos en formato de archivo, puede descomprimirlos para acceder a los archivos adicionales desde dentro. Por ejemplo, el siguiente comando descomprimirá el contenido del paquete de prueba (para los archivos APK, IPA o JAR) en el directorio: */tmp* ``` unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp ``` En el caso de un archivo APK o JAR, encontrarás los archivos adicionales descomprimidos en el */tmp* directorio (por ejemplo,). */tmp/extra\$1file* En el caso de un archivo IPA, como se explicó anteriormente, los archivos adicionales estarían en una ubicación ligeramente diferente dentro de la carpeta que termina en*.app*, que está dentro del directorio. *Payload* Por ejemplo, según el ejemplo anterior de IPA, el archivo se encontraría en la ubicación */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file* (se puede hacer referencia como). */tmp/Payload/\$1.app/extra\$1file* Para ver otras maneras de ampliar el conjunto de pruebas y optimizar las pruebas, consulte [Ampliación de los entornos de prueba personalizados en Device Farm](custom-test-environments-extending.md).