Automatiser ses tests fonctionnels chez eXo Platform

“Espace numérique de travail” est un terme que l’on retrouve communément dans le langage courant.
test automatisé

Table des matières

1. Qu’est ce qu’un Test automatisé ?

Un test automatisé est un test dont l’exécution ne nécessite pas l’intervention d’un humain.
L’exécution de tests automatisés nécessite l’utilisation de solutions informatiques dont le but est d’exécuter des actions, soit spécifiquement dans un navigateur web, soit plus généralement au niveau du système d’exploitation.
L’automatisation du test peut significativement réduire les efforts nécessaires au test, et considérablement augmenter la quantité de tests effectués dans un temps limité. Certains tests peuvent être effectués en quelques minutes alors qu’ils auraient pris plusieurs heures s’ils avaient été exécutés manuellement.

2. Comment nous automatisons les tests chez eXo ?

2.1 Langages du développement et outils

Pour développer et exécuter les cas de test, nous avons besoin de l’environnement suivant:
  • Maven 3
  • JDK 8
  • Docker
L’outil d’automatisation des tests utilisé est le framework Selenide.

Pourquoi Selenide ?

Afin de départager les meilleurs outils, nous avons sélectionné des critères, que nous avons jugés essentiels, décrits dans le tableau ci-dessous.

SeleniumCodeceptionWindmillSahiCucumberSelenide
Open sourceOuiOuiOuiOui avec version ProOuiOui
Multi-navigateursOuiOuiOuiOuiOuiOui
Langage de développementJavaPHPPythonPHPPHPJava
Langage de script/testJavaScript PHP Python C# Java RubyPHPJavaScript Python RubyJavaScriptGherkin + javaJavaScript PHP Python C# Java
Communauté active et mises à jour régulièresImportanteImportanteFaibleFaibleBonneImportante
Record-playbackOuiOuiOuiOuiNooui
Identification intelligente des objetsNonNonNonOuiNonNon
Attente des évènements (Ajax)OuiOuiNonOuiNonOui
Génération de rapports de tests personnalisésOuiOuiOuiVersion Pro seulementPluginOui
FREE WHITE PAPER
Benefits of Open Source Software
for the Enterprise
The term open source refers to any solution that has its source code widely accessible to the public for modification and sharing.
D’après cette étude comparative, nous remarquons que les critères du choix du meilleur outil d’automatisation sont les mêmes pour Selenium et Selenide. Nous avons choisi Selenide à cause de sa simplicité de création des cas des tests expliquée dans ce lien : selenide vs selenium.

2.2 Développement des tests automatiques

Le choix des cas de tests à automatiser est basé sur plusieurs critères comme la fréquence de l’exécution, le temps du développement et de maintenance du cas du test, le temps d’exécution du cas du test …
Le diagramme ci dessous représente les différents critères pour sélectionner les cas qui vont être automatiser.
Les différents critères pour un test automatisé
Pour automatiser un cas de tests, nous devons passer par 3 étapes :

1 Déclaration des locators :

Les « locators » sont les variables déclarées dans les classes « Xlocators » pour sélectionner les éléments HTML utilisés dans les cas de test.
On peut trouver ces classes sous le module “Selenium”.
Classes sous le module Selenium
Ci-dessous quelques exemples des locators que nous utilisons:
Par “id”

public static final SelenideElement ELEMENT_ABOUT_ME_PORTLET=$(byId("UIExperienceProfilePortlet"));

Par “className”

public static final SelenideElement ELEMENT_BUTTON_ADD_GADGET=$(byClassName("AddIcon"));

Par “Xpath”

public static final SelenideElement ELEMENT_TAB_ACCESS_AND =  $(byXpath("//*[@id=\"UITabPane\"]/ul/li[2]/a"));
Il existe plusieurs façons pour définir le locator, il faudrait mieux prioriser la sélection par “id” s’il existe ou bien par “className” (s’il est unique).Si ce n’est pas le cas, nous pouvons utiliser le “xpath”, “value”, ”type”, ”name”…

2 Développement des fonctions à utiliser

Ces fonctions sont actions spécifiques que nous allons implémenter qui seront ensuite utilisées dans les cas de test.
Toutes les fonctions utilisées dans nos cas de tests se trouvent dans le package “pageobject” de chaque module. Par exemple, les fonctions utilisées pour les cas de tests wiki se trouvent sous le package “pageobject” du module wiki.
Les fonctions utilisées pour les cas de tests wiki
On doit utiliser les locators que l’on a déjà déclarés dans nos fonctions. L’image ci-dessous représente la fonction “ajouter un utilisateur” qui est très utilisée dans nos cas de test
Locators déclarés dans un cas de test

3 Développement des cas de tests

On trouve les classes qui contiennent les cas de tests Smoke (basic de priorité haute) sous le module concerné par ces tests. Par exemple, les tests smoke forum se trouvent sous le module forum.
Tests Smoke sous le module Forum
Les autres (Sniff et functional) se trouvent sous le module platform, car ils nécessitent des dépendances vers les autres modules.
Dans les classes de tests, le type de test est spécifié en utilisant l’annotation @Tag. Par exemple ce test est un test sniff de la fonctionnalité Answer:
Dans les cas de tests automatisés, on appelle les fonctions déjà créés pour exécuter le scénario souhaité.

3. Comment nous exécutons les tests automatiques ?

3.1 Exécution avec l’IDE et le navigateur en local

On peut exécuter un cas de test à travers l’IDE (Intellij) en passant les paramètres nécessaires dans VM_options(-ea -Dwebdriver.chrome.driver=<path-to-chrome-driver> -Dselenide.baseUrl=<exoplatform-instance-url>). Le test sera exécuté sur le navigateur déjà installé.

3.2 Exécution avec maven et le navigateur en local

On peut aussi exécuter les tests avec une commande maven:

mvn  clean verify -Prun-its,chrome \
-Dselenide.baseUrl=<exoplatform-instance-url> \

-Dselenium.webdriver.chrome.driver.path=<path-to-chrome-driver>

L’image ci dessous est un exemple de cette exécution .

3.3 Execution avec Docker, Maven et Selenium Grid

Les tests peuvent être exécutés sur des images docker du Selenium Grid et chrome.
Premièrement, on doit démarrer les conteneurs avec cette commande:
docker-compose -f core/src/main/resources/stack/docker-compose-50-hsqldb.yml -p qa_ui up
Ensuite, on exécute les tests sur le noeud chrome du Selenium Grid.
				
					<i>mvn &nbsp;clean verify -Prun-its,grid \</i><i>
</i><i> &nbsp;&nbsp;&nbsp;-Dselenide.baseUrl=</i><i>&lt;exoplatform-instance-url&gt;</i><i> \</i><i>
</i><i> &nbsp;&nbsp;&nbsp;-Dremote=http://localhost:4444/wd/hub \</i><i>
</i><i> &nbsp;&nbsp;&nbsp;-Dselenide.browser=chrome &nbsp;\</i><i>
</i><i> &nbsp;&nbsp;&nbsp;-Dselenide.timeout=20000</i>
				
			
On peut utiliser ce paramètre pour sélectionner les tests à exécuter, par exemple, si on veut exécuter que les tests smoke, on ajoute : -Dselenide.test.tags.include=smoke \

3.4 Exécution avec Jenkins

On peut aussi lancer les tests automatisés à travers notre job privé   platform-qa-ui-with-params.

Conclusion

La mise en place des tests automatiques chez eXo a permis l’augmentation de la couverture des cas de tests, la détection précoce des anomalies (nous avons planifié une exécution hebdomadaire automatique du pipeline jenkins donc  la détection précoce des bugs ) et le gain de temps d’exécution (1000 cas nécessitent 10 j/h pour les exécuter sur une instance manuellement  alors que les tests automatiques sont exécutés en 4 heures sur plusieurs instances en parallèle) .
Votre solution de Digital Workplace
Boostez l'engagement de vos collaborateurs
Julian dubois
Je suis expert solution chez eXo Platform.
Mon rôle est d’accompagner les clients dans le déploiement de leur projet de plateforme et l’accompagnement au changement lié à ce projet. J’ai piloté et administré une Digital Workplace pendant 3 ans avant de rejoindre eXo Platform.
Améliorer l’environnement et les conditions de travail m’a toujours passioné, je peux maintenant accompagner nos clients dans cette démarche.
Laisser une réponse
( Votre adresse email ne sera pas publiée)
guest
0 Commentaires
Commentaires en ligne
Afficher tous les commentaires