Partager via


Préparation des tests Appium pour le chargement

Important

La mise hors service de Visual Studio App Center est prévue pour le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à sa mise hors service complète, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager la migration.

En savoir plus sur les chronologies et les alternatives de support.

Les étapes de préparation d’une application et de sa suite de tests pour le chargement varient en fonction de l’infrastructure de test. Ce guide explique comment préparer des tests Appium à l’aide de Java avec JUnit pour le chargement dans App Center. Pour obtenir des conseils sur la création de tests Appium, consultez la documentation Appium.

Notez les limitations suivantes pour la prise en charge d’Appium :

Notes

Le contexte WebView, le pilote web Chrome et les tests de navigateur Chrome avec browserName fonctionnalité sont pris en charge !

  • Aucune prise en charge de TestNG (seuls les tests JUnit sont pris en charge).
  • Aucune prise en charge d’Android 4.2 ou version antérieure. Aucune prise en charge du pilote UIAutomator déprécié.
  • Aucune prise en charge d’iOS 9.2.1 ou version antérieure. Aucune prise en charge du pilote iOS UIAutomation déconseillé.
  • Aucune prise en charge pour JUnit @Category attribute. (Peut utiliser Include/Exclude à la place)
  • La version de Maven doit être au moins 3.3.9.
  • La version actuelle d’Appium est 1.22.0. Il est régulièrement mis à jour avec les nouvelles versions.
  • JUnit 4.9 - 4.12 est pris en charge ; nous ne prenons pas en charge JUnit 5.
  • Les tests doivent cibler précisément une application. (MobileCapabilityType.FULL_RESET est pris en charge)

Notes

Dans certains cas, les tests peuvent toujours fonctionner dans App Center si vous utilisez des fonctionnalités ou des outils non pris en charge. Toutefois, cette fonctionnalité non prise en charge ne fait pas l’objet d’une assurance qualité dans les futures mises à jour et peut s’interrompre sans avertissement.

Prérequis

Les tests seront exécutés à l’aide de Maven Surefire, ce qui nécessite que les tests suivent certaines conventions d’affectation de noms :

"**/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".

Avant de tenter de charger dans App Center Test, assurez-vous que l’exécution de tests localement sur votre ordinateur à l’aide de Maven fonctionne :

➜  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 vous ne parvenez pas à exécuter les tests à l’aide de la ligne de commande localement, les tests ne fonctionnent pas non plus dans App Center Test.

1. Modifications apportées au système de génération

Étape 1 - Ajouter une dépendance

Vous devez ajouter une dépendance pour les extensions de test Appium :

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

Ce code garantit que les pilotes Android et iOS améliorés sont disponibles au moment de la compilation. Les pilotes améliorés sont fournis principalement pour activer la label fonctionnalité. Pour plus d’informations sur la label fonctionnalité, consultez Étape 4.

Étape 2 - Ajouter un profil de chargement

Copiez cet extrait de code dans votre pom.xml dans la <profiles> balise . S’il n’y a pas <profiles> de section dans votre pom, faites-en une. Le profil, lorsqu’il est activé, empaquet vos classes de test et toutes les dépendances dans le target/upload dossier, prêt à être chargé dans Test.

2. Modifications apportées aux tests

Étape 1 - Ajouter des importations

Importez ces packages dans vos classes de test :

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

Étape 2 : instancier testWatcher

Insérez cette déclaration dans chacune de vos classes de test :

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

Étape 3 : Mettre à jour votre déclaration de pilote

Remplacez votre déclaration de par AndroidDriver<MobileElement>EnhancedAndroidDriver<MobileElement> ou IOSDriver<MobileElement> par EnhancedIOSDriver<MobileElement>

    private static EnhancedAndroidDriver<MobileElement> driver;

Étape 4 : Mettre à jour vos instanciations de pilote

Remplacez la façon dont vous instanciez votre pilote, telle que les lignes sous la forme :

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

... sont remplacés par :

    driver = Factory.createAndroidDriver(url, capabilities);

L’utilisation de ces pilotes vous permet toujours d’exécuter vos tests localement sans modifications supplémentaires, mais vous permet d'« étiqueter » les étapes de test dans votre exécution de test à l’aide driver.label("text")de . Le texte et une capture d’écran de l’appareil seront visibles dans le rapport de test dans App Center.

Il est recommandé d’appeler driver.label dans la @After méthode , qui prend une capture d’écran de l’état final de l’application. Un exemple @After de méthode pour un test peut ressembler à ce code :

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

3. Charger dans le test App Center

Étapes de chargement d’un test :

  1. Générez une commande de chargement de test App Center à l’aide des instructions de démarrage d’une série de tests.

  2. Emballez vos classes de test et toutes les dépendances dans le target/upload dossier :

    mvn -DskipTests -P prepare-for-upload package
    
  3. Exécutez la commande 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. Résolution des problèmes de performances

Les tests sur les appareils dans App Center s’exécutent légèrement plus lentement que sur un appareil local. Normalement, une exécution plus lente est compensée par la disponibilité d’un plus grand nombre d’appareils, ce qui permet des exécutions de tests parallèles.

Il existe trois sources main de séries de tests plus lentes : la ré-signature, la réinstallation et les tâches réseau.

Re-signature (sur iOS)

Avant d’être installée sur l’appareil iOS, votre application passe par un processus appelé re-signature. Ce processus est nécessaire pour que le profil d’approvisionnement corresponde à l’appareil dans le cloud. La nouvelle signature prend un certain temps, généralement environ 1 à 2 minutes. Rarement, la ré-signature entraîne également une dégradation des performances, car les applications ré-signées sont mises en cache. Le processus chronophage ne s’exécute qu’une seule fois par binaire.

Si votre configuration de livraison continue met à jour la version IPA avant de générer et de tester, le fichier binaire sera différent pour chaque test et la pénalité de re-signature se produira plus souvent.

La réinstallation

Sur un cloud d’appareils partagés, il est important pour nous de garantir que les appareils sont nettoyés entre chaque test. Le client suivant qui utilise l’appareil peut être une personne d’un autre organization. Dans App Center Test, l’application est automatiquement désinstallée une fois votre série de tests terminée.

Il est possible d’omettre MobileCapabilityType.FULL_RESET et de définir sur MobileCapabilityType.NO_RESETtrue pour accélérer l’exécution des tests. Pour plus d’informations, consultez Réinitialiser les stratégies .

Tâches réseau

Les tâches de réseau local sont plus rapides, car le serveur est plus proche et plus dédié à l’hôte distant.