Accueil > Outillage > Comment j’ai fiabilisé mon projet avec Selenium IDE (2/2) !

Comment j’ai fiabilisé mon projet avec Selenium IDE (2/2) !

La semaine dernière, je vous expliquais comment j’avais été amenée à utiliser Selenium IDE, dans quel contexte, et comment faire les premiers pas (c’est ).

Rentrons maintenant dans les détails et étudions, en particulier, les sujets suivants : les commandes les plus utiles, la gestion du multi-plateformes, l’organisation des tests, le problème de leur maintenance et l’outillage à mettre en place pour pouvoir les lancer en « batch ».

Les commandes les plus utiles

Voici les commandes que j’ai le plus utilisées dans le contexte de mon projet. Comme vous pouvez le constater, il n’y en pas plus d’une dizaine…

Actions
Commande Cible Valeur
open <URL (absolue ou relative)>
type name=<nom champ> <valeur>
clickAndWait css=<css locator>
OU link=<nom lien hypertexte>

A noter que la commande clickAndWait permet d’attendre l’ouverture de la nouvelle page avant de passer à la commande suivante (contrairement à la commande click).

Contrôles
Commande Cible Valeur
verifyTextPresent / verifyTextNotPresent <chaine de caractères à chercher dans la page>
verifyXpathCount <Xpath locator> <nombre d’occurrences>
verifyTitle / verifyNotTitle <titre de la page>
verifyValue name=<nom champ> <valeur>
verifyLocation <URL (absolue ou relative)>

A noter qu’il existe des commandes de contrôles de type « verify » ou « assert » : celles de type « assert » stoppent le test quand elles échouent, contrairement à celles de type « verify ». Je conseille donc plutôt celles de type « verify » pour pouvoir jouer les tests en mode « batch ».

Pour mémoire, la documentation en ligne de Selenium est accessible ici.

Gestion du multi-plateformes

Pour pouvoir jouer les tests sur différentes plateformes (environnements de développement, d’intégration, de recette, etc.), il faut que les tests soient enregistrés sans que l’URL de base soit fixée.

A la création d’un nouveau test, à partir de Selenium IDE, l’URL de base est positionnée avec la valeur du domaine courant.

Pour corriger cela, il faut aller dans l’onglet source et remplacer :

<link rel="selenium.base" href="http://blog.viseo-bt.com/" /> (par exemple)

par : <link rel="selenium.base"/>

Puis, saisir dans le champ « Base URL » le nom du domaine à partir duquel vous voulez jouer votre test.

Organisation des tests

Dans Selenium, les tests peuvent être regroupés au sein de suite de tests (dans le menu Fichier, options « Nouvelle suite de tests », « Enregistrer une suite de tests », etc.).

Dans le cadre de mon projet, j’ai créé deux types de suites de tests :

  • suite de tests « version » : regroupe tous les tests associés aux évolutions d’une version donnée
  • suite de tests « thématique » : regroupe tous les tests associés à une thématique

Quand faire l’un ou l’autre ?

Le regroupement par thématique permet d’avoir une vue complète de tous les tests existants sur une thématique, et quelque part, donc, des règles de gestion associées au sujet. Ça constitue un référentiel précieux, mais ça demande un effort d’organisation en terme de maintenance (lorsqu’il y a une nouvelle version, il faut dispatcher les nouveaux tests dans les différentes séries).

Le regroupement par version permet d’avoir un historique, de retrouver quand telle ou telle règle a été mise en place… intéressant aussi. En terme de mise en place, c’est le plus simple. Ça permet également de bien distinguer les régressions (tests des versions précédentes) des anomalies de la version en cours.

Et donc ? Et donc, personnellement, je faisais un mix des 2 : des séries thématiques pour les sujets complexes et/ou importants (en nombre de tests ou en sensibilité) et des séries versions pour tout le reste.

Maintenance des tests

Les tests Selenium s’appuyant sur la couche IHM, ils sont sujets aux variations, d’abord parce que le métier aime changer l’IHM (un libellé par ci, un contenu par là), mais aussi parce que les données affichées sont variables (plus ou moins selon le type d’application).

Donc, à chaque fois que les tests sont lancés, il faut se demander, pour ceux qui échouent, si c’est un échec « normal » (dans ce cas, c’est le test qui doit être mis à jour) ou un bug.

Il y a, de fait, un coût de maintenance non négligeable à prévoir (mais qui, j’en suis convaincue, est moindre par rapport au coût d’éventuelles régressions).

Et qui s’en occupe ? Sur mon projet, c’était essentiellement moi, avec ma double-casquette AMOA/Chef de Projet. On peut aussi imaginer confier cette activité à une cellule de tests, à condition qu’il y ait, par ailleurs, des spécifications dignes de ce nom… Une solution intermédiaire peut être envisagée : confier la création des nouveaux tests (pour la version en cours) à l’équipe projet et la maintenance des tests existants (non régression) à une cellule de tests. Je n’ai pas testé cette organisation mais elle me parait raisonnable.

Outillage du lancement des tests

Au début, je lançais patiemment les séries de tests, les unes après les autres, sur le navigateur de mon poste de travail. Jusqu’au moment où ça s’est mis à prendre des heures… c’est le problème quand les séries se multiplient (et à l’époque, Selenium libérait mal la mémoire, ce qui m’obligeait à rebooter après avoir passé un certain nombre de séries).

Je me suis alors tournée vers mon développeur préféré pour lui demander s’il pouvait faire quelque chose pour moi (youpi, il pouvait !).

Option 1 : automatiser le lancement de tous les tests à partir de Jenkins. Ce n’est pas l’option qui a été retenue car l’objet n’était pas tant d’automatiser le lancement que d’avoir un outil me permettant de lancer toutes mes séries, à la demande, en un clic, sur n’importe laquelle de nos plateformes, de manière facile. L’utilisation de Jenkins, dans ce cadre, aurait posé des problèmes de droit d’accès, m’aurait obligé à tripatouiller la configuration Jenkins à chaque lancement (entre autres pour choisir la plateforme ou prendre en compte des séries fraichement modifiées), ce n’était donc pas la solution idéale.

Option 2 : écrire notre propre outil de lancement. C’est l’option qu’on a retenue. Ça nous a permis d’avoir un outil vraiment en accord avec notre besoin, très user-friendly, sans couche graphique (temps d’exécution raccourci), qui tournait sur nos plateformes de dév (et ne mangeait pas donc pas les ressources de mon poste), qui pouvait être lancé depuis n’importe quel navigateur, n’importe quel poste, attaquer n’importe quelle plateforme, et avec une restitution des résultats aux petits oignons. Ça a pris une dizaine de jours.homme à être développé  mais ça répondait parfaitement à mon besoin. :-)

Bref, à chacun de trouver la solution qui lui convient, en fonction de son organisation, de ses utilisateurs et de son besoin, mais ce qui est sûr, c’est que le lancement manuel peut vite devenir ingérable.

Conclusion

L’utilisation de Selenium a vraiment été déterminante pour améliorer la qualité et la robustesse de notre projet. Au bout de 2 ans, nous avions environ 400 scenarios de test répartis en 25 séries, et nous dormions sur nos deux oreilles les veilles de mise en production… alors, avis aux amateurs !

  1. vincent
    03/03/2016 à 16:20 | #1

    Bonjour,

    Article très intéressant, j’ai une question à poser même si j’ai peu d’espoir d’avoir une réponse.

    Comment vous avez pu créer votre propre outil afin de lancer automatiquement les tests à distance ?

    J’utilise un super addons, Selblocks global, maintenant on arrive à un point ou il serait fortement appréciable de lancer nos tests la nuit, mais j’ai peur d’être confronté à quelques difficultés à cause de cet addons. Y a t’il un moyen de lancer un test Selenium IDE en ligne de commande?

    Merci en tout cas.

  1. 27/02/2014 à 09:11 | #1


× huit = 48