Fermer

juillet 21, 2021

Amélioration ciblée de la logique de recherche basée sur des requêtes enchaînées


Les applications à page unique (SPA) volumineuses et complexes peuvent imposer des défis importants aux outils d'automatisation des tests en raison de la manière dont les éléments sont organisés. Cet article de blog vous guide à travers quelques étapes simples pour automatiser les SPA et gérer des scénarios difficiles en améliorant la logique de recherche d'éléments de Test Studio.

Localisation d'éléments dans des applications à page unique (SPA)

Dans un SPA (application à page unique [Web] ), le DOM du navigateur peut changer radicalement sans que l'URL ne change du tout. Cela peut devenir un cauchemar pour les testeurs essayant de localiser des éléments dans le DOM lors de l'enregistrement et de l'exécution des tests, ce qui pose des problèmes même pour Test Studio. La logique d'identification d'élément basée sur l'image de Test Studio peut être trop générique si vous souhaitez identifier de manière unique des éléments dans un SPA. Le résultat est que lors de l'exécution du test, un élément inattendu peut être localisé à la place de celui souhaité.

Ce problème est plutôt courant pour les SPA en raison de la manière dont les éléments sont organisés dans le DOM. Avec cet article, je vais démontrer les défis associés à la localisation des éléments dans les ZPS. L'histoire ne sera pas complète, cependant, si nous ne vous présentons pas une solution qui peut vous aider et vous éviter bien des ennuis. Dans notre cas, la solution est basée sur l'utilisation de requêtes chaînées pour améliorer délibérément la logique de recherche d'éléments de Test Studio.

Attribution d'ID à des conteneurs au lieu d'éléments uniques

En bref, la solution est basée sur l'attribution d'ID à des conteneurs au lieu d'éléments uniques. éléments. En faisant cela, nous nous assurons que Test Studio peut localiser ces éléments et les identifier de manière unique. Par exemple, si vous avez un formulaire de contact avec des champs de saisie (avec le même formulaire de contact existant plusieurs fois dans la même page), vous n'attribuerez pas d'ID à toutes les entrées du formulaire de contact, mais uniquement au conteneur sous lequel ces éléments (prénomnomadresse) sont répertoriés.

De cette façon, il est assuré que les actions et vérifications seront exécutées sur le bon contact formulaire tout en évitant le travail fastidieux d'attribution d'identifiants à chaque champ dans plusieurs formulaires de contact identiques qui peuvent apparaître sur la page selon les circonstances.

Lorsque vous souhaitez que Test Studio identifie le champ contenant nom de famillevous rechercherez le conteneur en fonction de l'ID que vous avez attribué à ce conteneur. Ensuite, vous pouvez utiliser des expressions de recherche en chaîne pour rechercher un élément dans un conteneur spécifique.

Cela permettra non seulement aux tests automatisés de réussir sans échec, mais vous pouvez également être sûr du résultat final après l'exécution du test ou que Test Studio valide les éléments corrects.

Présentation de l'utilisation de l'interface utilisateur Kendo pour les composants angulaires.

La démonstration que nous allons montrer représente un cas d'utilisation fourni par l'utilisateur de Test Studio Mark Claassen et son équipe en fonction des défis auxquels ils étaient confrontés lors de l'automatisation de leur interface utilisateur Kendo pour une application basée sur Angular.

Mark a travaillé sur Conception d'interface utilisateur depuis plus de 20 ans, créant des interfaces hautement dynamiques. Il a travaillé sur toutes les phases du processus de conception et a mis en œuvre les solutions sur tous les niveaux de l'application.

Voici la description du cas d'utilisation fournie par Mark. Dans leur application basée sur Kendo UI for Angulardeux boîtes de dialogue peuvent apparaître après une connexion réussie. Lorsqu'ils ont enregistré un test et que l'une de ces boîtes de dialogue est apparue, ils ont sélectionné un bouton dans ce composant pour fermer la boîte de dialogue.

Test Studio crée une logique de recherche pour ce bouton impliquant quelque chose comme : « Rechercher une boîte de dialogue (par nom de classe ), puis recherchez bouton 1. Cependant, lors d'une exécution ultérieure, l'autre boîte de dialogue est apparue. Cette boîte de dialogue elle-même avait une classe correspondante et avait un "bouton 1". Cependant, le "bouton 1" dans cette boîte de dialogue n'était pas un bouton "fermer", mais un bouton "suivant". Lorsque Test Studio a exécuté le test, des étapes ont été exécutées sur la boîte de dialogue inattendue et l'ensemble du test a déraillé à partir de ce point. Pire encore, les étapes d'action n'ont pas échoué, ce qui a rendu le cas de test difficile à déboguer.

L'image de l'élément capturée par Test Studio a montré que l'élément était le bouton « fermer », donc il avait l'air bien dans l'éditeur. Cependant, lorsque la fonction d'annotation a été activée, le bouton « fermer » attendu n'apparaissait pas, mais l'action était effectuée sur le bouton « suivant » de la deuxième boîte de dialogue.

Mark avait essayé de déterminer pourquoi la "fermeture" ne fonctionnait pas, mais il avait raté le fait qu'il le trouvait dans la mauvaise boîte de dialogue.

Pourquoi est-ce un problème ?

Lorsque l'élément trouve la logique dans Test Studio tombe en panne, comme dans l'exemple ci-dessus, cela peut conduire à des situations difficiles à diagnostiquer. Bien que l'exemple ci-dessus soit simple, il existe des scénarios plus complexes qui nécessitent des solutions complexes. Si nous voulons que cela fonctionne dans Test Studio, nous devons :

  • Trouver tous les endroits où un élément est utilisé
  • Déterminer quelles utilisations sont correctes et lesquelles ne le sont pas
  • Casser le partage d'éléments si nécessaire [19659020]Mieux définir une logique de recherche pour ces éléments

Bien que cela soit possible, ce n'est pas très efficace. Vous finirez par travailler en étroite collaboration avec le développement pour vous assurer que la logique de recherche appropriée est utilisée pour localiser les éléments dans le DOM et, en fin de compte, vous devrez retester tous les tests déjà créés.

Il existe un moyen plus simple de le faire avec Test Studio, et cela a parfaitement fonctionné pour l'application de Mark, l'aidant à surmonter complètement le problème. Cela lui a cependant demandé d'adapter légèrement l'application.

Utiliser des expressions de recherche chaînées

Modifier l'exemple d'origine impliquerait d'ajouter un attribut "automation_id" à chacune des boîtes de dialogue : "automation_id=Dialog 1" et "automation_id=Dialog 2 ”.

Ensuite, ce que nous devons faire dans Test Studio est d'ajouter l'attribut personnalisé « automation_id » pour améliorer la logique de recherche dans le cadre des paramètres du projet.

Cela informera Test L'algorithme de logique de recherche de Studio utilise toujours les nœuds parents qui ont cet attribut. Cela signifierait que la logique de recherche d'élément automatique pour ces boutons utilise des requêtes chaînées comme suit :

  • automation_id=Dialog 1,|,tagIndex=button:1
  • automation_id=Dialog 2,|,tagIndex=button:2 [19659023] Le premier élément (bouton:1) ne serait jamais accidentellement trouvé dans "Dialog 2" car il n'est trouvé que lorsqu'il suit la logique parent-enfant et fait partie du conteneur "Dialog 1".

    Voici à quoi ressemble le paramètre Rechercher des expressions dans Test Studio.

    Le volet Modifier l'élément affiche l'expression de recherche actuellement utilisée pour l'élément et vous permet de la modifier.

    Expression de recherche d'élément - recherche de div avec un identifiant correspondant exactement au conteneur de bouton et filtre enfant recherchant le bouton TagIndex correspondant exactement au bouton : 0. L'élément a été trouvé avec succès.

    Le bouton Mode avancé affiche l'expression de recherche actuelle au format texte et vous permet d'en saisir une personnalisée.

    Expressions de recherche d'élément personnalisées. En haut à droite, il y a une option pour passer en mode avancé pour le filtre de recherche. L'expression de recherche personnalisée utilisée est 'id=button-containr,|,TagIndex=button:0', et le message dit à nouveau, 'Super ! Nous avons trouvé votre élément.'

    L'attribution d'attributs "automation_id" stratégiquement aux conteneurs au lieu d'éléments uniques améliorera considérablement la logique de recherche d'éléments et permettra la réutilisation ciblée des éléments dans un SPA.

    Il est important que les développeurs de l'équipe soient conscients de cette approche et la suivent en ajoutant de tels attributs aux domaines qu'ils savent être susceptibles de jouer un rôle pour les testeurs, ou, en d'autres termes, d'écrire du code avec ses testabilité à l'esprit. Cela permettra aux testeurs d'utiliser ces attributs sans analyse supplémentaire et fastidieuse du DOM.

    Si un AQ détermine que la logique de recherche est trop spécifique pour un élément particulier, il peut toujours adapter le niveau de détail. Mais gardez à l'esprit qu'il est plus facile de supprimer des niveaux de spécificité que de les ajouter.

    L'écran de logique de recherche se compose de groupes d'attributs permettant de rechercher un nœud dans le DOM. Ces groupes forment ensemble un chemin. L'ajout de groupes supplémentaires sous un groupe est intuitif. Pour insérer un groupe en haut, vous pouvez utiliser la zone de texte dans le Mode avancé de la fenêtre de recherche d'expression.

    Conclusion

    Les SPA volumineux et complexes peuvent être assez difficiles à automatiser pour les outils de test. . L'objectif ultime ici est de maintenir une logique de recherche robuste et de localiser les éléments facilement et de manière unique, sans modifier trop souvent le code de l'application, car cela créerait un chaos dans toute l'équipe ou le projet.

    L'ajout d'identifiants HTML à chaque élément demanderait beaucoup d'efforts et serait difficile à maintenir. D'un autre côté, l'utilisation des attributs « automation_id », comme décrit dans cet article, peut aider énormément à trouver un bon équilibre entre modifier le moins possible le code source tout en améliorant la logique de recherche dans une mesure qui fonctionne pour nous et, en fin de compte, bénéficie nous.

    Essayez Test Studio




Source link