Preparación de pruebas de Appium para la carga

Artigo
03/18/2024

Importante

Visual Studio App Center está programado para la retirada el 31 de marzo de 2025. Aunque puede seguir usando Visual Studio App Center hasta que se retire por completo, hay varias alternativas recomendadas a las que puede considerar la posibilidad de migrar.

Obtenga más información sobre las escalas de tiempo de soporte técnico y las alternativas.

Los pasos para preparar una aplicación y su conjunto de pruebas para la carga varían en función del marco de pruebas. En esta guía se explica cómo preparar las pruebas de Appium mediante Java con JUnit para la carga en App Center. Para obtener instrucciones sobre la creación de pruebas de Appium, consulte la documentación de Appium.

Tenga en cuenta las siguientes limitaciones para la compatibilidad con Appium:

Nota

El contexto de WebView, el controlador web chrome y las pruebas del explorador Chrome con browserName funcionalidad son compatibles.

No se admite TestNG (solo se admiten pruebas JUnit).
No se admite Android 4.2 o anterior. No se admite el controlador UIAutomator en desuso.
No se admite iOS 9.2.1 o anterior. No se admite el controlador UIAutomation iOS en desuso.
No se admite JUnit @Category attribute. (En su lugar, puede usar Include/Exclude )
La versión de Maven debe ser al menos 3.3.9.
La versión actual de Appium es la 1.22.0. Se actualiza normalmente con nuevas versiones.
Se admite JUnit 4.9 - 4.12; no se admite JUnit 5.
Las pruebas deben tener como destino precisamente una aplicación. (MobileCapabilityType.FULL_RESET se admite)

Nota

En algunos casos, las pruebas pueden seguir funcionando en App Center si se usan herramientas o características no admitidas. Sin embargo, esa funcionalidad no admitida no es qa'd en futuras actualizaciones y podría interrumpirse sin advertencia.

Requisitos previos

Las pruebas se ejecutarán mediante Maven Surefire, que requiere que las pruebas sigan ciertas convenciones de nomenclatura:

"**/Test*.java" - includes all of its subdirectories and all Java filenames that start with "Test".
"**/*Test.java" - includes all of its subdirectories and all Java filenames that end with "Test".
"**/*Tests.java" - includes all of its subdirectories and all Java filenames that end with "Tests".
"**/*TestCase.java" - includes all of its subdirectories and all Java filenames that end with "TestCase".

Antes de intentar cargar en App Center Test, asegúrese de que la ejecución de pruebas localmente en el equipo con Maven funciona:

➜  AppiumTest git:(main) ✗ mvn verify
...
Running MainTest
started: SimpleTest (MainTest)
Setting up capabilities
failed
finished
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.728 sec <<< FAILURE!
SimpleTest(MainTest)  Time elapsed: 0.594 sec  <<< ERROR!
...

Si no puede ejecutar las pruebas mediante la línea de comandos localmente, las pruebas tampoco funcionarán en App Center Test.

1. Cambios en el sistema de compilación

Paso 1: Agregar dependencia

Deberá agregar una dependencia para las extensiones de prueba de Appium:

<dependency>
    <groupId>com.microsoft.appcenter</groupId>
    <artifactId>appium-test-extension</artifactId>
    <version>1.6</version>
</dependency>

Este código garantizará que los controladores mejorados de Android e iOS estén disponibles en tiempo de compilación. Los controladores mejorados se proporcionan principalmente para habilitar la label característica. Consulte el paso 4 para obtener más información sobre la label característica.

Paso 2: Agregar perfil de carga

Copie este fragmento de código en pom.xml en la <profiles> etiqueta . Si no hay ninguna <profiles> sección en el pomo, haz una. El perfil, cuando se activa, empaquetará las clases de prueba y todas las dependencias en la target/upload carpeta, listas para cargarse en Test.

2. Cambios en las pruebas

Paso 1: Agregar importaciones

Importe estos paquetes en las clases de prueba:

import com.microsoft.appcenter.appium.Factory;
import com.microsoft.appcenter.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;

Paso 2: Creación de una instancia del TestWatcher

Inserte esta declaración en cada una de las clases de prueba:

    @Rule
    public TestWatcher watcher = Factory.createWatcher();

Paso 3: Actualización de la declaración del controlador

Reemplace la declaración de AndroidDriver<MobileElement> por EnhancedAndroidDriver<MobileElement> o IOSDriver<MobileElement> por EnhancedIOSDriver<MobileElement>

    private static EnhancedAndroidDriver<MobileElement> driver;

Paso 4: Actualización de las instancias del controlador

Reemplace la forma en que cree una instancia del controlador, de modo que las líneas en forma de:

    driver = new AndroidDriver<MobileElement>(url, capabilities);

... se cambian a:

    driver = Factory.createAndroidDriver(url, capabilities);

El uso de estos controladores todavía le permitirá ejecutar las pruebas localmente sin modificaciones adicionales, pero le permite "etiquetar" los pasos de prueba en la ejecución de pruebas mediante driver.label("text"). El texto y una captura de pantalla del dispositivo estarán visibles en el informe de prueba de App Center.

Se recomienda llamar driver.label al @After método , que toma una captura de pantalla del estado final de la aplicación. Un método de ejemplo @After para una prueba podría ser similar a este código:

    @After
    public void TearDown(){
        driver.label("Stopping App");
        driver.quit();
    }

3. Cargar en la prueba de App Center

Pasos para cargar una prueba:

Genere un comando de carga de pruebas de App Center con las instrucciones para iniciar una ejecución de prueba.
Empaquetar las clases de prueba y todas las dependencias en la target/upload carpeta :
```
mvn -DskipTests -P prepare-for-upload package
```

Ejecute el comando upload:

appcenter test run appium --app "APP_ID" --devices "DEVICE_SET_ID" --app-path PATH_TO_FILE.apk  --test-series "main" --locale "en_US" --build-dir target/upload

4. Solución de problemas de rendimiento

Las pruebas en dispositivos de App Center se ejecutarán ligeramente más lentamente que en un dispositivo local. Normalmente, la ejecución más lenta se supera al tener más dispositivos disponibles, lo que permite ejecuciones de pruebas paralelas.

Hay tres orígenes principales de ejecuciones de pruebas más lentas: volver a firmar, reinstalar y tareas de red.

Volver a firmar (en iOS)

Antes de instalarse en el dispositivo iOS, la aplicación pasa por un proceso denominado volver a firmar. Este proceso es necesario para que el perfil de aprovisionamiento coincida con el dispositivo en la nube. La nueva firma tarda algún tiempo, normalmente de aproximadamente 1 a 2 minutos. En raras ocasiones, la nueva firma también provoca una degradación del rendimiento porque las aplicaciones firmadas se almacenan en caché. El proceso que consume mucho tiempo solo se ejecutará una vez por binario.

Si la configuración de entrega continua actualiza la versión de IPA antes de compilar y probar, el binario será diferente para cada prueba y la penalización de nueva firma se producirá con más frecuencia.

Reinstalación

En una nube de dispositivos compartidos, es importante garantizar que los dispositivos se limpien entre cada prueba. El siguiente cliente que usa el dispositivo puede ser alguien de otra organización. En App Center Test, la aplicación se desinstala automáticamente después de la finalización de la ejecución de la prueba.

Es posible omitir MobileCapabilityType.FULL_RESET y establecer MobileCapabilityType.NO_RESET en true para acelerar la ejecución de pruebas. Consulte Reset Strategies (Estrategias de restablecimiento ) para obtener más información.

Tareas de red

Las tareas de red local son más rápidas porque el servidor está más cercano y dedicado al host remoto.

Compartir por