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. # 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).