Trucs et astuces pour rendre les outils d'enregistrement de l'interface utilisateur moins douloureux

Les outils d'enregistrement de l'interface utilisateur peuvent être frustrants, mais ils ne doivent pas l'être. Avec quelques conseils et astuces rapides pour rendre les cas marginaux moins douloureux, vous serez plus heureux de faire évoluer votre automatisation de test d'interface utilisateur.

Les testeurs adoptent l'automatisation des tests, en particulier l'automatisation des tests d'interface utilisateur, pour accélérer les actions de test répétitives et concentrer le travail manuel sur la recherche de problèmes nouveaux et intéressants. Avec l'automatisation des tests d'interface utilisateur, vous pouvez définir les différents chemins que vous souhaitez emprunter à travers l'application et, au lieu qu'un humain fasse le travail, la machine peut valider l'application de manière continue et automatisée.

La principale façon de créer un test automatisé consiste à écrire du code. Cela peut être malheureux, car un testeur qui sait comment parcourir l'application à la main doit soit apprendre à écrire du code à l'aide d'un framework comme Selenium, soit utiliser un outil propriétaire comme UFT pour créer un flux de travail automatisé qui reflète celui qu'il faisait par main. Cela peut rapidement devenir difficile, car le code par nature est sujet aux erreurs et l'écriture de tests automatisés peut nécessiter un ensemble de compétences assez sophistiquées.

Pour relever le défi, de nombreux outils (Parasoft's Outil d'automatisation des tests d'interface utilisateur inclus) incluent la possibilité d'enregistrer et de lire un scénario Web. Ces outils sont excellents en théorie, mais un gros problème est que la plupart des enregistreurs ne parviennent pas à enregistrer et à lire le scénario exact 80% du temps. C'est une triste réalité, mais il y a une lumière au bout du tunnel. Voici quelques-uns des défis courants auxquels tous les enregistreurs sont confrontés, ainsi que quelques trucs et astuces que vous pouvez adopter pour les résoudre.

Lorsque l'application Web se comporte différemment pendant la lecture et lorsque vous l'avez enregistrée…

L'incohérence dans le comportement des applications Web est le défi numéro un auquel vous devrez faire face avec les technologies d'enregistrement et de lecture, et peut être assez difficile à surmonter. Voici quelques raisons différentes pour lesquelles cela peut se produire, ainsi que certaines techniques pour vous aider à diagnostiquer et potentiellement résoudre les problèmes.

Problème n ° 1: l'application a été enregistrée dans un état particulier, même si vous ne le saviez pas.

Les développeurs de logiciels utilisent des cookies de navigateur pour stocker des informations de session pour un utilisateur particulier d'une application Web ou pour suivre les sessions entre des applications associées. Les cookies peuvent être utilisés pour récupérer des informations sur l'utilisateur sans avoir besoin de stocker les informations dans un système back-end. Un cookie enregistre des données telles que le fait que le navigateur de l'utilisateur a déjà visité l'application Web ou des informations sur la session actuelle de l'utilisateur.

À des fins d'automatisation, les cookies existants peuvent facilement causer un problème. Les frameworks d'automatisation de test tels que Selenium démarrent souvent le navigateur dans un état «propre» où tous les cookies ont été supprimés. Si vous avez enregistré un test avec la présence de cookies, l'application Web se comportera différemment pendant la lecture de ce qu'elle faisait lorsque vous l'avez enregistré, et le test enregistré peut échouer.

Un exemple est les données de session stockées dans un cookie qui permet à un utilisateur de rester connecté à une application Web entre les sessions du navigateur. Si vous démarrez l'enregistrement alors que vous êtes déjà connecté, aucune information de connexion ne sera capturée dans le scénario de test enregistré. Pendant la lecture, aucun cookie ne sera présent, l'application ira donc immédiatement à une page de connexion et le test échouera.

Le même type de problème se produit lorsque des éléments apparaissent sur la page pendant la lecture et qui n'apparaissent pas pendant l'enregistrement. De nombreuses applications Web affichent une notification lors de la première visite d'un utilisateur, telle qu'une notification GDPR concernant l'utilisation des cookies par l'application, ou une fenêtre contextuelle qui affiche une offre spéciale, une vente ou une opportunité d'inscription à la newsletter. La lecture des scénarios enregistrés dans ce cas échouera car les éléments de page supplémentaires ne sont pas apparus pendant l'enregistrement et le test ne sait donc pas comment interagir avec les éléments supplémentaires.

Voici comment rendre cela moins douloureux…

Solution: enregistrement et lecture en mode incognito / privé

La plupart des navigateurs peuvent être configurés pour se lancer en mode incognito / privé. Lors de l'exécution dans ce mode, les cookies et les informations de profil sont supprimés, de sorte que l'application Web se comportera comme s'il s'agissait de votre première visite et que vous n'étiez pas connecté. Enregistrez vos scénarios de test à l'aide d'un navigateur qui a été lancé en mode incognito / privé, et vous aurez une base de référence propre pour vos scénarios de test enregistrés. Dans Chrome, le paramètre ressemble à ceci:

Voici un excellent article qui montre comment configurer ce mode dans les navigateurs autres que Chrome.

Une fois que vous avez créé votre script de test, vous pouvez généralement l'autoriser à être lu en mode normal. Cependant, dans certains cas, il peut être avantageux de lire en mode incognito / privé. Un exemple de ceci serait une application Web qui utilise votre emplacement actuel pour personnaliser l'expérience sur la page. J'ai vu des cas où l'emplacement actuel récupéré pendant la lecture d'un test Selenium différait de l'emplacement récupéré pendant l'enregistrement (je ne sais pas pourquoi). La lecture en mode incognito / privé empêchera le navigateur d'obtenir votre position actuelle et stabilisera votre scénario de test. Dans Selenium, vous pouvez demander à la lecture de se dérouler en mode incognito / privé - consultez ces liens pratiques pour Chrome et Firefox.

Solution: définir des cookies spécifiques

Cela peut être utile si vous avez besoin de certains cookies pour vous assurer que la lecture démarre avec l'application Web dans un état spécifique. Voici un super message de forum qui décrit le processus de capture et de configuration de cookies spécifiques lors de la lecture.

Problème n ° 2: changer les tailles d'écran

La pratique de développement d'applications Web moderne de web design réactif provoque des problèmes lors de la création de tests automatisés. Afin de créer une application Web qui fonctionne à la fois pour les mobiles et les ordinateurs de bureau, les développeurs créent des applications réactives qui changent en fonction de la taille de l'écran. Vous voyez cela lorsque vous redimensionnez une fenêtre et que l'interface utilisateur change complètement. Imaginez ce que cela fait à un test automatisé!

Si vous enregistrez votre test dans une fenêtre agrandie, puis le relisez dans une fenêtre de demi-taille, les éléments de la page peuvent être masqués ou obscurcis en raison des différences de taille du navigateur. Un effet similaire se produit lorsque la résolution de votre appareil de lecture est différente de celle de votre appareil d'enregistrement. Quoi qu'il en soit, cela a un impact considérable sur l'automatisation de vos tests.

Voici comment rendre cela moins douloureux…

Solution: optimisez votre navigateur lors de la lecture

Vous pouvez utiliser les commandes Selenium pour maximiser la taille du navigateur:

• Utilisez l'API Selenium WebDriver (fonctionne dans tous les navigateurs pris en charge par Selenium):

  driver.manage (). window (). maximiser ();

• Ajoutez cette option pour Chrome qui vous fera gagner une étape dans votre test en configurant le WebDriver Options de Chrome:

  options.addArguments ("début maximisé")

• Consultez ce tutoriel utile pour d'autres commandes de taille du navigateur

L'optimisation du navigateur garantit que la page est en taille réelle et que les éléments sont disposés sur la page pour cette configuration. En supposant que vous ayez enregistré avec la taille d'écran maximale, les éléments seront généralement cohérents entre l'enregistrement et la lecture, même si la machine effectuant la lecture utilise une résolution différente.

Lorsque les tests échouent sporadiquement ou se comportent différemment en raison de problèmes de synchronisation…

En tant qu'humain, lorsque j'utilise une application Web, je recherche des éléments spécifiques et j'interagis avec ces éléments lorsqu'ils sont «prêts». Dans un test automatisé, il est un peu plus difficile pour la machine de savoir quand faire les choses que quand attendre.

L'outil de test automatisé exécute un scénario de test en une série d'étapes. Par exemple, lors de l'exécution d'un test de panier par rapport à Amazon, il se peut que l'étape suivante consiste à ajouter un article au panier, puis à cliquer sur le bouton du panier. Le problème est que le bouton du panier peut ne pas être disponible immédiatement après l'ajout de l'article et qu'il peut y avoir un moment où l'icône change. Le script de test a besoin de connaître exactement le bon temps d'attente ou les conditions à rechercher pour avancer. La configuration du test qui gère cela est généralement appelée «conditions d'attente». Les enregistreurs ont du mal à comprendre les conditions d'attente à créer dans les scripts de test, vous devez donc créer manuellement des conditions d'attente sophistiquées dans vos tests.

Voici comment rendre cela moins douloureux…

Solution: utilisez des attentes explicites

Les attentes explicites sont des conditions d'attente définies sur un élément individuel, qui indiquent à Selenium WebDriver d'attendre qu'une condition spécifique soit remplie, comme attendre qu'un élément soit présent ou visible sur la page. La condition d'attente spécifie une durée maximale d'attente pour que la condition soit remplie.

Utilisez des attentes explicites chaque fois que le test tente de trouver un élément. Si aucune condition d'attente n'est utilisée du tout, le test échouera si l'élément n'est pas immédiatement présent dans l'état approprié. Selenium WebDriver prend également en charge les conditions d'attente implicites, qui sont définies globalement pour un scénario de test entier et utilisées chaque fois que le test tente de trouver un élément. Cependant, les attentes implicites ne sont pas recommandées. Voir la documentation Selenium sur attentes explicites et implicites.

Lors de l'utilisation d'attentes explicites, des exceptions peuvent être levées par Selenium qui interrompent la condition d'attente - mais vous voulez en fait que la condition d'attente continue dans ces cas. Vous gérez cela en configurant les attentes explicites pour ignorer des exceptions particulières. Certaines exceptions courantes qui doivent être ignorées sont NoSuchElementException, StaleElementReferenceException et ElementClickInterceptedException.

Voici un bon exemple d'attente explicite qui ignore l'une de ces exceptions:

WebDriverWait wait = new WebDriverWait (pilote, DEFAULT_WAIT_FOR_ELEMENT_TIMEOUT); wait.ignoring (StaleElementReferenceException.class); wait.until (ExpectedConditions.elementToBeClickable (élément);

Lorsque les localisateurs d'élément sont interrompus en raison de modifications dans des parties non liées de la page…

Les enregistreurs d'applications Web tentent de créer un bon localisateur d'élément pour chaque élément de page référencé dans le test enregistré, mais dans de nombreux cas, les localisateurs enregistrés ne sont pas idéaux. Par exemple, le localisateur enregistré peut faire référence à des informations dynamiques qui changent à chaque fois que la page est visitée, ou être enclin à se rompre lorsque des parties non liées de la page sont modifiées ultérieurement.

Des exemples courants pourraient être:

• ID qui changent à chaque fois que vous visitez la page, ce qui est très courant dans les applications Salesforce et SAP:

  Cliquez ici pour plus d'informations

• Texte qui diffère en fonction de l'utilisateur spécifique connecté:

  Déconnexion de l'utilisateur (bob)

• Localisateurs basés sur la position, tels qu'un xpath, qui ne fonctionneront plus si les éléments de page référencés par des segments dans xpath sont ultérieurement déplacés ou modifiés dans l'application Web.

Voici comment rendre cela moins douloureux…

Solution: créez des localisateurs intelligents

Il est généralement assez facile d'identifier les localisateurs d'éléments contenant des informations dynamiques. Dès que vous lisez votre scénario enregistré, ces localisateurs échoueront car les informations dynamiques dont ils dépendent sont différentes. Pour gérer ces cas, vous devez rechercher des attributs d'identification unique de l'élément de page que vous pouvez utiliser dans le localisateur d'élément au lieu de l'attribut dynamique qui a été enregistré.

Une façon de le faire est de naviguer manuellement dans votre navigateur jusqu'à la page où l'élément apparaît, puis de cliquer avec le bouton droit sur l'élément et de choisir l'option de menu pour inspecter l'élément (appelée Inspecter dans Chrome et Inspecter l'élément dans Firefox). Cela vous mènera à une structure DOM qui vous permettra de visualiser le DOM et le code HTML sous-jacents de l'élément. Dans cette vue, vous pouvez identifier d'autres attributs permettant d'identifier l'élément. Les attributs communs à rechercher sont «classe», «nom», «titre» et «alt», mais ils peuvent également être dynamiques et vous devez en choisir un ou plusieurs qui identifient de manière unique l'élément. Dans certains cas, un attribut qui est le mieux utilisé pour identifier de manière unique l'élément se trouve sur un élément parent, vous pouvez donc créer un xpath relatif tel que le suivant:

// div [@ class = 'actionButton'] / bouton

Une autre approche consiste à utiliser des outils qui peuvent vous donner diverses options de localisateur, parmi lesquelles vous pouvez en choisir une, puis la modifier si nécessaire. Certains outils spécifiques qui me viennent à l'esprit sont SeleniumIDE et TruePath, qui créent tous deux plusieurs localisateurs différents qui peuvent être utilisés pour identifier un élément. Vous pouvez utiliser un localisateur tel quel ou en choisir un et le modifier en fonction de vos besoins.

Une troisième option consiste à utiliser Parasoft Sélénic pour générer des recommandations pour de meilleurs localisateurs lorsque les tests échouent en raison de mauvais localisateurs ou localisateurs cassés d'auto-guérison lors de l'exécution. Selenic utilisera les données historiques des exécutions de tests précédentes ainsi que des informations sur l'état actuel de la page pour suggérer un ensemble de différents localisateurs que vous pouvez utiliser, ainsi que sa confiance sur chaque localisateur.

Quelques conseils supplémentaires

En plus de ce que j'ai déjà mentionné, il existe un certain nombre d'autres situations courantes qui surviennent lors de la création de scénarios de test à partir de l'enregistrement. Voici quelques conseils supplémentaires pour rendre l'utilisation des outils d'enregistrement de l'interface utilisateur moins pénible.

Enregistrement des actions de survol

Il est traditionnellement difficile pour les outils d'enregistrement et de lecture de capturer des éléments de page qui apparaissent lorsqu'un utilisateur place la souris sur un autre élément. L'action de survol n'est généralement pas enregistrée, mais l'interaction avec l'élément qui apparaît est enregistrée. Lors de l'exécution du scénario de test, l'action de survol ne se produit pas et l'élément de page suivant défini dans le scénario de test n'apparaît jamais, ce qui entraîne l'échec du test.

Pour rendre cela moins douloureux, faites attention pendant l'enregistrement à l'endroit où les actions de survol révèlent des éléments supplémentaires, et lorsque vous voyez l'un de ces cas, cliquez sur l'élément au lieu de simplement le survoler. Cela entraînera l'enregistrement d'une action de clic dans votre test pour cet élément de page. Si vous voulez que le test survole au lieu de cliquer sur l'élément, changez l'action de clic dans le test en une action de survol après le fait. Voici un article pour vous aider.

Défilement

Plusieurs fois pendant l'enregistrement, vous devez faire défiler les éléments de la page afin d'interagir avec eux. Les outils d'enregistrement n'enregistrent généralement pas les actions de défilement, et ils n'en ont pas besoin puisque Selenium gère normalement le défilement pour vous. Cependant, dans certains cas, Selenium ne fait pas défiler l'élément de page dans la vue lors de la lecture du test, et le test échouera car l'élément n'est pas visible. Pour rendre cela moins pénible, ajoutez manuellement les interactions de défilement ultérieurement à l'aide d'un exécuteur JavaScript. Voici un excellent article qui vous aide à traverser cela.

Certaines actions non enregistrées

De temps en temps pendant l'enregistrement, les éléments ne sont tout simplement pas enregistrés. Cela est souvent dû au fait que le cadre de l'interface utilisateur crée les éléments de la page de manière unique.

Pour rendre cela moins douloureux, gardez une trace des actions spécifiques que vous effectuez sur votre application Web pendant l'enregistrement. Après l'enregistrement, identifiez dans votre script Selenium où l'action aurait dû se trouver et ajoutez-la manuellement. Vous pouvez identifier le localisateur à utiliser en naviguant dans le navigateur jusqu'à la page où l'action a été manquée, puis en utilisant l'une des extensions de navigateur mentionnées précédemment pour capturer un localisateur et le mettre manuellement dans le test.

Conclusion

La création de scénarios de test à l'aide d'outils d'enregistrement de l'interface utilisateur peut être pénible, mais ce n'est pas obligatoire. Tirez parti de ces techniques pour réussir votre pratique d'automatisation des tests d'interface utilisateur. Bon test!