Un bon testeur doté de capacités de réflexion critique ne peut pas être complètement remplacé par l'automatisation. Le rendre plus efficace est facile. Avec cette conviction, je me suis rendu dans notre service d'essais avec une nouvelle tâche, où nous, avec Pavel, avons pris en charge sa mise en œuvre. Voyons ce qu'il en est advenu.En collaboration avec nos partenaires, nous développons, testons et soutenons activement une famille d'applications pour différentes plates-formes: Android, iOS, Windows. Les applications se développent activement, avec lesquelles le volume de tests augmente, principalement la régression.
Nous avons décidé d'essayer de faciliter et d'accélérer les tests en automatisant la plupart des scénarios de test. Dans le même temps, nous ne voulions pas abandonner complètement le processus de test manuel, mais plutôt le modifier.
La mise en œuvre de cette approche a commencé avec l'une des applications Android, dont je vais parler. L'article sera intéressant pour les auteurs débutants de tests d'interface utilisateur, principalement pour les applications mobiles, ainsi que pour ceux qui souhaitent automatiser le processus de test manuel dans une certaine mesure.
C'est parti!
Point de départ
Pour chaque plate-forme, nous en avons plusieurs similaires qui exécutent le même processus métier principal des applications. Cependant, ils diffèrent les uns des autres par un ensemble de petites fonctionnalités auxiliaires, sont réalisées sous différentes marques en fonction du client (à cause de quoi l'interface change d'une application à l'autre), et le processus métier peut être personnalisé en ajoutant des étapes supplémentaires.
Nous sommes confrontés à certains problèmes qui doivent être résolus. Des difficultés similaires peuvent survenir dans une situation différente de la nôtre. Par exemple, si vous avez une application volumineuse avec une logique métier difficile, envahie par de nombreux tests.
Problème n ° 1: beaucoup de tests de régression
Les ensembles de scénarios de test pour chaque application sont simultanément similaires et différents les uns des autres, ce qui contribue à une augmentation de la régression et la rend encore plus ennuyeuse. Cependant, vous devez tester toutes les applications individuellement.
Étant donné que les applications déjà en cours d'exécution sont régulièrement mises à jour et qu'il n'y en aura qu'à l'avenir, le nombre total de tests augmentera inexorablement.
Problème numéro 2: vous devez tester sur toutes les versions du système d'exploitation mobile
Une exigence importante est la disponibilité de nos applications mobiles sur une large gamme de versions de système d'exploitation. Par exemple, dans le cas d'Android au moment de la rédaction, ce sont des niveaux d'API de 17 à 28.
Idéalement, nous devrions tester sur chaque version d'Android, ce qui complique encore notre régression. Le processus de test direct de l'application acquiert une routine supplémentaire multipliée par le nombre d'appareils: installer et exécuter l'application, la ramener à son état d'origine après chaque test individuel, la suppression. Dans le même temps, la maintenance de votre propre batterie de périphériques nécessite beaucoup de travail.
Solution: intégrer l'automatisation dans le processus de test manuel
Une tâche typique de l'automatisation des tests consiste à automatiser les tests de régression. Nous voulons donc améliorer l'efficacité du processus de test aujourd'hui et prévenir les conséquences possibles de la croissance de demain.
Dans le même temps, nous sommes bien conscients qu'il est impossible et inutile d'éradiquer complètement les tests manuels par automatisation. La pensée critique et l'œil humain sont difficiles à remplacer par quelque chose. Il y a un bon article à ce sujet sur le blog de Michael Bolton, The
End of Manual Testing (ou
traduction d'Anna Rodionova).
Nous avons pensé qu'il serait utile d'avoir un ensemble de tests automatisés qui couvrent les parties stables de l'application, et à l'avenir d'écrire des tests pour les bogues trouvés et les nouvelles fonctionnalités. Dans le même temps, nous voulons associer les autotests aux suites de tests existantes dans notre système de gestion des tests (nous utilisons TestRail), et permettre également aux testeurs d'exécuter facilement des autotests sur des appareils physiques cloud (nous avons choisi Firebase Test Lab comme infrastructure cloud).
Pour commencer et essayer, nous avons pris une de nos applications Android. Il était important de considérer que si la solution réussissait, ses meilleures pratiques pourraient être appliquées à nos autres applications, y compris sur d'autres plateformes.
Ce que nous voulons obtenir en conséquence:
- Automatisation des tests de régression.
- Intégration avec le système de gestion des tests.
- Possibilité de démarrage manuel paramétré des autotests sur les appareils cloud.
- La possibilité de réutiliser la solution à l'avenir.
Ensuite, je parlerai séparément de la mise en œuvre de chacun de ces points avec une petite immersion dans la composante technique.
Schéma général d'implémentation de la solution
Mais d'abord, un aperçu général de ce que nous avons obtenu:
Les tests automatiques s'exécutent de deux manières:
- De CI après fusion ou extraction de la demande au maître.
- Testez manuellement depuis l'interface Web de Jenkins Job.
Dans le cas d'un lancement manuel, le testeur doit soit indiquer le numéro de la build correspondante, soit télécharger 2 APK depuis l'ordinateur: avec l'application et avec les tests. Cette méthode est nécessaire pour que vous puissiez exécuter les tests nécessaires à tout moment sur tous les appareils disponibles.
Pendant les tests, leurs résultats sont envoyés à TestRail. Cela se produit de la même manière que si le testeur effectuait le test manuellement et saisissait les résultats d'une manière qui lui était familière.
Ainsi, nous avons abandonné le processus établi de tests manuels, mais y avons ajouté une automatisation, qui effectue un ensemble spécifique de tests. Le testeur «détecte» ce qui a été fait automatiquement et:
- voit le résultat des cas de test sur chaque appareil qui ont été sélectionnés;
- peut vérifier manuellement n'importe quel cas de test;
- effectue des cas de test qui ne sont pas encore automatisés ou qui ne peuvent être optimisés pour aucune raison;
- prend la décision finale sur le test en cours.
Passons maintenant à la description promise de l'implémentation.
1. Tests automatiques
Les outils
Nous avons utilisé 3 outils pour interagir avec l'interface utilisateur:
- Espresso
- Barista.
- UI Automator.
L'outil principal et celui avec lequel nous avons commencé est Espresso. Le principal argument en faveur de son choix était le fait qu'Espresso vous permet de tester en utilisant la méthode de la boîte blanche, donnant accès à Android Instrumentation. Le code de test se trouve dans le même projet que le code d'application.
L'accès au code de l'application Android est nécessaire pour appeler ses méthodes dans les tests. Nous pouvons préparer notre demande pour un test spécifique à l'avance en l'exécutant dans le bon état. Sinon, nous devons atteindre cet état via l'interface, ce qui prive les tests d'atomicité, les rendant dépendants les uns des autres, et mange simplement beaucoup de temps.
Pendant la mise en œuvre, un autre outil a été ajouté à Espresso - UI Automator. Les deux cadres font partie de
la bibliothèque de prise en charge des tests Android de
Google . À l'aide de l'UI Automator, nous pouvons interagir avec diverses boîtes de dialogue système ou, par exemple, Notification Drawer.
Et le dernier de notre arsenal était le framework Barista. Il s'agit d'une enveloppe autour d'Espresso, vous permettant d'économiser le code passe-partout lors de la mise en œuvre d'actions utilisateur courantes.
En gardant à l'esprit le désir de pouvoir réutiliser la solution dans d'autres applications, il est important de noter que les outils listés sont destinés exclusivement aux applications Android. Si vous n'avez pas besoin d'accéder au code de l'application en cours de test, vous préférerez probablement utiliser un framework différent. Par exemple, le très populaire Appium aujourd'hui. Bien que vous puissiez également essayer d'accéder au code de l'application à l'aide de portes dérobées, c'est un bon
article sur le blog Badoo. Le choix vous appartient.
Implémentation
Comme modèle de conception, nous avons choisi Testing Robots, proposé par Jake Wharton dans le
rapport éponyme. L'idée de cette approche est similaire au modèle de conception d'objet de page commun utilisé dans les tests de systèmes Web. Le langage de programmation est Java.
Pour chaque fragment indépendant de l'application, une classe de robot spéciale est créée dans laquelle la logique métier est implémentée. L'interaction avec chaque élément du fragment est décrite dans une méthode distincte. De plus, toutes les assertions effectuées dans ce fragment sont également décrites ici.
Prenons un exemple simple. Le fragment décrit contient plusieurs champs pour entrer des données et un bouton d'action:
Le code de la fonctionnalité de connexion se teste:
Ici, nous vérifions le scénario positif lorsque les données d'authentification saisies sont correctes. Les données elles-mêmes sont soumises aux tests d'entrée ou les valeurs par défaut sont utilisées. Ainsi, le testeur a la possibilité de paramétrer en termes de données de test.
Cette structure donne tout d'abord une excellente lisibilité aux tests lorsque l'ensemble du script est divisé en principales étapes d'exécution. Nous avons également beaucoup aimé l'idée de transférer des assertions aux méthodes individuelles du robot correspondant. Assert devient la même étape, sans rompre la chaîne générale, et vos tests ne savent toujours rien de l'application.
Dans le rapport susmentionné, Jake Wharton donne une implémentation dans Kotlin, où elle est finie. Nous l'avons déjà essayé sur un autre projet et nous l'avons vraiment aimé.
2. Intégration avec le système de gestion des tests
Avant l'introduction de l'automatisation, nous avons effectué tous nos tests dans le système de gestion des tests TestRail. La bonne nouvelle était qu'il existe une assez bonne
API TestRail , avec laquelle nous avons pu connecter des cas de test déjà établis dans le système avec des autotests.
Pendant le test à l'aide de JUnit
RunListener , divers événements sont interceptés, tels que
testRunStarted ,
testFailure ,
testFinished , dans lesquels nous envoyons les résultats à TestRail. Si vous utilisez AndroidJUnitRunner, alors il doit informer de votre RunListener d'une certaine manière, décrite dans la
documentation officielle
.Vous devez également communiquer avec diverses entités TestRail par leur ID. Ainsi, pour connecter le test au
@CaseId test correspondant, nous avons créé une annotation simple
@CaseId , dont l'utilisation est illustrée dans l'exemple d'implémentation du test ci-dessus.
Code pour implémenter l'annotation elle-même:
Il ne reste plus qu'à obtenir sa valeur au bon endroit à partir de la description:
3. Démarrage manuel des autotests sur les appareils cloud
Paramétrage de démarrage dans le travail Jenkins
Pour organiser le démarrage manuel des autotests, nous utilisons le
travail Jenkins de style libre . Cette option a été choisie parce que l'entreprise avait déjà une certaine expérience avec un travail similaire avec Jenkins Job dans d'autres domaines, en particulier avec les ingénieurs DevOps, qu'ils ont volontiers partagés.
Jenkins Job exécute un script basé sur les données transférées depuis l'interface Web. Ainsi, le paramétrage des cycles de test est implémenté. Dans notre cas, le script Bash lance le lancement des tests sur les appareils cloud Firebase.
Le paramétrage comprend:
- Sélectionner l'APK souhaité en spécifiant le numéro de la build correspondante ou en les téléchargeant manuellement.
- Saisissez toutes sortes de données de test.
- Saisie de données personnalisées supplémentaires pour TestRail.
- Sélectionnez les périphériques physiques basés sur le cloud sur lesquels les tests seront exécutés dans la liste disponible dans le laboratoire de test Firebase.
- La sélection des kits de test à effectuer.
Regardons une partie de la page Web de notre travail Jenkins en utilisant un exemple d'interface de sélection de périphérique et de suites de tests:
Chaque élément où vous pouvez entrer ou sélectionner des données est implémenté par des plugins Jenkins spéciaux. Par exemple, l'interface de sélection de périphérique est réalisée à l'aide du
plugin Active Choices . En utilisant un script groovy de Firebase, une liste des périphériques disponibles est obtenue, qui est ensuite affichée sous la forme souhaitée sur la page Web.
Une fois que toutes les données nécessaires ont été entrées, le script correspondant est lancé, dont la progression peut être observée dans la section Sortie de la console:
À partir de là, le testeur qui a lancé le test peut accéder à TestRail ou à la console Firebase en utilisant les URL reçues, qui contiennent de nombreuses informations utiles sur l'exécution de tests sur chacun des périphériques sélectionnés.
Matrice de test finale dans Firebase Test Lab
La matrice des périphériques dans Firebase contient la distribution des tests par les périphériques sur lesquels ils ont été exécutés:
Pour chaque appareil, vous pouvez consulter le journal complet, la vidéo du test, divers indicateurs de performance. De plus, vous pouvez accéder à tous les fichiers qui auraient pu être créés lors de l'exécution des tests. Nous l'utilisons pour télécharger des indicateurs de couverture de test depuis l'appareil.
Nous avons choisi Firebase, car nous avons déjà utilisé ce service pour résoudre d'autres problèmes et nous sommes satisfaits de la politique de prix. Si vous rencontrez 30 minutes de temps pur pour les tests par jour, vous n'avez pas besoin de payer du tout. Cela peut être une raison supplémentaire pour laquelle il est important de pouvoir exécuter uniquement certains tests.
Vous préférerez peut-être une infrastructure cloud différente qui s'intègre également bien à votre processus de test.
4. Réutilisation
Comment utiliser tout cela à l'avenir? Du point de vue de la base de code, cette solution n'est applicable qu'aux applications Android. Par exemple, pendant l'implémentation, nous avons ajouté les classes d'assistance
EspressoExtensions et
UiAutomatorExtensions , où nous encapsulons diverses options d'interaction avec l'interface et attendons que les éléments soient prêts. Cela inclut également la classe RunListener, qui est responsable de l'intégration avec TestRail. Nous les avons déjà placés dans des modules séparés et les utilisons pour automatiser d'autres applications.
Si nous parlons d'autres plates-formes, l'expérience acquise peut être très utile pour construire et mettre en œuvre des processus similaires. Nous le faisons activement dans le domaine iOS et pensons à Windows.
Conclusion
Il existe de nombreuses options pour implémenter et utiliser l'automatisation des tests. Nous sommes d'avis que l'automatisation est avant tout un outil conçu pour faciliter le processus traditionnel de tests "humains", et non pour l'éradiquer.