Discussion :

[piickwick]

Bonjour,
je suis actuellement a la recherche d'outils qui permet d'automatiser les tests pour une application test, je doit faire une analyse des outils sur le marché. J'ai trouvé quelques éléments sur selenium sahi ou encore watij. Je voulais avoir votre avis sur ces outils et si vous en avait d'autres
Cordialement.

[Laurent 1973]

Bonjour,

J'utilise Selenium.
Plusieurs avantages:

• Test un site web sans d'élément intrusif dans le code du site.
• Possibilité d'utiliser plusieurs langage de programmation de tests (python est très bien pour cela).
• Utilise des navigateurs populaires pour dérouler les tests: Firefox, Chrome, IE, ...

Mais si d'autres ont utilisé des outils, je suis intéresse pour avoir leur retour.

[piickwick]

Merci de ta reponse, mais peux tu également les difficultés que tu rencontres avec selenium ?

[kolodz]

En général les problèmes avec Selenium, c'est les "timeout" et les délai d'affichage variable. Ce qui a tendance à faire des faux positifs.
La seconde, c'est la gestion des cas de test. Il faut que tes données soient suffisamment valide pour passer l'ensemble des tests que tu as dans l'application et que cela soit re-jouable à volonté. Le mieux étant de ne pas faire de teste automatisé en production et garder cela pour la recette, sauf quand tu sais ce que tu fait (Tu ne sais jamais !).

Il faut cependant faire très attention à ce que test Selenium, car une petite modification dans l'interface peut caser l'ensemble des tests. Le cas typique est de mettre la classe ou l'id d'un élément en dur pour y accéder via Selenium. Le jour où tu change le nom tu perds ton test !

L’outil est exclament, je n'en connais pas d'autre de ce niveau personnellement.

[Laurent 1973]

Nous sommes là dans des tests graphiques.
N'oublions pas la pyramides des tests (http://softmethods.fr/la-pyramide-de-tests/)

Bien sur que ces tests via Selenium reprennent quelque scénario typiques de notre application mais en amont, un grand nombre de tests unitaires et fonctionnaires nous ont prémunis contre des dysfonctionnements.
Selenium nous permet là de vérifier que, sur plusieurs navigateurs, l'application se comporte bien.
Mais c'est tests reste très fragile à l'évolution graphique de vos pages web ainsi, comme l'évoque kolodz, à des contraintes systèmes de la machine de test.

Si vous voulez tester des algos ou des traitements (back-office ou javascript) il vaut mieux mettre en places des testes unitaires (voir fonctionnelles) sur ces points précis.

Et puis, je ne connais pas de tests a faire avec Selenium (ou un autre outil) pour me dire: mon site est beau
Là, le test manuelle est nécessaire.

Donc, tester une application web avec Selenium: important mais pas suffisant

[el_slapper]

D'une manière générale, les tests automatiques d'interface sont fragiles, Selenium ou pas. Ils sont utiles, mais couteux à réaliser, à maintenir, et même à exécuter. C'est pourquoi le ciblage des éléments à tester est fondamental. Là où on en est, on couvre moins de 2% de l'appli, mais les crashs lors des livraisons chez le client ont été réduits d'un facteur 10. Pour 2 raisons :

(1) on passe dans tous les écrans fragiles. Si une modif a cassé quelque chose, ça se voit vite, même si ce n'est pas ça qu'on teste.
(2) on passe dans les traitements fonctionnels historiquement "à problèmes". Une livraison sur 4 nous amène des régressions dans nos filets.

On continue à rajouter des cas pour augmenter notre couverture et notre qualité, mais les fruits murs en bas de l'arbre, on les a déjà. C'est la priorité absolue quand on met en place un nouveau système. Vu le prix, c'est la seule manière d'être rentable.

Les tests automatiques sont fragiles, parce que le moindre changement dans l'interface - ou dans le fonctionnel - entraine tout de suite des modifications massives du script, longues à mettre au point. Même quand on paramétrise un max.

[Shily]

Bonjour,

je me permets d'intervenir (un peu en retard je l'avoue ^^) afin d'apporter ma vision du test auto et de contredire un peu le dernier commentaire.

Je ne trouve pas que les tests d'interface soient spécialement "fragiles". Il suffit deux mettre en place deux points importants pour éviter toute mauvaise surprise avec l'évolution du produit que l'on teste.
1) Lorsqu'on utilise un outil comme Selenium, il est préférable de sélectionner les composants d'une page via les identifiants. Il faut donc que l'équipe dev ne modifie pas les identifiants des boutons submits, textbox etc etc etc. Ou alors, il faut que le(s) responsable(s) tests soit prévenu immédiatement.
2) Le second point important est de coder proprement ses tests. Si on utilise Selenium IDE par exemple, c'est sûr que chaque test est à modifier si il y a un changement quelconque dans le code... Mais prenons l'exemple d'un site web : si chaque page et menu est modélisé sous la forme d'une classe (je conseille le Java pour Selenium), alors les identifiants ne sont à modifier qu'à un endroit dans le code. Autre avantage à cette façon de faire : une connexion à un espace client, par exemple, représente une simple méthode dans le code, et il suffit de l'appeler en passant les paramètres "id" et "password".

Si j'ai conseillé le langage Java pour coder ses tests, c'est pour permettre l'utilisation d'un framework qui simplifie bien la vie : Fluentlenium.

Voila voila, j'espère avoir répondu un peu à la question sans être trop long.

[el_slapper]

(../...) Il faut donc que l'équipe dev ne modifie pas les identifiants des boutons submits, textbox etc etc etc. Ou alors, il faut que le(s) responsable(s) tests soit prévenu immédiatement.(.../...)

Si je peux me permettre, c'est souvent un vœu pieux. Le dev qui fait une correction est généralement sous pression, et l'équipe QA est la dernière de ses priorités. Ce que je considère comme légitime, j'ai été à sa place.

Pour le reste, je suis d'accord : une architecture logicielle bien pensée sur les scripts de test permet de gagner beaucoup de temps sur les changements du logiciel testé. Ca fait 6 mois que j'essaye de convaincre mon collègue, qui trouve "que je me complique la vie pour pas grand chose". Mais qui a du corriger 4 fois la même case dans le même tableau quand les dev ont rajouté 2 colonnes... On est pas obligé de faire une classe(ça a ses avantages et ses inconvénients, je ne le fait que si il est pertinent de stocké des variables, sinon, je fais de bêtes fonctions), mais il me semble très positif de mutualiser son code.

[randriano]

Donc, pour un outil de test automatisé fiable, et gratuit, il n'y a pour l'instant que Selenium!? Je parle d'UI test (test fonctionnel)
Dans les classements on voit d'autres noms mais avec peu de feedbacks: Windmill, etc.

[el_slapper]

On m'a récemment conseillé Nightwatch..... qui est une surcouche de selenium. Je n'ai pas regardé, puisque dans ma boite, on est en train de créer une surcouche à Webdriver I/O, qui lui aussi est une surcouche à selenium...

[randriano]

On m'a récemment conseillé Nightwatch..... qui est une surcouche de selenium. Je n'ai pas regardé, puisque dans ma boite, on est en train de créer une surcouche à Webdriver I/O, qui lui aussi est une surcouche à selenium...

Wow, vous développez vous-même votre outil de test: les américains diraient "dope!!" De plus ce sont des surcouches assez parfaites que vous continuez à perfectionner