Test de charge des applications AJAX
Créez des scripts de scénarios utilisateur pour vos applications AJAX afin d’examiner le comportement des utilisateurs
sous charge, d’identifier les problèmes et de valider les performances.
Aperçu du contenu
- Qu’est-ce que AJAX ?
- Quels sont les défis liés aux applications AJAX ?
- Techniques de simulation utilisateur
Ceux d’entre vous qui ont dû s’occuper des tests de charge des applications web AJAX (Asynchronous JavaScript and XML) ont appris que cela peut souvent représenter un défi difficile en termes de développement et d’automatisation. Cet article fournira des informations supplémentaires sur la technique de développement AJAX, ses avantages et inconvénients, ainsi qu’une approche recommandée pour les tests de performance AJAX.
Il y a plusieurs décennies, les pages web et applications étaient ennuyeuses, mais extrêmement légères, faciles à maintenir et leur testabilité était fantastique comparée aux frameworks d’applications web utilisés aujourd’hui. Les utilisateurs passaient souvent plus de temps à attendre devant un écran blanc qu’à interagir avec ces premières applications web. En raison de cette faible utilisabilité, les entreprises évitaient de dépenser de l’argent pour de nouveaux services web.
À partir de 2005, une nouvelle technologie appelée AJAX a permis aux développeurs de créer des sites web modernes, réduisant le temps que les utilisateurs passaient devant un écran vide en attendant le chargement d’une page. AJAX est une abréviation et plus qu’une technologie, puisqu’elle comprend HTML, CSS, JavaScript, XMLHttpRequest, et un langage de script côté serveur tel que PHP.
Au début de l’ère Internet, la popularité des pages web riches en contenu et interactives était limitée car il n’était pas possible de mettre à jour une page web sans la recharger entièrement. Avec l’évolution des technologies et techniques, AJAX a permis de combler cette lacune en introduisant le concept de chargement de données asynchrone, permettant à l’utilisateur final d’interagir avec la page pendant que les données sont chargées en arrière-plan. Aujourd’hui, ce concept est largement utilisé car il permet la mise en œuvre d’applications web interactives et dynamiques, améliorant ainsi l’expérience utilisateur globale.
Une requête AJAX typique se compose du processus suivant :
- L’utilisateur navigue sur la page web ou l’application web.
- Le gestionnaire de cette page crée un objet XMLHttpRequest.
- L’objet XMLHttpRequest demande un document au serveur.
- Le serveur récupère les données appropriées et les renvoie.
- L’objet XMLHttpRequest déclenche un événement pour notifier la page web ou l’application que les données sont arrivées.
- Le gestionnaire traite et affiche les données.
Mise à jour 2026 : Le comportement asynchrone de style AJAX est toujours largement utilisé dans les applications web modernes, en particulier avec les API et les frameworks front-end dynamiques. Les tests de charge doivent simuler les interactions réelles du navigateur pour capturer avec précision le comportement des requêtes en arrière-plan et des actions utilisateur sous charge.
Quels sont les défis liés aux applications AJAX ?
Quelques pièges communs associés aux applications web dynamiques basées sur AJAX sont déjà bien connus dans la communauté des développeurs. Nous aborderons certains des aspects les plus problématiques d’AJAX ci-dessous.
Premièrement, comme nous l’avons mentionné plus haut, l’un des composants d’AJAX est JavaScript. Si vous désactivez JavaScript dans votre navigateur, votre application ou site deviendra inutilisable. Il y a plusieurs années, il était courant que des organisations verrouillent les navigateurs de leurs employés et désactivent JavaScript pour des raisons de sécurité. Ces temps sont révolus, mais il est toujours bon d’en tenir compte car même de tels changements peuvent avoir des conséquences inattendues.
Deuxièmement, les données chargées et affichées dynamiquement ne font pas partie de la page, en particulier pour les pages créées en tant que SPA (Single-page Application). Si un moteur de recherche a indexé votre page web basée sur AJAX, le résultat, du point de vue SEO, peut être insatisfaisant car une grande partie du contenu n’est pas visible pour ces moteurs d’indexation.
Troisièmement, les mises à jour dynamiques continues de la page peuvent perturber les utilisateurs ayant une faible capacité d’attention. Plus les éléments dynamiques apparaissent sur ces pages, plus la probabilité que votre utilisateur soit interrompu et ne puisse pas finir son travail dans un temps acceptable augmente.
Enfin, en raison de la communication client-serveur basée sur des callbacks, la latence peut être plusieurs fois plus élevée comparée à d’autres technologies, comme WebSockets par exemple. Les clients web effectuent un tirage de mise à jour des données, ce qui est également un défi pour les tests automatisés.
Test de charge AJAX : techniques de simulation utilisateur
Les spécialistes des tests de charge et les ingénieurs performance sont responsables du choix d’une approche de simulation utilisateur appropriée, à la fois adaptée à votre application testée et ne générant pas trop d’efforts de votre part. Si vous choisissez la mauvaise méthode de simulation, il y a une forte probabilité que vous ne puissiez pas identifier les goulets d’étranglement de performance dans votre application.
Nous allons discuter de deux méthodes de simulation utilisateur ci-dessous.
Simulation basée sur le protocole des requêtes et réponses
La plupart des outils de test open source ainsi que les outils commerciaux de test de charge supportent cette procédure. Vous enregistrez les interactions client-serveur, et l’outil de test capture toutes les requêtes et réponses dans un script de test. Après paramétrage des données dynamiques, telles que les ID de sessions ou les données d’entrée du test, les scripts peuvent être utilisés pour simuler la charge requise sur votre système back-end. Sachez que le traitement ou les interactions côté client ne font pas partie de vos mesures de temps de réponse au niveau protocole.
Simulation complète basée sur le navigateur des interactions utilisateur réelles
Seules certaines des solutions de test de charge plus complètes sur le marché fournissent et supportent des simulations de test de charge basées sur un navigateur complet. La raison en est que les exigences en ressources système sont plus élevées et la mise en œuvre d’une relecture fiable peut être assez difficile. Lorsqu’il s’agit de créer des scripts de test pour des simulations utilisateur basées sur un navigateur complet, la création est similaire à l’approche basée sur protocole, cependant, cette fois toutes les interactions côté client sont enregistrées et sauvegardées.
Le testeur ou l’ingénieur navigue sur la page web ou l’application web pendant qu’un enregistreur de script capture toutes les interactions dans le navigateur web. Pendant l’exécution du test, un navigateur web sans interface utilisateur exécute les interactions enregistrées et répond aux callbacks du serveur comme un utilisateur réel. Ce type de simulation utilisateur est très précis et fournit des métriques de performance front-end réalistes.
La première méthode de simulation décrite est parfaite pour les applications web statiques, a une faible charge de simulation sur votre machine d’injection de charge et est souvent facile à mettre en œuvre. La seconde technique fournit des temps de réponse de bout en bout précis, mais leur charge sur le serveur de test de charge est bien plus élevée. Alors, comment choisir la meilleure méthode de simulation utilisateur pour tester la charge des applications ou pages web basées sur AJAX ?
Test de charge AJAX en action
Quelle est la meilleure approche de test de charge AJAX et comment valider votre décision ? Évidemment, il est bon de commencer par une petite expérience si vous n’êtes pas sûr de l’approche qui fournira des résultats précis.
Pour ce scénario, nous avons couvert deux implémentations de test de charge pour une application d’exemple AJAX utilisant ajaxsearchpro.com. Cette application de démonstration est un moteur de recherche simple. Pour cet exemple, supposons qu’un utilisateur tape un terme de recherche dans le champ de recherche et que le contenu correspondant soit affiché. Après que la touche entrée soit enfoncée ou que le bouton de recherche soit cliqué, la recherche finale est exécutée et les résultats de recherche correspondants s’affichent à l’écran. Ci-dessous se trouve le graphique en cascade capturé avec les DevTools du navigateur Chrome. Le temps de réponse de la requête de recherche « car » était de 2,2 secondes.
Nous avons utilisé les outils de développement intégrés au navigateur Chrome, qui nous ont permis de découvrir qu’il exécute cette requête lorsqu’il effectue l’action de recherche : ajaxsearchpro.com/?s=car
Nous avons créé un script de test de charge basé sur le protocole et un autre basé sur le navigateur, exécuté les deux, et comparé les métriques de performance résultantes. Qu’en pensez-vous ? Quelle simulation utilisateur est la meilleure pour une application basée sur AJAX ?
Script de test de charge AJAX basé sur le protocole
| Étapes scriptées : | https://ajaxsearchpro.com/?s=car | Temps de réponse : | 594 ms |
| Approche de simulation : | Niveau protocole, Chrome | Nombre de requêtes : | 1 |
Graphique en cascade
Résumé de l’exécution du script basé sur le protocole
Script de test de charge AJAX basé sur le navigateur
| Étapes scriptées : | https://ajaxsearchpro.com/?s=car | Temps de réponse : | 2,18 s |
| Approche de simulation : | Niveau protocole, Chrome | Nombre de requêtes : | 32 |
Graphique en cascade
Résumé de l’exécution du script basé sur le navigateur
Comparaison des deux méthodes de simulation
En raison de son modèle de communication asynchrone, les applications basées sur AJAX ne peuvent pas être automatisées au niveau protocole. Seule une simulation basée sur un véritable navigateur fournit des résultats précis et génère une charge réaliste sur votre système back-end.
Considérons un test de charge de notre application de démonstration ajaxsearchpro.com avec 100 utilisateurs concurrents et 10 ,000 recherches par heure. Si vous décidez d’utiliser la simulation basée sur le protocole, vous manquerez 10 000 x 31 = 310 000 requêtes. Évidemment, cela conduirait à des résultats de test de charge totalement inexactes.
Comment la solution LoadView gère les tests de charge avec AJAX
LoadView, notre plateforme de test de charge cloud, est conçue pour tester toutes les applications web 2.0 modernes telles que AJAX, Flash, Angular, Knockout, HTML5, jQuery, et bien d’autres. Sa facilité d’utilisation est exceptionnelle. Vous pouvez enregistrer des scénarios complets basés sur le navigateur et simuler plus de 40 appareils mobiles ou navigateurs tels qu’Internet Explorer, Chrome, iPhone, Samsung, Blackberry, et bien d’autres.
Comme nous l’avons mentionné plus tôt, de nombreuses solutions de test de charge ne fournissent qu’une approche de simulation utilisateur basée sur le protocole, ce qui est insuffisant. Vous pouvez mettre à rude épreuve votre back end avec des tests au niveau du protocole, mais une part importante des requêtes client-serveur et du traitement côté client est exclue. La plateforme LoadView vous offre tout ce dont vous avez besoin en matière de simulation utilisateur précise.
Cinq étapes pour exécuter vos tests de charge basés sur AJAX avec LoadView
1. Enregistrez votre application AJAX
Vous pouvez utiliser EveryStep Web Recorder pour naviguer manuellement dans votre application basée sur AJAX. EveryStep enregistrera toutes les actions et vous permettra d’ajouter des minuteries ou des étapes de vérification. Une fois que vous aurez parcouru votre application et créé un script, vous pourrez effectuer un essai avec un seul utilisateur ou télécharger les actions enregistrées sur notre plateforme et créer votre dispositif de test de charge.
2. Calibrez
L’attribution des machines d’injection de charge est souvent une estimation. Des machines de génération de charge défaillantes fausseront vos résultats de test. LoadView exécute un test utilisateur unique de votre dispositif et calcule le nombre maximal d’utilisateurs par machine d’injection de charge. Cette étape évite qu’une machine surchargée impacte négativement les temps de réponse de votre application.
3. Plan d’exécution
Le volume d’utilisateurs varie souvent tout au long de la journée typique d’affaires. Nous avons répondu à ce besoin avec notre fonction de plan d’exécution. Elle vous offre une flexibilité totale pour modéliser des scénarios de test de charge réalistes.
4. Distribution des utilisateurs virtuels
LoadView vous permet de choisir parmi un large éventail de machines d’injection de charge dans le monde. Sélectionnez celles qui représentent la localisation habituelle de vos clients.
5. Lancez le test et consultez vos résultats
Dans cette dernière étape, vous pouvez démarrer l’exécution du test de charge. Une vue en ligne vous donnera en temps réel des informations sur les performances de votre application AJAX sous charge. Une fois l’exécution terminée, vous recevrez un rapport détaillé avec les principaux indicateurs de performance.
Tout considéré, LoadView remplit toutes les exigences d’une plateforme moderne de test de charge simplifiant les défis de l’automatisation des tests et vous aidant à simuler des scénarios proches de la production sur vos applications métier complexes. Pour plus d’informations sur LoadView, visitez le site web LoadView. Pour des informations techniques plus approfondies et des vidéos, consultez notre base de connaissances.
Vous souhaitez une démonstration en direct ? Planifiez une démo avec l’un de nos ingénieurs performance. Nos ingénieurs performance vous guideront à travers toute la solution LoadView, du scripting et la configuration du test de charge à l’exécution et à l’analyse post-test. Obtenez toutes vos réponses concernant les tests de charge !
Outils utilisés
LoadView : plateforme de test de charge cloud de Dotcom-Monitor
EveryStep Web Recorder : outil de scripting par pointage et clic web.
Chrome Developer Tools : outils de développement intégrés dans le navigateur Chrome.
Pour en savoir plus sur la plateforme Dotcom-Monitor et les solutions de surveillance proposées, visitez www.dotcom-monitor.com