Le produit a changé de nom plusieurs fois : Mercury, HP, Micro Focus, puis OpenText, qui l'appelle Professional Performance Engineering, Enterprise Performance Engineering pour l'ancien Performance Center, et Core Performance Engineering pour la version SaaS. Les CV et les annonces disent encore LoadRunner, VuGen et PerfCenter. Des questions d'entretien LoadRunner utiles portent sur ce que fait le poste au quotidien : corréler, paramétrer, régler les runtime settings, construire le scénario dans le Controller, filtrer et croiser les graphes dans Analysis.
Beaucoup de profils ont appris l'outil sur un seul protocole, souvent Web HTTP/HTML, et l'ont pratiqué dans un cadre très outillé où les scripts existaient déjà. L'entretien vérifie les protocoles réellement scriptés, le niveau de C (une chaîne mal copiée suffit à faire dériver un tir), le calcul du pacing et la capacité à filtrer Analysis avant de présenter un chiffre.
Sur un poste qui prépare une migration, s'ajoutent des questions sur l'inventaire des scripts et la comparaison des tirs entre deux outils. Le PDF contient 30 questions sur six axes, un cas de 20 minutes sur une application publiée en Citrix avec son portail web, et une grille de 1 à 4.
Les composants LoadRunner cités dans les CV
VuGen (Virtual User Generator)
L'atelier où l'on enregistre et écrit les scripts. Un script se découpe en vuser_init, Action et vuser_end, et s'écrit en C pour la plupart des protocoles, avec des fonctions lr_ et web_. C'est là que se jouent la corrélation, le paramétrage et la qualité du code.
Corrélation et paramètres
web_reg_save_param_ex et ses variantes JSON, expression régulière et XPath capturent les valeurs dynamiques, placées avant la requête concernée. Les paramètres alimentent les scripts en comptes, dates et identifiants, avec des règles de distribution qui garantissent l'unicité entre Vusers. Des règles de corrélation partagées évitent de tout refaire à chaque réenregistrement.
Protocoles
Web HTTP/HTML pour le trafic web et les API, TruClient pour piloter un navigateur, DevWeb pour des scripts JavaScript légers et multiplateformes, Citrix ICA et SAP GUI pour les applications publiées ou SAP, et d'autres pour les bases ou les clients lourds. Le candidat doit citer les protocoles qu'il a scriptés lui-même.
Controller et load generators
Le Controller construit le scénario (manuel ou orienté objectif), répartit les groupes de Vusers sur les load generators, applique le planning et suit le tir. Les runtime settings (pacing, think time, nouvel utilisateur à chaque itération, simulation de vitesse) décident de la charge réellement produite.
Analysis
L'outil d'analyse des résultats : graphes de transactions, de ressources, de diagnostic des pages, fusion et corrélation de graphes, SLA, rapports. Les filtres (montée en charge, transactions réussies, temps de réflexion) et l'agrégation des données changent les chiffres présentés.
LoadRunner Enterprise
L'ancien Performance Center, renommé par OpenText Enterprise Performance Engineering. Plateforme web partagée entre projets, avec pool de load generators, réservations de créneaux, dépôt central des scripts et des résultats, tendances d'un tir à l'autre et API REST pour la CI.
Core Performance Engineering (ex LoadRunner Cloud)
La version SaaS, issue de StormRunner Load puis de LoadRunner Cloud. Les tirs partent d'injecteurs dans le cloud ou d'injecteurs installés dans le réseau de l'entreprise. Elle sert surtout aux équipes qui ne veulent pas maintenir de parc de load generators.
Versions 26.x et Aviator
Les versions 26.1 et 26.3 de 2026 ajoutent Aviator, un assistant d'IA pour le scripting et l'analyse, un serveur MCP pour DevWeb, TruClient 2.0 avec l'enregistrement sous Firefox et des graphes CLS et INP, un nouveau protocole Blazor - Web. La 25.1 avait apporté une intégration OpenTelemetry et Ubuntu 24.04 pour les load generators.
Intégrations : APM, Jenkins, ALM
Les tirs se relient à Dynatrace ou AppDynamics pour le diagnostic, se lancent depuis Jenkins ou d'autres outils de CI, et s'articulent dans certaines équipes avec ALM pour la traçabilité des campagnes.
Le poste s'appelle ingénieur performance, testeur de performance, consultant LoadRunner ou expert tests de charge. LoadRunner reste présent dans des DSI qui l'utilisent depuis des années, souvent à côté de NeoLoad ou de JMeter, et certaines préparent une sortie de licence. Le candidat doit alors lire des scripts anciens, parfois écrits par plusieurs équipes, et maîtriser des protocoles que les outils récents couvrent mal. OpenText propose des formations et des certifications sur ses produits de test de performance, et la certification ISTQB Performance Testing couvre la méthode. La pratique se vérifie sur un script et un résultat réels.
Les points à valider chez un ingénieur LoadRunner
- Scripting VuGen et code C
- Corrélation et paramétrage
- Choix et pratique des protocoles
- Scénarios Controller et runtime settings
- Analyse des résultats dans Analysis
- LoadRunner Enterprise, CI et migration
Cinq questions pour tester la pratique de LoadRunner
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Comment repérez-vous dans VuGen les valeurs à corréler, et où placez-vous web_reg_save_param_ex dans le script ?
Une bonne réponseLe candidat compare la réplique à l'enregistrement, lance le scan de corrélation de Design Studio ou s'appuie sur les règles de corrélation, puis vérifie chaque proposition. web_reg_save_param_ex est une fonction d'enregistrement : elle se place avant la requête dont la réponse contient la valeur, avec LB et RB, l'Ordinal, NotFound=ERROR et le Scope (corps ou en-têtes). Pour du JSON ou du XML, il préfère web_reg_save_param_json, web_reg_save_param_regexp ou web_reg_save_param_xpath. La valeur est ensuite remplacée par {Param} partout où elle apparaît.
Signal d'alerteLa fonction placée après la requête, une corrélation acceptée en bloc sans vérification, ou des frontières LB/RB si larges qu'elles capturent la mauvaise valeur.
Question 2 · confirmé
Pacing, think time, nouvel utilisateur à chaque itération : comment réglez-vous ces runtime settings pour tenir 20 transactions par seconde ?
Une bonne réponseLe pacing fixe l'intervalle entre deux débuts d'itération : avec un pacing de 30 secondes, il faut 600 Vusers pour 20 itérations par seconde. Le pacing doit dépasser la durée réelle d'une itération, sinon le débit baisse. Le think time se rejoue tel qu'enregistré, en aléatoire autour de cette valeur, ou s'ignore, selon le réalisme voulu. L'option qui simule un nouvel utilisateur à chaque itération vide cookies et cache, donc ajoute une connexion par itération : le candidat la règle selon le comportement réel.
Signal d'alertePacing à zéro, think time ignoré et Vusers ajoutés jusqu'à atteindre le chiffre, ce qui produit une charge sans rapport avec la production.
Question 3 · confirmé
Web HTTP/HTML, TruClient ou DevWeb : comment choisissez-vous le protocole pour une application web récente ?
Une bonne réponseWeb HTTP/HTML rejoue les requêtes, tient beaucoup de Vusers par machine et demande une corrélation soignée. TruClient pilote un navigateur, s'écrit au niveau des interactions et mesure le côté client (TruClient 2.0 remonte le CLS et l'INP), mais consomme beaucoup sur les load generators. DevWeb s'écrit en JavaScript, tourne sous Windows et Linux et convient aux API et à la CI. Un bon plan met la charge en HTTP/HTML ou DevWeb et ajoute quelques Vusers TruClient pour l'expérience utilisateur.
Signal d'alerteTruClient pour 3 000 Vusers parce que l'enregistrement est plus simple, ou HTTP/HTML présenté comme une mesure du temps d'affichage.
Question 4 · confirmé
Quels filtres appliquez-vous dans Analysis avant de présenter les temps de réponse d'un tir ?
Une bonne réponseIl retire la montée et la descente en filtrant sur le temps écoulé du scénario, calcule les temps sur les transactions réussies et présente les échecs à part. Il vérifie que le temps de réflexion est exclu, regarde la granularité des graphes et le réglage d'agrégation des données, qui change la précision des percentiles. Il contrôle aussi les résultats par load generator pour écarter une machine défaillante.
Signal d'alerteLe rapport de synthèse par défaut, montée en charge comprise, avec la moyenne mise en avant.
Question 5 · senior
Le client arrête LoadRunner dans un an et possède 120 scripts, dont 30 Citrix et 15 SAP GUI. Comment préparez-vous la migration vers NeoLoad ou JMeter, et comment prouvez-vous que les nouveaux tirs mesurent la même chose ?
Une bonne réponseUn inventaire par protocole, usage et criticité, pour écarter les scripts morts. La vérification, protocole par protocole, de ce que l'outil cible sait faire : JMeter ne couvre pas Citrix nativement, et la prise en charge de SAP GUI ou de Citrix se vérifie dans la version de l'outil visé. Une réécriture plutôt qu'une conversion automatique pour les scripts lourds en corrélation. Avant de couper, un tir de référence avec LoadRunner et le même scénario rejoué avec le nouvel outil, pour comparer débit, percentiles et erreurs, et garder LoadRunner pour les protocoles non couverts le temps qu'il faut.
Signal d'alertePromettre une conversion automatique des 120 scripts en quelques semaines, ou abandonner les tests Citrix sans le dire.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
LoadRunner en entretien : réponses courtes
Quels protocoles LoadRunner sont attendus d'un candidat ?
Ceux des applications à tester. Web HTTP/HTML est le socle presque partout. Pour des applications publiées en Citrix ou un SAP GUI, une expérience réelle de ces protocoles s'impose : ils demandent des réglages et une rigueur que l'on n'acquiert pas en lisant la documentation. TruClient et DevWeb se prennent en main plus vite. Le candidat détaille le dernier script écrit sur chaque protocole cité, avec ses difficultés.
LoadRunner est-il encore utilisé, ou faut-il viser un autre outil ?
Il est toujours développé par OpenText, sous de nouveaux noms, avec des versions publiées en 2026. Beaucoup d'équipes le gardent pour son parc de scripts et ses protocoles, d'autres préparent une migration vers NeoLoad ou JMeter. Un ingénieur LoadRunner qui connaît aussi l'un de ces outils laisse le choix ouvert. Sur un projet de migration, sa connaissance des anciens scripts compte autant que celle de l'outil cible.
Quel test technique est donné à un ingénieur LoadRunner ?
Un script VuGen préparé à l'avance, sur une petite application de démonstration, avec une valeur non corrélée, un web_reg_find mal placé et un paramètre qui donne le même compte à tous les Vusers. S'y ajoute un extrait de résultats Analysis à commenter. Le candidat corrige et explique en partageant son écran pendant vingt à trente minutes. Sans licence disponible, des captures du script et des graphes suffisent pour la lecture.
Un profil JMeter peut-il reprendre un parc de scripts LoadRunner ?
Pour la méthode, oui. Pour les scripts, il faut un temps d'adaptation : le code C de VuGen, les fonctions d'enregistrement placées avant la requête, les runtime settings et les filtres d'Analysis n'ont pas d'équivalent direct dans JMeter. Si le parc contient du Citrix ou du SAP GUI, l'écart grandit encore. Deux questions de l'axe VuGen et une sur le pacing mesurent la distance.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
