Les scénarios sont rédigés soit sous formes de tables HTML (à la manière de FIT), soit sous forme de programmes qui pilotent le navigateur (Ruby, Python, Java, C#).
Ces outils se sont récemment réunis sous une même bannière : OpenQA (QA pour Quality Assurance ou Assurance Qualité dans la langue de Molière). Les fonctionnalités suivantes sont proposées :
- Enregistrement automatique des actions
- Localisation des éléments de manière intelligente
- Possibilité d'inclure ses extensions Selenium
- Rejouer rapidement le test
- Copier/coller très complet
- Maîtrise du format des fichiers
- Sauvegarde en tests HTML ou Ruby
Ces outils sont sous licence Apache 2. Selenium est un outil impressionnant de simplicité, de puissance et de souplesse à la fois. La relative pauvreté du mode "tables HTML" pour contrôler le flot est en fait voulu et force à se placer dans des conditions de tests très déterministes ce qui est un facteur de qualité des tests.
Mené par Shinya Kasatani, le Selenium IDE s'appelait précédemment Selenium Recorder et a repris beaucoup d'idées de Selenium Test Editor écrit par Hoa Dung Ha Duong.
Il apporte un réel plus pour enregistrer des tests.
Sur une application qui serait développée avec un HTML suffisamment clair (pas du HTML4 plein de tableaux), il permettrait à un utilisateur de saisir des tests de manière quasi autonome.
Une vidéo de démonstration est disponible sur le site.
Aller plus loin
- Selenium IDE (97 clics)
- openQA (23 clics)
- FIT (6 clics)
- Article sur l'utilisation de Selenium (61 clics)
- XPI de Selenium IDE (20 clics)
- XPI de Selenium Test Editor (12 clics)
# Plugin ruby on rails
Posté par Vincent Behar . Évalué à 8.
# Appli Web
Posté par golum . Évalué à 3.
Peut-on s'en servir pour tester ses extension Mozilla ?
[^] # Re: Appli Web
Posté par Alex G. . Évalué à 4.
Par contre le code est très bien écrit et une évolution pour tester des extension Mozilla serait sûrement intéressante.
# WebInject
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Visiblement, on peut écrire de nouvelles fonctions pour la sauvegarde, ce serait donc possible.
[1]: http://www.webinject.org/
--
Raphaël 'SurcouF' Bordet
[^] # Re: WebInject
Posté par Alex G. . Évalué à 2.
Webinject s'occupe de test avec Http alors que Selenium test l'interface dans le navigateur. Donc, d'une part, Selenium test aussi le javascript mais surtout décrit les actions utilisateur : rentrer xxx dans tel champs sans forcément savoir quel est le résultat final en terme de formulaire (ce qui sera envoyé par Http).
J'avais a un moment regardé une solution de tests par Http qui s'appelle webtst ( http://webtst.assisrosa.com ) : l'utilisateur peut enregistrer des tests avec un proxy qui enregistre les trames Http. Le test peut ensuite être rejoué et comparé au résultat précédent.
[^] # Re: WebInject
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Tout ce qu'il me manque jusqu'à présent, c'est l'outil qui saura convertir les requêtes HTTP en fichiers de configuration XML (et du temps aussi).
Etant donné que Selenium IDE permettait manifestement d'enregistrer au format HTML, je me demandais si c'était possible d'en faire autant en XML, les langages de descriptions étant sensiblement assez proches, àmha.
[^] # Re: WebInject
Posté par Bruno Vernay . Évalué à 1.
Enfin il faut faire un tour dans les options de Selenium-IDE pour voir que le format de sortie (par défaut table HTML) est completement configurable. Et si ca ne suffit pas, un petit coup de XSLT fera l'affaire.
J'attend beaucoup de cet outil, Selenium permet d'automatiser des tests fonctionnels, mais le driver/proxy est un peu en chantier semble-t-il. Derrière OpenQA, il y a ThoughWorks et ca met en confiance.
Sinon, pour élargir l'horizon : http://opensourcetesting.org/
Bruno
# tres fort
Posté par jmny . Évalué à 1.
[^] # Re: tres fort
Posté par srm . Évalué à 2.
Je me demande concrêtement comment l'utiliser. Quel utilité ça a vraiment ? Ca m'échappe un peu. En quoi un site web à besoin d'être testé ?
[^] # Re: tres fort
Posté par gc (site web personnel) . Évalué à 4.
en espérant avoir été agréable à ton oreille.
[^] # Re: tres fort
Posté par Jean-Marc Spaggiari . Évalué à 1.
Donc pour ma part, je trouve cela tres pratique, et je vais m'en servir frequemment. Ce qui serait encore mieux, ca serai de pouvoir prendre les saisies dans un fichier ou une base. Par exemple si je veux tester mes deux millions de comptes, ben j'aimerai pouvoir dire "login" = select * from matable...
Voila un exemple d'utilisation...
JMS
[^] # Re: tres fort
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Sans doute conviendra-t-il alors, si le test n'est toujours pas concluant, de le rejouer aux heures normalement ouvrées parce que la nuit, l'utilisation des ressources peut-être sensiblement différente (sauvegardes, moins d'utilisateurs, etc.).
[^] # Re: tres fort
Posté par Alex G. . Évalué à 3.
Dans ce cas ce sont des applications métier. Dans ce genre d'application, la difficulté n'est pas dans l'algoritmique mais plus dans le comprendre et respecter la spécification, ce que veut le client, et avoir un produit évolutif.
Dans ce contexte, les tests fait par une personne différente du développeur sont un grand plus.
- celui qui fait les tests à souvent une vision orientée par les données, tandis que le développeur à une vision orientée par les traitements, et là déjà on trouve plein de bugs.
- La meilleur façon de clarifier la spécification est souvent de raconter un scénario. C'est exactement ce que l'on fait avec un test
- Le test est une vrai capitalisation lorsque l'on veut faire évoluer le produit. Tu peux reprendre les entrailles de la bête et s'assurer pourtant que rien ne devrait être cassé en terme de fonctionnalités
# merci
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: merci
Posté par jc . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.