Avec cet article, nous ouvrons une série de publications sur la façon dont nous avons automatisé le processus de test manuel d'un grand système d'information dans l'un des principaux projets de LANIT et sur les résultats.

La première partie - organisationnelle et managériale - devrait être utile principalement à ceux qui sont chargés de tester l'automatisation et de créer de tels systèmes dans leur ensemble. Les chefs de projet, chefs de groupe et propriétaires de services de tests fonctionnels et automatiques, tous soucieux de la question «comment construire un test de bout en bout rentable de leur système informatique», trouveront ici un plan et une méthodologie spécifiques.

Source

Partie 1 - Organisationnelle et managériale. Pourquoi avons-nous eu besoin d'automatisation. Organisation du processus de développement et de gestion. Organisation d'utilisation

Au départ, il y avait au départ un système d'information vaste et complexe (nous l'appellerons le «Système») avec de nombreux scénarios d'affaires complexes, longs et interconnectés. Tous les scripts ont été testés en tant qu'E2E via des interfaces Web exclusivement en mode manuel (il y avait plus d'un millier et demi de ces scénarios de la priorité la plus critique uniquement). De plus, tous ces scénarios devaient être exécutés au moins une fois lors de la régression de chaque nouvelle version ou correctif avant la prochaine mise à jour du déploiement du produit.

À un certain moment, quand il est devenu complètement insupportable de cliquer sur la souris en mode manuel, ils ont décidé d'automatiser tout cela. C'est ce qu'ils ont fait à travers le développement d'un service séparé basé sur java + sélénium + séléniure + sélénoïde, qui est également appelé "cadre de test" ou simplement "Autotests" .

Historiquement, le code du framework de test a été développé par deux équipes. Tout d'abord, la première équipe a créé un prototype avec quelques dizaines de scénarios. Ensuite, la deuxième équipe pendant un an a mis à l'échelle le prototype à la fois en largeur (nombre de tests) et en profondeur (des modèles de codage et de mise en œuvre typiques ont été introduits).

Je suis l'équipe et le chef d'équipe de la deuxième équipe, qui a adopté le cadre prototype pour la mise à l'échelle (en mai 2018).

Au moment d'écrire ces lignes, la tâche définie il y a un an était terminée et l'équipe de projet a bénéficié d'un service d' automatisation stable. Ce n'est pas en vain que j'ai insisté sur le service , car initialement la tâche n'était pas définie comme le développement d'une application, mais comme la fourniture d'un service-service pour tester l'automatisation à un groupe de «tests fonctionnels». Et cette fonctionnalité a par la suite grandement influencé l'organisation du développement et l'architecture du cadre de test.

Résumé

Environ 1 500 scénarios de test ont été automatisés: dans chaque test, de 200 à 2 000 opérations utilisateur.

La capacité totale du service est jusqu'à 60 navigateurs fonctionnant simultanément, et ce n'est pas la limite (le nombre peut être multiplié par 5 en raison de machines virtuelles).
La durée totale d'une régression complète ne dépasse pas 3 heures et le test PreQA est inférieur à une heure.

Une large gamme de fonctionnalités a été implémentée:

• utilisation locale (exécution en temps réel) et à distance (via des plans Bamboo);
• limiter la composition des tests en cours par filtre;
• un rapport détaillé avec les résultats de chaque étape du scénario de test (via le framework Allure);
• télécharger et télécharger des fichiers depuis / vers le navigateur, puis vérifier les résultats de leur traitement en termes de format et de contenu des fichiers;
• comptabilité et contrôle de la nature asynchrone de l'interface angulaire. Y compris le contrôle des requêtes bloquées (requête en attente) entre les services Angular et REST;
• contrôle des journaux du navigateur;
• enregistrement de test vidéo;
• suppression de l'instantané de la page au moment de la "chute" du test;
• transmission d'événements en ELK;
• beaucoup plus sur les petites choses ...

Pourquoi tout cela était-il nécessaire?

Au début, le but du système était assez simple et clair.

Imaginez que vous disposez d'un grand système de registre pour gérer une vaste gamme de documents et leur cycle de vie, qui fournissent quelques centaines de processus métier. De plus, il y a des millions de personnes, des fournisseurs - des dizaines de milliers, des services - des milliers, des documents complexes, y compris le cadre et le modèle, et les processus métier sont fournis de centaines de façons différentes ...

Tout cela se transforme en mille cinq cents scénarios de test, et ce n'est que la priorité la plus élevée et seulement positive.

Dans le processus d'automatisation, diverses nuances ont été révélées qui nécessitaient l'utilisation de diverses solutions.

Par exemple, un script peut contenir jusqu'à des centaines d'opérations distinctes, y compris des opérations intéressantes telles que: «Téléchargez un fichier EXCEL avec des données et vérifiez que le système traite chaque enregistrement du fichier» (pour résoudre ce problème, il a fallu plusieurs étapes pour préparer les données, puis vérifier le résultat du chargement dans Système). Et maintenant, nous ajoutons la restriction de la réutilisation des données de test: les données de test pour la réussite de la plupart des scénarios de test doivent être «fraîches» et non utilisées auparavant dans des scénarios similaires (pendant les tests, l'état des données dans le système change, par conséquent, elles ne peuvent pas être réutilisées pour les mêmes contrôles).

Source

À un moment donné, les tests manuels du système dans le cadre de la régression ont cessé de sembler rentables et assez rapides, et ils ont décidé de l'automatiser via l'interface utilisateur Web.

En d'autres termes, le groupe de tests fonctionnels ouvre la «page», sélectionne le «groupe de tests», appuie sur le bouton «exécuter» (nous avons utilisé Bamboo). Ensuite, les autotests (ci-après dénommés autotests. Désignez le produit créé pour les tests en général) émulent automatiquement les actions des utilisateurs du système via le navigateur («appuyez» sur les boutons nécessaires, entrez des valeurs dans les champs, etc.), une fois terminé, affichez un rapport détaillé sur tous étapes et actions terminées et résultats de la vérification (correspondance de la réaction attendue du système avec son comportement réel).

Total, le but des autotests est l'automatisation des tests E2E manuels. Il s'agit d'un système «externe» qui ne participe pas au processus de développement du système sous test et n'est en aucun cas lié aux tests unitaires ou d'intégration utilisés par les développeurs.

Buts

Il était nécessaire de réduire considérablement les coûts de main-d'œuvre pour effectuer des tests End-2-End et d'augmenter la vitesse des régressions complètes et réduites en termes de volume.

Les tâches

La tâche principale du développement a été formulée très simplement - automatiser au cours des 6 prochains mois 1000 scénarios de test de la plus haute priorité.

Le nombre prévu d'actions de test de base variait de 100 à 300, ce qui nous a donné environ 200 mille méthodes de test avec 10 à 20 lignes de code, sans tenir compte des classes générales et auxiliaires d'aides, des fournisseurs de données et des modèles de données.

Ainsi, il s'est avéré que, compte tenu des contraintes de temps (130 jours ouvrables), il était nécessaire de faire au moins 10 tests par jour et en même temps de s'assurer de la pertinence des autotests mis en œuvre en tenant compte des changements intervenus dans le Système (le Système se développe activement).

Selon des estimations d'experts, le travail requis pour développer un autotest était de 4 à 8 heures. Nous avons donc au moins une équipe de 5 personnes (en réalité, au plus fort du développement des autotests, l'équipe comptait plus de 10 ingénieurs en automatisation).

Les tâches à résoudre étaient également compréhensibles.

• Configurer les processus et la commande:
• définir le processus d'interaction avec le client (groupe de test fonctionnel), fixer le format de description du cas de test comme entrée pour l'équipe d'automatisation;
• organiser le processus de développement et de maintenance;
• former une équipe.
  
• Développez des autotests avec les fonctionnalités suivantes:
• cliquer automatiquement sur les boutons du navigateur avec une vérification préalable de la présence d'éléments et des informations nécessaires sur la page;
• fournir du travail avec des éléments complexes tels que Yandex.Map;
• assurer le chargement des fichiers générés automatiquement dans le système, assurer le téléchargement des fichiers du système avec vérification de leur format et de leur contenu.
• Fournissez un enregistrement à partir des captures d'écran du navigateur, des vidéos et des journaux internes.
• Pour offrir la possibilité de s'intégrer à des systèmes externes comme un serveur de messagerie, le système de suivi des tâches (JIRA) permet de vérifier les processus d'intégration entre le système testé et les systèmes externes.
• Fournissez un rapport documenté sur toutes les mesures prises, y compris un affichage des valeurs saisies et vérifiées, ainsi que tous les investissements nécessaires.
• Effectuez des tests dans le volume requis en mode parallèle.
• Déployez des autotests dans l'infrastructure existante.
• Affinez les scripts de test déjà automatisés du concept de cible consonantique (vitesse de raffinement - environ 50 tests par sprint hebdomadaire).

Comme je l'ai mentionné dans l'introduction, au début, nous avions un prototype MVP fonctionnel mis en œuvre par une autre équipe, qui devait être augmenté de 20 tests à 1000, ajoutant de nouvelles fonctionnalités en cours de route, et garantissant une évolutivité et une flexibilité acceptables pour apporter des modifications.

La présence d'un prototype fonctionnel en plus à l'entrée nous a donné une pile technologique, qui comprenait: Java SE8, JUnit4, Selenium + Selenide + Selenoid, Bamboo en tant que «coureur» de tests et «constructeur» de rapports Allure. Comme le prototype fonctionnait bien et offrait les fonctionnalités de base nécessaires, nous avons décidé de ne pas modifier la pile technologique, mais de nous concentrer sur le développement de l'évolutivité de la solution, l'augmentation de la stabilité et le développement des fonctionnalités requises manquantes.

Fondamentalement, tout semblait réalisable et optimiste. De plus, nous avons complètement fait face aux tâches à un moment donné.

Ce qui suit décrit les aspects technologiques et de processus individuels du développement des tests automatiques.

Description des autotests. Histoires d'utilisateurs et fonctionnalités

Source

Les autotests implémentent l'ensemble d'histoires utilisateur suivant dans le contexte de leur utilisation par le groupe de test:

• automatisation manuelle des tests;
• régression complète automatique;
• contrôle qualité des assemblages de la chaîne CI \ CD.

Les détails de mise en œuvre et les décisions architecturales seront discutés dans la Partie 2 - Technique. Architecture et pile technique. Détails de mise en œuvre et surprises techniques .

Tests automatiques et manuels (User stories)

En tant que testeur, je souhaite effectuer le test E2E cible, qui sera réalisé sans ma participation directe (en mode automatique) et me fournira un rapport détaillé dans le cadre des étapes franchies, y compris les données saisies et les résultats obtenus, ainsi que:

• Il devrait être possible de sélectionner différents peuplements cibles avant de commencer le test;
• devrait être capable de gérer la composition des tests en cours de tous les implémentés;
• à la fin du test, vous devez obtenir une vidéo du test à partir de l'écran du navigateur;
• lorsque le test se bloque, vous devez obtenir une capture d'écran de la fenêtre du navigateur actif.

Régression complète automatique

En tant que groupe de test, je souhaite effectuer tous les tests tous les soirs sur un banc de test particulier en mode automatique, y compris toutes les fonctionnalités du "Test manuel automatique".

Contrôle qualité des assemblages dans la chaîne CI \ CD

En tant que groupe de test, je souhaite effectuer des tests automatiques des mises à jour déployées du système sur un stand pré-QA dédié avant de mettre à jour les stands de l'étape de test fonctionnel cible, qui ont ensuite été utilisés pour les tests fonctionnels.

Fonctionnalités de base implémentées

Source

Voici un bref ensemble des principales fonctions implémentées des tests automatiques, qui se sont avérées essentielles ou simplement utiles. Les détails de la mise en œuvre de certaines fonctions intéressantes seront dans la deuxième partie de l'article.

Utilisation locale et à distance

La fonction offrait deux options pour exécuter les autotests - local et distant.

En mode local, le testeur a exécuté l'autotest requis sur son lieu de travail et a pu observer en même temps ce qui se passait dans le navigateur. Le lancement s'est fait à travers le "triangle vert" dans IntelliJ IIDEA -). La fonction était très utile au début du projet pour le débogage et les démonstrations, mais maintenant elle n'est utilisée que par les développeurs d'autotests.

En mode distant, le testeur démarre l'autotest en utilisant l'interface du plan Bamboo avec les paramètres de la composition des tests en cours, un stand et quelques autres paramètres.

La fonction a été implémentée à l'aide de la variable d'environnement MODE = REMOTE | LOCAL, selon le navigateur Web local ou distant qui a été initialisé dans le cloud Selenoid .

Limiter la composition des tests en cours par filtre

La fonction permet de limiter la composition des tests en cours en mode d'utilisation à distance pour la commodité des utilisateurs et de réduire le temps de test. Une filtration en deux étapes est utilisée. La première étape bloque l'exécution des tests basés sur la variable FILTER_BLOCK et sert principalement à exclure de grands groupes de tests de l'exécution. La deuxième étape «ignore» uniquement les tests qui correspondent à la variable FILTER.

La valeur des filtres est spécifiée comme un ensemble d'expressions régulières REGEXP1, ..., REGEXPN, appliquées par le principe de "OU".

Lors du démarrage en mode manuel, il a été demandé au testeur de définir une variable d'environnement spéciale en tant que liste d'expressions régulières applicables à l'annotation spéciale @ Filter (valeur de chaîne), qui annotait toutes les méthodes de test dans les classes de test. Pour chaque test, cette annotation est unique et est construite sur la base d'un ensemble de balises séparées par un trait de soulignement. Nous utilisons le modèle minimum suivant SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}, où la balise DEFAULT est pour les tests inclus dans la régression nocturne automatique.

La fonction est implémentée via une extension personnalisée de la classe org.junit.runners.BlockJUnit4ClassRunner (les détails seront donnés dans la partie 2-1 de la suite de cet article)

Documenter le rapport avec les résultats pour toutes les étapes

Les résultats du test sont affichés pour toutes les actions de test (étapes) avec toutes les informations requises disponibles dans Allure Framework. Les énumérer n'a pas de sens. Il y a suffisamment d'informations sur le site officiel et sur Internet dans son ensemble. Il n'y a eu aucune surprise en utilisant le framework Allure, et en général je le recommande pour son utilisation.

Les principales fonctions utilisées sont:

• affichage de chaque étape de test (le nom de l'étape correspond à son nom dans la spécification de test - script de test);
• afficher les paramètres d'étape sous une forme lisible par l'homme (grâce à la mise en œuvre requise de la méthode toString de toutes les valeurs transmises);
• Joindre des captures d'écran, des vidéos et divers fichiers supplémentaires au rapport;
• classification des tests par types et sous-systèmes, ainsi que la liaison de l'autotest avec la spécification de test dans le système de gestion de lien de test Test Link grâce à l'utilisation d'annotations spécialisées.

Téléchargez et téléchargez des fichiers depuis / vers le navigateur avec leur vérification et analyse ultérieures

Travailler avec des fichiers est un aspect extrêmement important des scripts de test. Il était nécessaire de fournir à la fois le téléchargement de divers fichiers et le téléchargement.

Le téléchargement de fichiers impliquait tout d'abord le chargement de fichiers EXCEL générés dynamiquement dans le système conformément au contexte d'exécution du script de test. Le téléchargement a été implémenté à l'aide de méthodes standard fournies par les outils de sélénium.

Le téléchargement de fichiers impliquait le téléchargement de fichiers en appuyant sur le «bouton» du navigateur vers un répertoire local avec le «transfert» ultérieur de ce fichier vers le serveur sur lequel les AutoTests ont été exécutés (le serveur sur lequel l'agent Bamboo distant a été installé). De plus, ce fichier a été analysé et analysé en termes de format et de contenu. Les principaux types de fichiers étaient les fichiers EXCEL et PDF.

L'implémentation de cette fonction s'est avérée être une tâche non triviale, principalement en raison du manque de capacités de gestion de fichiers standard: pour le moment, la fonction n'est implémentée que pour le navigateur Chrome via la page de service «chrome: // Downloads /».

Je vais vous parler en détail des détails d'implémentation dans la deuxième partie.

Comptabilité et contrôle de la nature asynchrone de l'interface angulaire. Contrôle des demandes en attente entre les services Angular et REST

Étant donné que l'objet de nos tests était basé sur Angular, nous avons dû apprendre à "lutter" avec la nature asynchrone du frontend et des timeouts.

En général, en plus de org.openqa.selenium.support.ui.FluentWait, nous utilisons une méthode d'attente spécialement conçue qui vérifie via Javascript les interactions «incomplètes» avec les services REST frontaux, et sur la base de ce délai d'attente dynamique, les tests obtiennent des informations sur le suivi puis attendez encore un peu.

Du point de vue de la fonctionnalité, nous avons pu réduire considérablement le temps nécessaire pour terminer les tests en raison du rejet des attentes statiques où il n'y a aucun moyen de déterminer différemment la fin de l'opération. De plus, cela nous a permis de définir des services REST «suspendus» avec des problèmes de performances. Par exemple, ils ont intercepté un service REST pour lequel le nombre d'enregistrements affichés sur la page a été défini sur 10 000 éléments.

Des informations sur le service REST «gelé» avec tous les paramètres de son appel, pour lesquels le test «tombe» pour des raisons d'infrastructure, sont ajoutées aux résultats du test interrompu et sont également diffusées en tant qu'événement dans ELK. Cela vous permet de transférer immédiatement les problèmes identifiés aux équipes de développement appropriées du système.

Contrôle du journal du navigateur

La fonction de contrôle du journal du navigateur a été ajoutée pour contrôler les erreurs sur les pages de niveau SÉVÈRE afin de recevoir des informations supplémentaires pour les tests abandonnés, par exemple, pour surveiller les erreurs comme "... Échec du chargement de la ressource: le serveur a répondu avec un état de 500 (erreur interne du serveur)".

La composition des erreurs de traitement de page dans le navigateur est appliquée à chaque résultat de test et est également déchargée en tant qu'événements dans l'ELK.

Enregistrement vidéo du test et suppression de l'instantané de la page au point de "chute" du test

Les fonctions sont implémentées pour faciliter le diagnostic et l'analyse des tests abandonnés.

L'enregistrement vidéo est activé séparément pour le mode d'exécution de test à distance sélectionné. La vidéo est jointe en tant que pièce jointe aux résultats dans le rapport Allure.
Une capture d'écran est prise automatiquement lorsque le test se bloque et les résultats sont également appliqués au rapport Allure.

Passer des événements à ELK

La fonction d'envoi d'événements à ELK est implémentée pour permettre une analyse statistique du comportement général des AutoTests et de la stabilité de l'objet de test. À l'heure actuelle, des événements ont été envoyés pour terminer les tests avec les résultats et la durée, ainsi que des erreurs de navigateur de niveau SÉVÈRE et des services REST fixes de «gel».

Organisation de développement

Source

Équipe de développement

Nous avions donc besoin d'au moins 5 développeurs. Ajoutez une autre personne pour compenser les absences non planifiées. Nous en avons 6. Plus un chef d'équipe, qui est responsable de la fonctionnalité transversale et de la révision du code.

Ainsi, nous avons dû prendre 6 développeurs Java (en réalité, au plus fort du développement des autotests, l'équipe a dépassé 10 ingénieurs en automatisation).

Compte tenu de l'état général du marché et d'une pile technologique assez simple, l'équipe était principalement composée de stagiaires, la plupart d'entre eux soit juste diplômés des universités, soit en dernière année. En fait, nous recherchions des personnes ayant une connaissance de base de Java. La préférence a été donnée aux spécialistes des tests manuels qui souhaiteraient devenir programmeurs et aux candidats motivés ayant une expérience (insignifiante) en développement qui, à l'avenir, souhaitaient devenir programmeurs.

, ( 2 – . . ).

, , . CodeRush . .

. , , «» .

() . code review merge request ( GitLab). code review «» ( ) .

– . / , .

ode review , , () - , . ode review .

code review , .

: , , , , . , , , / .

« », - -. -.

, . sprint retrospective event.

- ( ) , stakeholder .

– . , , . , - . .

- ( , . .), . () , « » / « » ( , , ).

- - ( : - – , - , — , ). , - / : « - ( )».

- , - (-) - («» ). «» - - « X» ( , -).

, . master, -. - - code review.

, – , .

:

(+) ;
(+) ;
(+) «» ;
(-) ();
(-) hotfix .

.

• MASTER.
• .
• FEATURE .
• , « » rebase.
• Gitlab merge request . merge request- :
• — «Jira»;
• — Bamboo.

GateKeeper ( )

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

La deuxième partie - la partie technique - est principalement axée sur les chefs de file des groupes d'automatisation, les tests d'interface utilisateur de bout en bout et l'automatisation des tests. Ils y trouveront des recettes spécifiques pour l'organisation architecturale du code et du déploiement, qui soutiennent le développement en masse parallèle de grands groupes de tests face à la variabilité constante des spécifications de test. De plus, vous pouvez trouver dans la deuxième partie la liste complète des fonctions nécessaires aux tests d'interface utilisateur avec quelques détails d'implémentation. Et une liste de surprises que vous pourriez également rencontrer.