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.
| Selenium | Codeception | Windmill | Sahi | Cucumber | Selenide | |
| Open source | Oui | Oui | Oui | Oui avec version Pro | Oui | Oui |
| Multi-navigateurs | Oui | Oui | Oui | Oui | Oui | Oui |
| Langage de développement | Java | PHP | Python | PHP | PHP | Java |
| Langage de script/test | JavaScript PHP Python
C# Java Ruby |
PHP | JavaScript Python
Ruby |
JavaScript | Gherkin
+ java |
JavaScript PHP Python
C# Java |
| Communauté active et mises à jour régulières | Importante | Importante | Faible | Faible | Bonne | Importante |
| Record-playback | Oui | Oui | Oui | Oui | No | oui |
| Identification intelligente des objets | Non | Non | Non | Oui | Non | Non |
| Attente des évènements (Ajax) | Oui | Oui | Non | Oui | Non | Oui |
| Génération de rapports de tests personnalisés | Oui | Oui | Oui | Version Pro seulement | Plugin | Oui |
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.
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”.
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.
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
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.
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.
mvn clean verify -Prun-its,grid \
-Dselenide.baseUrl=<exoplatform-instance-url> \
-Dremote=http://localhost:4444/wd/hub \
-Dselenide.browser=chrome \
-Dselenide.timeout=20000
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) .
