Dans cet article, nous comparons LoadRunner et LoadView en utilisant un scénario de test pratique sur l’application exemple PhoneNumberMonitoring.com. Le flux de test est simple :
Lancer l’application → Se connecter → Naviguer vers un onglet → Se déconnecter
Cependant, la manière dont ce flux est mis en œuvre dans LoadRunner vs LoadView est complètement différente — surtout en ce qui concerne l’effort de configuration, la flexibilité, la scalabilité et la précision de la simulation en conditions réelles.
Utilisation de LoadRunner : Puissance au niveau protocolaire avec haute complexité
LoadRunner offre un contrôle approfondi au niveau protocolaire grâce à VuGen (Virtual User Generator) et prend en charge des protocoles tels que HTTP/HTML, SAP, Web Services, TruClient, etc. Bien que cela offre une flexibilité pour les tests en entreprise, l’effort nécessaire pour configurer même un flux basique peut être écrasant.
Pour ce test, nous avons utilisé le protocole Web HTTP/HTML, qui convient aux applications web sans rendu complet du navigateur.
Ce que nous avons fait dans LoadRunner
- Sélection du protocole : Choisi HTTP/HTML ; cependant, sélectionner le mode d’enregistrement correct (basé sur HTML vs basé sur URL) est une décision cruciale et nécessite souvent des essais et erreurs pour garantir la génération correcte du script.
- Enregistrement avec VuGen : Configuré le mappage des ports (comme vu dans la capture d’écran) et sélectionné le niveau de capture (par exemple WinInet ou Socket) — chacun avec son propre comportement et
- Configuration de la corrélation : Extraction manuelle des données de session dynamiques via web_reg_save_param_ex et le chemin JSON. Si la corrélation est manquée, le test échoue — pas de suggestions automatiques ni d’indices UI.
- Paramétrisation : Remplacement des valeurs codées en dur par des fichiers de données en utilisant l’utilitaire de paramétrisation de LoadRunner.
- Temps de réflexion & Transactions : Encapsulation des actions critiques dans lr_start_transaction() et ajout de lr_think_time() pour simuler les délais utilisateur.
- Gestion de session : Gestion manuelle des cookies et des en-têtes personnalisés entre
- Logique avancée : Ajout de if-else, boucles et code personnalisé en C pour le contrôle des flux
Points de douleur clés & limitations avec LoadRunner
Malgré sa puissance, LoadRunner présente plusieurs points de friction : complexité d’enregistrement
- Le choix entre enregistrement basé sur HTML ou basé sur URL impacte souvent le script
- Le choix entre capture au niveau WinInet et Socket peut déconcerter les débutants — certaines applications ne répondent correctement qu’à des modes de capture spécifiques.
Journalisation, dépannage & débogage
- Les journaux LoadRunner sont spécifiques au protocole et souvent cryptiques — journaux HTTP, dumps XML, et journaux de lecture sont répartis sur différents onglets et difficiles à corréler en temps réel.
- La relecture en direct des sessions utilisateur n’est pas disponible — ce qui complique l’identification visuelle des erreurs durant la lecture du script.
Corrélation spécifique au protocole
- Chaque protocole (SAP, Oracle, HTTP, etc.) nécessite des approches de corrélation différentes.
Protocole HTTP/HTML
web_reg_save_param, web_reg_save_param_ex, web_reg_save_param_json, web_reg_save_param_xpath (HTTP/HTML, Web Services), web_reg_save_param_attrib, etc.
Protocole SAP GUI
sapgui_get_text, sapgui_select_active_window, sapgui_set_property, sapgui_get_property, sapgui_status_bar_set_text, etc.
Protocole Oracle NCA
nca_set_window, nca_set_menu_item, nca_edit_set, nca_button_press, nca_get_text, etc.
Protocole Web Service
web_custom_request, web_service_call, etc.
- Il n’y a pas de cadre de corrélation unifié — même TruClient se comporte entièrement différemment et ne partage pas la logique de corrélation avec le protocole HTTP.
Performance & Utilisabilité
- Les scripts TruClient simulent des flux basés sur le navigateur mais consomment beaucoup de ressources système et prennent beaucoup plus de temps à s’exécuter.
- L’édition visuelle du flux est basique, les échecs de débogage impliquent souvent de passer d’une fenêtre de journal à l’autre avec des captures d’écran.
Configuration des tests de charge distribués avec LoadRunner
- LoadRunner nécessite plusieurs composants : VuGen pour le scripting, Controller pour l’orchestration, et Load Generators (LG) pour la distribution.
- Nécessite une configuration manuelle, règles de pare-feu, ouvertures de ports, et réseau
- La scalabilité et l’orchestration d’exécution ajoutent à la complexité — peu adapté aux équipes agiles nécessitant des cycles rapides.
LoadRunner est puissant pour les systèmes hérités, mais pas idéal pour les tests web modernes ou les itérations en sprint.
Utilisation de LoadView : Test de charge avec navigateur réel simplifié
LoadView propose une approche moderne avec tests de charge basés sur navigateur, natifs dans le cloud. Il simule le comportement réel des utilisateurs dans des navigateurs comme Chrome ou Edge, validant non seulement les réponses back-end mais aussi la performance front-end réelle (métriques UX).
Pour le même flux sur PhoneNumberMonitoring.com, nous avons utilisé EveryStep Recorder et terminé la configuration du test en moins de 5 minutes — sans code, sans configurations, et sans plugins.
Pourquoi LoadView semblait sans effort
- Enregistrez comme un utilisateur réel : Il suffit de cliquer, taper, faire défiler — comme interagit un utilisateur réel.
- Pas de corrélation : LoadView capture les valeurs dynamiques (tokens, sessions)
- Support complet du scripting C# : Pour les utilisateurs avancés, LoadView offre des capacités complètes de script C#, permettant l’usage de boucles, conditions, déclarations de variables, et plus — vous offrant la flexibilité de personnaliser les flux selon les besoins.
Par exemple : arrêt de l’exécution du script en cas d’erreur de validation de contenu
- Cookies et en-têtes prédéfinis : Vous pouvez configurer les en-têtes de requête, détails d’authentification, cookies et agents utilisateurs avant exécution pour mieux simuler les scénarios réels.
- Accessible aux débutants, prêt pour les experts : Bien qu’il soit facile de commencer avec un enregistrement simple, LoadView évolue avec les besoins des testeurs de performance expérimentés, formant un rare mélange de simplicité et de puissance.
- Rendu complet du navigateur : Prend en charge SPA, AJAX, WebSockets — vous testez ce que vous voyez.
- Tests géodistribués : Choisissez parmi plus de 40 régions globales pour simuler la charge utilisateur depuis des emplacements réels.
- Relecture de session en direct : Vous pouvez voir comment le test s’est déroulé, étape par étape, y compris le rendu des pages et l’activité de saisie — ce qui n’est pas possible dans LoadRunner.
- Métriques Front-End : Visualisez LCP (Largest Contentful Paint), FCP (First Contentful Paint) et TTI (Time to Interactive) directement depuis le rapport.
- Éditeur visuel de flux : Modifiez visuellement n’importe quelle étape — pas besoin de toucher au code ni de scanner les journaux
Comparaison des fonctionnalités : LoadRunner vs LoadView
| Fonctionnalité | LoadRunner | LoadView |
| Options d’enregistrement | Plusieurs niveaux de capture (WinInet, Socket), décisions protocolaires | Enregistrement basé sur navigateur, en un clic |
| Scripting requis | Oui – scripting avancé, paramétrisation, corrélation | Non – enregistrez et exécutez sans scripts |
| Gestion des valeurs dynamiques | Manuelle – selon chaque protocole | Corrélation automatique |
| Simulation de navigateur réel | Uniquement via TruClient (lourd, lent) | Natif Chrome/Edge |
| Métriques frontend | Limitée dans TruClient | Entièrement disponible (FCP, LCP, TTI) |
| Relecture de session en direct | Non disponible | Disponible — avec lecture |
| Temps de création du test | 45–90 minutes | 5–10 minutes |
| Analyse des journaux | Journaux de protocole complexes, corrélation manuelle | Journaux d’étapes UI, captures d’écran |
| Gestion spécifique aux protocoles | Varie selon le type d’application (HTML, SAP, Oracle) | Enregistreur unifié pour tous les flux web |
| Tests distribués | Nécessite Load Generators et Controller | Exécution cloud intégrée |
| Niveau de compétence requis | Élevé – nécessite scripting & débogage | Faible – les utilisateurs métier peuvent aussi tester |
| Coût & licences | Licence entreprise coûteuse | Tarification transparente, basée sur l’utilisation |
Impact réel sur les applications
| Cas d’utilisation | LoadRunner | LoadView |
| Commande e-commerce | Nécessite du scripting pour les tokens asynchrones & délais JS | Flux de commande basé sur navigateur réel avec validation UX |
| Tableaux de bord bancaires | Nécessite une corrélation approfondie, suivi des tokens | Facile de simuler la connexion & la navigation sur tableaux sécurisés |
| Simulation de charge géographique | Configuration LG requise pour chaque région | Sélecteur géographique simple dans l’interface |
| Tests sprint Agile | Modifications & réexécutions lentes des tests | Création rapide et réutilisation facile |
| Démos client & POCs | Nécessite configuration et coordination | Enregistrez & partagez les résultats instantanément |
Résumé final
Choisissez LoadRunner si :
- Vous avez besoin de tests approfondis au niveau protocolaire
- Vous travaillez avec des applications héritées (SAP, Oracle, Mainframes)
- Votre équipe est techniquement compétente et dispose d’une infrastructure dédiée
Choisissez LoadView si :
- Vous souhaitez tester des applications modernes basées sur navigateur
- Vous accordez de l’importance à la performance front-end et à l’expérience utilisateur
- Vous avez besoin d’un cycle de test plus rapide et simple avec support du navigateur réel