Re: protocole de test Comet

Pierre Goupil <[email protected]> Wed, 23 Mar 2011 17:07:34 +0100
Newsgroups gmane.comp.java.french.general
Message-ID <[email protected]>
Non, je n'en sais pas plus, mais je me disais que ça m'aiderait peut-être à
construire un sampler JMeter ou que cela pourrait m'aider dans mes tests
Selenium. Comment, je ne sais pas trop mais la notion d'attente active sur
une condition de garde pourra peut-être me permettre de surveiller une
réponse initiée d'elle-même.

Je me rends compte que je n'avais pas répondu à la question de Damien. Je
veux deux canaux de communication : serveur => client et client 1 => serveur
=> client 2.

Pierre



2011/3/23 Laurent Forêt <[email protected]>

> Salut Pierre
>
>   Je viens de lire cet article sur awaitility
> http://blog.xebia.fr/2011/03/23/tester-les-services-asynchrones-avec-awaitility/ et
> j'ai pas fait le lien avec ton problème. Excuse m'en .
>
> Le post est assez intéressant, mais je suppose que tu en sais déja plus sur
> awaitility que ce qu'il en est dit dans cet article.
>
> Laurent.
>
> 2011/3/23 Pierre Goupil <[email protected]>
>
>> Merci,
>>
>> Jean-François Arcand vient de me conseiller ceci :
>> https://github.com/sonatype/async-http-client
>>
>> et j'ai trouvé ça dans mes flux RSS du jour :
>> http://code.google.com/p/awaitility/
>>
>> Avec tes idées, ça fait un sacré arsenal ! Je vais voir à écrire mon
>> propre sampler JMeter et ça devrait le faire.
>>
>> Thanx,
>>
>> Pierre
>>
>>
>>
>>
>> 2011/3/23 Damien Lecan <[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 !
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Sauvez un arbre, mangez un castor !
>>
>>
>>
>


-- 
Sauvez un arbre, mangez un castor !