Outil de test LoadRunner : ArchiSchéma de structure et composants

Qu'est-ce que LoadRunner ?

LoadRunner est un Test de performance outil dont le pionnier était Mercury Interactive en 1999. LoadRunner a ensuite été acquis par HP en 2006, et l'activité logicielle de HP a fusionné avec Micro Focus dans le cadre d'un accord annoncé en 2016 et finalisé en 2017.

Note de la marque : OpenText a finalisé l'acquisition de Micro Focus en janvier 2023Cet outil n'est plus vendu sous la marque HP ou Micro Focus LoadRunnerLoadRunner Professional est maintenant disponible. OpenText Ingénierie professionnelle des performances, LoadRunner Enterprise est OpenText L'ingénierie des performances d'entreprise et LoadRunner Cloud sont OpenText Ingénierie des performances de base. Les noms des composants ci-dessous — VuGen, Contrôleur, générateurs de charge et Analyse — restent inchangés.

LoadRunner prend en charge divers outils de développement, technologies et protocoles de communication. Il intègre l'une des bibliothèques de protocoles les plus complètes du marché pour la réalisation de tests de performance. Les résultats de ces tests, générés par LoadRunner, servent de référence pour comparer ses performances à celles d'autres outils.

Vidéo LoadRunner

Visionnez la vidéo ci-dessous pour une brève introduction à LoadRunner avant d'examiner ses composants.

Pourquoi LoadRunner ?

LoadRunner n'est pas seulement un outil pionnier dans le domaine des tests de performance, il reste l'un des leaders du marché dans ce paradigme et constitue toujours le point de référence pour de nombreuses entreprises.

La couverture du protocole est la raison la plus évidente pour laquelle les équipes le choisissent, comme le montre le schéma des composants ci-dessous.

D'une manière générale, l'outil LoadRunner prend en charge RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex et Silverlight, etc.), Mobile, SAP, Oracle, MS SQL Serveur, Citrix, RTE, Mail et par dessus tout, Windows Socket. Peu d'outils concurrents offrent une telle variété de protocoles intégrés dans un seul outil, comme l'illustre la liste de protocoles ci-dessous.

Ce qui est encore plus convaincant dans le choix de LoadRunner pour les tests logiciels, c'est la crédibilité de cet outil. LoadRunner jouit d'une excellente réputation depuis longtemps, et il n'est pas rare que des clients vérifient vos indicateurs de performance à l'aide de cet outil. Si vous utilisez déjà LoadRunner pour vos tests de performance, vous apprécierez son efficacité.

Le logiciel LoadRunner est étroitement intégré aux outils apparentés de la même suite : Unified Functional Testing (l'ancien QTP, maintenant vendu sous le nom de OpenText Tests fonctionnels) et ALM (Gestion du cycle de vie des applications, maintenant OpenText ALM/Centre de qualité) — qui vous permet d'effectuer vos processus de test de bout en bout.

LoadRunner fonctionne en simulant des utilisateurs virtuels au sein de l'application concernée. Ces utilisateurs virtuels, également appelés VUsers, reproduisent les requêtes du client et attendent une réponse correspondante pour valider une transaction.

Pourquoi avez-vous besoin de tests de performances ?

Les estimations sectorielles ci-dessous sont largement citées et datent du début des années 2010, mais la tendance qu'elles décrivent n'a pas changé : les pages lentes coûtent cher.

On estime à 4.4 milliards de dollars la perte de revenus annuelle due aux mauvaises performances des sites web.

À l'ère du Web 2.0, les utilisateurs quittent un site web s'il ne répond pas dans les 8 secondes. Imaginez-vous attendre 5 secondes lors d'une recherche… Google ou d'envoyer une demande d'ami sur Facebook. Les répercussions d'une interruption de service sont souvent plus dévastatrices qu'on ne l'imagine. On peut citer des exemples bien connus, comme ceux qui ont touché les services bancaires en ligne de Bank of America. Amazon Services Web, Intuit et Blackberry.

Selon Dun & Bradstreet, 59 % des entreprises du classement Fortune 500 subissent en moyenne 1.6 heure d'indisponibilité de leurs systèmes chaque semaine. Sachant qu'une entreprise du Fortune 500 comptant au moins 10 000 employés paie en moyenne 56 $ de l'heure, le coût de la main-d'œuvre lié à ces indisponibilités s'élèverait à 896 000 $ par semaine, soit plus de 46 millions de dollars par an.

Seulement 5 minutes d'interruption de service GoogleOn estime que l'acquisition de .com en août 2013 a coûté au géant de la recherche jusqu'à 545 000 dollars.

On estime que les entreprises ont perdu des ventes d'une valeur de 1 100 dollars par seconde au cours d'une période passée Amazon Panne des services Web.

Lorsqu'un système logiciel est déployé par une organisation, il peut rencontrer de nombreux scénarios pouvant entraîner une latence des performances. Un certain nombre de facteurs entraînent une décélération des performances, quelques exemples peuvent inclure :

• Augmentation du nombre d'enregistrements présents dans la base de données
• Augmentation du nombre de requêtes simultanées adressées au système
• Un plus grand nombre d'utilisateurs accèdent simultanément au système par rapport au passé.

Cependant, toutes les candidatures ne sont pas retenues. test de charge Ce logiciel cible les systèmes client-serveur multi-utilisateurs ; par conséquent, il n’est pas pertinent de tester les performances d’un utilitaire de bureau mono-utilisateur comme celui présenté ci-dessous.

Qu'est-ce que LoadRunner Architecture ?

De manière générale, l'architecture de LoadRunner est complexe, mais facile à comprendre. Le schéma d'architecture ci-dessous illustre le fonctionnement conjoint des quatre composants.

Supposons que vous soyez chargé de vérifier les performances de Amazon.com pour 5000 utilisateurs.

Dans la réalité, ces 5 000 utilisateurs ne resteront pas tous sur la page d’accueil ; ils seront répartis sur différentes sections du site web. Comment simuler cette répartition ?

VuGen

VuGen ou utilisateur virtuel Generator VuGen est un EDI (environnement de développement intégré) ou un éditeur de code riche. Il est utilisé pour reproduire le comportement d'un système sous charge (SUL). VuGen offre une fonction d'« enregistrement » qui enregistre les communications entre le client et le serveur sous la forme d'un script codé, également appelé Script VUser.

Ainsi, en reprenant l'exemple ci-dessus, VuGen peut enregistrer pour simuler les processus métier suivants :

• Surfer sur la page produits de Amazon.com
• Paiement
• Traitement des paiements
• Vérification de la page Mon compte

Une fois que le script s'exécute correctement, les valeurs dynamiques du serveur doivent généralement être capturées avec corrélation avant de pouvoir être mis à l'échelle.

Contrôleur

Une fois le script VUser finalisé, le Contrôleur est l'un des principaux composants de LoadRunner qui contrôle la simulation de charge en gérant, par exemple :

• Combien de VUsers simuler pour chaque processus métier ou groupe VUser
• Comportement des VUsers (montée en puissance, descente en puissance, caractère simultané ou concurrent, etc.)
• Nature du scénario de charge, par exemple dans la vie réelle ou orienté vers un objectif ou vérification du SLA
• Quels injecteurs utiliser, combien de VUsers pour chaque injecteur
• Rassembler les résultats périodiquement
• Spoofing IP
• Rapport d'erreur
• Rapports de transactions, etc.

Pour reprendre notre exemple, le contrôleur ajoutera les paramètres suivants au script VuGen :

1. 3500 utilisateurs consultent la page produits de Amazon.com
2. 750 utilisateurs sont en train de finaliser leur commande.
3. 500 utilisateurs effectuent le traitement des paiements
4. 250 utilisateurs consultent la page Mon compte UNIQUEMENT après que 500 utilisateurs aient effectué le traitement du paiement.

Des scénarios encore plus complexes sont possibles :

• Initiez 5 VUsers toutes les 2 secondes jusqu'à une charge de 3500 VUsers (surf Amazon page produit) est atteint.
• Itérer pendant 30 minutes
• Suspendre l'itération pour 25 VUsers
• Redémarrage de 20 utilisateurs virtuels
• Initiez 2 utilisateurs (dans la caisse, le traitement des paiements, la page Mes comptes) chaque seconde.
• 2500 VUsers seront générés sur la machine A
• 2500 VUsers seront générés sur la machine B

Agents Machine/Charge Generators/Injecteurs

Le contrôleur LoadRunner est chargé de simuler des milliers d'utilisateurs virtuels (VUs). Ces VUs consomment des ressources matérielles, comme le processeur et la mémoire, ce qui limite la capacité de la machine qui les simule. De plus, le contrôleur effectue ces simulations depuis la même machine (celle sur laquelle il réside), ce qui peut entraîner un manque de précision des résultats. Pour pallier ce problème, les VUs sont répartis sur plusieurs machines, appelées groupes de charge. Generators ou injecteurs de charge.

En règle générale, le contrôleur réside sur une autre machine et la charge est simulée à partir d’autres machines. En fonction du protocole des scripts VUser et des spécifications de la machine, un certain nombre d'injecteurs de charge peuvent être nécessaires pour une simulation complète. Par exemple, les VUsers pour un script HTTP nécessiteront 2 à 4 Mo par VUser pour la simulation, donc 4 machines avec 4 Go de RAM chacune seront nécessaires pour simuler une charge de 10,000 VUsers.

En reprenant l'analogie de notre Amazon Par exemple, la sortie de ce composant est constituée de 5000 utilisateurs virtuels répartis sur deux injecteurs : 2500 utilisateurs virtuels générés sur la machine A et 2500 sur la machine B.

Analyse

Une fois les scénarios de chargement exécutés, le rôle du Analyse Le composant LoadRunner entre en jeu.

Pendant l'exécution, Controller crée un vidage des résultats sous forme brute et contient des informations telles que la version de LoadRunner qui a créé ce vidage de résultats et quelles étaient les configurations.

Toutes les erreurs et exceptions sont enregistrées dans un Microsoft Accédez à la base de données nommée output.mdb. Le composant d'analyse lit ce fichier de base de données pour effectuer différents types d'analyses et générer des graphiques.

Ces graphiques montrent diverses tendances pour comprendre le raisonnement derrière les erreurs et les défaillances sous charge ; aide ainsi à déterminer si une optimisation est requise dans SUL, Server (par exemple JBoss, Oracle) ou des infrastructures.

Voici un exemple où la bande passante peut constituer un goulot d'étranglement. Supposons que le serveur Web ait une capacité de 1 Gbit/s, mais que le trafic de données la dépasse, ce qui pénalise les utilisateurs suivants. Pour déterminer si le système est adapté à ces besoins, l'ingénieur de performance doit analyser le comportement de l'application en cas de charge anormale. Le graphique ci-dessous, généré par LoadRunner, permet d'évaluer la bande passante utilisée.

Comment effectuer des tests de performances

La feuille de route des tests de performance peut être globalement divisée en 5 étapes, résumées dans la feuille de route ci-dessous :

1. Planification du test de charge
2. Créer des scripts VuGen
3. Création de scénario
4. Exécution du scénario
5. Analyse des résultats (suivie d'un ajustement du système)

LoadRunner étant installé, examinons une à une les étapes du processus.

Étape 1) Planification du test de charge

La planification des tests de performances est différente de la planification d'un SIT (Tests d'intégration système) or UAT (test d'acceptation par l'utilisateur). La planification peut être divisée en petites étapes comme décrit ci-dessous :

Assemblez votre équipe

Lorsqu'on commence les tests LoadRunner, il est préférable de documenter qui participera à l'activité au sein de chaque équipe impliquée dans le processus, comme le montre l'organigramme ci-dessous.

• Chef de projet: Nommez le chef de projet qui sera responsable de cette activité et servira de personne-ressource pour la remontée des informations.
• Expert fonctionnel / Analyste d'affaires : Fournit une analyse d'utilisation du SUL et une expertise sur les fonctionnalités commerciales du site web ou du SUL.
• Expert en tests de performances : Crée les tests de performance automatisés et exécute les scénarios de charge.
• Système Archidétecter : Fournit le plan directeur du SUL.
• Développeur Web et PME : Il assure la maintenance du site web, effectue le suivi des aspects techniques, développe le site et corrige les bugs.
• Administrateur du système: Assure la maintenance des serveurs concernés tout au long d'un projet de test.

Décrire les applications et les processus métier impliqués

Réussi test de charge nécessite que vous envisagiez d'effectuer certains processus métier. Un processus métier se compose d'étapes clairement définies en conformité avec les transactions commerciales souhaitées – afin d'atteindre vos objectifs de tests de charge.

Une métrique d'exigences peut être préparée pour connaître la charge utilisateur sur le système. Ci-dessous un exemple de système de présence dans une entreprise :

Dans l'exemple ci-dessus, les chiffres indiquent le nombre d'utilisateurs connectés à l'application (SUL) à une heure donnée. Nous pouvons extract représente le nombre maximal d'utilisateurs connectés à un processus métier à n'importe quelle heure de la journée, calculé dans les colonnes les plus à droite.

De même, on peut conclure au nombre total d'utilisateurs connectés à l'application (SUL) à toute heure de la journée. Ceci est calculé dans la dernière ligne.

Les 2 faits ci-dessus combinés nous donnent le nombre total d’utilisateurs avec lesquels nous devons tester les performances du système.

Définir les procédures de gestion des données de test

Les statistiques et les observations tirées des tests de performance sont fortement influencées par de nombreux facteurs, comme indiqué précédemment. Il est d'une importance cruciale de préparer les données de test pour les tests de performances. Parfois, un processus métier particulier consomme un ensemble de données et produit un ensemble de données différent. Prenons l'exemple ci-dessous :

• Un utilisateur « A » crée une escroquerie financièretract et le soumet pour examen.
• Un autre utilisateur, « B », approuve 200 contraccs a day créé par l'utilisateur 'A'
• Un autre utilisateur, « C », paie environ 150 contracc'est un jour approuvé par l'utilisateur 'B'

Dans cette situation, l'utilisateur B a besoin de 200 points de connexion.tracts « créé » dans le système. De plus, l'utilisateur C a besoin de 150 contracts comme « approuvé » afin de simuler une charge de 150 utilisateurs.

Cela signifie implicitement que vous devez créer au moins 200 + 150 = 350 unités.tracts.

Après cela, approuvez 150 contracts serviront de données de test pour l'utilisateur C – les 200 restants contracCes données serviront de données de test pour l'utilisateur B.

Moniteurs de contour

Analysez tous les facteurs susceptibles d'affecter les performances d'un système. Par exemple, une configuration matérielle réduite peut avoir un impact sur les performances du système en charge (SUL).

Recensez tous les facteurs et configurez des moniteurs afin de pouvoir les évaluer. Voici quelques exemples :

• Processeur (pour serveur Web, serveur d'applications, serveur de base de données et injecteurs)
• RAM (pour le serveur Web, le serveur d'applications, le serveur de base de données et les injecteurs)
• Serveur Web/App (par exemple IIS, JBoss, Jaguar Server, Tomcat, etc.)
• Serveur DB (taille PGA et SGA en cas de Oracle et MSSQL Server, SP, etc.)
• Utilisation de la bande passante du réseau
• Carte réseau interne et externe en cas de clustering
• Load Balancer (et qu'il répartit la charge uniformément sur tous les nœuds des clusters)
• Centres de données flux (Calculer la quantité de données échangées entre le client et le serveur, puis déterminer si la capacité de la carte réseau est suffisante pour simuler un nombre X d'utilisateurs.)

Étape 2) Créer des scripts VuGen

L'étape suivante après la planification consiste à créer des scripts VUser, en ajoutant paramétrage, transactions et paramètres d'exécution à mesure que le scénario mûrit.

Étape 3) Création de scénario

L'étape suivante consiste à créer votre scénario de chargement dans le contrôleur, en choisissant entre un scénario manuel et un scénario orienté objectif.

Étape 4) Exécution du scénario

L'exécution de scénario consiste à émuler la charge utilisateur sur le serveur en demandant à plusieurs VUsers d'effectuer des tâches simultanément.

Vous pouvez définir le niveau d'une charge en augmentant et en diminuant le nombre de VUsers qui effectuent des tâches en même temps.

Cette exécution peut entraîner la mise hors service du serveur. stress et présentant un comportement anormal. C'est précisément l'objectif des tests de performance. Les résultats obtenus servent ensuite à une analyse détaillée et à l'identification des causes profondes.

Étape 5) Analyse des résultats (suivie d'un ajustement du système)

Lors de l'exécution d'un scénario, LoadRunner enregistre les performances de l'application sous différentes charges. Les statistiques issues de l'exécution des tests sont sauvegardées et une analyse détaillée est effectuée. L'outil d'analyse (nommé « HP Analysis » dans les versions utilisées pour la rédaction de ce guide) génère divers graphiques permettant d'identifier les causes profondes d'un ralentissement des performances du système, ainsi que d'une panne système.

Certains des graphiques obtenus comprennent :

• Temps jusqu'au premier tampon
• Temps de réponse des transactions
• Temps de réponse moyen des transactions
• Coups par seconde
• Windows Ressources
• Statistiques d'erreurs
• récapitulatif des transactions

FAQ