Syllabus A4Q Testeur Selenium certifié

3.1   Mécanismes de logs et de reporting (K3)

Les scripts de test automatisés sont du code logiciel qui exécutent des commandes sur le SUT. Ainsi, ils simulent des opérateurs humains en train de réaliser des tests à l’aide du clavier et de la souris. La solution d’automatisation des tests doit fournir un mécanisme qui implémente la couche d’exécution des tests. Une façon d’implémenter un tel mécanisme est de coder entièrement les scripts d’automatisation de tests. De tels scripts peuvent alors être exécutés comme n’importe quel autre script, par exemple en langage Python.

Plutôt que de créer complètement de tels scripts, nous pouvons plutôt utiliser des bibliothèques de tests unitaires existantes, tels que par exemple, unittest ou pytest, qui facilitent l’exécution des tests et la gestion des résultats d’exécution. Dans ce syllabus, nous avons choisi le framework d’automatisation pytest comme bibliothèque d’exécution des tests.

Pytest est un framework d’automatisation de test qui facilite l’écriture de tests pour Python, mais aussi pour Selenium WebDriver avec Python. Pytest facilite l’écriture de tests simples, mais permet aussi de réaliser des tests automatisés plus complexes.

Lorsqu’il est appelé, Pytest exécute tous les tests dans le répertoire courant ou ses sous-répertoires. Il recherche spécifiquement tous les fichiers qui répondent aux patterns : “test__*.py” ou :*__test.py” et les exécute ensuite.
Lorsqu’il est exécuté sans option (pytest), pytest exécute tous les tests dans le répertoire courant et dans ses sous-répertoires.

Il est également possible de définir les options suivantes lors de l’appel de la commande (pytest) :

• (pytest -v) Mode verbeux qui affiche les noms complets des tests plutôt qu’un point.
• (pytest -q) Mode silencieux qui affiche moins d’information en sortie.
• (pytest –html=report.html) Exécute le(s) test(s) avec un rapport dans un fichier HTML.

Les tests peuvent être annotés pour être traités d’une manière particulière. Par exemple, lorsque vous mettez (@pytest.mark.skip) avant une définition de test, pytest ne lancera pas le test. Si vous mettez (@pytest.mark.xfail) avant une définition de test, il informe le moteur d’exécution que le test devrait échouer. Ces tests, s’ils échouent lors de leur exécution, ne seront pas notifiés de la même manière que les tests qui échouent lorsqu’on s’attend à ce qu’ils réussissent.

Lorsqu’un testeur manuel exécute un cas de test et que ce cas de test échoue, le testeur a une assez bonne idée de ce qui s’est passé. Il connait les étapes qui ont mené à l’échec, ce qui s’est passé lors de l’échec, quelles données ont été utilisées et quel est le résultat obtenu. Lors de l’exécution d’un test exploratoire, bien que le testeur n’ait pas de cas de test documenté prédéfini, il a une vision générale de l’exécution et la possibilité dans une certaine mesure de revenir en arrière et établir pourquoi un échec est survenu.

Dans le contexte de l’automatisation, pratiquement rien de cela n’est vrai.

Souvent, dans l’automatisation, le message d’erreur enregistré par l’outil est tout à fait insuffisant pour que la personne qui examine une exécution qui a échoué puisse comprendre ce qui est arrivé. Par exemple, le message d’erreur n’a pas de contexte et l’erreur enregistrée peut n’avoir rien à voir avec le dysfonctionnement réel qui a arrêté l’exécution du test.

Par exemple, supposons qu’une défaillance se produise à l’étape N. Selon la façon dont la défaillance s’est produite, le résultat peut signifier que l’interface du SUT ne se trouve pas dans l’état correct. Lorsque le script tente d’exécuter l’étape N+1, l’étape échoue parce que le SUT n’est pas dans l’état correct pour exécuter cette étape. Le rapport de l’exécution du test (le fichier de logs) indique alors que c’est l’étape N+1 qui a échoué.

Dans ce cas, le diagnostic du problème commence mal. De plus, si l’analyste de test qui a exécuté le test automatisé (généralement en mode batch) n’a pas une connaissance détaillée du script qui a été exécuté, essayer de diagnostiquer l’échec pour déterminer si c’est une défaillance réelle du SUT ou une défaillance d’automatisation peut prendre un temps conséquent.

Il n’est pas nécessaire qu’il en soit ainsi dans le domaine de l’automatisation. L’enregistrement de l’exécution des tests automatisés, correctement réalisé, peut grandement aider un analyste de test à déterminer rapidement si la défaillance a été causée par le SUT ou non. Il est primordial qu’un automaticien de tests soit attentif à la précision des logs. Une bonne gestion des logs peut faire la différence entre un projet d’automatisation qui échoue et un projet qui réussit à apporter de la valeur lorsqu’elle est réalisée.

L’enregistrement des logs est un moyen de suivre les événements qui se produisent pendant l’exécution. L’automaticien de tests peut intégrer des instructions de log à un script pour enregistrer des informations afin de faciliter la compréhension de l’exécution. Cet enregistrement peut être effectué avant et après une étape et peut inclure les données qui ont été utilisées dans l’étape et le comportement qui s’est produit à la suite de l’étape. Plus cet enregistrement est détaillé, mieux il permettra de comprendre le résultat de l’exécution du test.

Dans certains cas, lorsque vous testez des logiciels critiques pour la sureté ou pour le service rendu, un enregistrement détaillé des logs peut être nécessaire à des fins d’audit.

L’enregistrement des logs peut être conditionné. Ainsi, les données de logs peuvent n’être sauvegardées et restituées en tant que logs uniquement si le test est en échec ou si un rapport de diagnostic complet est nécessaire. L’enregistrement de chaque étape peut ne pas être recommandé lorsque le test se déroule comme attendu ; cependant, en cas d’échec, ces informations d’enregistrement peuvent économiser des heures de dépannage du fait de la sauvegarde, étape par étape, des données exactes qui ont été utilisées et des événements survenus pendant l’exécution.

Tous les projets d’automatisation n’ont pas besoin de logs aussi robustes. Souvent, un projet d’automatisation démarre avec un ou deux automaticiens de test qui vont créer et exécuter leurs propres scripts. Dans ce cas, l’enregistrement des logs tels que décrit ci- dessus peut être considéré comme excessif. Mais, il faut noter que lorsque de petits projets d’automatisation réussissent, il est à peu près garanti que le management en voudra plus : beaucoup plus d’automatisation. Plus il y a de succès, plus la demande est forte.

Cela signifie qu’à terme, le projet va atteindre une taille telle que la gestion des enregistrements d’exécution décrite précédemment sera nécessaire. Ce qui impliquera que les scripts automatisés existants devront être repris et amélioré pour des logs plus pertinents. Il est de ce fait plus efficace et plus efficient de réaliser un enregistrement des logs de manière robuste dès le début.

Python dispose d’un ensemble complet de fonctions pour l’enregistrement des logs qui peuvent être utilisées avec WebDriver. À tout moment dans un script automatisé,

Lorsqu’il est appelé, Pytest exécute tous les tests dans le répertoire courant ou ses sous- répertoires. Il recherche spécifiquement tous les fichiers qui répondent aux patterns : “test *.py” ou :* test.py” et les exécute ensuite.

Lorsqu’il est exécuté sans option (pytest), pytest exécute tous les tests dans le répertoire courant et dans ses sous-répertoires. Il est également possible de définir les options suivantes lors de l’appel de la commande (pytest) :

• (pytest -v) Mode verbeux qui affiche les noms complets des tests plutôt qu’un
• (pytest -q) Mode silencieux qui affiche moins d’information en
• (pytest –html=report.html) Exécute le(s) test(s) avec un rapport dans un fichier HTML.

Les tests peuvent être annotés pour être traités d’une manière particulière. Par exemple, lorsque vous mettez (@pytest.mark.skip) avant une définition de test, pytest ne lancera pas le test. Si vous mettez (@pytest.mark.xfail) avant une définition de test, il informe le moteur d’exécution que le test devrait échouer. Ces tests, s’ils échouent lors de leur exécution, ne seront pas notifiés de la même manière que les tests qui échouent lorsqu’on s’attend à ce qu’ils réussissent.

Lorsqu’un testeur manuel exécute un cas de test et que ce cas de test échoue, le testeur a une assez bonne idée de ce qui s’est passé. Il connait les étapes qui ont mené à l’échec, ce qui s’est passé lors de l’échec, quelles données ont été utilisées et quel est le résultat obtenu. Lors de l’exécution d’un test exploratoire, bien que le testeur n’ait pas de cas de test documenté prédéfini, il a une vision générale de l’exécution et la possibilité dans une certaine mesure de revenir en arrière et établir pourquoi un échec est survenu.

Dans le contexte de l’automatisation, pratiquement rien de cela n’est vrai.

Souvent, dans l’automatisation, le message d’erreur enregistré par l’outil est tout à fait insuffisant pour que la personne qui examine une exécution qui a échoué puisse comprendre ce qui est arrivé. Par exemple, le message d’erreur n’a pas de contexte et l’erreur enregistrée peut n’avoir rien à voir avec le dysfonctionnement réel qui a arrêté l’exécution du test.

Par exemple, supposons qu’une défaillance se produise à l’étape N. Selon la façon dont la défaillance s’est produite, le résultat peut signifier que l’interface du SUT ne se trouve pas dans l’état correct. Lorsque le script tente d’exécuter l’étape N+1, l’étape échoue parce que le SUT n’est pas dans l’état correct pour exécuter cette étape. Le rapport de l’exécution du test (le fichier de logs) indique alors que c’est l’étape N+1 qui a échoué.

Dans ce cas, le diagnostic du problème commence mal. De plus, si l’analyste de test qui a exécuté le test automatisé (généralement en mode batch) n’a pas une connaissance détaillée du script qui a été exécuté, essayer de diagnostiquer l’échec pour déterminer si c’est une défaillance réelle du SUT ou une défaillance d’automatisation peut prendre un temps conséquent.

Il n’est pas nécessaire qu’il en soit ainsi dans le domaine de l’automatisation. L’enregistrement de l’exécution des tests automatisés, correctement réalisé, peut grandement aider un analyste de test à déterminer rapidement si la défaillance a été causée par le SUT ou non. Il est primordial qu’un automaticien de tests soit attentif à la précision des logs. Une bonne gestion des logs peut faire la différence entre un projet d’automatisation qui échoue et un projet qui réussit à apporter de la valeur lorsqu’elle est réalisée.

L’enregistrement des logs est un moyen de suivre les événements qui se produisent pendant l’exécution. L’automaticien de tests peut intégrer des instructions de log à un script pour enregistrer des informations afin de faciliter la compréhension de l’exécution. Cet enregistrement peut être effectué avant et après une étape et peut inclure les données qui ont été utilisées dans l’étape et le comportement qui s’est produit à la suite de l’étape. Plus cet enregistrement est détaillé, mieux il permettra de comprendre le résultat de l’exécution du test.

Dans certains cas, lorsque vous testez des logiciels critiques pour la sureté ou pour le service rendu, un enregistrement détaillé des logs peut être nécessaire à des fins d’audit.

L’enregistrement des logs peut être conditionné. Ainsi, les données de logs peuvent n’être sauvegardées et restituées en tant que logs uniquement si le test est en échec ou si un rapport de diagnostic complet est nécessaire. L’enregistrement de chaque étape peut ne pas être recommandé lorsque le test se déroule comme attendu ; cependant, en cas d’échec, ces informations d’enregistrement peuvent économiser des heures de dépannage du fait de la sauvegarde, étape par étape, des données exactes qui ont été utilisées et des événements survenus pendant l’exécution.

Tous les projets d’automatisation n’ont pas besoin de logs aussi robustes. Souvent, un projet d’automatisation démarre avec un ou deux automaticiens de test qui vont créer et exécuter leurs propres scripts. Dans ce cas, l’enregistrement des logs tels que décrit ci- dessus peut être considéré comme excessif. Mais, il faut noter que lorsque de petits projets d’automatisation réussissent, il est à peu près garanti que le management en voudra plus : beaucoup plus d’automatisation. Plus il y a de succès, plus la demande est forte.

Cela signifie qu’à terme, le projet va atteindre une taille telle que la gestion des enregistrements d’exécution décrite précédemment sera nécessaire. Ce qui impliquera que les scripts automatisés existants devront être repris et amélioré pour des logs plus pertinents. Il est de ce fait plus efficace et plus efficient de réaliser un enregistrement des logs de manière robuste dès le début.

Python dispose d’un ensemble complet de fonctions pour l’enregistrement des logs qui peuvent être utilisées avec WebDriver. À tout moment dans un script automatisé, l’automaticien de tests peut ajouter des appels d’enregistrement de logs pour rapporter toutes les informations souhaitées. Il peut s’agir d’informations générales pour le suivi ultérieur du test (par exemple, “Je suis sur le point de cliquer sur le bouton XYZ”), d’avertissements concernant un événement à noter même s’il ne provoque pas l’échec du test (par exemple, “Ouverture du fichier a pris plus longtemps que prévu.”) ou des erreurs réelles, qui provoquent une exception déclenchant les actions de terminaison du test et le passage au test suivant

La bibliothèque d’enregistrement des logs en Python possède cinq niveaux différents de messages qui peuvent être sauvegardés. Du plus bas au plus haut niveau :

• DEBUG: pour diagnostiquer les problèmes
• INFO: pour informer sur le déroulement du test
• WARNING: quelque chose d’inattendu s’est produit, un problème potentiel
• ERROR: un problème majeur s’est produit
• CRITICAL: un problème critique s’est produit

Lorsqu’un log est édité sur la console ou dans un fichier, le niveau de message peut être paramétré sur l’un de ces cinq niveaux (ou sur un niveau personnalisé pouvant être défini) permettant à l’utilisateur de voir uniquement les messages désirés. Par exemple, si l’édition des logs est paramétrée au niveau WARNING, l’utilisateur ne verra pas les messages DEBUG ou INFO, mais seulement les messages de logs de types WARNING, ERROR, et CRITICAL. Ainsi, supposons que le code suivant a été exécuté :

Comme le niveau d’enregistrement par défaut est WARNING, les informations suivantes sont affichées sur la console :

WARNING:root: Title: 101 Dalmatians

Lors de l’exécution d’un cas de test, il est important de tester un comportement effectif du système. Chaque cas de test doit pour cela avoir des résultats attendus liés à des actions du SUT qui peuvent être vérifiée. Python dispose d’un mécanisme intégré pour vérifier si les données ou le comportement corrects se sont produits : l’assertion.

Une assertion est un énoncé dont on s’attend à ce qu’il soit vrai à un moment donné dans le script. Par exemple, si nous testons une calculatrice, nous pourrions ajouter deux plus deux, puis affirmer que la réponse devrait être égale à quatre. Si pour une raison quelconque le calcul est incorrect, le script lancera une exception.

La syntaxe est la suivante :

assert sumVariable==4, “sumVariable should equal 4.”

Avec Selenium WebDriver, une étape d’un cas de test comprend généralement les actions suivantes.

1. Localiser un élément web affiché.
2. Agir sur cet élément
3. S’assurer que la situation s’est bien déroulée.

Pour la première action (1), si l’élément n’est pas trouvé, ou est trouvé dans un état incorrect, une exception est levée.

Pour l’action deux (2), si la tentative d’agir sur l’élément web échoue, une exception est levée.

Pour l’action trois (3), nous pouvons utiliser une assertion pour vérifier que le comportement attendu s’est produit, ou que la valeur attendue a été reçue.

Fondamentalement, cela suit la façon dont un testeur manuel effectuerait ces étapes et permet à la personne qui évalue un test échoué de comprendre ce qui s’est passé.

Le reporting s’appuie sur l’enregistrement des logs d’exécution, mais ils sont différents. L’enregistrement des logs d’exécution fournit des informations sur l’exécution des scripts automatisés à l’analyste de test qui a lancé la suite de test, et au(x) automaticien(s) responsable(s) de la correction des tests si nécessaire. Le reporting consiste à fournir cette information d’exécution ainsi que d’autres informations contextuelles aux divers intervenants, à l’extérieur comme à l’extérieur, qui en ont besoin ou qui les souhaitent.

Il est important que les automaticiens de test déterminent qui veut ou a besoin de rapports d’exécution des tests, et quelles informations les intéressent. Envoyer les enregistrements d’exécutions tels quels aux parties prenantes les submergerait certainement avec une masse d’informations sur l’exécution dont ils n’ont ni besoin ni envie.

Une façon de gérer les rapports est de les créer à partir des logs et d’autres informations et de les mettre à la disposition des parties prenantes pour qu’elles puissent les télécharger quand elles le souhaitent. L’autre moyen est de créer et d’envoyer les rapports dès qu’ils sont prêts aux parties prenantes qui le souhaitent.

Dans les deux cas, il faut chercher à automatiser la création et la diffusion des rapports pour supprimer une tâche manuelle à réaliser.

Les rapports doivent contenir un résumé avec un aperçu du système testé, de l’environnement ou des environnements sur lesquels les tests ont été réalisés et des résultats obtenus pendant l’exécution. Comme nous l’avons mentionné, chaque partie prenante peut vouloir avoir une vision différente des résultats et ces besoins doivent être satisfaits par l’équipe d’automatisation. Souvent, les parties prenantes peuvent vouloir voir les évolutions des résultats des tests, et pas seulement à un moment précis dans le temps. Comme chaque projet a probablement des intervenants différents ayant des besoins différents, plus les tâches de production de rapports sont automatisées, plus il sera facile d’y parvenir.

3.2 – Naviguer dans différentes URLs (K3)

3.2.1     Démarrer une session d’automatisation des tests

Il existe de nombreux navigateurs différents que vous pourriez vouloir tester. Bien que la tâche de base d’un navigateur soit de permettre à l’utilisateur de visualiser et d’interagir avec diverses pages Web, il est probable que chaque navigateur ait un comportement un peu différent des autres navigateurs.

Au début d’Internet, il arrivait que certaines pages web ne fonctionnaient que dans Netscape, alors que d’autres ne fonctionnaient correctement que dans IE. Heureusement, la plupart de ces problèmes ont disparu depuis longtemps, bien qu’il y ait encore quelques incompatibilités entre les navigateurs. Lorsqu’une organisation veut mettre en place un site Web, des tests doivent donc être effectués sur différents navigateurs afin de vérifier la compatibilité.

Au chapitre 1.4, lorsque nous avons introduit Selenium WebDriver pour la première fois, nous avons mentionné que différents navigateurs nécessitaient différents pilotes pour s’assurer que les scripts automatisés que nous écrivons fonctionnent avec les différents navigateurs de la liste suivante :

• Chrome (chromedriver.exe)
• Internet Explorer (IEDriverServer.exe)
• Edge (MicrosoftWebDriver.msi)
• Firefox (geckodriver.exe)
• Safari (safaridriver)
• HtmlUnit (HtmlUnit driver)

Par exemple, si nous voulons tester le navigateur Chrome, nous devons d’abord télécharger le pilote Chrome (commodément nommé chromedriver.exe) et installer ce fichier à un endroit bien défini du poste de travail du testeur. Ceci est généralement réalisé en éditant la variable d’environnement Path pour que votre système d’exploitation la trouve quand il en a besoin.

Veuillez noter que, comme c’est souvent le cas avec les aspects techniques, ces fichiers de pilotes et les informations nécessaires à leur utilisation peuvent changer. L’information contenue dans ce syllabus a été vérifiée et est valide au moment où elle a été rédigée. Mais cela peut évoluer. La meilleure chose qu’un automaticien puisse faire est de se familiariser avec la documentation accessible sur les différents sites web de support pour les différents navigateurs, et le site de support Selenium WebDriver.

Pour travailler avec des pages Web, vous devez d’abord ouvrir un navigateur Web. Ceci peut être réalisé en créant un objet WebDriver. L’instanciation de l’objet WebDriver crée l’interface de programmation entre un script et le navigateur Web. Il exécutera également un processus WebDriver si besoin est pour un navigateur Web particulier. En général, il lancera également le navigateur Web lui-même.

from selenium import webdriver
driver= webdriver.Chrome()

Figure 20: Code pour créer un objet WebDriver 

Ce code ne fonctionnera qu’après l’installation du fichier  chromedriver.exe comme indiqué précédemment.

La création d’un objet WebDriver démarre un navigateur Web avec une page vide. Pour naviguer à la page de site désirée, la fonction get() doit être utilisée. Notez que la fonctionnalité de l’objet pilote est accessible en utilisant la notation “.” car Python est un langage orienté objet.

driver.get('https://www.python.org')

Figure 21: Se positionner sur l’URL

Il est également possible d’attacher un objet WebDriver à un processus Webdriver existant ou de créer un processus WebDriver et de le rattacher à un navigateur déjà lancé via Selenium RemoteWebDriver, mais ces aspects ne sont pas couverts par ce syllabus.

Après avoir ouvert une page ou navigué vers une page différente, il est conseillé de vérifier si la page correcte a été ouverte. L’objet WebDriver contient deux attributs utiles pour cela : current_url et title. La vérification des valeurs de ces champs permet au script de garder la trace de sa page courante.

assert driver.current_url =='https://www.python.org/', ErrMsg
assert driver.title =='Welcome to Python.org', ErrMsg
Figure 22: Assertion de la page correcte

3.2.2    Navigation et rafraîchissement des pages

Lorsque vous avez besoin de simuler la navigation avant et arrière dans le navigateur Web, vous devez utiliser les méthodes back() et forward() de l’objet WebDriver. Ils enverront les commandes appropriées au WebDriver. Ces méthodes n’ont pas d’arguments.

driver.back()
driver.forward()
Figure 23: Navigation dans l’historique du navigateur

Il est également possible de rafraîchir la page en cours avec le navigateur Web. Ceci peut être fait en appelant la méthode refresh() de WebDriver.

driver.refresh()
Figure 24: Rafraîchissement du navigateur

3.2.3    Fermeture du navigateur

À la fin du test, vous devez fermer le processus du navigateur Web et tous les autres processus du pilote qui ont été exécutés. Si vous ne fermez pas le navigateur, il restera ouvert même une fois le test terminé. Il est conseillé de replacer l’environnement de test dans le même état que celui dans lequel le(s) test(s) a (ont) commencé. Cela permet d’exécuter un nombre indéfini de tests sans intervention humaine.

Pour fermer le navigateur contrôlé par webdriver, appelez la méthode quit() de l’objet webdriver.

driver.quit()
Figure 25: Fermeture du navigateur complet

Vous devez placer la fonction quit() dans la partie du script de test qui est exécutée quel que soit le résultat du test. Une erreur courante consiste à considérer la fermeture du navigateur comme l’une des étapes de test ordinaires. Dans ce cas, lorsque le test échoue, la bibliothèque d’exécution de test arrête l’exécution des étapes de test et l’étape qui est responsable de la fermeture du navigateur n’est jamais exécutée. Généralement, les bibliothèques de test ont leurs propres mécanismes de définition et d’exécution du code de fin d’exécution du test – appelé « tear down » en anglais -, par exemple, les méthodes tearDown() du module Python unittest. Il faut vous référer à la documentation de la bibliothèque que vous utilisez pour obtenir plus de détails à ce sujet.

cur_win =driver.title
Figure 26: Obtenir le titre de la fenêtre active

Si plusieurs onglets sont ouverts dans le navigateur testé, vous pouvez déterminer lequel des onglets est ouvert en vérifiant le titre de la fenêtre en cours en utilisant la commande suivante :

driver.close()
Figure 27: Fermeture de l’onglet actif

Si vous ne voulez pas quitter tout le navigateur et seulement fermer un onglet dans le navigateur, utilisez la fonction ci-dessus et déplacez-vous dans les onglets jusqu’à ce que vous arriviez dans la fenêtre à fermer. Puis fermez l’onglet en utilisant la méthode close(). Lorsque le dernier onglet ouvert est fermé, le processus du navigateur se termine automatiquement.

Cette méthode ne prend aucun paramètre et ferme l’onglet actif. N’oubliez pas de changer le contexte sur l’onglet désiré pour pouvoir fermer cet onglet. Une fois la fermeture effectuée, l’appel de toute autre commande WebDriver autre que driver.switch_to.window() lèvera alors une exception NoSuchWindowException puisque la référence objet pointe toujours sur la fenêtre qui n’existe plus. Vous devez passer de manière proactive à une autre fenêtre avant d’appeler une méthode WebDriver. Après avoir changé d’onglet, vous pouvez vérifier le titre pour déterminer quel onglet est maintenant actif. Nous abordons ci-dessous le contrôle des onglets multiples.

3.3 – Changer le contexte de la fenêtre (K3)

Parfois, lorsque vous testez des applications ou des scénarios plus complexes, vous devrez changer le contexte courant de l’interface graphique que vous testez. Cela peut être dû à la nécessité de vérifier le résultat du test dans un autre système ou d’exécuter une étape de test dans une autre application.

Il peut aussi arriver que l’interface graphique de l’application que vous testez soit si complexe que vous aurez besoin de passer d’un cadre ou d’une fenêtre à l’autre.

Un navigateur Web n’a pas besoin d’avoir le focus pour pouvoir exécuter des commandes Selenium Webdriver, car le protocole WebDriver est basé sur la communication HTTP. Ceci permet à WebDriver d’exécuter plusieurs tests simultanément ou de contrôler plusieurs navigateurs dans un seul script.

Changer le contexte du script peut se faire de trois façons :

• changer d’instance de navigateur
• changer de fenêtre ou d’onglet au sein d’un même navigateur
• changer de cadre dans une page

Pour ouvrir deux navigateurs, vous devez créer deux objets WebDriver. Chaque objet WebDriver contrôle un navigateur. Chaque objet WebDriver est ensuite utilisé dans le script de test conformément aux étapes du scénario de test automatisé. Les objets WebDriver peuvent contrôler le même type de navigateur Web (par exemple, Chrome, Firefox) ou des types différents (par exemple, un Chrome et l’autre Firefox). Vous pouvez également ouvrir plus de deux navigateurs si nécessaire. Rappelez-vous que chaque navigateur est contrôlé par un objet WebDriver. Et n’oubliez pas de fermer tous les navigateurs à la fin du test.

Ouvrir plusieurs onglets ou fenêtres dans un même navigateur peut se révéler compliqué, car les différents navigateurs et systèmes d’exploitation ont des méthodes différentes pour le faire. Une façon qui fonctionne pour Windows dans le navigateur Chrome est d’exécuter un appel de fonction en code JavaScript comme suit :

driver.execute_script("$(window.open('')")
Figure 28: Appel JavaScript pour ouvrir un nouvel onglet

Une présentation plus approfondie de l’ouverture de plusieurs onglets/fenêtres dans un navigateur Web n’entre pas dans le cadre de ce syllabus.

Pour basculer entre les onglets ouverts dans un navigateur, vous devez d’abord obtenir la liste de tous les onglets ouverts. Cette liste se trouve dans l’attribut window_handles de l’objet WebDriver. Sachez que l’ordre des onglets dans le tableau window_handles peut être différent de celui des onglets dans le navigateur.

Vous pouvez faire défiler tous les onglets/fenêtres en utilisant le code suivant :

for handle in driver.window_handles:
    driver.switch_to.window(handle)
Figure 29: Parcourir les onglets ouverts

La façon la plus sûre de déterminer quelle fenêtre est la fenêtre actuellement ouverte est d’utiliser l’attribut driver.title mentionné précédemment.

Le code Python suivant ouvre la page d’accueil de Python, ouvre un nouvel onglet, puis ouvre la page d’accueil de Perl dans le deuxième onglet, puis ramène le navigateur Web dans l’onglet contenant la page d’accueil de Python :

From selenium import webdriver
driver = webdriver.Chrome()
driver.get('http://python.org')
driver.execute_script("$(window.open('')")
driver.switch_to.window(driver.window_handle[1])
driver.get('https://perl.org')
driver.switch_to.window(driver.window_handle[0])

Figure 30: Ouvrir deux onglets et passer d’un onglet à l’autre

Veuillez noter que ce code n’est pas valide pour un test de production réel car il suppose que les contrôles de l’onglet seront dans l’ordre. Il ne sert qu’à des fins de référence. Pour visualiser le déroulement de ce code, ajoutez des fonctions sleep() pour qu’il ne soit pas exécuté trop rapidement pour en voir le résultat à l’affichage.

La troisième situation où vous pouvez vouloir changer de contexte dans un navigateur Web est le changement de cadre (“frame” en anglais). Ceci est souvent nécessaire ; si vous ne changez pas le contexte d’un cadre particulier, vous ne serez pas en mesure de trouver des éléments dans ce cadre, et donc d’automatiser les tests pour les éléments de ce cadre.

Pour modifier le contexte d’un cadre spécifique, vous devez d’abord trouver ce cadre. Si vous connaissez l’ID du cadre, vous pouvez directement y accéder, comme suit :

driver.switch_to.frame('foo')
Figure 31: Changer de cadre

où foo est l’ID du cadre sur lequel vous voulez changer le contexte.

Si le cadre n’a pas d’ID ou si vous voulez utiliser une stratégie différente pour le trouver, le changement de contexte peut se faire en deux étapes. La première étape, comme mentionnée plus haut, est de trouver le cadre comme un élément web, et la deuxième étape est de passer au cadre trouvé. La bascule dans ce cas est exécutée par la même méthode que la bascule par identifiant, mais l’argument donné à une fonction est l’élément web trouvé.

Voici une section du code Python qui montre un exemple de basculement de cadre dans lequel trouver le cadre est la première étape :

frm_message = driver.find_element_by_name('messase')
driver.switch_to_frame(frm_message)
Figure 32: Trouver puis changer de cadre

Notez que lors de l’appel à switch_to.frame(), nous n’utilisons pas d’apostrophes ni de guillemets, car nous passons la variable frm_message en argument variable plutôt qu’une chaîne contenant l’ID du cadre.

Si vous voulez revenir au cadre parent, utilisez la commande suivante :

driver.switch_to.parent_frame()
Figure 33: Basculer vers le parent du cadre

Vous pouvez aussi revenir à la page entière en utilisant :

driver.switch_to.default_content()
Figure 34: Passage à la fenêtre principale

Outre la modification du contexte d’une fenêtre ou d’un cadre du navigateur Web, le framework Selenium WebDriver vous permet de manipuler la taille de la fenêtre du navigateur Web. Le terme fenêtre est ici utilisé comme désignant toute la fenêtre vue du système d’exploitation, plutôt qu’un simple onglet dans un navigateur Web.

Selenium permet de minimiser et de maximiser les fenêtres du navigateur Web et de le mettre en mode plein écran. Les raccourcis Python pour cette fonction sont les suivants :

maximize: driver.maximize_window()
minimize: driver.minimize_window()
fullsreen: driver.fullsreen_window()
Figure 35: Dimensionnement du navigateur

Ces fonctions ne prennent aucun argument, car elles fonctionnent sur le navigateur web contrôlé par l’objet driver.

3.4 – Capturer des captures d’écran de pages Web (K3)

Lorsqu’un testeur manuel exécute un cas de test, il interagit visuellement avec les objets de l’interface graphique à l’écran. En cas d’échec d’un cas de test, les testeurs manuels peuvent le constater car ce qu’ils voient à l’écran n’est pas correct.

Un testeur utilisant l’automatisation n’a pas cette possibilité.

Les scripts d’automatisation des tests ne sont pas en mesure de vérifier de manière fiable la mise en page et l’apparence des pages Web. Il est souvent utile de prendre des captures d’écran d’une page ou d’un élément particulier de l’écran et de les enregistrer dans les logs ou à un emplacement connu, afin de pouvoir les visualiser ultérieurement, dans les cas suivants :

• Lorsque le script automatisé détecte qu’une défaillance s’est produite.
• Lorsque le test est très visuel et que la détermination de la réussite ou de l’échec ne peut se faire qu’en visualisant l’image de l’écran.
• Lorsqu’il s’agit de logiciels critiques pour la sûreté ou la mission, qui pourraient nécessiter un audit des tests.
• Lors des tests de configuration sur différents systèmes.

Pour tirer profit des informations fournies par les captures d’écran, elles doivent être prises au bon moment. Généralement, les parties des scripts de test qui font des captures d’écran sont placées juste après les étapes de test qui contrôlent l’interface utilisateur ou dans les fonctions de fin de test (étape « tear down »). Mais comme ces captures sont un outil précieux pour comprendre les résultats des tests automatisés, ces captures peuvent être réalisées à tout endroit jugé utile du script.

Une question importante à traiter est de nommer les fichiers avec des noms et des emplacements uniques afin que votre automatisation n’écrase pas les captures d’écran effectuées plus tôt dans l’exécution. Il y a une variété de façons différentes de le faire ; mais cela dépasse le cadre de ce syllabus.

Les captures d’écran peuvent être prises selon deux portées différentes : la page entière du navigateur, ou un seul élément dans la page du navigateur. Les deux méthodes utilisent le même appel de fonction mais sont appelées à partir de contextes différents.

L’appel de méthode à utiliser est screenshot(). L’exemple suivant en Python montre comment faire une capture d’écran d’une page entière et la placer à un endroit spécifique :

driver.get_screenshot_as_file('C:\\temp\\screenshot.png')
Figure 36: Enregistrement d’une capture d’écran d’une page entière

Cet exemple montre comment faire une capture d’écran d’un élément et l’enregistrer à un emplacement spécifique :

ele = driver.find_element_by_id('btnLogin')
ele.screenshot('c:\\temp\\element_screenshot.png')
Figure 37: Enregistrer la capture d’écran de l’élément

La réalisation d’une capture d’écran dans le navigateur peut prendre un certain temps car une grande partie du traitement doit être effectuée par le poste de travail. Si l’état de l’interface graphique change rapidement (par exemple, en exécutant simultanément des bibliothèques AJAX), la capture d’écran prise peut ne pas montrer l’état exact de la page ou l’élément attendu. De nouveau, il existe des solutions à cette situation, mais elles dépassent le cadre de ce syllabus.

Si vous voulez prendre une capture d’écran et la traiter autrement que comme un fichier, il existe des alternatives dans WebDriver. Par exemple, supposons qu’au lieu d’utiliser un fichier HTML pour un log, vous souhaitiez vous connecter à une base de données à la place. Lorsque vous prenez une capture d’écran, ou d’un élément, vous ne voulez pas créer un fichier *.png avec cette capture, mais vous voudrez peut-être la lire directement dans un enregistrement de base de données. Les appels suivants créeraient une image en tant que chaîne de caractères codée base64 de la capture d’écran. La version codée base64 est beaucoup plus sûre à lire en continu qu’un fichier binaire, tel qu’un fichier *.png. Le premier appel ci-dessous capturera la totalité de la fenêtre, le second un seul élément :

img_b64 = driver.get_screenshoot_as_base64()
img_b64 = element.screenshoot_as_base64()
Figure 38: Création d’une chaîne encodée en base64 à partir d’une image

De même, si vous voulez obtenir une chaîne binaire représentant une image, sans l’enregistrer dans un fichier, vous pouvez utiliser les appels suivants pour retourner la représentation binaire d’un fichier *.png. Le premier appel renvoie l’image d’un écran entier, le second renvoie l’image d’un seul élément :

png-str = driver.get_screenshoot_as_png()
png-str = element.screenshoot_as_png()
Figure 39: Création d’une chaîne binaire à partir d’une image

3.5 – Localiser les éléments de l’interface graphique (K4)

3.5.1     Introduction

Pour effectuer la plupart des opérations avec WebDriver, vous devez localiser les éléments de l’interface utilisateur sur lesquels vous voulez opérer dans l’écran actuellement actif.

Ceci peut être réalisé en utilisant les méthodes find_element_ ou find_elements_ de WebDriver. Ces deux méthodes ont des actions différentes selon l’objet de la recherche. Pour la recherche, par exemple, les éléments suivants peuvent être utilisés :

• by_id (id_)
• by_class_name (name)
• by_tag_name (name)
• by_xpath (xpath)

• by_css_selector (css_selector)

Dans chaque cas, l’argument pris par la fonction est une chaîne représentant le ou les éléments que nous recherchons. Les valeurs de retour sont différentes ; par exemple, la version au singulier (find_element_) retournera un seul des éléments Web (si un est trouvé) et la version multiple (find_elements_) retournera une liste des éléments Web qui correspondent à cet argument.

Pour ce faire, nous devons introduire un concept utilisé dans le développement et les tests web : le DOM (Document Object Model). Lorsqu’une page Web est chargée dans le navigateur, le navigateur crée un DOM, modélisant la page Web comme une arborescence d’objets. Ce DOM définit un standard pour accéder à la page web. Comme défini par le W3C :

” Le Document Object Model (DOM) du W3C est une interface neutre en termes de plate-forme et de langage qui permet aux programmes et aux scripts d’accéder dynamiquement au contenu, à la structure et au style d’un document et de les actualiser.”

 Le DOM définit :

• Tous les éléments HTML en tant qu’objets.
• Les propriétés de tous les éléments
• Les méthodes qui peuvent être utilisées pour accéder à tous les éléments
• Les événements qui affectent tous les éléments

Figure 40: Arborescence DOM

3.5.2     HTML Methods

Les méthodes suivantes dépendent de la recherche d’éléments de l’écran en recherchant des artefacts HTML dans le document. La première méthode que nous allons discuter est l’utilisation de l’attribut HTML ID. Pour chaque façon différente de localiser un élément Web, il y a des avantages et des inconvénients possibles.

 
Figure 41: Extrait HTML

Exemple de localisation Python WebDriver :

element_found = driver.find_element_by_id("unique_id") 
Figure 42: Localisation par ID

Avantages :

• Façon performante de réaliser l’opération.
• Par définition, chaque ID doit être unique dans le document HTML.
• Un testeur peut facilement ajouter des ID au SUT (note : ces changements doivent être revus et vérifiés au moins sous la forme d’une revue informelle).

Inconvénients :

• Les IDs peuvent être générés automatiquement, ce qui implique qu’ils peuvent être modifiés dynamiquement.
• Les ID ne sont pas appropriés pour le code qui est utilisé à plusieurs endroits, par exemple, un template utilisé pour générer des en-têtes et des pieds de page pour différents modes de dialogue.
• Il se peut qu’un testeur ne soit pas autorisé à modifier le code du SUT.

La deuxième façon de trouver un élément web est de le trouver en recherchant son nom de classe. Il s’agit de l’attribut class HTML d’un élément DOM, par exemple, dans cet extrait HTML :

 
Figure 43: Extrait HTML

Exemple de localisation WebDriver en Python :

element_found = driver.find_element_by_class_name('class-name1') 
Figure 44: Localiser par classe

Avantages :

• Les noms de classes peuvent être utilisés à plusieurs endroits dans le DOM, mais vous pouvez limiter la localisation à la page chargée (par exemple dans une fenêtre popup modale).
• Un testeur peut facilement ajouter des noms de classes au SUT (note : ces changements doivent être revus et vérifiés au moins sous la forme d’une revue informelle).

Inconvénients :

• Comme les noms de classe peuvent être utilisés à plusieurs endroits, il faut faire plus attention de ne pas localiser le mauvais élément.
• Il se peut qu’un testeur ne soit pas autorisé à modifier le code du SUT

La troisième façon de réaliser la localisation d’un élément web est d’utiliser le nom de balise HTML de l’élément. Il s’agit du nom de la balise DOM d’un élément, par exemple, dans cet extrait HTML :

Figure 45: Tag HTML

Exemple de localisation Python WebDriver :

heading2_found = driver.find_element_by_tag_name('h2') 
Figure 46: Localisation par Tag

Avantage : Si une balise est unique à une page, vous pouvez restreindre l’endroit où chercher.

Inconvénient : Si une balise n’est pas unique à une page, vous pouvez trouver le mauvais élément.

Notre quatrième façon d’identifier l’élément web est d’utiliser le texte du lien. Il s’agit uniquement d’une balise a ancre qui contient du texte qui sera surligné pour qu’un utilisateur puisse cliquer dessus. Il existe en fait deux méthodes similaires : vous pouvez spécifier la chaîne de texte entière ou une partie de la chaîne. Par exemple, dans l’extrait HTML suivant, le texte du lien a été mis en gras pour l’identifier :

XyzAbc.


  Next Page
    Figure 47: Extrait HTML

Exemples de localisation Python WebDriver :

element = driver.find_element_by_link_text('Next Page') 
Figure 48: Localisation par  texte de lien

element = driver.find_element_by_partial_link('Next Pa') 
Figure 49: Localisation par texte de lien partiel

Avantages :

• Si le texte du lien est unique à une page, vous pouvez trouver l’élément.
• Le texte du lien est visible par l’utilisateur (dans la plupart des cas), il est donc facile de savoir ce que le code de test
• Un texte de lien partiel est un peu moins susceptible d’être modifié que le texte intégral du lien.

Inconvénients :

• Le texte du lien est plus susceptible de changer qu’un ID ou un nom de classe.
• L’utilisation d’un texte partiel peut rendre plus difficile l’identification unique d’un lien unique.

3.5.3     Méthodes XPath

Comme indiqué dans la section 2.2, XPath (XML Path Language) est un langage qui peut être utilisé pour sélectionner des nœuds spécifiques à l’aide de différents critères dans un document XML. Par exemple, prenons le fragment HTML suivant. Comme HTML est un sous-ensemble de XML, il peut être parcouru à l’aide de XPath. À noter que des erreurs peuvent apparaitre si le HTML est mal formé (p. ex. si toutes les balises de fermeture ne sont pas incluses).

Figure 50: Extrait HTML

WebDriver peut utiliser XPath pour trouver un nœud spécifique, et à partir de là, un élément peut être localisé. Vous pouvez spécifier un chemin absolu, mais c’est une mauvaise pratique, car tout changement invaliderait probablement votre code. Une meilleure façon est d’identifier un chemin relatif à partir d’un nœud trouvé qui correspond à un critère. Ci- dessous se trouve un exemple de spécification d’un chemin absolu, puis d’une version plus robuste trouvant l’élément souhaité via XPath. Les deux renverront le deuxième champ d’entrée dans l’extrait HTML.

element = driver.find_element_by_xpath('/html/body/form[2]') 
Figure 51: Utilisation de XPath avec chemin absolu

element = driver.find_element_by_xpath("//form[@id='sample_form1']/input[2]") 
Figure 52: Utilisation de XPath avec chemin relatif

L’utilisation du chemin relatif demandera souvent une expression XPath plus longue, mais il sera beaucoup plus robuste pour trouver le nœud désiré. C’est un bon compromis.

Dans une chaîne XPath, vous pouvez rechercher un identifiant, un nom, une classe, un nom de balise, etc. Ainsi, il est possible de créer des fonctions de localisation génériques en utilisant XPath en passant un type d’attribut à la fonction, ou une chaîne de chemin qui incorpore l’attribut dans celle-ci. Par exemple :

def find_by_xpath(driver, path_string):
  element = driver.find_element_by_xpath('path_string')
  return element
Figure 53: Fonction de recherche générique XPath

La variable path_string peut alors être définie en fonction de l’attribut que nous cherchons à localiser. Ci-dessous deux exemples, la première recherche par identifiant, la seconde recherche par classe :

path_string = "//*[@id = '%s']" %'id_to_find'
path_string = "//*[@class = '%s']" %'class_to_find'
Figure 53: Fonction de recherche générique XPath

L’appel de la fonction générique s’effectuerait alors de la manière suivante :

element_found = find_element_by_xpath(driver, path_string)
Figure 55: Appel de la fonction XPath générique

Cette méthode n’est pas élégante, mais elle montre la flexibilité de XPath pour localiser des éléments.

Avantages :

• Vous pouvez trouver des éléments qui n’ont pas d’attributs uniques (id, classe, nom, etc.).
• Vous pouvez utiliser XPath dans les localisateurs génériques, en utilisant les différentes stratégies “By” (par id, par classe, etc.) si nécessaire.

Inconvénients :

• Le code XPath absolu est ” fragile ” et peut ne pas fonctionner après un petit changement dans la structure HTML.
• Le code XPath relatif peut trouver le mauvais nœud si l’attribut ou l’élément que vous recherchez n’est pas unique sur la page.
• Comme XPath peut être implémenté différemment d’un navigateur à l’autre, des efforts supplémentaires peuvent être nécessaires pour exécuter des tests WebDriver dans chaque environnement.

3.5.4  Méthodes de sélection CSS

Comme nous l’avons vu dans la section 2.3, nous pouvons également trouver des éléments à l’aide de sélecteurs CSS. Par exemple, dans cet extrait HTML :

Some Latin nonsense.


    Figure 56: Extrait HTML

En utilisant les règles des Sélecteurs CSS, décrites à la section 2.3, le code suivant identifiera le nœud souhaité :

element = driver.find_element_by_css_selector('p.paragraph') 
Figure 57: Identification d’un élément WebElement via le sélecteur CSS

Avantage: Si un élément est unique à une page, vous pouvez restreindre l’endroit où vous cherchez.

Inconvénient : Si un élément n’est pas unique à une page, vous pouvez trouver le mauvais élément.

3.5.5     Localisation via des conditions prédéfinies

Selenium avec Python intègre a un module appelé expected_conditions qui peut être importé à partir de selenium.webdriver.support avec des conditions prédéfinies. Vous pouvez créer des classes de conditions personnalisées, mais les classes prédéfinies devraient satisfaire la plupart de vos besoins. Ces classes offrent une plus grande spécificité que les localisateurs mentionnés ci-dessus. En d’autres termes, ils ne se contentent pas de déterminer si un élément existe, ils permettent aussi de vérifier les états spécifiques dans lesquels cet élément se trouve. Par exemple, la fonction element_to_be_selected() détermine non seulement que l’élément existe, mais elle vérifie également s’il est dans un état sélectionné.

Cette liste n’est pas exhaustive, mais en donne quelques exemples :

• alert_is_present
• element_selection_state_to_be(element, is_selected)
• element_to_be_clickable(locator)
• element_to_be_selected(element)
• frame_to_be_available_and_switch_to_it(locator)
• invisibility_of_element_located(locator)
• presence_of_element_located(locator)
• text_to_be_present_in_element(locator, text_)
• title_is(title)
• visibility_of_element_located(locator)

Nous en discutons plus en détail à la section 4.2, puisque plusieurs d’entre eux sont également utilisés comme mécanismes d’attente.

3.6 – Obtenir l’état des éléments de l’interface graphique (K3)

Obtenir simplement l’emplacement d’un élément web spécifique n’est souvent pas suffisant. Pour l’automatisation des tests, il peut y avoir plusieurs raisons différentes pour lesquelles nous avons également besoin d’accéder à certaines informations sur un élément.

L’information peut inclure sa visibilité actuelle, si elle est activée ou non, ou si elle est sélectionnée ou non. Les raisons en sont notamment les suivantes :

• S’assurer que l’état est tel que prévu à un moment donné du test.
• S’assurer qu’un contrôle est dans un état tel qu’il puisse être manipulé selon les besoins dans le cas de test (c.-à-d., activé).
• S’assurer qu’après que le contrôle a été manipulé, il est maintenant dans l’état prévu.
• S’assurer que les résultats attendus sont corrects après l’exécution d’un test.

Différents éléments web ont différents moyens d’accéder aux informations qu’ils contiennent. Par exemple, de nombreux éléments web ont une propriété texte qui peut être récupérée en utilisant le code suivant :

element_text = Element.text
Figure 58: Récupération d’une propriété texte

Tous les éléments web n’ont pas de propriété texte. Par exemple, si nous examinons un nœud d’en-tête (éventuellement en utilisant une méthode find_by_css_selector(‘h1’)), nous nous attendons à ce qu’il ait une propriété texte. D’autres éléments web peuvent ne pas avoir la même propriété. Le contexte d’un élément web et la façon dont il est utilisé peuvent vous aider à comprendre les propriétés qu’il est susceptible d’avoir.

Certaines propriétés d’un élément web doivent être accédées à l’aide d’une méthode de la classe WebElement. Par exemple, supposons que vous souhaitiez déterminer si un élément web particulier est actuellement activé ou désactivé. Vous pouvez appeler la méthode suivante pour obtenir cette valeur booléenne :

cur_state = element.is_enabled() 
Figure 559: Vérifier si WebElement est activé

Le tableau suivant n’est pas exhaustif, mais il énumère un ensemble de propriétés communes et de méthodes d’accès dont vous pouvez avoir besoin pour l’automatisation.

Table 16: Propriétés communes et méthodes d’accès

3.7 – Interagir avec les éléments de l’interface utilisateur à l’aide des commandes WebDriver (K3)

3.7.1     Introduction

Vous avez donc localisé l’élément web avec lequel vous voulez que votre test automatisé interagisse (voir la section 3.5). Vous vous êtes assuré que l’élément est dans l’état correct, de sorte que vous pouvez le manipuler selon votre cas de test (discuté dans la section 3.6). À présent, il convient de réaliser l’action voulue dans le script de test automatisé.

L’une des raisons principales pour lesquelles les interfaces utilisateur graphiques sont devenues courantes est qu’il existe un ensemble limité de commandes qui peuvent être manipulées ; chaque commande est essentiellement un contrôle à l’écran qui peut être facilement manipulé en utilisant le clavier et/ou la souris. Chaque contrôle est conçu pour être compris de façon intuitive, même par les utilisateurs débutants. Ainsi, je peux taper dans un champ texte, cliquer sur un bouton radio, sélectionner un élément dans une zone de liste, etc.

L’automatisation de la manipulation de ces contrôles peut toutefois être plus difficile à comprendre. Ce qu’un testeur réalise lors de l’exécution manuelle des tests est souvent fait inconsciemment. En tant qu’automaticiens, nous devons nous assurer que nous comprenons toutes les subtilités des modifications qui sont faites aux contrôles à l’écran.

Dans les prochaines sections, nous discuterons de la manipulation des éléments suivants :

• Champs texte
• Éléments web cliquables (champs sur lesquels vous pouvez cliquer)
• Cases à cocher
• Listes déroulantes

Pour tout élément web que vous souhaitez manipuler, vous avez plusieurs aspects à vérifier :

• Si l’élément web existe
• Si l’élément web est affiché
• Si l’élément web est activé

Selon le site Web, la façon dont le code HTML a été écrit, si Ajax est utilisé et d’autres conditions, il peut y avoir une disparité quant à la nécessité d’afficher ou non l’élément Web que vous voulez traiter pour que vous puissiez le manipuler. Par exemple, si l’élément web est sur la page active et qu’il est activé, mais qu’il a été placé hors de la vue, essayer de le manipuler peut ne pas fonctionner. Des tests effectués avec Chrome ont montré que, sur certaines pages, travailler avec un élément web non visible actuellement fonctionne et sur d’autres navigateurs, cela lève une exception. Notre conseil est d’essayer d’afficher à l’écran tous les éléments web que vous utilisez (affichés).

Puisqu’un écran de navigateur peut être modifié dynamiquement (via Ajax, par exemple) ou mis à jour sur la base d’actions précédentes, ces vérifications peuvent être effectuées en utilisant les classes expected_condition qui nous permettent de synchroniser les temporisations ; nous traitons cela dans le chapitre 4.

3.7.2     Manipulation des champs de texte

Lorsque vous saisissez dans un champ de texte modifiable, vous voudrez généralement d’abord effacer le texte de l’élément, puis saisir la chaîne souhaitée dans le champ. Nous supposons que vous avez déjà vérifié que l’élément existe, est affiché et est activé. Si vous ne vous assurez pas de l’état du contrôle, et qu’un ou plusieurs d’entre eux sont faux, votre tentative de manipulation de l’élément peut causer une exception.

Nous considérerons que vous avez déjà localisé le contrôle d’entrée, et qu’il se trouve dans la variable nommée element.

# First clear the control
element.clear()

# Now type into the control
string_to_type = 'XYZ' element.send_keys(string_to_type)
Figure 60: Saisir dans un champ d’édition

3.7.3  Cliquez sur des éléments web

Cliquer sur un élément simule un clic de souris. Ceci peut être fait sur un bouton radio, un lien ou une image ; en fait, tout endroit sur lequel vous pouvez cliquer manuellement avec votre souris. Nous n’incluons pas les cases à cocher ici ; elles seront abordées dans la prochaine section. Il est important de vérifier que l’élément web est réellement cliquable. Vous pouvez utiliser la méthode element_to_be_clickable de la classe expected_condition pour attendre qu’il devienne cliquable.

Nous supposons de nouveau que l’élément web a été localisé. Nous devons éventuellement attendre pour nous assurer qu’il est prêt à être cliqué, en utilisant une méthode de la classe expected_condition :

Driver.support.expected_conditions.element_to_be_clickable(locator) 
Figure 61: Méthode de synchronisation

La synchronisation sera abordée au chapitre 4. En supposant que l’élément web a été référencé dans la variable element et qu’il est cliquable, on peut appeler alors :

element.click() 
Figure 62:  Cliquer sur un élément web

Si l’élément web est un lien ou un bouton, on doit s’attendre à un changement de contexte qui peut être vérifié à l’écran. S’il s’agit d’une case à cocher, le résultat peut être sélectionné ou non sélectionné : ceci sera discuté dans la section suivante. S’il s’agit d’un bouton radio sur lequel on clique, vous pouvez vérifier que le bouton est bien sélectionné en appelant :

element.is_selected() 
Figure 663: Vérifier l’état d’un élément web

3.7.4     Manipulation des cases à cocher

Si nous cliquons sur les cases à cocher, elles doivent être traitées différemment des autres contrôles cliquables. Si vous cliquez plusieurs fois sur un bouton radio, il reste sélectionné. Cependant, chaque fois que vous cliquez sur une case à cocher, elle fait basculer l’état sélectionné. Cliquez une fois, désormais la case est çà l’état sélectionné. Cliquez à nouveau, la case redevient non sélectionnée. Cliquez à nouveau et vous revenez à l’option sélectionnée.

De ce fait, il est important de maîtriser l’état que l’on veut atteindre lors de la manipulation d’une case à cocher. Nous pouvons écrire une fonction qui utilisera la case à cocher et l’état désiré et effectuera l’action correcte quel que soit l’état actuel de la case à cocher.

Supposons que la case à cocher a été chargée dans la variable checkbox et qu’une variable booléenne want_checked soit passée pour déterminer l’état final que nous voulons.

# if we want it selected and it is not, then click on it 
# if we want it deselected and it is selected, then click on it 
def set_check_box(element, want_checked):
  if want_checked and not element.is_selected():
     element.click()
  elif element.is_selected() and not want_checked
    element.click() 
Figure 64: Fonction de sélection de la case à cocher

set_checkbox (checkbox, True) 
Figure 65: Appel de la fonction

3.7.5     Manipulation des menus déroulants

Les menus déroulants (contrôles de sélection) sont utilisés par de nombreux sites Web pour permettre aux utilisateurs de sélectionner une des options proposées. Certains de ces menus déroulants permettent de sélectionner simultanément plusieurs éléments de la liste.

Il existe de nombreuses façons de travailler avec la liste d’un champ de sélection. Il s’agit notamment d’options de sélection d’éléments simples ou multiples. Il existe également différentes façons de désélectionner des éléments.

Les options de sélection sont les suivantes :

• Cherchez dans le code HTML pour trouver un élément désiré et cliquez
• Sélectionner par une valeur (select_by_value(value))
• Sélectionner tous les éléments qui affichent le texte correspondant (select_by_visible_text(text))
• Sélectionner un élément par son index (select_by_index(index)) Les options de désélection sont les suivantes :
• Désélectionner tous les éléments (deselect_all())
• Désélectionner par index (deselect_by_index(index))
• Désélectionner par valeur (deselect_by_value(value))
• Désélectionner en fonction du texte visible (deselect_by_visible_text(text))

Une fois que vous avez fini de sélectionner/désélectionner les éléments dans la liste déroulante, il y a plusieurs options pour vous permettre de voir ce qui a été sélectionné :

• Retourner la liste de tous les éléments sélectionnés (all_selected_options)
• Retourner le premier élément sélectionné (ou un seul dans le cas d’un seul élément sélectionné) (first_selected_option)
• Voir toutes les options de la liste (options)

Puisque cliquer sur les éléments de la liste est une opération courante que nous devons faire, nous pouvons construire une fonction comme nous l’avons fait avec les cases à cocher. Dans ce cas, nous devons d’abord cliquer sur le bouton déroulant pour afficher la liste complète. Ensuite, une fois la liste ouverte, trouvez l’option désirée et cliquez dessus. Voici une fonction qui permet de réaliser cela.

def click_dropdown_option_by_id_and_id(driver, dropdown_id, option_id):
  dropdown_element  = driver.find_element_by_id('dropdown_id')
    dropdown_element.click()
    option_element = driver.find_element_by_id('option_id')
    option_element.click() 
Figure 66: Fonction pour cliquer sur l’élément de la liste déroulante

3.7.6    Travailler avec les boîtes de dialogue modal

Une boîte de dialogue modal s’ouvre au-dessus d’une fenêtre de navigateur et n’autorise pas l’accès à la fenêtre sous-jacente tant qu’elle n’a pas été traitée. Ces boîtes de dialogue sont similaires aux invites utilisateur, mais suffisamment différentes pour en discuter séparément. Nous aborderons les invites utilisateur, telles que les alertes, dans le prochain chapitre.

Généralement, ce type de boîtes de dialogue sont utilisées lorsque l’auteur du site Web souhaite obtenir des informations spécifiques de l’utilisateur (par exemple, un nom d’utilisateur/mot de passe) ou faire exécuter certaines tâches par l’utilisateur. Par exemple, sur un site de commerce électronique, l’ajout d’un article à un panier peut faire apparaître une fenêtre d’information comme suit :

Dans l’exemple ci-dessus, l’utilisateur peut choisir le chemin à suivre : passer à sa commande ou continuer ses achats. De plus, il est possible de présenter des informations supplémentaires dans le dialogue modal. Dans ce cas, le site de commerce électronique a pour but d’inciter l’utilisateur à acheter quelque chose d’autre en fonction de ce qu’il a placé dans le panier.

Tout le code de la boite de dialogue modal se trouve dans le code HTML qui a fait apparaître la boite de dialogue modal. Par conséquent, manipuler la boite de dialogue modal revient à trouver le code dans la page appelante et à la manipuler. Ceci suit les mêmes règles que pour localiser et manipuler les contrôles de formulaire que celles dont nous avons discuté précédemment.

Par exemple, supposons que nous voulions cliquer sur le bouton Proceed to Checkout dans cette boite de dialogue modal. La première étape serait de déterminer l’emplacement du code pour la boite de dialogue modal. Dans ce cas, l’ID de la section représentant l’élément modal est layer_cart. Nous allons créer une référence objet WebDriver pour cet élément du code de cette manière :

modal = driver.find_element_by_id('layer_cart') 
Figure 68: Recherche de l’élément modal

La tâche suivante serait d’identifier l’élément représentant le bouton en utilisant la fonctionnalité Inspecter du navigateur. Dans ce cas, le nom de classe du bouton est button_medium. Cette fois encore, nous voulons créer une référence à cet élément, afin de pouvoir le manipuler. Nous pouvons utiliser le code suivant :

proceed_button = modal.find_element_by_class_name('button_medium') 
Figure 69: Recherche d’un bouton dans l’élément modal

Une fois trouvé, cliquer sur le bouton équivaut à appeler la méthode click() pour cette référence :

proceed_button.click() 
Figure 70: Cliquer sur le bouton

À cette étape, la boîte de dialogue modale est fermée, et nous nous déplaçons vers un nouvel emplacement dans la fenêtre principale du navigateur, dans ce cas la page de résumé du panier d’achat est affichée comme indiqué ci-dessous :

Figure 71: Écran du panier d’achat

3.8 – Interagir avec les invites de l’utilisateur dans les navigateurs Web à l’aide des commandes WebDriver

Les invites utilisateur (appelée « User prompts » en anglais) sont des fenêtres modales dans lesquelles l’utilisateur doit interagir avec les commandes avant de pouvoir continuer à interagir avec les commandes de la fenêtre du navigateur elle-même.

Pour les besoins de l’automatisation, les invites utilisateur ne sont généralement pas traitées automatiquement. Par conséquent, si votre script essaie d’ignorer l’invite et de continuer à envoyer des commandes à la fenêtre du navigateur lui-même, une erreur d’ouverture d’alerte inattendue sera renvoyée par l’action suivante réalisée.

Chaque invite utilisateur est associée à un message d’invite utilisateur (qui peut être NULL). Il s’agit d’une zone de texte qui peut être saisie à l’aide du code indiqué ci-dessous.

Le W3C définit trois boîtes de dialogue de type alerte différentes :

• Alert
• Confirm
• Prompt

Comme ils sont définis de telle sorte qu’ils fonctionnent pratiquement tous de la même façon, nous abordons l’invite d’alerte (Alert).

La boîte de dialogue d’alerte est souvent utilisée pour s’assurer que l’utilisateur est informé de certaines informations importantes.

Comme les boîtes de dialogue d’alerte ne font pas partie de la page Web, elles nécessitent un traitement spécial. WebDriver utilisant Python dispose d’un ensemble de méthodes qui vous permettent de contrôler le dialogue d’alerte depuis votre script d’automatisation. Ces méthodes sont communes aux trois boîtes de dialogue d’invite utilisateur.

Ceci crée d’abord une référence en utilisant une méthode de l’objet WebDriver appelée

switch_to. La syntaxe pour utiliser cette méthode est la suivante :

alert = driver.switch_to.alert

Figure 72: Créer un objet d’alerte

Nous pouvons obtenir le texte dans l’alerte via :

msg_text = alert.text

Figure 73: Obtenir du texte à partir d’une alerte

Pour déterminer si le texte attendu se trouve dans l’alerte, passez dans l’alerte, récupérez le texte, puis vérifiez si le texte attendu se trouvait dans l’alerte. Si le texte est là, la variable passed sera mise à True. Si ce n’est pas le cas, la variable passed sera mise à False.


alert = driver.switch_to.alert
msg_text = alert.text
expected_text = 'XYZ'
assert expected_text in msg_text, "The expected text not found"

Figure 74: Comparaison du texte d’une alerte

Les boîtes de dialogue d’alerte peuvent être fermées de deux façons. Considérez la méthode accept() comme appuyant sur le bouton OK, et la méthode dismiss() comme appuyant sur le bouton Cancel, ou le bouton de fermeture de fenêtre dans le coin supérieur de l’invite.


alert = driver.switch_to.alert
alert.accept()
alert.dismiss()

Figure 75: Fermeture d’une alerte