Archive for the ‘Les navigateurs web’ Category

Rapprochement entre WebDriver et Selenium

octobre 31, 2009

Webdriver et Seleniumhq sont des outils de tests des applications web. Au départ webdriver est projet hébergé dans Google code.

Depuis le septembre, les deux projets se sont rapprochés et les jars les plus récents de WebDriver sont maintenant disponibles sur le site « Open QA ». Selenium RC (Remote Control) permet de piloter des navigateurs Web et l’API peut être utilisée avec de nombreux langages dont Java. WebDriver est une API de haut niveau qui permet soit de piloter des navigateurs soit d’utiliser une API de plus bas niveau HtmlUnit permettant de simuler un navigateur Web. Ce qui permet soit de jouer les test dans un vrai navigateur soit de les jouer sans aucune interface. Ce dernier cas est intéressant dans le cadre d’une intégration continue. Une autre particularité de WebDriver est la volonté de fournir une API simple. Le projet n’est cependant pas encore tout à fait mature, ce qui est compréhensible puisqu’il a commencé en mars 2008.

Pour l’instant pour mes projets, je continue à utiliser JwebUnit qui finalement est assez proche dans ses principes à WebDriver. Mais je pense à l’avenir que WebDriver / Selenium est une alternative valable.

IETester test sur le site de ie6nomore.com

août 13, 2009

Pour compléter ma présentation de IETester, j’ai fait le test sur le test ie6nomore.com. Ce site est une initiative de nombreux sites web pour inciter à l’abandon d’IE6 au profit de navigateurs plus récents et plus respectueux des normes web. En effet, ce navigateur a plus de 8 ans et il devient très coûteux de maintenir une compatibilité des sites web pour ce navigateur.

Le site w3schools fournit des statistiques montrant que IE6 représentait en juillet 2009 encore 14,4% de part de marché. Avec le rythme actuel de baisse, il pourrait encore survivre plus de deux ans. Je pense que les derniers utilisateurs sont surtout dans des entreprises qui bloquent la migration d’IE.

Ce site propose un petit morceau de code à insérer dans les sites web pour avertir les utilisateurs. Ce code utilise simplement une fonctionnalité propriétaire de IE qui est le commentaire conditionnel Html.

<!--[if lt IE 7]> Affiché si la version d'IE inférieure strictement à 7...<![endif]-->

IETester passe avec succès ce test. Les simulations d’IE5.5 et 6 affichent le message d’avertissement tandis que celles de IE7 et IE8 ignorent ce message. J’ai remarqué au passage la lenteur notable de IETester. Alors IETester est-il finalement mort-né ?

IETester et ienomore

IETester et ienomore

Selenium RC (Remote Control)

novembre 11, 2008

Selenium RC fait partie d’un ensemble d’outils de test des applications web. Parmi ces outils, il existe un outil particulièrement intéressant Selenium IDE.

Ce dernier est un plugin pour Firefox permettant d’enregistrer et de lancer des scripts de test des applications web. Le langage utilisé par défaut est propriétaire, exportable au format HTML. Mais ce plugin peut servir avantageusement de « recorder » pour la version Java. En effet, il suffit d’aller dans le menu de Selenium IDE « option\format » est de choisir le langage Java. En effet, il est parfois au début très difficile de passer du langage de commande au langage Java.

Il est possible d’écrire les tests avec Selenium à l’aide du langage Java. Un framework de test comme JUnit permet d’organiser ces tests. Au début, j’ai été tenté d’utiliser un autre framework de test que JUnit3 (JUnit4). Mais finalement le Selenium RC est une librairie de test intimement liée à JUnit3. Il est préférable de suivre le choix des concepteurs. La classe SeleneseTestCase étend la classe TestCase de JUnit. Elle contient une variable selenium de type Selenium initialisée lors de la méthode setup. Cette variable représente le navigateur web.

La classe SeleneseTestCase fournit des assertions supplémentaires commençant par verify comme verifyEquals. Quelle est la différence avec le assertEquals de TestCase ? En fait, ces méthodes font échouer le test si une assertion n’est pas respectée lors du tearDown, donc sans arrêter le script de test. Attention, ceci est « anti test unitaire », mais reste acceptable ici. En effet les tests des applications web ne sont pas en soit des tests unitaires, mais des tests de plus haut niveau.

Selenium RC se base sur un « serveur » ou un « proxy applicatif ». Pour démarrer ce serveur, le plus simple est d’utiliser le jar selenium-server*.jar, avec la commande « java -jar selenium-server.jar ». Le serveur démarre par défaut sur le port 4444. Il faut éviter de le changer car il s’agit du port qu’utilise la classe SeleneseTestCase. Dans un autre article, je décrirai comment le démarrer de manière programmatique.

Le code du test simpliste de démonstration avec le moteur de recherche Google peut être le suivant:


package com.petitteckel.seleniumdemo;

import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleTest extends SeleneseTestCase {


 public void setUp() throws Exception {
  //setUp("http://www.google.fr/", "*custom E:\\program\\mozilla.org\\SeaMonkey\\seamonkey.exe");
  setUp("http://www.google.fr/", "*iexplore");
 }


 public void testGoogle() {
  selenium.open("http://www.google.fr");
  verifyEquals(selenium.getTitle(),"Google");
  selenium.type("q", "Selenium");
  selenium.click("btnG");
  selenium.waitForPageToLoad("5000");
  verifyEquals(selenium.getTitle(),"Selenium - Recherche Google");
 }
}

La chaîne de caractères « *iexplore » représente le type de navigateur à utiliser. En effet Selenium RC pour effectuer les tests pilote les navigateurs existants. Il a donc besoin de la présence de ces logiciels. Cela pose des contraintes, par contre a l’avantage d’être fidèle à ces navigateurs. Au niveau des variables prédéfinies, il en existe 11 correspondant à des navigateurs ou des configurations de navigateurs, *iexplore pour Internet Explorer, *firefox pour Firefox, *opera pour Opera. Pour voir la liste de ces variables, il suffit de mettre *nimportquoi au niveau de cette variable et la console du serveur va la refuser et afficher la liste des variables possibles. L’utilisation de ces variables devrait permettre l’utilisation des navigateurs sans les reconfigurer, dans la pratique cela ne marche pas très bien, voire pas du tout. La solution de secours est d’utiliser la chaîne *custom.

Il faut dans ce cas faire suivre *custom du chemin exact du navigateur. Au niveau du navigateur, il faut préciser que le proxy est localhost port 4444. Cela fonctionne avec tous les navigateurs installés sur mon poste Windows (de Flock à Safari en passant par Google Chrome). Mais cela risque de poser un problème si la connexion vers l’application testée passe également par un proxy.

Enfin, il est possible d’utiliser Maven, pour la gestion des dépendances dans le projet Java. Je mets dans l’exemple plus bas les dépendances pour la version 1.0-beta-1 (la dernière). Par défaut, le jar junit3.8.1.jar est mis dans le projet. Ceci confirme bien ce que j’ai expliqué un peu avant.


 <dependency>
  <groupId>org.openqa.selenium.client-drivers</groupId>
  <artifactId>selenium-java-client-driver</artifactId>
  <version>1.0-beta-1</version>
 </dependency>
 <dependency>
  <groupId>org.openqa.selenium.core</groupId>
  <artifactId>selenium-core</artifactId>
  <version>1.0-beta-1</version>
 </dependency>

Au final, je trouve que Selenium RC est un outil intéressant mais pas encore stabilisé, donc difficile à généraliser au niveau d’une entreprise.

Les outils de test commerciaux iMacros et eValid

octobre 15, 2008

Concernant les tests des applications web, je me suis posé la question s’il est possible de tester des applets. Cette problématique pourrait être généralisée aux autres technologies comme Flash Silverlight. Les outils libres ne semblent pas répondre à cette question. Je me suis tourné vers des outils commerciaux, iMacros et eValid.

IMacros existe sous forme de plugin pour navigateur web en freeware, également pour une utilisation commerciale. Ce plugin existe pour les navigateurs Firefox et Internet Explorer. Les tests sont écrits avec un langage de script spécifique. Il existe un enregistreur. Le site d’Iopus déclare que iMacros supporte les technologies Flash, Flex, Java, Silverlight. Dans la pratique le freeware ne semble pas fonctionner correctement, et le principe semble de repérer au pixel près la position du curseur. Est-ce réellement portable.

Le second outil qui peut répondre à ce problème est eValid. Je n’ai pas pu réellement le tester.

Comparaison des différents navigateurs Web basée sur les tests Acid

septembre 20, 2008

Une piste de comparaison des navigateurs web est le respect des standards Web. Plusieurs tests ont été mis en place pour montrer le respect ou non par les navigateurs web des standard du web. Ceci évite une « balkanisation » du web. Le test Acid1 été mis en place en 1998 par Tod Fahrner et ne concerne que les CSS. Il n’a qu’un intérêt historique. Les deux suivants Acid2 et Acid3 dépendent du WASP (Web Standards Project). Le test Acid2 date de 2005. Il ne concerne que les CSS1 et CSS2. Son résultat est purement visuel. Le dernier Acid3 concerne un spectre plus large de technologies DOM level2, JavaScript, CSS3, SVG… Il est très récents 2008. Le résultat est une note sur 100. Il s’agit de 100 tests de base. Il est possible de voir les tests ayant échoué. Enfin, il existe un site qui regroupe l’ensemble des test acid.

La liste suivante se compose des principaux navigateurs actifs disponibles pour Windows, en dehors des surcouches pour IE (comme CrazyBrowser et Maxthon). Les navigateurs abandonnés comme Netscape n’y sont pas présents. Pour l’instant cette liste compte 8 membres.

La comparaison a été faite avec les dernières versions stables des navigateurs sous Windows Vista. Il est remarquable que les deux grands sont loin d’être les premiers. Firefox passe le test Acid2 depuis sa version 3. IE est toujours bon dernier. Les équipes de Microsoft n’ont jamais officiellement mis ces tests Acid en priorité. Les navigateurs basé sur le moteur de rendu de Firefox 2, K Meleon, Flock et SeaMonkey obtiennent en gros le même résultat. Enfin, aucun navigateur obtient 100 au test Acid3.

Voici les résultats détaillés :

Navigateur Version Test acid 2 Test acid 3
Opera 9.52 Oui 84/100
Google Chrome 0.2.149.29 Oui 78/100
Safari pour Windows 3.1.2 Oui 75/100
Firefox3 3.01 Oui 71/100
K Meleon 1.5 Non 53/100
Flock 1.2.5 Non 53/100
SeaMonkey 1.1.11 Non 52/100
IE 7 Non 12/100

Le test de performance JavaScript SunSpider

septembre 18, 2008

SunSpider est un test de performance du moteur de JavaScript. Ce test a été écrit par l’équipe de WebKit le moteur de rendu HTML présent dans les navigateurs sous Mac OS, comme Safari. Ce benchmark exécute 5 fois une série de tests et fournit une moyenne.

Le JavaScript est assez important pour les utilisateurs des applications web. En effet, le type de code est exécuté sur le client et non le serveur. L’importance de ce langage s’est accrue avec le Web 2.0. Cependant, la performance du moteur de JavaScript n’est qu’un élément dans le performance globale du navigateur web. Cela ne présume pas de la performance globale du navigateur.

Les résultats suivants ont été obtenus sur Windows Vista avec les navigateurs actifs, les plus courants dans leurs dernières versions stables. Google Chrome avec son tout nouveau moteur V8 obtient un résultat remarquable. Par contre celui d’Internet Explorer 7 est médiocre, en effet le moteur de JavaScript de ce navigateur est de conception ancienne et devrait être remplacé dans la version 8.

Navigateur Version Résultat
Google Chrome 0.2.149.29 3 301 ms
Firefox 3.01 5 558 ms
Safari 3.1.2 7 019 ms
Opera 9.52 7 931
K Melon 1.5 15 321 ms
SeaMonkey 1.1.11 21 422 ms
Flock 1.2.5 23 214 ms
IE 7 58 033 ms

Une petite fonctionnalité de Google Chrome

septembre 14, 2008

J’ai fait découvert une petite fonctionnalité de Google Chrome. Souvent, je tente de débugger du code Javascript avec une série de boite de dialogue « alert ». Cette méthode est loin d’être parfaite…
Google Chrome propose à la seconde boite de dialogue d’empêcher l’affichage des boites de dialogue suivantes.

Les autres navigateurs courants ne possède pas cette fonctionnalité. Une exception notable est Opera qui propose d’arrêter l’exécution des scripts dans la page, ce qui est un peu plus brutal que dans le cas de Google Chrome.

arret des boites de dialogue javascript

arret des boites de dialogue javascript

arrêt des scripts dans Opera

arrêt des scripts dans Opera

Le nouveau navigateur Google Chrome

septembre 8, 2008

Google a sorti son navigateur web Google Chrome. Cette sortie a largement été commentée du fait de la place stratégique du navigateur web. Google Chrome est un logiciel libre, de licence BSD. Il s’appuie sur WebKit également sous BSD. Le projet est hébergé sur le site code.google.com.

Un moteur de Javascript a été développé spécifiquement pour ce navigateur, V8. Ce projet est également sur le site code.google.com. Autre point, le support des applets nécessite apparemment Java 6 update 10.

Enfin, ce navigateur apparaît très respectueux des standard web. Je l’ai testé sous Windows. Il réussit largement le test acid2. Il obtient un score de 79/100 au test acid3. Ce qui est un résultat excellent pour une navigateur sous Windows.

L’outil de test des applications web WebDriver

août 12, 2008

WebDriver est un nouvel outil de test des applications web. Il s’agit d’un projet faisant partie du site code.google.com, qui regroupe des projets développés par les employés de cette entreprise. le site de WebDriver est http://code.google.com/p/webdriver/. Une présentation vidéo de cet outil lors du GTAC 2007 (Google’s Test Automation Conference) est disponible sur le site YouTube .

Il s’agit d’une API Java permettant de simuler ou de piloter un navigateur web. L’équipe à l’origine de WebDriver parle de navigateur idéalisé. WebDriver est similaire aux outils comme htmlUnit, HttpUnit, JWebUnit, ou Selenium Remote Control. Il fait partie des outils de test des applications web.

L’API WebDriver est de haut niveau, comme celle de JWebUnit par opposition aux API de bas niveau HtmlUnit et HttpUnit. Le but est de simuler un utilisateur manipulant une interface web, pas analyser ou manipuler les requêtes web. Comme JWebUnit, WebDriver utilise des API de plus bas niveau dans la pratique uniquement HtmlUnit. Il reste cependant ouvert à utilisation d’autres API comme Selenium RC. JWebUnit dans sa version 2 devrait permettre l’utilisation en plus d’HtmlUnit de Selenium RC, HttpUnit et Jacobie.

WebDriver est en fait une interface qui peut utiliser des implémentations différentes. Ces implémentations sont soit des API de bas niveau qui simulent des navigateurs web comme HtmlUnit, soit des outils pilotant des navigateurs web. Il s’agit de Firefox, et Internet Explorer pour Windows, Safara pour Mac OS X. Une implémentation utilisant un navigateur web permet d’avoir un support natif du Javascript et de suivre visuellement les tests. Donc, il est donc possible de vérifier leur fonctionnement et de les faire évoluer. Par contre, cette méthode est plus lente que des tests utilisant un simulation d’un navigateur web. Un simulateur est plus rapide mais propose un support imparfait du javascript.

Contrairement aux outils concurrents, l’API de WebDriver est très simple. L’API tourne autour de deux classes WebDriver (le navigateur) et WebElement (un élément dans page courante). Les API de HttpUnit et HtmlUnit sont à côté complexes. Le choix de l’implémentation de la classe WebDriver définit le type d’implémentation utilisé (HtmlUnit, Firefox, IE ou Safari).

Dans la pratique, cet outil est disponible en version « alpha ». La version du 31/07/2008 que j’ai évaluée n’est utilisable uniquement avec les implémentations HtmlUnit et Firefox. Il suffit de changer l’instruction d’initialisation de la classe WebDriver pour choisir l’implémentation Firefox ou HtmlUnit.

Voici des exemples de code:

WebDriver driver;
driver = new FirefoxDriver(); //piloter Firefox
driver = new HtmlDriver(); //utiliser HtmlUnit

Il faut mettre de temps à autre des « pause » pour pouvoir visualiser le résultat.

Thread.sleep(tempo); //tempo est grand pour Firefox mettre 1 pour htmlUnit.

WebDriver souffre de limitations : il est instable et sa documentation est partielle. Je ne le conseille pas pour une utilisation dans un projet important. Les outils matures dans le domaine des tests des applications web sont plutôt HtmlUnit et JWebUnit.

Créer plusieurs profils utilisateur avec Mozilla Firefox

mai 1, 2008

Le problème est assez simple : j’apprécie le navigateur Mozilla Firefox. Il existe en effet de nombreux plugins qui me sont utiles dans le travail de développement web. Citons Selenium IDE, Firebug, Web Developer. Ils sont nombreux et j’ai tendance à en installer beaucoup voir trop.

Le risque est d’avoir un navigateur éléphantesque avec des fuites de mémoire. Un autre point est le cycle de développement beaucoup plus lent au niveau de ces plugins par rapport au navigateur. Des failles de sécurité sont parfois non corrigées. Lors de nouvelles versions majeures du navigateur, certains plugins peuvent ne plus fonctionner.

La solution est de créer plusieurs profils utilisateur. Il suffit d’ajouter l’option « -P » à l’exécutable firefox.exe. Fermez ensuite toutes les sessions Firefox et démarrez le navigateur. Une boite de dialogue de gestion et de choix des profils utilisateur apparaît. Il est donc possible de créer de nouveaux profils et de changer le nom des profils existants. La création d’un nouveau profil engendre un profil sans aucun plugin complémentaire.

Il est donc possible de créer les profils selon vos besoins. Je pense créer trois profils un profil simple sans aucun plugin pour la navigation, un autre pour les tests des applications web avec Selenium et enfin un éléphant pour le développement web.