Dans cet article, nous comparons LoadRunner et LoadView à l’aide d’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 — en particulier en ce qui concerne l’effort de configuration, la flexibilité, l’évolutivité et la précision de la simulation réelle.
Utiliser LoadRunner : puissance au niveau protocole avec complexité élevée
LoadRunner fournit un contrôle approfondi au niveau protocole via VuGen (Virtual User Generator) et prend en charge des protocoles comme HTTP/HTML, SAP, Web Services, TruClient, etc. Bien que cela offre de la flexibilité pour les tests d’entreprise, l’effort nécessaire pour configurer même un flux de base peut être accablant.
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 : Choix du protocole HTTP/HTML ; cependant, le choix du bon mode d’enregistrement (basé sur HTML ou sur URL) est une décision critique et nécessite souvent des essais-erreurs pour garantir une génération correcte du script.
- Enregistrement avec VuGen : Configuration du mappage de port (comme visible sur la capture d’écran) et sélection du niveau de capture (par ex. WinInet ou Socket) — chacun avec son propre comportement
- Configuration de la corrélation : Extraction manuelle des données de session dynamiques à l’aide de web_reg_save_param_ex et de chemins JSON. Si la corrélation est manquée, le test échoue — aucune suggestion automatique ou indication dans l’interface.
- Paramétrage : Remplacement des valeurs codées en dur par des fichiers de données à l’aide de l’utilitaire de paramétrage 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 en-têtes personnalisés entre les requêtes
- Logique avancée : Ajout de conditions if-else, de boucles et de code personnalisé en C pour le contrôle de flux
Points douloureux & limitations de LoadRunner
Bien qu’étant un outil puissant, LoadRunner introduit plusieurs points de friction : complexité de l’enregistrement
- Le choix entre enregistrement basé sur HTML ou URL impacte souvent le script
- Le choix entre capture au niveau WinInet ou Socket peut dérouter les débutants — certaines applications ne répondent correctement qu’à certains modes de capture.
Dépannage & analyse des journaux
- Les journaux de LoadRunner sont spécifiques au protocole et souvent cryptiques — journaux HTTP, dumps XML et journaux de relecture sont dispersés sur plusieurs onglets et difficiles à corréler en temps réel.
- La relecture de session utilisateur en direct n’est pas disponible — ce qui complique l’identification visuelle des erreurs pendant l’exécution 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 Services
web_custom_request, web_service_call, etc.
- Il n’y a pas de cadre unifié de corrélation — même TruClient fonctionne de manière totalement différente et ne partage pas la logique de corrélation avec le protocole HTTP.
Performance & convivialité
- Les scripts TruClient simulent les flux basés sur le navigateur mais consomment beaucoup de ressources système et sont plus longs à exécuter.
- L’édition de flux visuelle est basique — le débogage des erreurs implique souvent de basculer entre plusieurs fenêtres de journalisation et captures d’écran.
Configuration de tests de charge distribués avec LoadRunner
- LoadRunner nécessite plusieurs composants : VuGen pour le scripting, Controller pour l’orchestration et Load Generators (LGs) pour la distribution.
- Nécessite une configuration manuelle, des règles de pare-feu, des ouvertures de port, et du réseau
- L’évolutivité et l’orchestration de l’exécution ajoutent de la complexité — peu adapté aux équipes agiles ayant besoin de résultats rapides.
LoadRunner est puissant pour les systèmes anciens, mais peu adapté aux tests Web modernes ou aux itérations en sprint.
Utiliser LoadView : test de charge avec navigateur réel simplifié
LoadView propose une approche moderne avec des tests de charge cloud-natifs basés sur navigateur. Il simule un comportement utilisateur réel dans des navigateurs comme Chrome ou Edge, validant non seulement la réponse du backend mais aussi les performances réelles du frontend (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 configuration, et sans plugins.
Pourquoi LoadView est apparu sans effort
- Enregistrez comme un vrai utilisateur : Cliquez, tapez, faites défiler — comme le ferait un utilisateur réel.
- Aucune corrélation : LoadView capture les valeurs dynamiques (tokens, sessions)
- Plein support de scripting en C# : Pour les utilisateurs avancés, LoadView propose des capacités complètes de scripting en C#, permettant l’utilisation de boucles, conditions, déclarations de variables, etc. — vous donnant la flexibilité de personnaliser les flux selon vos besoins.
Par exemple : arrêter 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, les détails d’authentification, les cookies et les agents utilisateur avant l’exécution pour mieux simuler des scénarios réels.
- Convient aux débutants comme aux experts : Facile à démarrer avec un simple enregistrement, LoadView évolue avec les besoins des testeurs de performance expérimentés, offrant un rare mélange de simplicité et de puissance.
- Rendu complet du navigateur : Prend en charge les SPAs, AJAX, WebSockets — ce que vous voyez est ce que vous testez.
- Tests géo-distribués : Choisissez parmi plus de 40 régions mondiales pour simuler des charges utilisateur réelles.
- Relecture de session en direct : Vous pouvez voir comment le test s’est déroulé, étape par étape, y compris le rendu de la page et l’activité utilisateur — ce qui est impossible avec LoadRunner.
- Métriques Front-End : Affichez LCP (Largest Contentful Paint), FCP (First Contentful Paint) et TTI (Time to Interactive) directement dans le rapport.
- Éditeur de flux visuel : Modifiez n’importe quelle étape visuellement — sans toucher au code ni parcourir les journaux
Comparaison des fonctionnalités : LoadRunner vs LoadView
| Fonctionnalité | LoadRunner | LoadView |
| Options d’enregistrement | Niveaux de capture multiples (WinInet, Socket), décisions sur les protocoles | Enregistrement en un clic via navigateur |
| Scripting requis | Oui – scripting avancé, paramétrage, corrélation | Non – enregistrer et exécuter sans script |
| Gestion des valeurs dynamiques | Manuelle – selon le protocole | Corrélation automatique |
| Simulation navigateur réel | Uniquement via TruClient (lourd, lent) | Chrome/Edge natif |
| Métriques frontend | Limité avec TruClient | Complètes (FCP, LCP, TTI) |
| Relecture de session | Non disponible | Disponible — avec lecture |
| Temps de création du test | 45–90 minutes | 5–10 minutes |
| Analyse des journaux | Journaux complexes, corrélation manuelle | Étapes dans l’interface, captures d’écran |
| Gestion par protocole | Varie selon le type d’application | Enregistreur unifié pour tous les flux Web |
| Tests distribués | Nécessite LGs et Controller | Exécution cloud intégrée |
| Niveau de compétence requis | Élevé – scripting & débogage | Faible – les utilisateurs métier peuvent aussi tester |
| Coût & licences | Licence d’entreprise coûteuse | Tarification transparente basée sur l’usage |
Impact sur les applications réelles
| Cas d’usage | LoadRunner | LoadView |
| Paiement e-commerce | Nécessite script pour tokens asynchrones & délais JS | Flux de paiement navigateur réel avec validation UX |
| Tableaux de bord bancaires | Corrélation poussée, suivi de token requis | Connexion & navigation faciles sur zones sécurisées |
| Simulation géographique | Configuration LG requise par région | Sélecteur géographique simple dans l’interface |
| Tests en sprint agile | Modifications & relances plus lentes | Création rapide et réutilisation aisée |
| Démos client & POC | Configuration et coordination nécessaires | Enregistrez & partagez les résultats instantanément |
Résumé final
Choisissez LoadRunner si :
- Vous avez besoin de tests au niveau protocole approfondis
- Vous travaillez avec des applications anciennes (SAP, Oracle, Mainframes)
- Votre équipe est techniquement expérimentée et dispose d’une infrastructure dédiée
Choisissez LoadView si :
- Vous souhaitez tester des applications modernes basées sur navigateur
- Vous vous souciez des performances frontend et de l’expérience utilisateur
- Vous avez besoin d’un cycle de test rapide et simple avec prise en charge navigateur réel