Je suis en désaccord avec Nathan et Freddy à un certain degré. Ils ont raison de dire que "AJAX testing" n'est vraiment pas différent en ce sens que les requêtes HTTP sont faites. Mais ce n'est pas si simple. Voir mon article sur Ajaxian.com sur Why Load Testing Ajax is Hard. JMeter, Pylot, et The Grinder sont tous d'excellents outils pour générer des requêtes HTTP (je recommande personnellement Pylot). Mais à la base, ils n'agissent pas comme un navigateur et traitent le JavaScript, ce qui signifie qu'ils ne rejouent que le trafic qu'ils ont vu en un temps record. Si ces requêtes AJAX étaient uniques à cette session, elles peuvent ne pas convenir/être correctes pour être rejouées en gros volumes. Le fait est que plus la logique est poussée vers le navigateur, plus il devient difficile (sinon impossible) de simuler correctement le trafic en utilisant des outils de test de charge traditionnels.
Dans mon article, je donne un exemple simple de la difficulté à tester quelque chose comme la page d'accueil de Google lorsque vous souhaitez interroger 1000 de différents termes de recherche (un objectif important lors des tests de charge).Pour le faire avec JMeter/Pylot/Grinder, vous finissez par réécrire des parties du code AJAX (dans votre cas w/jQuery) dans la langue maternelle de l'outil.
Cela devient encore plus complexe si votre objectif est de mesurer le temps de réponse tel que perçu par l'utilisateur (ce qui est sans doute la chose la plus importante à la fin de la journée). Pour les applications vraiment complexes qui utilisent Comet/"Reverse Ajax" (une technique qui maintient les sockets ouvertes pendant de longues périodes), les outils de chargement traditionnels ne fonctionnent pas du tout.
Mon entreprise, BrowserMob, fournit un load testing service qui utilise les navigateurs Firefox, alimentés par Selenium, pour conduire des centaines ou des milliers de navigateurs réels, vous permettant de mesurer et de temps la performance des éléments visuels comme on le voit dans le navigateur. Nous prenons également en charge les utilisateurs virtuels traditionnels (trafic HTTP invisible) et un navigateur simulé (via HtmlUnit). Tout ce qui est dit, généralement un mélange d'un service comme BrowserMob et le test de charge traditionnel est la bonne approche. C'est-à-dire que les vrais navigateurs sont parfaits pour un test de charge en toute fidélité, mais ils ne seront jamais aussi économiques que les "utilisateurs virtuels", puisqu'ils nécessitent 10 à 100 fois plus de RAM et de CPU. Voir mon blog récent sur la question de savoir si simulate or not to simulate virtual users.
Espérons que ça aide!