Paramétrage, Fonctions, Transactions dans LoadRunner

Un script enregistré peut simuler un utilisateur virtuel ; cependant, un simple enregistrement peut ne pas suffire à reproduire le comportement d'un utilisateur réel.

Lorsqu'un script est enregistré, il décrit un flux unique et linéaire au sein de l'application. Un utilisateur réel peut effectuer plusieurs itérations d'une procédure avant de se déconnecter. Le temps de réaction (délai entre les clics) varie d'une personne à l'autre, et certains utilisateurs bénéficient d'une connexion rapide tandis que d'autres non. Par conséquent, pour reproduire au mieux l'expérience utilisateur, nos scripts doivent se comporter comme de véritables utilisateurs.

C'est là la considération la plus importante lors de la réalisation de «Test de performanceMais un script VUser ne se limite pas à cela. Comment mesurer le temps d'exécution d'un VUser pendant le test de charge système (SUL) ? Comment savoir si le VUser a réussi ou échoué à un moment donné, et si un processus en arrière-plan a échoué ou si les ressources du serveur ont manqué ?

Nous devons améliorer notre script pour pouvoir répondre à toutes les questions ci-dessus.

Note de la marque : VuGen a été commercialisé sous les noms de HP, puis Micro Focus, et fait désormais partie de OpenText Ingénierie de la performance professionnelleLes fonctions et paramètres ci-dessous restent inchangés.

Utilisation des transactions

Les transactions mesurent le temps de réponse du serveur pour chaque opération. Autrement dit, une « transaction » mesure le temps nécessaire au système pour traiter une requête particulière. Il peut s'agir d'un simple clic sur un bouton ou d'un appel AJAX déclenché lorsqu'une zone de texte perd le focus.

L'application des transactions est simple. Il suffit d'écrire une ligne de code avant la requête et de fermer la transaction une fois celle-ci terminée. LoadRunner requiert uniquement une chaîne de caractères comme nom de transaction.

Pour ouvrir une transaction, utilisez cette ligne de code :

lr_start_transaction(“Transaction Name”);

Pour clôturer la transaction, utilisez cette ligne de code :

lr_end_transaction(“Transaction Name”, <status>);

Le indique à LoadRunner si cette transaction particulière a réussi ou échoué. Les paramètres possibles pourraient être :

• LR_AUTO
• LR_PASS
• LR_FAIL

Exemple :

lr_end_transaction(“My_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction(“Business_Workflow_Transaction Name”, LR_FAIL);

Code Notes: Les extraits sont reproduits à l'identique, guillemets typographiques inclus. Un véritable script VuGen nécessite des guillemets doubles ASCII ; veuillez donc les retaper si vous copiez ce code.

Points à noter:

• N'oubliez pas que vous travaillez avec « C » et que c'est un langage sensible à la casse.
• Le point (.) n'est pas autorisé dans le nom d'une transaction, mais vous pouvez utiliser des espaces et des traits de soulignement.
• Si votre code est bien structuré en branches et comporte des points de contrôle pour vérifier la réponse du serveur, vous pouvez utiliser une gestion d'erreurs personnalisée, comme LR_PASS ou LR_FAIL. Sinon, utilisez LR_AUTO : LoadRunner gérera automatiquement les erreurs serveur (HTTP 500, 400, etc.).
• Lors de l'application des transactions, assurez-vous qu'aucune instruction de temps de réflexion n'est insérée à l'intérieur, sinon votre transaction inclura toujours cette période.
• Comme LoadRunner exige une chaîne de caractères constante comme nom de transaction, un problème fréquent lors de l'application de transactions est l'incohérence de ces chaînes. Si vous utilisez des noms différents pour l'ouverture et la fermeture d'une transaction, vous obtiendrez au moins deux erreurs. La transaction ouverte n'a jamais été fermée, ce qui provoque une erreur de LoadRunner ; et la transaction que vous tentez de fermer n'a jamais été ouverte, ce qui provoque une seconde erreur.
• Les deux erreurs apparaissent dans le journal de relecture ; par conséquent, lorsqu’une de ces erreurs est signalée, vérifiez d’abord le nom de la transaction dans les instructions d’ouverture et de fermeture.
• Comme LoadRunner gère automatiquement la synchronisation des requêtes et des réponses, vous n'aurez pas à vous soucier de la réponse lors de l'application de transactions.

Points de rendez-vous, commentaires et fonctions de script

Trois petites améliorations permettent à un script de se comporter et de se lire comme du code de production : les points de rendez-vous, les commentaires et le navigateur de fonctions intégré à VuGen.

Points de rendez-vous

Un point de rendez-vous est un « point de rencontre ». Il s'agit d'une instruction unique qui indique à LoadRunner d'introduire de la concurrence. Vous insérez des points de rendez-vous dans les scripts VUser pour simuler une charge utilisateur importante sur le serveur.

Les points de rendez-vous indiquent à un utilisateur virtuel d'attendre, pendant l'exécution d'une tâche, que plusieurs utilisateurs virtuels convergent vers un point précis afin de pouvoir l'effectuer simultanément. Par exemple, pour simuler une charge maximale sur un serveur bancaire, insérez un point de rendez-vous demandant à 100 utilisateurs virtuels de déposer de l'argent en même temps.

Si les points de rendez-vous ne sont pas correctement positionnés, les utilisateurs virtuels accéderont à différentes parties de l'application, même pour un même script. En effet, chaque utilisateur virtuel a un temps de réponse différent, ce qui entraîne un décalage pour certains.

syntaxe:

lr_rendezvous(“Logical Name”);

Note de correction : la page publiée épelle ceci lr_rendez-vousLe nom correct de la fonction est lr_rendezvous; la forme mal orthographiée ne sera pas compilée.

Meilleures pratiques :

• Préfixez un point de rendez-vous avec « rdv_ » pour une meilleure lisibilité du code ; par exemple "rdv_Login"
• Supprimez toutes les déclarations de temps de réflexion immédiatement adjacentes.
• Appliquez les points de rendez-vous dans la vue Script, après l'enregistrement.

L'aperçu du script ci-dessous montre une instruction de rendez-vous insérée dans une action enregistrée :

Commentaires

Ajoutez des commentaires pour décrire une activité, un fragment de code ou une ligne de code. Les commentaires facilitent la compréhension du code pour toute personne qui s'y référera ultérieurement. Ils fournissent des informations sur une opération spécifique et permettent de délimiter des sections pour une meilleure distinction.

Vous pouvez ajouter des commentaires

• Pendant l'enregistrement (à l'aide de l'outil)
• Après enregistrement (écriture directe dans le code)

Meilleure pratique : indiquez tous les commentaires en haut de chaque fichier de script.

Insertion de fonctions via le menu

Vous pouvez écrire directement des lignes de code simples, mais il vous faudra peut-être un indice pour retrouver une fonction. Vous pouvez également utiliser la boîte à outils Steps (appelée « Insérer une fonction » avant la version 12) pour trouver et insérer directement n’importe quelle fonction dans votre script.

Vous trouverez la boîte à outils Étapes sous Affichage → Boîte à outils Étapes, comme indiqué ci-dessous.

Cela ouvrira une fenêtre latérale. Regardez la capture d'écran :

Qu’est-ce que le paramétrage ?

Dans VuGen, un paramètre est un conteneur qui renferme une valeur enregistrée, laquelle est remplacée pour différents utilisateurs.

Lors de l'exécution du script (dans VuGen ou le Contrôleur), une valeur provenant d'une source externe (telle qu'un fichier .txt, XML ou une base de données) remplace la valeur précédente du paramètre.

La paramétrisation est utile pour envoyer des valeurs dynamiques (ou uniques) au serveur. Par exemple, un processus métier peut nécessiter 10 itérations avec un nom d'utilisateur unique à chaque fois.

Cela permet également de simuler des comportements réalistes face au système étudié. Consultez les exemples ci-dessous.

Exemples de problèmes :

• Un processus métier ne fonctionne que pour la date actuelle, qui provient du serveur ; il ne peut donc pas être transmis sous forme de requête codée en dur.
• Il arrive que l'application cliente transmette un identifiant unique au serveur (par exemple, session_id) pour que le processus puisse se poursuivre, même pour un seul utilisateur. Dans ce cas, la paramétrisation s'avère utile.
• Souvent, l'application cliente conserve en cache les données échangées avec le serveur. Par conséquent, le serveur ne reçoit pas le comportement réel de l'utilisateur (où le serveur exécute un algorithme différent selon les critères de recherche). Le script VUser s'exécutera correctement, mais les statistiques de performance générées seront inexploitables. L'utilisation de données différentes grâce à la paramétrisation permet de simuler l'activité côté serveur, comme l'exécution de procédures stockées, et de solliciter le système.
• Une date codée en dur dans l'utilisateur virtuel lors de l'enregistrement peut devenir obsolète une fois cette date passée. Le paramétrage de la date permet à l'exécution de l'utilisateur virtuel de réussir en remplaçant la date codée en dur. Les champs ou requêtes concernés sont des candidats idéaux pour le paramétrage.

Pour en créer un, cliquez avec le bouton droit sur la valeur enregistrée dans la vue Script et choisissez « Remplacer par un paramètre ». VuGen vous demandera ensuite quel type de donnée fournit la valeur :

Deux autres options déterminent la manière dont les données sont consommées au fil des itérations :

La procédure ci-dessous illustre la paramétrisation appliquée à un script enregistré :

Cliquez à nouveau ici si la vidéo n'est pas accessible.

Paramètres d'exécution et leur impact sur la simulation des utilisateurs virtuels

Les paramètres d'exécution sont aussi importants que votre script VuGen. Des configurations différentes peuvent engendrer des conceptions de test totalement différentes ; c'est pourquoi des paramètres d'exécution incohérents sont généralement la cause de résultats non reproductibles. Examinons chaque attribut un par un.

Exécuter la logique

Run Logic définit le nombre de fois que toutes les actions seront exécutées, à l'exception de vuser_init et vuser_end.

Cela explique probablement mieux pourquoi LoadRunner suggère de conserverping Tout le code de connexion dans vuser_init et la partie déconnexion dans vuser_end, exclusivement.

Si vous avez créé plusieurs actions (par exemple, Se connecter, Ouvrir l'écran, Calculer le loyer, Soumettre des fonds, Vérifier le solde et Se déconnecter), le scénario ci-dessous se produira pour chaque utilisateur virtuel :

Tous les utilisateurs virtuels se connecteront, exécuteront les étapes suivantes : Ouvrir l'écran, Calculer le loyer, Soumettre les fonds et Vérifier le solde, puis à nouveau Ouvrir l'écran, Calculer le loyer et ainsi de suite, en itérant 10 fois, suivi d'une déconnexion (une seule fois).

Il s'agit d'un paramètre puissant qui permet au script de se comporter comme un véritable utilisateur. N'oubliez pas qu'un utilisateur réel ne se connecte et ne se déconnecte pas systématiquement ; il répète généralement les mêmes étapes.

Combien de fois cliquez-vous sur « boîte de réception » lorsque vous consultez vos e-mails avant de vous déconnecter ?

Stimulation

C'est important. La plupart des gens ne comprennent pas la différence entre le rythme et le temps de réflexion. La seule différence est que le rythme désigne le délai entre deux itérations, tandis que le temps de réflexion est le délai entre deux actions quelconques.

Le paramètre recommandé dépend du protocole de test. Toutefois, si vous souhaitez appliquer une charge importante, envisagez d'opter pour « Dès que l'itération précédente se termine », comme indiqué ci-dessous.

Historique

Un journal, tel qu'on l'entend généralement, enregistre tous les événements survenus pendant l'exécution de LoadRunner. Vous pouvez activer la journalisation pour suivre les échanges entre votre application et votre serveur.

LoadRunner intègre un mécanisme de journalisation performant, robuste et évolutif. Il permet de conserver un journal standard, un journal étendu détaillé et configurable, ou de désactiver complètement la journalisation.

Un journal standard est informatif et facile à comprendre. Il contient exactement les informations nécessaires au dépannage de vos scripts VUser.

Dans le cas du journal étendu, toutes les informations de journalisation standard ne constituent qu'un sous-ensemble. De plus, la substitution de paramètres est possible. Ceci indique au composant LoadRunner d'inclure des informations complètes sur tous les paramètres (issues de la paramétrisation), y compris les données des requêtes et des réponses.

Si vous incluez les « Données renvoyées par le serveur », la taille de votre journal augmentera considérablement. Il contiendra alors l'ensemble du code HTML, des balises, des ressources et des informations non liées aux ressources. Cette option est utile uniquement en cas de dépannage approfondi. Généralement, elle génère un fichier journal très volumineux et difficilement exploitable.

Comme vous l'aurez sans doute deviné, si vous optez pour « Avancé » TracVotre fichier journal sera volumineux. Il est conseillé d'essayer. Vous constaterez que le temps d'exécution de VuGen augmente considérablement, même si cela n'a aucun impact sur le temps de réponse des transactions indiqué par VuGen. Ces informations sont très techniques et ne sont utiles que si vous comprenez l'application concernée, la communication client-serveur entre votre application et le matériel, ainsi que les détails du protocole. En général, la lecture et le dépannage de ces informations exigent un effort considérable.

Conseils:

• Quel que soit le temps que prend VuGen lorsque la journalisation est activée, cela n'a aucun impact sur le temps de réponse de la transaction : la surcharge liée à la journalisation est exclue du temps mesuré.
• Désactivez le journal s'il n'est pas nécessaire.
• Désactivez la journalisation une fois vos scripts terminés. L'inclusion de scripts avec la journalisation activée ralentira le contrôleur et générera des messages d'erreur récurrents.
• La désactivation du journal augmentera le nombre maximal d'utilisateurs que vous pouvez simuler à partir de LoadRunner.
• Pensez à utiliser l’option « Envoyer des messages uniquement en cas d’erreur » : cela désactive les messages d’information inutiles et ne signale que les messages liés aux erreurs.

Pensez aux temps

Think Time est simplement le délai entre deux étapes.

Le temps de réflexion permet de reproduire le comportement d'un utilisateur, car aucun utilisateur réel ne peut se servir d'une application comme une machine. VuGen génère automatiquement ce temps de réflexion. Vous conservez un contrôle total sur sa durée : vous pouvez la supprimer, la multiplier ou la faire varier.

Pour mieux comprendre : un utilisateur ouvre un écran (une réponse suivie d’une requête), puis saisit un nom d’utilisateur et un mot de passe avant d’appuyer sur Entrée. L’interaction suivante entre l’application et le serveur a lieu lorsque l’utilisateur clique sur « Se connecter ». Le temps passé par l’utilisateur à saisir son nom d’utilisateur et son mot de passe correspond au temps de réflexion dans LoadRunner.

Si vous cherchez à simuler une charge agressive sur l'application, envisagez de désactiver complètement le temps de réflexion.

Toutefois, pour simuler un comportement réaliste, vous pouvez choisir « Utiliser un temps de réflexion aléatoire » et définir les pourcentages souhaités.

Pensez à utiliser la fonction « Limiter le temps de réflexion » pour le fixer à une durée raisonnable. En général, 30 secondes suffisent amplement.

Simulation de vitesse

La simulation de vitesse fait simplement référence à la capacité de bande passante de chaque machine cliente.

Étant donné que nous simulons des milliers d'utilisateurs virtuels via LoadRunner, il est remarquable de constater à quel point LoadRunner a simplifié la simulation de la bande passante et de la vitesse du réseau.

Si vos clients accèdent à votre application à plus de 128 kbit/s, vous pouvez gérer ce paramètre ici. Vous pourrez ainsi simuler un comportement réel et obtenir des statistiques de performance précises.

Il est fortement recommandé d'utiliser la bande passante maximale. Cela vous permet d'ignorer les limitations de performance liées au réseau et de vous concentrer d'abord sur les problèmes potentiels de l'application. Vous pouvez toujours exécuter le test plusieurs fois pour observer les variations de comportement selon les circonstances.

Émulation de navigateur

L'expérience utilisateur ne dépend pas du navigateur utilisé par l'utilisateur final ; ce facteur est donc largement hors du champ d'application des mesures de performance. Cependant, vous pouvez choisir le navigateur à émuler, comme le montre le panneau ci-dessous.

À quel moment précis le choix du navigateur dans cette configuration a-t-il réellement une importance ?

Vous utiliserez cette configuration si votre application cible est une application web qui renvoie des réponses différentes selon les navigateurs. Par exemple, vous pouvez voir des images et un contenu différents pour Internet Explorer et Internet Explorer. Firefox.

Un autre paramètre important est « Simuler le cache du navigateur ». Si vous souhaitez évaluer le temps de réponse avec le cache activé, cochez cette case. Si vous recherchez une simulation du pire scénario, ce paramètre n'est évidemment pas pertinent.

L'option « Télécharger les ressources non HTML » autorise LoadRunner à télécharger les fichiers CSS, JS et autres contenus multimédias. Il est recommandé de laisser cette option cochée. Toutefois, si vous souhaitez l'exclure de votre test de performance, vous pouvez la décocher.

procuration

Il est préférable de supprimer complètement le proxy de votre configuration. Environnement de test Un proxy placé sur le chemin du serveur peut fausser les résultats des tests. Cependant, il peut arriver que ce soit inévitable. Dans ce cas, LoadRunner propose des paramètres de proxy.

Vous travaillerez (ou devriez travailler) avec le paramètre « Aucun proxy ». Vous trouverez ce paramètre dans les paramètres de votre navigateur par défaut. N'oubliez pas de vérifier quel navigateur est défini par défaut et quelle est sa configuration de proxy.

Si vous utilisez un proxy nécessitant une authentification (ou un script), cliquez sur le bouton « S'authentifier » pour ouvrir une nouvelle fenêtre. Voir la capture d'écran ci-dessous.

Utilisez cet écran pour saisir un nom d'utilisateur et un mot de passe afin de vous authentifier sur le serveur proxy. Cliquez sur OK pour fermer l'écran.

Félicitations ! La configuration de votre script VuGen est terminée. N'oubliez pas de le configurer pour tous vos scripts VUser.

Viennent ensuite corrélation, en exécutant le scénario dans le Contrôleuret la lecture donne lieu à Analyse LoadRunner. Voir l' Architecture LoadRunner et test de charge guides.

FAQ