Dans notre article précédent, Test 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 dans les onglets, et déconnexion — en utilisant à la fois LoadRunner et LoadView. Cette comparaison mettait en avant les différences en termes d’effort de script, de complexité de configuration et de facilité d’utilisation.
En nous appuyant sur cet exercice, cet article présente une comparaison détaillée de 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 fonctionne lors de l’exécution d’un flux utilisateur réel avec plusieurs utilisateurs virtuels, et comment ils gèrent :
- Visibilité et précision de l’exécution
- Rapports en temps réel et post-test
- Contenu dynamique et comportement frontend
- Diagnostic et débogage au niveau des sessions
Vue d’ensemble
Cette comparaison se concentre exclusivement sur l’expérience de configuration des tests et les capacités de reporting de LoadView et LoadRunner, deux outils leaders en test de performance.
L’évaluation est basée sur un flux utilisateur réel — lancement, connexion, actions, déconnexion — exécuté sur une application web dynamique. La comparaison met en avant :
- Facilité de configuration des scénarios de charge
- Visibilité pendant l’exécution des tests
- Profondeur et clarté des rapports de test
- Fonctionnalités de débogage telles que la relecture vidéo, la capture d’écran, la classification des erreurs, et l’analyse en waterfall
À mesure que les applications modernes adoptent de plus en plus les SPA (Single-Page Applications) et des frontends riches en JavaScript, les outils capables de simuler un véritable comportement navigateur et offrant des diagnostics visuels en temps réel sont plus importants que jamais.
- Préparation du scénario de test
LoadView
Concepteur de scénario basé sur un vrai navigateur
LoadView enregistre les interactions réelles du navigateur (clics, défilements, attentes, déclencheurs AJAX) directement dans Chrome ou Edge. Chaque étape est cartographiée dans un organigramme visuel, assurant une parfaite correspondance avec l’expérience utilisateur.
Assistant de configuration de charge visuel
Configurez facilement :
- Types de charge utilisateur : Courbe par étapes, Courbe d’ajustement dynamique et Courbe basée sur des objectifs
- Modèles de charge : Progressif, Exponentiel, Pic, Charge, Endurance/Soak, Bascullement, etc.
- Configuration du scénario : Durée du test, montée en charge, réduction par, maintien
- Régions : plus de 40 emplacements cloud dans le monde entier
- Navigateurs : Chrome ou Edge pour un contexte de rendu réel
s (par ex., Singapour, Californie, Londres)
Configuration sans environnement
Pas besoin d’installer ni de gérer les Load Generators (LG), machines virtuelles, règles de pare-feu ou configurations réseau. Toute l’infrastructure est automatiquement provisionnée dans le cloud de LoadView.
Conditions par étape
Configurez les critères de réussite/échec pour chaque étape, tels que :
- Validation de texte
- Visibilité des éléments
- Déclencheurs JavaScript
- Codes d’état HTTP, etc.
Aperçu en un clic
Exécutez un aperçu en utilisateur unique pour vérifier l’ensemble du flux de test avant d’exécuter un test complet. Cela inclut le rendu UI, les validations et les métriques de réponse.
Notes additionnelles :
- Peut fournir les noms de transaction, délais, mesures de temps, Lighthouse, limitation de réseau, etc.
- Logique de branchement, attentes conditionnelles et bouclage disponibles nativement.
LoadRunner
Conception de scénario basée sur le Controller
Les scénarios sont créés à l’aide du LoadRunner Controller en assignant :
- Groupes d’utilisateurs
- Plannings de montée en charge
- Temps de réflexion et réglages de rythme
- Durées d’exécution
Installation manuelle des Load Generators
Les testeurs doivent déployer et configurer les LG manuellement sur différentes machines ou hôtes cloud. La connectivité entre les LG et le Controller nécessite des réglages de pare-feu/NAT, autorisations de ports, et permissions d’infrastructure.
Les tests géographiques sont complexes
Pour simuler une charge depuis plusieurs régions, les utilisateurs doivent provisionner manuellement des serveurs dans chaque localisation cible, configurer l’accès et synchroniser les exécutions de test.
Logique de validation basique
La validation d’étape est basée sur les réponses au niveau protocolaire (par ex., HTTP 200). Les validations visuelles ne sont possibles que dans les scripts TrueClient, qui sont gourmands en ressources et nécessitent plus de maintenance.
Aperçu d’exécution
L’aperçu des flux de test avec rendu UI est disponible uniquement dans TrueClient. Pour les autres protocoles, les simulations ne comprennent pas de confirmation visuelle des parcours de test.
Notes additionnelles :
- Exige des compétences en scripting et protocoles
- Le choix du protocole (Web HTTP/HTML, SAP, Citrix, etc.) impacte la conception du script
- Visibilité d’exécution en temps réel
LoadView
Rapports riches hébergés dans le cloud accessibles en temps réel : Métriques de performance en directcs sont affichés en continu pendant l’exécution du test.
Mise à jour continue en temps réel des KPIs de performance : Des métriques telles que le temps de réponse moyen, le 90e percentile, le minimum, le maximum et le taux d’échec se mettent à jour en temps réel.
Classification des erreurs pour une analyse plus rapide de la cause racine : Les erreurs sont regroupées en catégories validation, client, serveur et tierces parties.
Liens PDF basés sur le cloud et tableaux de bord partageables : Distribuez facilement des tableaux de bord en direct ou exportez des résumés à partager avec les équipes.
Graphiques interactifs pour les temps de réponse, la répartition des erreurs et l’activité des utilisateurs virtuels : Permet une identification rapide des pics, tendances ou échecs. Une vue récapitulative complète pour suivre l’avancement du test en temps réel.
La moitié supérieure montre un pic soudain du temps de réponse moyen, qui correspond (voir les flèches rouges) à une baisse des sessions réussies et une augmentation des sessions échouées (graphique du bas). C’est un exemple idéal de la capacité de LoadView à corréler visuellement les dégradations de performance avec le comportement des sessions utilisateur.
Suivi cumulatif des sessions sur des fenêtres temporelles : Aide à évaluer la cohérence et la stabilité des tests tout au long de la période d’exécution.
Courbes de montée en charge des utilisateurs virtuels : Représentation visuelle des augmentations de charge alignées avec la performance des sessions.
Ce graphique montre comment les utilisateurs virtuels ont été augmentés dans le temps. La ligne verte montre le nombre réel d’utilisateurs exécutés, correspondant étroitement à la ligne orange (utilisateurs attendus), prouvant un comportement stable de montée et descente en charge. La ligne violette marque la limite maximale configurée pour les utilisateurs virtuels.
Statistiques serveur de chaque zone géographique : Diagnostique des problèmes spécifiques à une région ou la latence.
Navigation session par session montrant les parcours individuels des utilisateurs : Examinez le chemin de chaque utilisateur virtuel et les données de réponse associées.
Approfondissement des IDs de session spécifiques : Inspectez les parcours de tests individuels et voyez des insights détaillés au niveau réseau par utilisateur et isolez rapidement la source des erreurs pour une résolution plus rapide.
Cela montre comment plusieurs agents cloud (des régions AWS, Azure) ont partagé la charge du test. Le CPU et la mémoire sont restés majoritairement équilibrés pendant tout le temps, vérifiant l’architecture de distribution de test élastique de LoadView.
Comparaison Historique des Exécutions de Test dans LoadView
Comparer les Résultats à Travers Plusieurs Exécutions de Test
Bien que les rapports en temps réel et statiques soient précieux, LoadView offre également le suivi des tendances historiques dès la sortie de la boîte. Chaque exécution de test est automatiquement archivée et peut être comparée aux exécutions précédentes.
Vue des Performances Avant/Après
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 bases de référence des performances précédentes avec les résultats les plus récents — sans intégration ou configuration complexe.
Pas de Configuration Requise
Contrairement à LoadRunner, qui nécessite généralement une intégration avec des outils externes tels qu’InfluxDB, Grafana ou HP ALM pour l’analyse des tendances et la comparaison historique, LoadView fournit une visualisation historique intégrée via une interface web simple — sans configuration ni infrastructure supplémentaire requise.
Exemple : Une équipe de développement peut comparer un test d’il y a deux semaines (avant une optimisation de la base de données) avec la dernière exécution et voir immédiatement les améliorations en termes de temps de réponse et de taux d’erreur.
Avantages Supplémentaires :
- Les équipes QA peuvent valider les flux fonctionnellement et visuellement
- Réduit l’effort de débogage en évitant l’analyse des logs ou des vues uniquement back-end
LoadRunner
Graphiques du Contrôleur (Édition sous Licence uniquement)
Lorsque sous licence, LoadRunner Controller fournit des métriques en temps réel telles que :
- VUsers en cours d’exécution
- TPS (Transactions Par Seconde)
- Erreurs par seconde et quelques autres
Ces graphiques ne sont pas disponibles dans la version gratuite, limitant considérablement la visibilité lors de l’exécution.
Pas de Retour Frontend
Les captures d’écran, validations visuelles et données au niveau DOM ne sont pas disponibles sauf si TrueClient est utilisé. Même avec TrueClient, ces informations sont plus difficiles à analyser sous forte charge.
Pas de Répartition Géographique
LoadRunner ne propose pas de segmentation des performances par région dès la sortie de la boîte. Un scripting ou un marquage personnalisé est nécessaire.
Absence de Surveillance au Niveau Session
LoadRunner n’offre pas d’informations par session, ce qui rend difficile le suivi de l’étape qui a échoué, de ce que le navigateur a rendu à ce moment-là ou de la progression de la session dans son parcours d’exécution.
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 profondes est retardée jusqu’au rapport post-exécution dans l’outil Analysis
- Tableau Comparatif Résumé
| Fonctionnalité | LoadView | LoadRunner |
| Créateur de scénarios | Visuel, basé sur navigateur | Basé sur script et protocole (Contrôleur) |
| Configuration de charge géographique | Intégrée, gérée dans le cloud | Déploiement manuel des LG nécessaire |
| Visibilité au niveau de la session | Complète, avec relectures et captures d’écran | Absente |
| Graphique en cascade | Oui, au niveau du navigateur | Non disponible |
| Lecture vidéo | Oui | Non |
| Métriques Frontend (FCP, LCP, TTI, CLS) | Oui | Non |
| Catégorisation des erreurs | Auto-groupées par type | Analyse manuelle des logs |
| Partage de rapports | Tableaux de bord cloud, PDF, Excel, liens de partage | HTML local ou PDF uniquement |
| Comparaison des résultats historiques | Intégrée | Nécessite une configuration ALM/externe |
| Rapports accessibles aux parties prenantes | Oui, convivial pour les entreprises | Technique uniquement |
| Configuration de l’environnement | Hébergé dans le cloud, aucune infrastructure requise | Nécessite la configuration des Load Generators |
| Meilleur cas d’utilisation | Applications web, UX, frontend moderne | APIs backend, tests au niveau protocolaire |
Meilleurs cas d’utilisation pour LoadRunner (Tests au niveau protocolaire)
LoadRunner est un outil de test de performance puissant, de niveau entreprise, idéal pour les tests lourds backend basés sur les protocoles. Il simule le trafic au niveau du transport, ce qui le rend parfait pour les applications où le rendu du navigateur n’est pas requis.
| Cas d’utilisation | Pourquoi LoadRunner fonctionne bien | Exemple |
| 1. Test de charge 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 gérant des transactions à grand volume |
| 2. Tests SAP, Oracle, Citrix | Offre un support au niveau protocolaire pour les systèmes d’entreprise complexes comme SAP GUI, Oracle Forms et Citrix. | Test de performance des flux du système SAP RH |
| 3. Test de charge des systèmes backend | Efficace pour les tests de charge des files de messages, bases de données et mainframes hérités. | Test de charge d’un backend de reporting financier basé sur COBOL |
| 4. Intégration dans la pipeline CI/CD | Intègre avec Jenkins, Azure DevOps, aet ALM pour les tests automatisés de régression et de performance. | Exécuter des tests de performance nocturnes après la fusion du code |
| 5. Tests de protocoles complexes | Simule les interactions FTP, SMTP, WebSocket et Telnet avec précision protocolaire. | Test de charge des performances de téléchargement de fichiers sur un serveur FTP interne |
| 6. Script personnalisé en C | Le scripting complet en langage C permet une conception de tests fine, la logique et la gestion des données. | Simulation d’un processus de réclamation d’assurance en plusieurs étapes via des scripts codés |
Meilleurs cas d’utilisation pour LoadView (test basé sur un 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 qui privilégient l’expérience utilisateur et la validation visuelle.
| Cas d’utilisation | Pourquoi LoadView est le meilleur choix | Exemple |
| 1. Test de charge basé sur un navigateur | Exécute de véritables parcours utilisateurs avec JavaScript, cookies, mises à jour DOM et rendu des pages. | Test de charge d’un portail de réservation de voyage |
| 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 sous Angular |
| 3. Validation UX e-commerce | Mesure le temps de chargement, FCP, LCP, TTI — indicateurs réels impactant le taux de conversion. | Test de charge d’un parcours du panier à la caisse avant le Black Friday |
| 4. Tests géo-distribués | Supporte les tests depuis plus de 40 emplacements pour simuler l’accès utilisateur depuis différentes régions. | Tester la vitesse du site depuis les États-Unis, l’Europe et l’Inde |
| 5. Tests de charge sans script | Enregistre les flux comme un utilisateur (clics, défilements, filtres, navigation). Aucun scripting technique nécessaire. | Les chefs de produit ou les équipes QA testent les parcours utilisateurs sans intervention des devs |
| 6. Rapports prêts pour les parties prenantes | Les rapports incluent replays de session, graphiques visuels, exportations PDF — adaptés aux utilisateurs métiers/non techniques. | Partager les résultats avec les VPs, propriétaires de produit ou clients |
| 7. Validation de contenu dynamique | Capture chaque changement d’interface, rendu différé, fenêtres modales ou filtres basés sur AJAX. | Test d’un site de listing d’hôtels avec filtres et chargement paresseux |
Résumé de l’article
LoadView offre une expérience de test moderne basée sur un navigateur, optimisée pour les applications web dynamiques. Il permet :
- Un accès en temps réel aux métriques live et graphiques de performance pendant l’exécution des tests
- Des insights approfondis au niveau des sessions avec lecture vidéo, captures d’écran et replays complets des interactions
- Facile report sharing through cloud dashboards, PDFs, and Excel exports
- Débogage simplifié avec des métriques de navigateur intégrées (FCP, LCP, TTI), des répartitions géographiques, et une classification automatique des erreurs
LoadRunner, bien que robuste pour les systèmes d’entreprise basés sur les protocoles, offre :
- Visibilité limitée de l’interface utilisateur et absence de métriques frontend intégrées
- Rapports post-exécution sans tableaux de bord en temps réel ni replays de session
- Fonctionnalités de reporting souvent dépendantes d’intégrations tierces (ex. ALM, InfluxDB, Grafana)
- Scripting TrueClient nécessaire pour la simulation de navigateur, augmentant la complexité des tests et la charge système