Connect(); 2016
Volume 31, numéro 12
Cet article a fait l'objet d'une traduction automatique.
Connect(); Test mobile - Mettre à l’échelle le test automatisé de votre application mobile avec Xamarin Test Cloud
Par Raczak de de ; 2016
Ces dernières années, il y a eu un changement spectaculaire dans la façon dont les équipes créent et livrer des logiciels. Lorsqu’il semblait une fois longue regroupant les exigences des processus qui garantisse la livraison d’un produit parfait avec la première version, vous savez désormais que l’apprentissage rapide couplée avec itération rapide est la clé du succès. Tout comme les modifications de penser, par conséquent, trop, les flux de travail. Cycles de développement durera plusieurs mois ou années suivies des phases d’assurance Qualité en cascade longue ne permettent pas la formation rapide. Boucles de commentaires doivent être réduits et les petites modifications mises en œuvre rapidement et publié aux utilisateurs. Pour déployer facilement, il doit être connu que le logiciel est en bon état à tout moment. Automatisation des tests rend cela possible.
Les tests automatisés vous permet de tester vos applications dans des modes qui permet de prendre plusieurs jours ou semaines. Au lieu d’attendre la fin d’un sprint composé des centaines de lignes de code nouveau, vous pouvez tester les petites modifications ajoutées à chaque validation. Cette surfaces test continu défauts dès qu’elles sont ajoutées et réduit le temps nécessaire pour un débogage. Et étant donné que le comportement de l’application est validé en permanence, vous êtes assuré à déployer pour les utilisateurs chaque fois que vous êtes prêt. Les tests automatisés rend possible un monde de découvrir des défauts et livrer un correctif dans le même jour. Mais l’écosystème mobile propose des défis uniques avec un paysage de périphérique mobile et les systèmes d’exploitation différents.
Xamarin Test Cloud est rapide et simple à l’échelle de vos tests automatisés avec un minimum de modifications à votre flux de travail existant. Offre plus de 400 configurations de périphérique unique, Test de Cloud vous permet de vérifier que le comportement de votre application sur les modèles de périphérique et de versions du système d’exploitation qui sont importantes pour les utilisateurs sans frais ou de frais de gestion qui est fourni avec la création et la gestion de votre propre laboratoire de périphérique. Dans la plupart des cas, vous pouvez exploiter cette valeur immense avec peu ou pas de modifications à votre code.
Cloud de test prend en charge la création de tests en c# (UITest), Ruby (Calabash) et Java (Appium et expresso). Dans la partie de modification de projet de cet article, je vous concentrer sur nos plus de framework de test plus demandée, Appium avec JUnit et passez en revue les modifications à apporter à votre projet pour exécuter vos tests existants dans le Cloud de Test. J’également jeter un œil de l’interface Web où vous allez examiner les résultats des tests et de résoudre les problèmes d’échec des tests. Les modifications spécifiques nécessaires peuvent changer au fil du temps. Vous trouverez la version la plus récente de ces instructions à bit.ly/2dhp2VQ.
Dans cet exemple, je suppose que les conditions préalables suivantes :
- Un compte de Test Cloud actif (Inscrivez-vous sur bit.ly/2e3YgTy)
- Un outil de ligne de commande installé (les instructions sont sur bit.ly/2dcrbXS)
- Un projet d’application Android native
- Une suite existante de Appium tests écrits en Java avec JUnit (au moins la version 4.9) conforme à Appium 1.5
- Système de génération Maven (au moins la version 3.3.9)
Modifications apportées au système de génération
Avant de commencer à l’aide de Cloud de Test, vous devez ajouter la dépendance pour les tâches de préparation des fichiers nécessaires soient disponibles pour votre build.
Ajoutez la dépendance de Cloud de Test pour inclure le Cloud de Test dans votre projet et vérifier ses pilotes améliorées Android et iOS sont disponibles au moment de la compilation, ajoutez la dépendance suivante au fichier pom.xml :
<dependency>
<groupId>com.xamarin.testcloud</groupId>
<artifactId>appium</artifactId>
<version>1.0</version>
</dependency>
Ajouter le profil télécharger ajouter le profil à partir de Figure 1 à votre pom.xml à l’intérieur de la <profiles>balise.</profiles> Si vous n’avez pas déjà un <profiles>section, créez-en un et ajouter le profil.</profiles> Ce profil compresse vos classes de test et toutes les dépendances dans le dossier cible/télécharger où ils peuvent être téléchargés à tester le Cloud.
Figure 1 profil de téléchargement de Cloud de Test
<profile>
<id>prepare-for-upload</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}
/upload/dependency-jars/</outputDirectory>
<useRepositoryLayout>true</useRepositoryLayout>
<copyPom>true</copyPom>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-pom-file</id>
<phase>package</phase>
<goals>
<goal>testResources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}
/upload/</outputDirectory>
<resources>
<resource>
<directory>
${project.basedir}
</directory>
<includes>
<include>pom.xml</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
<execution>
<id>copy-testclasses</id>
<phase>package</phase>
<goals>
<goal>testResources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}
/upload/test-classes</outputDirectory>
<resources>
<resource>
<directory>
${project.build.testOutputDirectory}
</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Modifications pour les Tests
Maintenant que votre build est configurée, vous devez modifier vos classes de test afin d’exploiter les extensions Java de Cloud de Test.
Ajoutez les importations à des Classes de Test importer les packages suivants dans vos classes de test :
import com.xamarin.testcloud.appium.Factory;
import com.xamarin.testcloud.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;
Instanciez le TestWatcher Insérez cette instanciation dans une de vos classes de test :
@Rule
public TestWatcher watcher = Factory.createWatcher();
Mettre à jour votre pilote déclarations , remplacez chaque déclaration de AndroidDriver<MobileElement> avec EnhancedAndroidDriver<MobileElement>, comme suit :</MobileElement> </MobileElement>
private static EnhancedAndroidDriver<MobileElement> driver;
Mettre à jour votre pilote instanciations remplacer chaque instanciation du votre pilote ce lignes sous la forme de :
Driver = new AndroidDriver<MobileElement>(url, capabilities);
devenir :
Driver = new EnhancedAndroidDriver<MobileElement>(url, capabilities);
Le pilote amélioré permet de « nommer « étapes de votre test à l’aide de driver.label("myTestStepLabel"). Cette méthode génère une étiquette d’étape de test et l’accompagne capture d’écran qui peuvent être consulté dans le rapport de test dans le Test de Cloud. Je vous recommande de l’appel d’étiquette dans la méthode @After, qui capture une capture d’écran de l’application dans son état final avant la fin du test. La capture d’écran va être effectuée, même si le test échoue, ce qui peut fournir des informations précieuses en raison de l’échec. Dans la pratique, cela pourrait ressembler à :
@After
public void tearDown(){
driver.label("Stopping app");
driver.quit();
}
Charger vers le Cloud de Test
Maintenant que votre projet est doté de toutes les conditions préalables, vous êtes prêt à préparer vos fichiers et exécuter une série de tests dans un Test de Cloud. Avant de poursuivre la procédure de téléchargement, il est judicieux d’essayer une série locale et assurez-vous que tout fonctionne comme prévu. Si vous avez besoin résoudre les modifications de configuration que vous venez de créer, il est beaucoup plus rapide pour le faire localement.
Pour compresser vos classes de test et toutes les dépendances dans le dossier cible/télécharger, exécutez la commande suivante :
mvn –DskipTests -P prepare-for-upload package
Vous voulez vérifier que le répertoire cible/télécharger existe maintenant dans le dossier racine de votre projet Vérifiez que vous êtes prêt à télécharger. S’il s’agit d’une nouvelle application dans le Cloud de Test, vous devez créer l’application dans le cadre de la série de tests. Suivez le flux pour créer une nouvelle série de tests pour sélectionner vos périphériques, de définir les préférences et de générer la commande, que vous devrez exécuter l’exécution. Pour cet exercice, je vous recommande de sélection d’un petit nombre de périphériques à partir de la catégorie de niveau 1 pour vos résultats seront prêts à être révisés rapidement. Copiez la commande générée et l’exécuter à la ligne de commande.
Une fois le téléchargement du fichier a été négocié et validé, les appareils sont configurés, votre application est installée et exécuter vos tests. Le Cloud de Test d’exploitation du modèle est basé sur la concurrence d’accès de périphérique, ou le nombre de périphériques physiques qui peuvent être utilisés en parallèle. Par exemple, un utilisateur avec cinq appareils simultanées permettre tester une application sur le X Nexus 5, Nexus 6P, Samsung Galaxy S5, Samsung Galaxy S6 et M8 HTC en même temps. Cette efficacité est un des principaux avantages du Cloud de Test, ce qui vous permet d’augmenter votre couverture pour la prise en charge des périphériques plus lors de l’ajout de peu à aucun délai d’attente supplémentaire.
L’outil de ligne de commande est diffusées sur la série de tests, les mises à jour l’état et de vous fournir un lien vers le rapport de test une fois l’exécution terminée. Suivez le lien de rapport de test fourni pour examiner les résultats.
Il existe trois niveaux de granularité avec laquelle vous pouvez afficher les résultats :
- Rapport vue d’ensemble.
- Grille de l’appareil.
- Rapport détaillé de périphérique.
J’aborderai chacun à son tour.
Le rapport vue d’ensemble la vue d’ensemble fournit des informations récapitulatives sur une série de tests y compris les détails de réussite/échec, statistiques d’échec par version du système d’exploitation, du constructeur et du facteur de forme et des détails sur l’exécution elle-même, y compris les configurations de périphérique ciblées et temps d’exécution total (voir Figure 2).
.png "Le rapport vue d’ensemble")
Figure 2 le rapport vue d’ensemble
Si votre série de tests génère des erreurs, vous souhaiterez probablement approfondir la question pour Explorer les causes premières et collecter des données pour le débogage. La grille de l’appareil est le niveau de détail suivant.
La grille de périphérique la grille de périphérique fournit un mécanisme très efficace pour la navigation parmi les résultats des tests étape par étape en même temps que les captures d’écran capturée à chaque étape. Échecs indiqués dans les étapes de test, vous pouvez rapidement passer à une étape qui a échoué et examiner l’état visuel de votre application sur chaque périphérique. Pour les ensembles de périphériques plus volumineux, vous pouvez filtrer les périphériques affichés à ceux qui n’a pas pu créer un champ pour l’inspection de nettoyage. Si la cause de l’échec n’est pas apparente à ce niveau de détail, vous pouvez descendre un niveau plus pour afficher les détails de l’appareil (voir Figure 3).
.png "Le rapport de grille du périphérique")
Figure 3 le rapport de grille du périphérique
Le rapport détaillé de périphérique l’affichage détaillé de l’appareil vous donne le même accès à la navigation de l’étape de test et des captures d’écran, mais fournit des détails supplémentaires spécifiques au périphérique sélectionné, notamment l’utilisation du processeur et de mémoire. Dans cette vue, vous pouvez également accéder les journaux d’appareil et la trace de la pile, les artefacts qui sera probablement le plus utile pour examiner un échec de test (voir Figure 4).
.png "Le rapport détaillé de périphérique")
Figure 4 le rapport détaillé de périphérique
À ce stade, j’ai suivi le flux de travail courants dans le Cloud de Test :
- Exécuter le test (manuellement ou via une intégration continue ou élément de configuration).
- Passez en revue les résultats.
- Récupérer les artefacts de débogage.
- Correctif.
Ensuite, j’aborderai quelques méthodes simples pour réfléchir à votre stratégie de ciblage de périphérique et l’optimisation de votre flux de travail de test de performances afin de suivre votre pipeline circuler rapidement.
Vous envisagez de la couverture du périphérique
Sélectionnez les périphériques de votre organisation prendra en charge et enfin tester est aussi important que le test lui-même. Bien qu’il existe de nombreuses sources de données d’agrégation et généralisée du marché qui peuvent vous aider à vos idées dans cette zone, la source plus percutantes est données d’utilisation de votre propre base de l’utilisateur. L’exception à cela, bien sûr, est une application en interne distribuée uniquement à un ensemble d’appareils connus et gérés. Pour externe et les applications consommateur et les applications internes distribuées sous la stratégie apporter à votre propre appareil (AVPA), les données d’utilisation sont votre meilleure source.
De nombreux outils de marché peuvent vous aider à recueillir la vision de périphériques qu'utilise votre audience. Il s’agit du jeu de données à partir de laquelle vous pouvez extrapoler votre liste de périphériques pris en charge. La méthodologie exacte que permet de déterminer quels périphériques pour prendre en charge à partir de la liste d’agrégats est à vous et votre organisation. Dans la plupart des cas, il ne sont pas judicieux de prendre en charge tous les périphériques à partir de vos données d’utilisation, comme cela peut devenir fastidieux et coûteux. Vous pouvez décider de couvrir autant de périphériques constituent un certain pourcentage de votre utilisateur de base. Ou vous pouvez décider de raisonner en termes de nombre d’utilisateurs et de prendre en charge des périphériques autant que nécessaire pour conserver des appareils moins de 500 utilisateurs couverts. Si vous avez une application de commerce électronique, vous pouvez à fournir les données d’utilisation des données de transaction, garantissant des périphériques qui représentent la dépense le plus élevée et les transactions plus fréquentes sont traitées. Là encore, l’approche spécifique de développement de votre liste de prise en charge de périphérique doit être basée sur les besoins et les objectifs de votre entreprise.
N’oubliez pas que le marché mobile déplace rapidement. Cela signifie que, dans l’ordre de votre liste de prise en charge précis et explicite, vous devez inspecter les données d’utilisation régulièrement. Regardez les signaux du marché qui peuvent supposer qu’il est judicieux de vérifier les données, telles que le déploiement d’un nouveau modèle de l’appareil ou le système d’exploitation.
Optimisation de votre Pipeline de test
Le meilleur moyen d’extraire la valeur d’automation de test consiste à tester régulièrement. Cela réduit le temps et les coûts associés à la résolution des bogues et garantit que le pipeline de déploiement reste clair. Mais équipes et les opérations de mise à l’échelle latence peut s’accumuler dans le pipeline et la productivité des développeurs peut diminuer. Examinons à maintenir le pipeline clair et améliorer la productivité.
Tous les Tests sont différent comme projets croître au fil du temps, leurs suites de tests prennent plus de temps. Il existe un point d’inflexion d’exécution la suite de tests après qu’une modification simple devient difficile et fastidieuse, entraînant souvent mauvaises habitudes telles qu’est complètement ignoré les tests. Vous pouvez prévalent sur en pensant à des chemins critiques de votre application dès le début, autrement dit, ce flux ou expériences dans votre application doivent absolument fonctionne ? À l’aide de l’exemple d’application de commerce électronique précédent, cela peut signifier les utilisateurs peuvent parcourir les produits, ajouter des produits au panier et extraire. Il est moins important que les utilisateurs peuvent définir leurs préférences de notification. Avec cette structure en place, il devient beaucoup plus pratique d’exécuter des tests sur chaque émission ou même chaque validation. Au lieu d’exécuter la suite de tests complète pour les petites modifications, vous pouvez exécuter uniquement ceux qui font partie des chemins critiques. Comment exactement, vous effectuez cette limite dépend de l’infrastructure de test que vous utilisez.
Les périphériques à droite au bon moment chaque push vers une branche de la fonctionnalité de test peut être idéale du point de vue de la qualité, cela devient rapidement coûteuse pour de grandes équipes, en particulier ceux qui prennent en charge de nombreuses configurations de périphérique différent. Vous pouvez réduire la surcharge ici en appliquant une stratégie progressive pour votre périphérique cible sur ces séries de tests. Une build d’une branche de test doit-elle être testés sur chaque périphérique que vous prenez en charge ? La réponse est non probable. Au lieu de cela, vous pouvez sélectionner un nombre raisonnable de périphériques qui équilibre des tests efficaces avec un délai plus court. Pour une version de pré-production à partir de l’élément de configuration, un échantillon des modèles de périphériques les plus utilisés et les versions du système d’exploitation à partir de votre liste de prise en charge des périphériques offre un niveau de couverture précieux sans augmenter votre temps de génération au-delà d’une heure. Pour un développeur de test à partir d’une station de travail locale, le test sur un ou deux périphériques peut suffire.
Voici quelques exemples de façons de considérer la configuration de votre flux de travail de test. Le point plus large est consacrer du temps à la question si votre flux de pipeline est optimal. Même si vous avez répondu à cette question avant tout, comme avec tout ce que vous le faites, il est toujours judicieux d’examiner et adapter régulièrement.
Pour résumer
Dans cet article, vous avez vu comment facilement, vous pouvez migrer à partir de l’exécution de vos tests sur un seul périphérique local ou un simulateur pour exploiter la puissance de centaines de configurations de périphérique à l’aide de Xamarin Test Cloud. J’ai également abordé quelques stratégies pour organiser votre flux de travail de test et l’extraction de la valeur de vos ressources de test. Si vous n’utilisez pas déjà le Cloud de Test, vous pouvez vous inscrire pour une évaluation gratuite sur bit.ly/2e3YgTy pour commencer à utiliser vos projets dès aujourd'hui.
Justin Raczakest responsable de programme senior chez Microsoft, il dirige le service d’automation de test mobile. Bien qu’il a rejoint Microsoft que récemment, il a axé sur les tests automatisés et son rôle dans le développement continu pour les trois dernières années. Il peut être contacté à justin.raczak@microsoft.com.
Merci à l'expert technique Microsoft suivant d'avoir relu cet article : Simon Søndergaard
Simon Søndergaard est ingénieur logiciel chez Microsoft.