Un script enregistré peut simuler un utilisateur virtuel; cependant, un simple enregistrement peut ne pas suffire à reproduire le «comportement réel de l'utilisateur».
Lorsqu'un script est enregistré, il couvre le flux simple et direct de l'application objet. Alors qu'un utilisateur réel peut effectuer plusieurs itérations de n'importe quel processus avant de se déconnecter. Le délai entre les clics sur les boutons (temps de réflexion) varie d'une personne à l'autre. Il est fort probable que certains utilisateurs réels accèdent à votre application via DSL et certains y accèdent via une connexion commutée. Ainsi, afin d'obtenir la vraie sensation de l'utilisateur final, nous devons améliorer nos scripts pour qu'ils correspondent exactement, ou au moins très proches dans le comportement des utilisateurs réels.
Ce qui précède est la considération la plus importante lors de la réalisation de «tests de performance», mais il y a plus à un script VU. Comment évaluerez-vous le temps précis nécessaire à un VUser lorsque SUL subit un test de performance? Comment sauriez-vous si le VUser est passé ou a échoué à un moment donné? Quelle est la cause de l'échec, si un processus backend a échoué ou si les ressources du serveur étaient limitées?
Nous devons améliorer notre script pour aider à répondre à toutes les questions ci-dessus.
- Utilisation des transactions
- Comprendre le temps de réflexion, les points de rendez-vous et les commentaires
- Insertion de fonctions via le menu
- Qu'est-ce que le paramétrage?
- Paramètres d'exécution et leur impact sur la simulation VU
- Exécuter la logique
- Stimulation
- Enregistrer
- Think Times
- Simulation de vitesse
- Émulation de navigateur
- Procuration
Utilisation des transactions
Les transactions sont des mécanismes permettant de mesurer le temps de réponse du serveur pour toute opération. En termes simples, l'utilisation de «Transaction» permet de mesurer le temps mis par le système pour une demande particulière. Cela peut être aussi petit qu'un clic sur un bouton ou un appel AJAX lors de la perte du focus de la zone de texte.
L'application des transactions est simple. Écrivez simplement une ligne de code avant que la demande ne soit faite au serveur et fermez la transaction lorsque la demande se termine. LoadRunner ne nécessite qu'une chaîne comme nom de transaction.
Pour ouvrir une transaction, utilisez cette ligne de code:
lr_start_transaction («Nom de la transaction»);
Pour clôturer la transaction, utilisez cette ligne de code:
lr_end_transaction («Nom de la transaction»,);
Le
- LR_AUTO
- LR_PASS
- LR_FAIL
Exemple:
lr_end_transaction ("Mon_Connexion", LR_AUTO);
lr_end_transaction («Nom de la transaction_du_fonctionnement_entreprise», LR_FAIL);
Points à noter:
- N'oubliez pas, vous travaillez avec «C» et c'est un langage sensible à la casse.
- Le caractère point (.) N'est pas autorisé dans le nom de la transaction, bien que vous puissiez utiliser des espaces et des traits de soulignement.
- Si vous avez bien branché votre code et ajouté des points de contrôle pour vérifier la réponse du serveur, vous pouvez utiliser la gestion des erreurs personnalisée, telle que LR_PASS ou LR_FAIL. Sinon, vous pouvez utiliser LR_AUTO et LoadRunner gérera automatiquement l'erreur du serveur (HTTP 500, 400 etc.)
- Lorsque vous appliquez des transactions, assurez-vous qu'aucune instruction think_time n'est prise en sandwich, sinon votre transaction inclura toujours cette période.
- Étant donné que LoadRunner nécessite une chaîne constante comme nom de transaction, un problème courant lors de l'application de la transaction est la non-concordance de la chaîne. Si vous donnez un nom différent lors de l'ouverture et de la clôture d'une transaction, vous aurez au moins 2 erreurs. Étant donné que la transaction que vous avez ouverte n'a jamais été clôturée, LoadRunner générera une erreur. En outre, la transaction que vous essayez de fermer n'a jamais été ouverte, ce qui entraîne une erreur.
- Pouvez-vous utiliser votre intelligence et vous dire laquelle des erreurs ci-dessus sera signalée en premier? Pour valider votre réponse, pourquoi ne pas faire votre propre erreur? Si vous aviez bien répondu, vous êtes sur la bonne voie. Si vous avez mal répondu, vous devez vous concentrer.
- Puisque LoadRunner s'occupe automatiquement de la synchronisation des demandes et des réponses, vous n'aurez pas à vous soucier de la réponse lors de l'application des transactions.
Comprendre le temps de réflexion, les points de rendez-vous et les commentaires
Points de rendez-vous
Rendezvous Points signifie «points de rencontre». C'est juste une ligne d'instruction qui indique à LoadRunner d'introduire la concurrence. Vous insérez des points de rendez-vous dans des scripts VUser pour émuler une charge utilisateur importante sur le serveur.
Les points de rendez-vous indiquent à VUser d'attendre pendant l'exécution du test que plusieurs VUser arrivent à un certain point, afin qu'ils puissent exécuter simultanément une tâche. Par exemple, pour émuler la charge de pointe sur le serveur de la banque, vous pouvez insérer un point de rendez-vous demandant à 100 VUser de déposer des espèces sur leurs comptes en même temps. Ceci peut être réalisé facilement en utilisant rendez-vous.
Si les points de rendez-vous ne sont pas correctement placés, le VUser accédera à différentes parties de l'application - même pour le même script. En effet, chaque VUser obtient un temps de réponse différent et, par conséquent, peu d'utilisateurs sont à la traîne.
Syntaxe: lr_rendesvous («Nom logique»);
Les meilleures pratiques:
- Préfixez un point de rendez-vous avec «rdv_» pour une meilleure lisibilité du code; par exemple "rdv_Login"
- Supprimer toutes les déclarations de temps de réflexion immédiates
- Application de points de rendez-vous dans une vue de script (après l'enregistrement)
commentaires
Ajoutez des commentaires pour décrire une activité, un morceau de code ou une ligne de code. Les commentaires aident à rendre le code compréhensible pour quiconque y fera référence à l'avenir. Ils fournissent des informations sur un fonctionnement spécifique et séparent deux sections pour les distinguer.
Vous pouvez ajouter des commentaires
- Pendant l'enregistrement (à l'aide de l'outil)
- Après l'enregistrement (écriture directe dans le code)
Meilleure pratique: marquez tous les commentaires en haut de chaque fichier de script
Insertion de fonctions via le menu
Bien que vous puissiez directement écrire de simples lignes de code, vous aurez peut-être besoin d'un indice pour rappeler une fonction. Vous pouvez également utiliser Steps Toolbox (connu sous le nom de fonction d'insertion avant la version 12) pour rechercher et insérer n'importe quelle fonction directement dans votre script.
Vous pouvez trouver la barre d'outils Steps sous View àSteps Toolbox.
Cela ouvrira une fenêtre latérale, regardez l'instantané:
Qu'est-ce que le paramétrage?
Un paramètre dans VUGen est un conteneur qui contient une valeur enregistrée qui est remplacée pour divers utilisateurs.
Lors de l'exécution du script (dans VUGen ou Controller), la valeur d'une source externe (comme .txt, XML ou base de données) remplace la valeur précédente du paramètre.
Le paramétrage est utile pour envoyer des valeurs dynamiques (ou uniques) au serveur, par exemple; un processus métier est souhaité pour exécuter 10 itérations mais en choisissant un nom d'utilisateur unique à chaque fois.
Cela aide également à stimuler le comportement réel du système sujet. Jetez un œil à l'exemple ci-dessous:
Exemples de problèmes:
Le processus métier ne fonctionne que pour la date actuelle qui provient du serveur et ne peut donc pas être passé en tant que requête codée en dur.
Parfois, l'application client passe un ID unique au serveur (par exemple session_id) pour que le processus se poursuive (même pour un seul utilisateur) - Dans ce cas, le paramétrage aide.
Souvent, l'application cliente maintient un cache des données envoyées vers et depuis le serveur. En conséquence, le serveur ne reçoit pas un comportement réel de l'utilisateur (au cas où le serveur exécute un algorithme différent en fonction des critères de recherche). Bien que le script VUser s'exécute avec succès, les statistiques de performances dessinées ne seront pas significatives. L'utilisation de différentes données via le paramétrage permet d'émuler l'activité côté serveur (procédures, etc.) et d'exercer le système.
Une date codée en dur dans le VUser pendant l'enregistrement peut ne plus être valide lorsque cette date est dépassée. Le paramétrage de la date permet à l'exécution de VUser de réussir en remplaçant la date codée en dur. Ces champs ou demandes sont les bons candidats pour le paramétrage.
Cliquez ici si la vidéo n'est pas accessible
Paramètres d'exécution et leur impact sur la simulation VU
Les paramètres d'exécution ont autant d'importance que votre script VUGen. Avec différentes configurations, vous pouvez obtenir différentes conceptions de test. C'est pourquoi vous risquez d'obtenir des résultats non répétables si les paramètres d'exécution ne sont pas cohérents. Discutons de chaque attribut un par un.
Exécuter la logique
Run Logic définit le nombre d'exécutions de toutes les actions, à l'exception de vuser_init et vuser_end.
Cela explique probablement plus clairement pourquoi LoadRunner suggère de conserver tout le code de connexion dans vuser_init et la partie Logout dans vuser_end, les deux exclusivement.
Si vous avez créé plusieurs actions, disons, se connecter, ouvrir l'écran, calculer la location, soumettre des fonds, vérifier le solde et se déconnecter, le scénario ci-dessous aura lieu pour chaque VUser:
Tous les VUsers se connecteront, exécuteront Ouvrir l'écran, Calculer la location, Soumettre les fonds, Vérifier le solde - puis - à nouveau Ouvrir l'écran, Calculer les locations… et ainsi de suite - en répétant 10 fois - puis se déconnecter (une fois).
Il s'agit d'un paramètre puissant permettant d'agir davantage comme un véritable utilisateur. N'oubliez pas qu'un utilisateur réel ne se connecte pas et ne se déconnecte pas à chaque fois - il répète généralement les mêmes étapes.
Combien de fois cliquez-vous sur «boîte de réception» lors de la vérification de vos e-mails avant de vous déconnecter?
Stimulation
C'est important. La plupart des gens sont incapables de comprendre la différence entre le rythme et le temps de réflexion. La seule différence est que «la stimulation fait référence au délai entre les itérations» alors que le temps de réflexion est le délai entre 2 étapes.
Le réglage recommandé dépend de la conception du test. Cependant, si vous cherchez à avoir une charge agressive, pensez à choisir "Dès que l'itération précédente se termine"
Enregistrer
Un journal (tel que généralement compris) est une comptabilité de tous les événements pendant que vous exécutez LoadRunner. Vous pouvez activer le journal pour savoir ce qui se passe entre votre application et votre serveur.
LoadRunner offre un mécanisme de journalisation puissant, robuste et évolutif. Il vous permet de ne conserver que le «journal standard» ou un journal étendu détaillé et configurable ou de le désactiver complètement.
Un journal standard est informatif et facilement compréhensible. Il contient juste la bonne quantité de connaissances dont vous aurez généralement besoin pour dépanner vos scripts VUser.
Dans le cas du journal étendu, toutes les informations du journal standard constituent un sous-ensemble. De plus, vous pouvez avoir une substitution de paramètres. Cela indique au composant LoadRunner d'inclure des informations complètes sur tous les paramètres (à partir du paramétrage), y compris les demandes, ainsi que les données de réponse.
Si vous incluez «Données renvoyées par le serveur», votre journal sera plus long. Cela inclura tout le HTML, les balises, les ressources, les informations non relatives aux ressources incluses directement dans le journal. L'option n'est bonne que si vous avez besoin d'un dépannage sérieux. Habituellement, cela rend le fichier journal très volumineux et difficilement compréhensible.
Comme vous pouvez le deviner maintenant si vous optez pour «Advance Trace», votre fichier journal sera énorme. Vous devez essayer. Vous remarquerez que le temps pris par VUGen a également augmenté de manière significative, bien que cela n'ait aucun impact sur le temps de réponse de transaction rapporté par VUGen. Cependant, il s'agit d'informations très avancées et peut-être utiles si vous comprenez l'application en question, la communication client-serveur entre votre application et le matériel ainsi que les détails du niveau de protocole. Habituellement, ces informations sont mortes par essence car elles nécessitent des efforts extrêmes pour les comprendre et les dépanner.
Des astuces:
- Quel que soit le temps que prend VUGen lorsque le journal est activé, cela n'a aucun impact sur le temps de réponse de la transaction. HP qualifie ce phénomène de «technologie de pointe».
- Désactivez le journal s'il n'est pas nécessaire.
- Désactivez le journal lorsque vous avez terminé vos scripts. L'inclusion de scripts avec la journalisation activée ralentira le contrôleur et signalera des messages lancinants.
- La désactivation du journal augmentera la capacité du nombre maximum d'utilisateurs que vous pouvez simuler à partir de LoadRunner.
- Pensez à utiliser «Envoyer un message uniquement en cas d'erreur» - cela désactivera les messages d'information inutiles et ne rapportera que les messages liés à l'erreur.
Think Times
Think Time est simplement le délai entre deux étapes.
Think Time aide à reproduire le comportement de l'utilisateur car aucun utilisateur réel ne peut utiliser une application telle qu'une machine (VUGen). VUGen génère automatiquement du temps de réflexion. Vous avez toujours un contrôle complet pour supprimer, multiplier ou faire varier la durée du temps de réflexion.
Pour mieux comprendre, par exemple, un utilisateur peut ouvrir un écran (c'est-à-dire une réponse suivie d'une demande) et ensuite fournir son nom d'utilisateur et son mot de passe avant d'appuyer sur Entrée. La prochaine interaction de l'application avec le serveur aura lieu lorsqu'il cliquera sur «Se connecter». Le temps qu'un utilisateur a mis pour taper son nom d'utilisateur et son mot de passe est Think Time dans LoadRunner.
Si vous cherchez à simuler une charge agressive sur l'application, envisagez de désactiver complètement le temps de réflexion.
Cependant, pour simuler un véritable comportement similaire, vous pouvez «User Random Think Time» et définir les pourcentages comme vous le souhaitez.
Pensez à limiter le temps de réflexion à une période légitime. Habituellement, 30 secondes sont assez bonnes.
Simulation de vitesse
La simulation de vitesse se réfère simplement à la capacité de bande passante pour chaque machine cliente.
Puisque nous simulons des milliers de VUser via LoadRunner, il est étonnant de voir à quel point LoadRunner a été simple pour contrôler la simulation de bande passante / vitesse du réseau.
Si vous êtes des clients qui accèdent à votre application à plus de 128 Kbps, vous pouvez la contrôler à partir d'ici. Vous pourrez simuler un «comportement réel», ce qui devrait vous aider à obtenir les bonnes statistiques de performance.
La meilleure recommandation est de définir sur Utiliser la bande passante maximale. Cela aidera à ignorer les goulots d'étranglement liés aux performances du réseau et à se concentrer d'abord sur les problèmes potentiels de l'application. Vous pouvez toujours exécuter le test plusieurs fois pour voir les différents comportements dans différentes circonstances.
Émulation de navigateur
L'expérience utilisateur ne dépend pas du navigateur utilisé par l'utilisateur final. De toute évidence, cela dépasse la portée des mesures du rendement. Cependant, vous pouvez choisir le navigateur que vous souhaitez émuler.
Pouvez-vous répondre à vous-même quand il sera vraiment important pour vous de sélectionner le bon navigateur dans cette configuration?
Vous utiliserez cette configuration si vous êtes sujet, l'application est une application Web, renvoyant des réponses différentes pour différents navigateurs. Par exemple, vous pouvez voir différentes images et contenus pour IE et Firefox, etc.
Un autre paramètre important est Simuler le cache du navigateur. Si vous souhaitez évaluer le temps de réponse lorsque le cache est activé, cochez cette case. Si vous recherchez le pire des cas, ce n'est évidemment pas une considération.
Le téléchargement de ressources non HTML permettra à LoadRunner de télécharger n'importe quel CSS, JS et autres rich media. Cela devrait être resté vérifié. Cependant, si vous souhaitez éliminer cela de la conception de votre test de performance, vous pouvez le décocher.
Procuration
Il est préférable d'éliminer complètement le proxy de votre environnement de test - cela rendra les résultats du test peu fiables. Cependant, vous pourriez être confronté à des situations où cela est inévitable. Dans une telle situation, LoadRunner vous facilite les paramètres de proxy.
Vous travaillerez (ou devriez travailler) avec Aucun paramètre de proxy. Vous pouvez l'obtenir à partir de votre navigateur par défaut. Cependant, n'oubliez pas de vérifier quel navigateur est défini par défaut et quelle est la configuration du proxy pour le navigateur par défaut.
Si vous utilisez un proxy et qu'il nécessite une authentification (ou un script), vous pouvez cliquer sur le bouton Authentifier qui mène à une nouvelle fenêtre. Reportez-vous à la capture d'écran ci-dessous.
Utilisez cet écran pour fournir un nom d'utilisateur et un mot de passe afin de vous authentifier sur le serveur proxy. Cliquez sur OK pour fermer l'écran.
Toutes nos félicitations. Vous avez terminé la configuration de votre script VUGen. N'oubliez pas de le configurer pour tous vos scripts VUser.