Dans notre précédent article, Tests de charge Web : LoadRunner vs. LoadView – Scénario réel, nous avons démontré comment simuler un parcours utilisateur typique sur PhoneNumberMonitoring.com — lancement du site, connexion, navigation entre les onglets et déconnexion — en utilisant à la fois LoadRunner et LoadView. Cette comparaison mettait en avant les différences en matière de complexité des scripts, de configuration et de facilité d’utilisation.
Poursuivant cet exercice, cet article présente une comparaison détaillée entre LoadView et LoadRunner, en se concentrant spécifiquement sur la préparation des scénarios de test et les capacités de reporting. Nous examinons comment chaque outil se comporte lors de l’exécution d’un parcours utilisateur réel avec plusieurs utilisateurs virtuels, et leur efficacité face à :
- La visibilité et la précision de l’exécution
- Le reporting en temps réel et post-test
- Le contenu dynamique et le comportement du frontend
- Les diagnostics et débogages au niveau des sessions
Vue d’ensemble
Cette comparaison se concentre exclusivement sur l’expérience de configuration de test et les capacités de reporting de LoadView et LoadRunner, deux outils leaders dans le domaine des tests de performance.
L’évaluation est basée sur un parcours utilisateur réel — lancement, connexion, actions, déconnexion — exécuté sur une application Web dynamique. La comparaison met en avant :
- La facilité de configuration des scénarios de charge
- La visibilité pendant l’exécution du test
- La profondeur et la clarté des rapports
- Les fonctionnalités de débogage telles que le replay vidéo, la capture d’écran, la classification des erreurs et l’analyse en cascade
À mesure que les applications modernes adoptent de plus en plus les SPAs (applications monopages) et les frontends riches en JavaScript, les outils capables de simuler un comportement réel de navigateur et de fournir des diagnostics visuels en temps réel deviennent plus essentiels que jamais.
- Préparation du scénario de test
LoadView
Concepteur de scénario basé sur navigateur réel
LoadView enregistre les interactions réelles dans le navigateur (clics, défilements, attentes, déclenchements AJAX) directement dans Chrome ou Edge. Chaque étape est représentée dans un organigramme visuel, garantissant un alignement complet avec l’expérience utilisateur.
Assistant de configuration visuelle de la charge
Configuration simple :
- Types de charge utilisateur : courbe de montée progressive, courbe d’ajustement dynamique et courbe basée sur des objectifs
- Modèles de charge : progressif, exponentiel, pic, charge, endurance/soak, basculement, etc.
- Paramètres du scénario : durée du test, montée en charge, diminution, maintien
- Régions : plus de 40 emplacements cloud dans le monde (ex : Singapour, Californie, Londres)
- Navigateurs : Chrome ou Edge pour un rendu fidèle du contexte
Configuration sans environnement
Aucune installation ni gestion de générateurs de charge (LG), de machines virtuelles, de règles pare-feu ou de configurations réseau requise. Toute l’infrastructure est automatiquement provisionnée dans le cloud de LoadView.
Conditions au niveau des étapes
Définissez des critères de réussite/échec pour chaque étape, tels que :
- Validation de texte
- Visibilité d’un élément
- Déclencheurs JavaScript
- Codes de statut HTTP, etc.
Aperçu en un clic
Lancez un aperçu avec un seul utilisateur pour vérifier l’ensemble du scénario avant l’exécution complète. Cela inclut le rendu de l’interface, les validations et les mesures de performance.
Notes supplémentaires :
- Peut définir des noms de transactions, délais, mesures de temps, Lighthouse, limitation de bande passante, etc.
- Logique conditionnelle, attentes conditionnelles et boucles disponibles nativement.
LoadRunner
Conception de scénario via le Controller
Les scénarios sont créés via le Controller de LoadRunner en assignant :
- Groupes d’utilisateurs
- Plannings de montée en charge
- Temps de réflexion et rythme d’exécution
- Durées d’exécution
Configuration manuelle des générateurs de charge
Les testeurs doivent déployer et configurer manuellement les LGs sur des machines ou des hôtes cloud. La connectivité entre les LGs et le Controller requiert des réglages de pare-feu/NAT, autorisations de port et accès à l’infrastructure.
Tests géographiques complexes
Pour simuler une charge depuis plusieurs régions, les utilisateurs doivent provisionner manuellement des serveurs dans chaque zone cible, configurer les accès et synchroniser les exécutions.
Logique de validation basique
La validation des étapes repose sur les réponses au niveau protocole (ex : HTTP 200). Les validations visuelles ne sont possibles que dans les scripts TrueClient, qui sont plus lourds et nécessitent un entretien accru.
Aperçu de l’exécution
L’aperçu visuel du scénario n’est disponible que pour les scripts TrueClient. Pour les autres protocoles, les tests à blanc n’incluent pas de confirmation visuelle du parcours.
Notes supplémentaires :
- Nécessite une expertise en scripting et protocoles
- Le choix du protocole (Web HTTP/HTML, SAP, Citrix, etc.) influence la structure du script
- Visibilité d’exécution en temps réel
LoadView
Rapports riches hébergés dans le cloud accessibles en temps réel : Les indicateurs de performance sont affichés en continu pendant l’exécution du test.
Mise à jour continue des indicateurs de performance : Des métriques comme le temps de réponse moyen, le 90e percentile, le minimum, le maximum et le taux d’échec sont actualisées en temps réel.
Classification des erreurs pour une analyse rapide des causes racines : Les erreurs sont regroupées par type : validation, client, serveur, tiers.
PDF dans le cloud et tableaux de bord partageables : Partagez facilement des tableaux de bord en direct ou exportez des résumés à transmettre à votre équipe.
Graphiques interactifs sur les temps de réponse, la répartition des erreurs et l’activité des utilisateurs virtuels : Permettent une identification rapide des pics, tendances ou échecs. Une vue récapitulative complète permet de surveiller la progression du test en temps réel.
La moitié supérieure montre un pic soudain du temps de réponse moyen, qui corrèle (flèches rouges) avec une baisse des sessions réussies et une hausse des sessions échouées (graphique inférieur). C’est un exemple idéal de la capacité de LoadView à corréler visuellement les dégradations de performance avec le comportement utilisateur.
Suivi cumulé des sessions sur des plages horaires : Permet d’évaluer la cohérence et la stabilité du test tout au long de son exécution.
Courbes de montée en charge des utilisateurs virtuels : Représentation visuelle de l’augmentation de la charge, alignée avec la performance des sessions.
Ce graphique montre comment les utilisateurs virtuels ont été progressivement augmentés. La ligne verte montre le nombre réel d’utilisateurs exécutés, correspondant presque à la ligne orange (utilisateurs attendus), ce qui démontre une montée et descente de charge stables. La ligne violette indique la limite maximale configurée pour les utilisateurs virtuels.
Statistiques serveur par zone géographique : Pour diagnostiquer les problèmes régionaux ou de latence.
Navigation par session montrant le parcours individuel de chaque utilisateur : Explorez le parcours de tout utilisateur virtuel et les données de réponse associées.
Analyse par ID de session : Inspectez le chemin de test individuel et obtenez des informations détaillées sur la couche réseau pour chaque utilisateur, afin d’isoler rapidement les erreurs.
Cela montre comment plusieurs agents cloud (AWS, Azure) ont partagé la charge du test. Le CPU et la mémoire sont restés globalement équilibrés, ce qui confirme l’architecture élastique de distribution de charge de LoadView.
Comparaison des exécutions de test historiques dans LoadView
Comparer les résultats entre plusieurs exécutions de test
Bien que les rapports en temps réel et statiques soient précieux, LoadView propose également un suivi des tendances historiques prêt à l’emploi. Chaque exécution de test est automatiquement archivée et peut être comparée aux exécutions précédentes.
Vue avant/après des performances
Cela permet aux équipes d’évaluer les modifications apportées au code de l’application, à l’infrastructure ou aux services tiers en comparant directement les performances de référence précédentes aux résultats les plus récents — sans intégration ou configuration complexe.
Aucune configuration requise
Contrairement à LoadRunner, qui nécessite généralement une intégration avec des outils externes comme InfluxDB, Grafana ou HP ALM pour l’analyse des tendances et la comparaison historique, LoadView propose une visualisation intégrée des données historiques via une interface Web simple — sans configuration ni infrastructure supplémentaire.
Exemple : Une équipe de développement peut comparer un test réalisé il y a deux semaines (avant une optimisation de base de données) avec l’exécution la plus récente et constater immédiatement les améliorations en termes de temps de réponse et de taux d’erreurs.
Avantages supplémentaires :
- Les équipes QA peuvent valider les parcours fonctionnellement et visuellement
- Réduction des efforts de débogage en évitant l’analyse des journaux ou les vues back-end uniquement
LoadRunner
Graphiques du Controller (version sous licence uniquement)
Avec licence, le Controller LoadRunner fournit des métriques d’exécution telles que :
- Utilisateurs virtuels actifs
- TPS (Transactions par seconde)
- Erreurs par seconde, etc.
Ces graphiques ne sont pas disponibles dans l’édition gratuite, ce qui limite fortement la visibilité pendant l’exécution.
Aucun retour visuel côté frontend
Les captures d’écran, validations visuelles et données DOM ne sont disponibles que via TrueClient. Même avec TrueClient, ces informations sont plus difficiles à analyser sous forte charge.
Pas de segmentation géographique
Par défaut, LoadRunner ne fournit pas de segmentation des performances par région. Un script personnalisé ou un marquage spécifique est requis.
Pas de suivi au niveau des sessions
LoadRunner ne propose pas d’informations détaillées par session, rendant difficile l’identification des étapes ayant échoué, de ce que le navigateur a rendu à ce moment-là, ou du chemin suivi par la session.
Limitations supplémentaires :
- Pas de capture d’écran intégrée
- Pas de données de session en temps réel
- L’analyse des causes racines est différée jusqu’au rapport post-exécution via l’outil Analysis
- Tableau comparatif récapitulatif
| Fonctionnalité | LoadView | LoadRunner |
| Créateur de scénario | Visuel, basé navigateur | Basé script et protocole (Controller) |
| Configuration de charge géographique | Intégrée, gérée dans le cloud | Déploiement manuel des LG requis |
| Visibilité au niveau des sessions | Complète, avec replays et captures | Absente |
| Diagramme en cascade (waterfall) | Oui, au niveau navigateur | Non disponible |
| Lecture vidéo | Oui | Non |
| Métriques frontend (FCP, LCP, TTI, CLS) | Oui | Non |
| Catégorisation des erreurs | Regroupement automatique par type | Analyse manuelle des journaux |
| Partage de rapports | Tableaux de bord cloud, PDF, Excel, liens partageables | HTML local ou PDF uniquement |
| Comparaison historique des résultats | Intégrée | Nécessite ALM/configuration externe |
| Rapports prêts pour les parties prenantes | Oui, lisibles par les métiers | Techniques uniquement |
| Configuration de l’environnement | Hébergé dans le cloud, aucune infra requise | Configuration des générateurs de charge requise |
| Cas d’usage optimal | Applications Web, UX, frontend moderne | APIs backend, tests au niveau protocole |
Meilleurs cas d’utilisation de LoadRunner (tests au niveau protocole)
LoadRunner est un outil de test de performance puissant, de niveau entreprise, particulièrement adapté aux tests axés sur le backend et basés sur les protocoles. Il simule le trafic au niveau de la couche de transport, ce qui le rend idéal pour les applications ne nécessitant pas de rendu navigateur.
| Cas d’utilisation | Pourquoi LoadRunner fonctionne bien | Exemple |
| 1. Test de charge d’API | Prend en charge divers protocoles comme HTTP, Web Services et REST. Permet une paramétrisation et une corrélation précises. | Test de charge d’une API bancaire ou d’assurance traitant un grand volume de transactions |
| 2. Tests SAP, Oracle, Citrix | Offre une prise en charge au niveau protocole pour des systèmes d’entreprise complexes comme SAP GUI, Oracle Forms et Citrix. | Test de performance des workflows du système SAP RH |
| 3. Test de charge de systèmes backend | Efficace pour les tests de résistance de files de messages, bases de données et mainframes anciens. | Test de charge d’un backend de reporting financier basé sur COBOL |
| 4. Intégration dans une pipeline CI/CD | S’intègre à Jenkins, Azure DevOps et ALM pour les tests automatisés de régression et de performance. | Exécuter des tests de performance nocturnes après une fusion de code |
| 5. Tests de protocoles complexes | Simule les interactions FTP, SMTP, WebSocket et Telnet avec une précision protocolaire. | Test de charge de la performance d’un serveur FTP interne |
| 6. Scripts personnalisés en C | Le langage C complet permet une conception de test, une logique et une gestion de données très détaillées. | Simulation d’un processus de réclamation d’assurance en plusieurs étapes via des scripts codés |
Meilleurs cas d’utilisation de LoadView (tests basés sur navigateur réel)
(Chrome, Edge) pour simuler le comportement réel des utilisateurs, ce qui le rend idéal pour les applications web modernes et les équipes mettant l’accent sur l’expérience utilisateur et la validation visuelle.
| Cas d’utilisation | Pourquoi LoadView est le plus adapté | Exemple |
| 1. Test de charge basé navigateur | Exécute de vrais parcours utilisateurs avec JavaScript, cookies, mises à jour DOM et rendu de page. | Test de charge d’un portail de réservation de voyages |
| 2. Test de SPA (React, Angular, Vue) | Gère automatiquement le comportement asynchrone (AJAX, fetch, websockets) des frameworks JS. | Test d’un tableau de bord client en Angular |
| 3. Validation UX pour e-commerce | Mesure le temps de chargement, FCP, LCP, TTI — métriques réelles influençant le taux de conversion. | Test de charge d’un parcours panier → paiement avant le Black Friday |
| 4. Tests géodistribués | Prend en charge des tests depuis plus de 40 emplacements pour simuler un accès mondial. | Tester la vitesse du site depuis les États-Unis, l’Europe et l’Inde |
| 5. Test de charge sans script | Enregistre les parcours utilisateur (clics, défilements, filtres, navigation). Aucun script technique requis. | Les chefs de produit ou les équipes QA testent les parcours utilisateurs sans intervention des développeurs |
| 6. Rapports adaptés aux parties prenantes | Les rapports incluent replays de sessions, graphiques visuels, exports PDF — adaptés aux utilisateurs métier/non-techniques. | Partager les résultats avec des VP, responsables produit ou clients |
| 7. Validation de contenu dynamique | Capture chaque changement UI, rendu différé, modales ou filtres AJAX. | Test d’un site d’hôtels avec filtres et chargement différé |
Résumé de l’article
LoadView offre une expérience de test moderne, basée sur navigateur, optimisée pour les applications web dynamiques. Il permet :
- Un accès en temps réel aux métriques et graphiques de performance pendant l’exécution
- Des insights approfondis au niveau des sessions avec replays vidéo, captures d’écran et rejouabilité complète
- Un partage facile des rapports via des tableaux de bord cloud, PDF et exports Excel
- Un débogage simplifié avec des métriques intégrées du navigateur (FCP, LCP, TTI), des ventilations géographiques et une classification automatique des erreurs
LoadRunner, bien que robuste pour les systèmes d’entreprise basés sur protocole, offre :
- Une visibilité limitée sur l’interface utilisateur et aucune métrique frontend intégrée
- Des rapports uniquement disponibles après l’exécution, sans tableau de bord temps réel ni replay de session
- Des capacités de reporting souvent dépendantes d’intégrations tierces (ex : ALM, InfluxDB, Grafana)
- Des scripts TrueClient requis pour simuler le navigateur, augmentant la complexité des tests et la charge système