View a markdown version of this page

Migration des tests d'un environnement de test standard vers un environnement de test personnalisé - AWS Device Farm

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration des tests d'un environnement de test standard vers un environnement de test personnalisé

Vous pouvez passer d'un mode d'exécution de test standard à un mode d'exécution personnalisé dans AWS Device Farm. La migration implique principalement deux formes d'exécution différentes :

  1. Mode standard  : ce mode d'exécution des tests est principalement conçu pour fournir aux clients des rapports granulaires et un environnement entièrement géré.

  2. Mode personnalisé  : ce mode d'exécution des tests est conçu pour différents cas d'utilisation nécessitant des exécutions de tests plus rapides, la possibilité de modifier et d'atteindre la parité avec leur environnement local, ainsi que la diffusion vidéo en direct.

Pour plus d'informations sur les modes standard et personnalisé de Device Farm, consultez Environnements de test dans AWS Device Farm etEnvironnements de test personnalisés dans AWS Device Farm.

Considérations relatives à la migration

Cette section répertorie certains des principaux cas d'utilisation à prendre en compte lors de la migration vers le mode personnalisé :

  1. Rapidité  : en mode d'exécution standard, Device Farm analyse les métadonnées des tests que vous avez empaquetés et chargés à l'aide des instructions d'empaquetage de votre framework particulier. L'analyse permet de détecter le nombre de tests contenus dans votre package. Device Farm exécute ensuite chaque test séparément et présente les journaux, les vidéos et les autres artefacts de résultats individuellement pour chaque test. Cependant, cela augmente régulièrement le temps total d'exécution des tests de bout en bout, car il y a le pré-traitement et le post-traitement des tests et des artefacts de résultats du côté du service.

    En revanche, le mode d'exécution personnalisé n'analyse pas votre package de test ; cela signifie qu'il n'y a pas de prétraitement et un post-traitement minimal pour les tests ou les artefacts de résultats. Cela se traduit par des temps d'exécution totaux de bout en bout proches de votre configuration locale. Les tests sont exécutés dans le même format que s'ils étaient exécutés sur votre ou vos machines locales. Les résultats des tests sont les mêmes que ceux que vous obtenez localement et peuvent être téléchargés à la fin de l'exécution de la tâche.

  2. Personnalisation ou flexibilité  : le mode d'exécution standard analyse votre package de test pour détecter le nombre de tests, puis exécute chaque test séparément. Notez que rien ne garantit que les tests seront exécutés dans l'ordre que vous avez spécifié. Par conséquent, les tests nécessitant une séquence d'exécution particulière peuvent ne pas fonctionner comme prévu. De plus, il n'est pas possible de personnaliser l'environnement de la machine hôte ou de transmettre les fichiers de configuration qui peuvent être nécessaires pour exécuter vos tests d'une certaine manière.

    En revanche, le mode personnalisé vous permet de configurer l'environnement de la machine hôte, notamment d'installer des logiciels supplémentaires, de transmettre des filtres à vos tests, de transmettre des fichiers de configuration et de contrôler la configuration de l'exécution des tests. Pour ce faire, il utilise un fichier yaml (également appelé fichier testspec) que vous pouvez modifier en y ajoutant des commandes shell. Ce fichier yaml est converti en un script shell qui est exécuté sur la machine hôte de test. Vous pouvez enregistrer plusieurs fichiers yaml et en choisir un de manière dynamique selon vos besoins lorsque vous planifiez une exécution.

  3. Vidéo en direct et journalisation  : les modes d'exécution standard et personnalisés vous fournissent des vidéos et des journaux pour vos tests. Cependant, en mode standard, vous n'obtenez la vidéo et les journaux prédéfinis de vos tests qu'une fois ceux-ci terminés.

    En revanche, le mode personnalisé vous permet de diffuser en direct la vidéo et les journaux côté client de vos tests. De plus, vous pouvez télécharger la vidéo et d'autres artefacts à la fin du ou des tests.

Astuce

Si votre cas d'utilisation implique au moins l'un des facteurs ci-dessus, nous vous recommandons vivement de passer au mode d'exécution personnalisé.

Étapes de la migration

Pour passer du mode standard au mode personnalisé, procédez comme suit :

  1. Connectez-vous Console de gestion AWS et ouvrez la console Device Farm à l'adresse https://console.aws.amazon.com/devicefarm/.

  2. Choisissez votre projet, puis lancez une nouvelle opération d'automatisation.

  3. Téléchargez votre application (ou sélectionnezweb app), choisissez votre type de framework de test, téléchargez votre package de test, puis, sous le Choose your execution environment paramètre, choisissez l'option pourRun your test in a custom environment.

  4. Par défaut, l'exemple de fichier de spécifications de test de Device Farm s'affiche pour que vous puissiez le consulter et le modifier. Ce fichier d'exemple peut être utilisé comme point de départ pour essayer vos tests en mode environnement personnalisé. Ensuite, une fois que vous avez vérifié que vos tests fonctionnent correctement depuis la console, vous pouvez modifier toutes vos intégrations d'API, de CLI et de pipeline avec Device Farm pour utiliser ce fichier de spécifications de test comme paramètre lors de la planification des essais. Pour plus d'informations sur la manière d'ajouter un fichier de spécifications de test en tant que paramètre pour vos exécutions, consultez la section des testSpecArn paramètres de l'ScheduleRunAPI dans notre guide des API.

Cadre Appium

Dans un environnement de test personnalisé, Device Farm n'insère ni ne remplace aucune fonctionnalité Appium dans vos tests du framework Appium. Vous devez spécifier les fonctionnalités Appium de votre test dans le fichier YAML de spécification de test ou dans votre code de test.

Instrumentation Android

Vous n'avez pas besoin d'effectuer de modifications pour déplacer vos tests d'instrumentation Android vers un environnement de test personnalisé.

XCUITest iOS

Vous n'avez pas besoin d'effectuer de modifications pour déplacer vos tests XCUITest iOS vers un environnement de test personnalisé.