Migración de pruebas de un entorno de pruebas estándar a un entorno de pruebas personalizado - AWS Device Farm

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

Migración de pruebas de un entorno de pruebas estándar a un entorno de pruebas personalizado

La siguiente guía explica cómo cambiar de un modo de ejecución de pruebas estándar a un modo de ejecución personalizado. 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.

  2. 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 vídeo en directo.

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, vídeos y otros artefactos de resultados de forma individual para cada prueba. Sin embargo, esto aumenta constantemente el tiempo total de ejecución de las end-to-end pruebas, ya que, por parte del servicio, se producen alteraciones en el procesamiento previo y posterior de las pruebas y en los resultados.

    Por el contrario, el modo de ejecución personalizado no analiza el paquete de pruebas, lo que significa que las pruebas o los resultados se producen sin preprocesamiento y con un mínimo de posprocesamiento. 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.

  2. 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.

  3. Vídeo en directo y registro: los modos de ejecución estándar y personalizado le proporcionan vídeos y registros para sus pruebas. Sin embargo, en el modo estándar, solo obtendrá el vídeo 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 vídeo y de los registros de sus pruebas desde el lado del cliente. Además, podrá descargar el vídeo y otros artefactos al final de las pruebas.

  4. Obsolación: los siguientes tipos de pruebas quedarán obsoletos a finales de diciembre de 2023 en el modo de ejecución estándar:

    • Appium (todos los idiomas)

    • Calabash

    • XCTest

    • UI Automation

    • UI Automator

    • Pruebas web

    • Built-in: Explorer

    Una vez que estén en desuso, no podrá utilizar estos marcos en modo estándar. En su lugar, puede utilizar el modo personalizado para los tipos de prueba enumerados anteriormente.

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 AWS Management Console y ábrala en https://console.aws.amazon.com/devicefarm/.

  2. Seleccione su proyecto y, a continuación, inicie una nueva ejecución de automatización.

  3. 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.

  4. 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. 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.

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 preciso realizar cambios para mover las pruebas de iOS XCUITest a un entorno de pruebas personalizado.