Disposition de test? Facile

Cet article a été préparé par Anna anna-che et Ksenia KseMish .

L'une des raisons pour lesquelles nous nous sommes activement lancés dans les mises en page de tests était, comme d'habitude, un râteau. Nous avons marché sur un bug qui a commencé à apparaître après la prochaine mise à jour de Chrome. Il s'est avéré que dans les 3 heures, les utilisateurs ne pouvaient pas transférer des fonds du compte via le compte personnel de notre banque Internet. Et tout cela parce que dans la nouvelle version du navigateur, la forme de transfert de fonds d'un compte à un autre a quitté la fenêtre.

Des bogues similaires sont inoffensifs. Par exemple, une marque de vêtements bien connue est également tombée sur ce râteau. En raison de tests de mise en page insuffisants, les utilisateurs du site de cette marque au lieu du bouton "En savoir plus" ont longtemps vu "Apprendre la douleur ..."


L'inscription sur le bouton, bien sûr, est proche de la vérité, les prix y sont vraiment pénibles, mais ce n'est clairement pas ce que les créateurs du site voulaient. En général, ces moments doivent être surveillés et corrigés, indépendamment de ce qu'ils provoquent - un inconvénient ou un sourire.

Conscients de ces problèmes, nous avons appliqué la pratique de l'examen obligatoire de la conception par nos concepteurs de produits, mais ce n'était pas le cas. Il s'est avéré que toutes les équipes n'ont pas un concepteur dédié, ou qu'elles n'ont pas assez de temps, ou pire encore, le recto et le concepteur ne peuvent pas parvenir à une approche commune de la mise en page d'une page, d'un formulaire ou d'un élément.

Sans réfléchir à deux fois, nous sommes partis à la recherche d'options pour minimiser à la fois le nombre de défauts de mise en page et les impasses Front VS Designer. Après avoir étudié les pratiques et outils possibles pour automatiser les mises en page de test et collecter les cônes, nous avons mis en œuvre l'approche suivante.

En bref sur nous:
Nous développons maintenant un produit unique, sur lequel travaillent plus de 20 équipes Scrum, chacune étant responsable d'une certaine fonctionnalité, tandis que nous essayons de maintenir un style et une conception uniques du produit lui-même - présentation visuelle, emplacement des principaux éléments, etc.

Concernant la répartition des utilisateurs par navigateur, nos utilisateurs utilisent aujourd'hui (les valeurs sont arrondies):

• 60% Chrome
• 30% - Firefox,
• 10% - autres navigateurs.

Nous testons la fonctionnalité avec notre framework Akita BDD (Java + Cucumber + Selenide), nous en avons parlé ici .

Pour commencer, nous voulions résoudre le problème des accords entre le front et le designer. Au stade initial de la création d'une maquette de fonctionnalité, la façade et le concepteur décrivent ensemble le «contrat». Dans ce contrat, ils décrivent tous les arrangements pour l'agencement des éléments, leurs styles, la distance, etc. Pour cette raison, lors de la détection des décalages de la mise en page avec la mise en page, les gars n'auront pas à découvrir pendant longtemps qui a raison et qui est à blâmer.

Ils décrivent leurs arrangements dans un fichier de spécification galen.

Qu'est-ce que Galen-spec?

Afin d'automatiser les tests de mise en page et ainsi minimiser le nombre de défauts, nous avons décidé de mettre en œuvre l'outil Galen Framework. Il est basé uniquement sur un fichier .spec (spécification ou, comme nous l'avons appelé, «contrat»). Et il s'intègre facilement aux tests Selenium.

Après que le concepteur et l'avant aient rédigé le «contrat», le testeur forme un fichier .spec basé sur celui-ci, conformément aux exigences de Galen. Le framework utilise son propre langage pour rédiger des spécifications de vérification.

En quoi consiste un fichier .spec?

Logiquement, il peut être divisé en deux parties:

1. définitions d'objets

Ici, nous devons spécifier quels objets sont sur notre page - en-tête, pied de page, menu, contenu, etc. En général, nous listons les principaux éléments que nous allons vérifier, leur donnons des noms et définissons des localisateurs.


@objects - éléments sur la page (vous pouvez utiliser CSS, XPATH, ID)

2. Lorsque les localisateurs sont définis, les styles et les spécifications d'objets spécifiques doivent être définis. Pour cela, nous utilisons la partie de la spécification d'objet , où nous décrivons en détail, par exemple, que notre bloc de texte (description-texte) est situé à l'intérieur du formulaire de description, sous l'en-tête et contient un certain texte.


Section principale - pour chaque élément décrit, @objects décrit les paramètres de vérification.

* Le langage de spécification galen est sensible à l'indentation dans la section principale, alors faites particulièrement attention à cela et respectez les onglets :)

Ainsi, le «Contrat», conclu entre le front et le designer et transféré dans la langue Galien, nous permet de vérifier automatiquement l'emplacement et le contenu interne des éléments, ainsi que l'adaptabilité et la compatibilité entre navigateurs.

Exemple de démarrage rapide

1. Nous décrivons les éléments d'une page spécifique et vérifions les fichiers .spec en utilisant le langage Galen Spec, et mettons les spécifications dans le package.
2. Nous ajoutons les captures d'écran de référence au package de spécifications / images
3. Nous travaillons sur BDD, donc le script dans le fichier .feature pourrait ressembler à ceci:
   
   
   
4. Exécutez le script de test via le Cucumber Runner habituel.

Dans ce scénario, nous vérifions la page d'accueil de GitHub. Dans la dernière étape, nous avons ajouté la vérification de la mise en page. Des tests similaires peuvent compléter les tests fonctionnels existants ou les exécuter séparément. Si des disparités sont trouvées dans la mise en page, nous aurons alors une image avec le résultat attendu et avec le résultat, plus la différence. Tout cela est joint au rapport du cocu.

La différence dans les rapports est la suivante:


error = Erreur {[L'élément ne ressemble pas à "./akita-testing-template/src/test/resources/specs/images/registration-form.png". Il y a 10,47% de pixels incompatibles mais le maximum autorisé est de 10%]

Ici, nous voyons que la vérification a échoué, les images diffèrent de plus de 10% et toutes ces différences de couleur, à l'exception du remplissage noir, c'est la différence entre les éléments.

Si les éléments sont complètement identiques, la différence sera affichée en noir.

La question la plus courante est: où puis-je obtenir une capture d'écran de référence?

Réponse: Nous prenons la norme soit du concepteur, soit en exécutant des tests sur l'environnement prodov, que nous considérons comme la norme. Nous obtenons des photos de nos blocs à partir de là, que nous comparerons et les placerons dans le dossier images, d'où les spécifications tireront des liens vers eux.

Qu'en est-il venu d'utiliser cette approche

• réussi à réduire le nombre de tests de fumée et le temps de leur passage d'environ 20% en raison du fait que la vérification de certaines formes et éléments similaires s'est effondrée en un seul test, qui vérifie leur composante visuelle et révèle immédiatement des écarts
• Maintenant, nous pouvons être sûrs que nos applications s'affichent correctement dans les navigateurs sélectionnés
• sachez que l'adaptabilité est correcte et non séparée
• est venu à une revue de conception automatique.

Vous pouvez lire la documentation sur la compilation des fichiers de spécification galen ici - galen-spec-language-guide .

Nous avons parlé des aspects techniques de l'utilisation du cadre Galen, de ses capacités et des vérifications de base lors du dernier camp de sélénium, et nous écrirons sur le blog.

La possibilité d'utiliser galen-spec et les nouvelles étapes pour vérifier la disposition que nous avons prise dans notre bibliothèque Akita , où il y a un modèle pour un démarrage rapide , et nous menons également une discussion par télégramme où vous pouvez poser des questions qui vous intéressent.

Et nous répondrons.