Re: protocole de test Comet
Damien Lecan <[email protected]> Wed, 23 Mar 2011 14:39:55 +0100
| Newsgroups | gmane.comp.java.french.general |
|---|---|
| Message-ID | <[email protected]> |
Bonjour, Problème toujours épineux avec les technologies récentes : les outils ne suivent pas ! :) Pour les tests fonctionnels, je ne vois pas mieux que Selenium puisqu'il met en oeuvre les navigateurs du marché et te garantit la compatibilité (ou non) avec ton protocole. Pour le test 1/, plutôt que de raisonner en timer avec des temps prédéfinis, tu peux peut-être raisonner en "attente", avec des clic + waitForQuelqueChose ? Pour le test 2/, je ne suis pas sûr de comprendre : tu as un protocole de communication client à client ou client <-> serveur <-> client ? Si c'est le 2è cas, tu te rapportes au cas 1/, non ? Pour les tests de performances, si tu as fais l'effort de mettre en place des tests Selenium, tu peux mettre en place une batterie de navigateurs, ce qui te génèrera ta charge (Cf. http://selenium-grid.seleniumhq.org/). Ce n'est pas vraiment fait pour ça, car c'est très consommateur de ressources. Mais avec Amazon AWS sous la main et du budget, ça se fait. Tu peux aussi écrire ton propre "sampler" JMeter qui gère spécifiquement ton protocole Comet ou WebSocket.. Plus trop de limite à tes tests dans ce cas. Bon courage Damien Le 18 mars 2011 17:37, Pierre Goupil <[email protected]> a écrit : > Bonjour la liste, > > J'essaye en ce moment de faire des tests fonctionnels d'une application > Comet. Deux cas d'usage : > > - soit je teste la communication HTTP serveur vers client, une réponse > Comet pouvant alors survenir à n'importe quel moment, > > - soit je teste la communication HTTP client vers client, même remarque. > > Mon outil de test fonctionnel de prédilection est Selenium mais il n'a pas > l'air adapté à ces usages : difficile en effet de démarrer 2 navigateurs > pour tester le point 2. Pour le point 1 cela peut encore aller mais il faut > des timers, ce que je trouve fragile. > > Auriez-vous une idée ? > > Question subsidiaire : pour la montée en charge, même problématique mais > avec JMeter, cette fois. > > Si vous avez des idées de protocole de tests ou des outils plus adaptés, je > suis tout ouïe. > > Cdt, > > Pierre > > > > -- > Sauvez un arbre, mangez un castor ! > > >