Get best of the week

Pourquoi sommes-nous passés à Selenide en écrivant plus de 200 nouveaux autotests en cours de route

Bonjour, je suis un outil d'automatisation des tests pour l'un des projets d'une grande entreprise. Dans cet article, je vais vous expliquer pourquoi nous avons décidé de passer de Serenity à Selenide. Nous avons une tâche à grande échelle, et bien que le changement de la pile technologique ait pris un certain temps, plus tard, il s'est plus que payé en accélérant la rédaction des tests et en effectuant une régression.

image

Avant d'arriver au point, un peu sur la tâche dans son ensemble.

Malheureusement, je ne peux pas divulguer les détails du projet selon les termes de la NDA. En fait, ce sont quelques-uns des outils pour un centre d'appels d'une grande entreprise - acheminement des appels, séparation des opérateurs par thème d'appels, etc. dans une belle interface utilisateur. L'interface, soit dit en passant, est fournie non seulement aux opérateurs, mais également aux contrôleurs qui écoutent et évaluent les appels sélectionnés. Surtout, il existe un système de différenciation des droits et un panneau d'administration qui vous permet de configurer toutes les fonctions intégrées - de la téléphonie aux classements disponibles pour les contrôleurs.

L'ensemble du volume de fonctionnalités est divisé en plusieurs projets: téléphonie, panneau utilisateur et panneau d'administration. Les trois projets sont en développement actif. Et ma tâche est d'automatiser les tests sur ces projets au sens large du terme.

Pour certaines des fonctionnalités développées, des tests automatiques existaient déjà, mais le spécialiste qui les a développés a quitté l'entreprise, il est donc apparu un certain devoir technique d'automatiser les tests. Au total, une cinquantaine d'autotests ont été rédigés, mais la grande majorité d'entre eux sont complètement obsolètes, car la fonctionnalité est allée très loin. Par conséquent, au départ, la tâche consistait à mettre à jour tout cela.

Mise à jour de la pile


Les autotests existants ont été écrits à l'aide de la bibliothèque Serenity. En fait, ils ont dû être réécrits à nouveau, il était donc inutile de conserver les développements existants. La bibliothèque elle-même m'était familière, mais personnellement, je ne la considère pas comme un outil optimal. Donc, comprenant la quantité de travail, j'ai décidé de passer à Selenide dès le début.

Selenide est un outil assez populaire pour lequel il existe de nombreuses solutions toutes faites. Certaines des fonctionnalités de Selenide sont également disponibles pour les analogues - Atlas, Selenium, HTMLElements, etc. Mais chacun à sa manière ne nous convenait pas.

Le sélénium est la base du séléniure. Mais pour nous, c'est un niveau trop bas. Cela n'a aucun sens de réinventer la roue quand il existe une solution toute faite.

Atlas est apparu récemment. Il est suffisamment brut et ne prend pas en charge Groovy.
HtmlElements est bon pour tout le monde, mais est obsolète et non pris en charge. Il existe également JDI, mais il présente des problèmes de multithreading.

Serenity, précédemment utilisé sur le projet, était trop lourd. Tout y est tellement interconnecté que pour ajouter un nouveau gestionnaire d'événements ou un intercepteur, une douzaine de classes ont dû être réécrites (et cela n'a pas abouti à chaque fois). De plus, Surenity n'a pas pu connecter Allure, la norme réelle de l'industrie et de l'entreprise pour générer des rapports de test.

Dans Selenide, du point de vue de l'automatisation, tout est beaucoup plus simple. Par exemple, il n'est pas nécessaire de décrire séparément les étapes - attacher aux méthodes, etc. Étant donné qu'il prend en charge Allure prêt à l'emploi, toutes les actions liées à l'utilisation des éléments Web tombent automatiquement dans le rapport de test.

Bien sûr, Selenide prend en charge PageFactory, Page Object et PageElement. Cela rend le code plus lisible. De plus, il existe des attentes internes pour le moment où l'élément apparaît - il n'est pas nécessaire d'indiquer explicitement que vous devez arrêter le test pendant quelques secondes avant de continuer (le délai d'expiration est défini dans les configurations). Les attentes explicites existent séparément - vous pouvez explicitement redéfinir le délai d'expiration des éléments nécessaires à chaque étape du test.

Idéalement, Selenide dispose d'un ensemble de différentes méthodes prêtes à l'emploi.

Étant donné que j'étais seul dans l'équipe au début de la transition de Serenity à Selenide, l'avantage supplémentaire était que j'avais déjà une expérience suffisante avec Selenide et Groovy, afin que je puisse rapidement mettre en œuvre des solutions toutes faites et par la suite dépenser moins d'efforts pour les soutenir.

La transition a été presque indolore. Nous avons implémenté Selenide en collaboration avec Allure. Allure vous permet de créer des rapports lisibles et même quelque peu beaux, qui montrent clairement quelles étapes ont échoué et avec quelle erreur. Prêt à l'emploi, vous pouvez joindre des captures d'écran de pages Web aux rapports. Nous ajoutons même une vidéo de la course, le code source de la page, les logs du navigateur et du pilote web.

La migration des tests existants a nécessité un minimum d'effort. Ce que Serenity a, ce que Selenide a, ce sont des PageObjects avec des annotations @FindBy. Serenity et Allure utilisent les mêmes annotations Step. J'ai dû mettre à jour le modèle, l'imbrication des éléments les uns dans les autres, l'ordre d'appeler les étapes de test. Certains tests ont été complètement supprimés, certains ont été réécrits à partir de zéro, et quelque part une simple mise à jour des localisateurs était suffisante. En fait, le déplacement est devenu une tâche triviale à laquelle la plupart des automatiseurs d'interface utilisateur doivent faire face lors de la conception d'une application Web.

Mise à jour du test


Après avoir mis à jour la pile technologique, ils ont repris les tests eux-mêmes. Soit dit en passant, une partie de ce travail a déjà été achevée dans le cadre de la transition vers une nouvelle pile.

Compte tenu de l'arriéré accumulé de la fonctionnalité des projets, ils devraient quand même être réécrits - c'est plus rentable dans le temps que de rechercher des incohérences dans un tel volume de code.

Au total, environ 220 autotests ont été écrits en ce moment pour le front-end et le back-end. L'accent sera mis sur le backend dans le développement ultérieur, car la plupart des éléments fonctionnels du front-end sont déjà impliqués dans les autotests. Dans le même temps, il est en constante évolution, de sorte que plus il y a de tests sur le front-end, plus il faut consacrer de forces à leur soutien.

Ayant des ressources de temps infinies, nous essayons toujours de diriger les efforts vers ce qui nous permettra de réduire les coûts de main-d'œuvre pour le support, en couvrant autant que possible les fonctionnalités. Désormais, la couverture des autotests dépasse légèrement 50%.


Les tests réécrits sur Selenide sont devenus plus compacts et précis en raison de la réutilisation répétée du code - tout cela grâce aux capacités de la bibliothèque elle-même.

En mettant à jour les tests, nous avons pris en compte qu'ils doivent être exécutés simultanément (dans plusieurs threads). Les tests étaient auparavant exécutés sur des machines virtuelles distinctes. Mais la transition vers Selenide nous a permis de paralléliser encore plus la tâche, en les exécutant dans plusieurs threads.

En gros, la transition vers un nouveau cadre lui-même a augmenté le nombre de threads lancés simultanément de 3 à 8, et l'optimisation ultérieure des tests - jusqu'à 50. En conséquence, 100 tests d'interface utilisateur s'exécutent en seulement 10 minutes.


Le multithreading, soit dit en passant, est un autre avantage pour lequel nous avons choisi Selenide. Ce n'est pas une grosse couche de passe-partout, vous écrivez un minimum de code. Il n'y a pas d'écriture superflue dont Selenium a besoin pour préparer le projet au lancement. Tout ce dont vous avez besoin pour exécuter les tests est déjà prêt à l'emploi.

Parallèlement à la mise à jour et à l'écriture de nouveaux tests, j'ai organisé une formation pour les gars du département des tests, les aidant à passer du test manuel au test complet, de sorte qu'il soit arrivé dans le régiment d'automatisation du projet. La pile technologique utilisée a un seuil d'entrée inférieur et Internet regorge de documentation et de vidéos sur la façon de résoudre certains problèmes. Un mois plus tard, j'ai été rejoint par quelques testeurs qui pouvaient effectuer des tâches liées à l'automatisation.

Déjà toute une équipe, nous avons pu optimiser les tests de régression. Si auparavant la régression a pris 7 jours à l'équipe, maintenant les mêmes tâches sont effectuées pendant 4 jours, soit Nous avons réduit le temps des tests de près de 2 fois.

Il existe de nombreux scénarios à venir qui doivent encore être automatisés. Nous avons automatisé les tests de fumée presque complètement, mais nous sommes maintenant passés aux scénarios de test les plus exigeants en main-d'œuvre. Cela contribuera à réduire davantage les temps de recours.

Naturellement, nous développerons une infrastructure de test. Prévoit d'introduire un serveur Mock. Maintenant, nous testons tout sur un vrai stand, générant des données de test. Cela prend du temps et des ressources. Le faux serveur vous permettra d'exécuter des autotests sans cette préparation préalable (nous avons écrit sur le faux serveur pour un autre projet ).

Nous prévoyons également d'introduire un enregistrement d'autotest afin que vous puissiez écrire un script TestRail basé sur une pièce obtenue en cliquant directement sur l'interface dans le navigateur. En sortie, on obtient une sorte de prototype d'autotest.

Auteur de l'article: Yuri Kudryavtsev, spécialiste des tests de logiciels automatisés.

PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous à nos pages sur VK , FB , Instagram ou la chaîne Telegram pour en savoir plus sur toutes nos publications et autres actualités Maxilect.

More articles:


All Articles