Qu'est-ce que l'outil de test HP LoadRunner? Architecture, composants

Qu'est-ce que LoadRunner?

LoadRunner est un outil de test de performances qui a été lancé par Mercury en 1999. LoadRunner a ensuite été acquis par HPE en 2006. En 2016, LoadRunner a été acquis par MicroFocus.

LoadRunner prend en charge divers outils de développement, technologies et protocoles de communication. En fait, c'est le seul outil sur le marché qui prend en charge un si grand nombre de protocoles pour effectuer des tests de performance. Les résultats des tests de performance produits par le logiciel LoadRunner sont utilisés comme référence par rapport à d'autres outils

Dans ce didacticiel, vous apprendrez-

• Pourquoi LoadRunner?
• Pourquoi avez-vous besoin de tests de performance?
• Qu'est-ce que l'architecture LoadRunner?
• Feuille de route des tests de performance: étapes détaillées
• FAQ

Pourquoi LoadRunner?

LoadRunner n'est pas seulement un outil pionnier dans le domaine des tests de performances, mais il est toujours un leader du marché dans le paradigme des tests de performances. Dans une évaluation récente, LoadRunner détient environ 85% de part de marché dans l'industrie des tests de performance.

Globalement, 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 Server, Citrix, RTE, Mail et surtout Windows Socket. Il n’existe aucun outil concurrent sur le marché qui pourrait offrir une telle variété de protocoles dans un seul et même outil.

Ce qui est plus convaincant de choisir LoadRunner dans les tests logiciels, c'est la crédibilité de cet outil. L'outil LoadRunner a longtemps établi une réputation car vous trouverez souvent des clients qui vérifient vos benchmarks de performance à l'aide de LoadRunner. Vous trouverez un soulagement si vous utilisez déjà LoadRunner pour vos besoins de test de performances.

Le logiciel LoadRunner est étroitement intégré à d'autres outils HP tels que les tests fonctionnels unifiés (QTP) et ALM (gestion du cycle de vie des applications) qui vous permettent d'effectuer vos processus de test de bout en bout.

LoadRunner fonctionne sur un principe de simulation d'utilisateurs virtuels sur l'application en question. Ces utilisateurs virtuels, également appelés VUsers, répliquent les demandes des clients et attendent une réponse correspondante au passage d'une transaction.

Pourquoi avez-vous besoin de tests de performance?

Une perte estimée de 4,4 milliards de revenus est enregistrée chaque année en raison de la mauvaise performance du Web.

À l'ère actuelle du Web 2.0, les utilisateurs cliquent loin si un site Web ne répond pas dans les 8 secondes. Imaginez-vous attendre 5 secondes lorsque vous recherchez Google ou faites une demande d'ami sur Facebook. Les répercussions des temps d'arrêt des performances sont souvent plus dévastatrices que jamais imaginées. Nous avons des exemples tels que ceux qui ont récemment frappé Bank of America Online Banking, Amazon Web Services, Intuit ou Blackberry.

Selon Dunn & Bradstreet, 59% des entreprises du classement Fortune 500 subissent environ 1,6 heure d'indisponibilité chaque semaine. Étant donné que l'entreprise Fortune 500 moyenne avec un minimum de 10 000 employés paie 56 $ l'heure, la partie main-d'œuvre des coûts des temps d'arrêt pour une telle organisation serait de 896 000 $ par semaine, soit plus de 46 millions de dollars par an.

On estime qu'un temps d'arrêt de seulement 5 minutes de Google.com (19 août 2013) coûterait au géant de la recherche jusqu'à 545 000 $.

On estime que les entreprises ont perdu des ventes d'une valeur de 1100 USD par seconde en raison d'une récente panne du service Web d'Amazon.

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 demandes simultanées adressées au système
• un plus grand nombre d'utilisateurs accédant au système à la fois par rapport au passé

Qu'est-ce que l'architecture LoadRunner?

D'une manière générale, l'architecture de HP LoadRunner est complexe, mais facile à comprendre.

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

Dans une situation réelle, tous ces 5000 utilisateurs ne seront pas sur la page d'accueil mais dans une section différente des sites Web. Comment pouvons-nous simuler différemment

VUGen:

VUGen ou Virtual User Generator est un IDE (Integrated Development Environment) ou un éditeur de codage riche. VUGen est utilisé pour répliquer le comportement du système sous charge (SUL). VUGen fournit une fonction «d'enregistrement» qui enregistre la communication vers et depuis le client et le serveur sous la forme d'un script codé - également appelé script VUser.

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

1. Surfer sur la page des produits d'Amazon.com
2. Vérifier
3. Traitement des paiements
4. Vérification de la page Mon compte

Manette

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

• Combien de VUsers à simuler par rapport à chaque processus métier ou groupe VUser
• Comportement des VUs (montée en puissance, décélération, nature simultanée ou simultanée, etc.)
• Nature du scénario de charge, par exemple la vie réelle ou axée sur les objectifs ou la vérification du SLA
• Quels injecteurs utiliser, combien de VUsers contre chaque injecteur
• Rassemblez les résultats périodiquement
• Usurpation IP
• Rapport d'erreurs
• Rapports de transaction, etc.

Prendre une analogie avec notre exemple de contrôleur ajoutera le paramètre suivant au script VUGen

1) 3500 utilisateurs surfent sur la page des produits d'Amazon.com

2) 750 utilisateurs sont en cours de paiement

3) 500 utilisateurs effectuent le traitement des paiements

4) 250 utilisateurs vérifient la page Mon compte UNIQUEMENT après que 500 utilisateurs ont effectué le traitement des paiements

Des scénarios encore plus complexes sont possibles

1. Lancez 5 VU toutes les 2 secondes jusqu'à ce qu'une charge de 3500 VU (navigation sur la page produit Amazon) soit atteinte.
2. Itérer pendant 30 minutes
3. Suspendre l'itération pour 25 VUsers
4. Redémarrez 20 VUSers
5. Initiez 2 utilisateurs (dans Checkout, Payment Processing, MyAccounts Page) toutes les secondes.
6. 2500 VUs seront générés sur la machine A
7. 2500 VUs seront générés sur la machine B

Agents Machine / Générateurs de Charge / Injecteurs

HP LoadRunner Controller est chargé de simuler des milliers de VU - ces VU consomment des ressources matérielles, par exemple le processeur et la mémoire - mettant ainsi une limite sur la machine qui les simule. En outre, le contrôleur simule ces VUsers à partir de la même machine (où réside le contrôleur) et, par conséquent, les résultats peuvent ne pas être précis. Pour résoudre ce problème, tous les VUsers sont répartis sur différentes machines, appelées générateurs de charge ou injecteurs de charge.

En règle générale, le contrôleur réside sur une machine différente 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 VU pour un script HTTP nécessiteront 2 à 4 Mo par VU pour la simulation, donc 4 machines avec 4 Go de RAM chacune seront nécessaires pour simuler une charge de 10 000 VU.

Prenant l'analogie de notre exemple Amazon, la sortie de ce composant sera

Analyse:

Une fois les scénarios de chargement exécutés, le rôle des composants « Analyse » de 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, quelle version de LoadRunner a créé ce vidage de résultats et quelles étaient les configurations.

Toutes les erreurs et exceptions sont enregistrées dans une base de données d'accès Microsoft, nommée output.mdb. Le composant "Analyse" lit ce fichier de base de données pour effectuer différents types d'analyses et génère des graphiques.

Ces graphiques montrent diverses tendances pour comprendre le raisonnement derrière les erreurs et les pannes sous charge; ainsi aider à déterminer si l'optimisation est nécessaire dans SUL, Server (par exemple JBoss, Oracle) ou infrastructure.

Voici un exemple où la bande passante pourrait créer un goulot d'étranglement. Disons que le serveur Web a une capacité de 1 Go / s alors que le trafic de données dépasse cette capacité, ce qui fait souffrir les utilisateurs ultérieurs. Pour déterminer que le système répond à ces besoins, Performance Engineer doit analyser le comportement de l'application avec une charge anormale. Vous trouverez ci-dessous un graphique généré par LoadRunner pour obtenir de la bande passante.

Feuille de route des tests de performance: étapes détaillées

La feuille de route des tests de performance peut être divisée en 5 étapes:

• Planification du test de charge
• Créer des scripts VUGen
• Création de scénario
• Exécution du scénario
• Analyse des résultats (suivie d'un peaufinage du système)

Maintenant que LoadRunner est installé, comprenons les étapes impliquées dans le processus une par une.

Étapes impliquées dans le processus de test de performance

Planification du test de charge

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

Rassemblez votre équipe

Lors de la mise en route de LoadRunner Testing, il est préférable de documenter qui participera à l'activité de chaque équipe impliquée au cours du processus.

Chef de projet:

Nommez le chef de projet qui sera propriétaire de cette activité et servira de personne-ressource pour l'escalade.

Expert de fonction / Business Analyst:

Fournir une analyse de l'utilisation de SUL et fournir une expertise sur les fonctionnalités commerciales du site Web / SUL

Expert en tests de performances:

Crée les tests de performance automatisés et exécute des scénarios de charge

Architecte système:

Fournit un plan directeur du SUL

Développeur Web et PME:

• Maintient le site Web et fournit des aspects de surveillance
• Développe le site Web et corrige les bogues

Administrateur du système:

• Maintient les serveurs impliqués tout au long d'un projet de test

Décrivez les applications et les processus métier impliqués:

Un test de charge réussi nécessite que vous prévoyiez d'exécuter certains processus métier. Un Business Process se compose d'étapes clairement définies en conformité avec les transactions commerciales souhaitées - afin d'atteindre vos objectifs de test de charge.

Une métrique des exigences peut être préparée pour susciter une charge utilisateur sur le système. Voici un exemple de système de présence dans une entreprise:

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

De même, nous pouvons conclure le nombre total d'utilisateurs connectés à l'application (SUL) à n'importe quelle 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 performance. Parfois, un processus métier particulier consomme un ensemble de données et produit un ensemble de données différent. Prenez l'exemple ci-dessous:

• Un utilisateur «A» crée un contrat financier et le soumet pour examen.
• Un autre utilisateur «B» approuve 200 contrats par jour créés par l'utilisateur «A»
• Un autre utilisateur «C» paie environ 150 contrats par jour approuvés par l'utilisateur «B»

Dans cette situation, l'utilisateur B doit avoir 200 contrats «créés» dans le système. De plus, l'utilisateur C a besoin de 150 contrats comme "approuvés" pour simuler une charge de 150 utilisateurs.

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

Après cela, approuvez 150 contrats qui serviront de données de test pour l'utilisateur C - les 200 contrats restants serviront de données de test pour l'utilisateur B.

Moniteurs de contour

Spécifiez chaque facteur qui pourrait éventuellement affecter les performances d'un système. Par exemple, une réduction du matériel aura un impact potentiel sur les performances du SUL (System Under Load).

Recensez tous les facteurs et configurez les moniteurs pour pouvoir les évaluer. Voici quelques exemples:

• Processeur (pour serveur Web, serveur d'applications, serveur de base de données et injecteurs)
• RAM (pour serveur Web, serveur d'applications, serveur de base de données et injecteurs)
• Serveur Web / App (par exemple IIS, JBoss, Jaguar Server, Tomcat, etc.)
• Serveur DB (taille PGA et SGA dans le cas d'Oracle et MSSQL Server, SPs etc.)
• Utilisation de la bande passante du réseau
• NIC 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)
• Flux de données (calculez la quantité de données transférées vers et depuis le client et le serveur - puis calculez si une capacité de carte réseau est suffisante pour simuler un nombre X d'utilisateurs)

Créer des scripts VUGen

La prochaine étape après la planification consiste à créer des scripts VUser.

Création de scénario

La prochaine étape consiste à créer votre scénario de chargement

Exécution du scénario

L'exécution de scénario est l'endroit où vous émulez la charge de l'utilisateur sur le serveur en demandant à plusieurs VU d'exécuter des tâches simultanément.

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

Cette exécution peut entraîner un stress et un comportement anormal du serveur. C'est le but même des tests de performance. Les résultats tirés sont ensuite utilisés pour une analyse détaillée et l'identification des causes profondes.

Analyse des résultats (suivie d'un peaufinage du système)

Pendant l'exécution du scénario, LoadRunner enregistre les performances de l'application sous différentes charges. Les statistiques tirées de l'exécution du test sont enregistrées et l'analyse des détails est effectuée. L'outil «HP Analysis» génère divers graphiques qui aident à identifier les causes profondes d'un retard des performances du système, ainsi que d'une défaillance du système.

Certains des graphiques obtenus comprennent:

• Heure du premier tampon
• Temps de réponse de la transaction
• Temps de réponse moyen des transactions
• Hits par seconde
• Ressources Windows
• Statistiques d'erreurs
• récapitulatif des transactions

FAQ

Quelles applications devons-nous tester les performances?

Les tests de performances sont toujours effectués pour les systèmes client-serveur uniquement. Cela signifie que toute application qui n'est pas une architecture client-serveur ne doit pas nécessiter de test de performance.

Par exemple, Microsoft Calculator n'est ni basé sur le client-serveur ni exécute plusieurs utilisateurs; par conséquent, ce n'est pas un candidat pour les tests de performance.

Quelle est la différence entre les tests de performance et l'ingénierie des performances

Il est important de comprendre la différence entre les tests de performance et l'ingénierie des performances. Une compréhension est partagée ci-dessous:

Les tests de performance sont une discipline qui consiste à tester et à signaler les performances actuelles d'une application logicielle sous divers paramètres.

L'ingénierie des performances est le processus par lequel le logiciel est testé et réglé dans le but de réaliser les performances requises. Ce processus vise à optimiser le trait de performance d'application le plus important, à savoir l'expérience utilisateur.

Historiquement, les tests et les réglages ont été des domaines distinctement distincts et souvent concurrents. Au cours des dernières années, cependant, plusieurs poches de testeurs et de développeurs ont collaboré indépendamment pour créer des équipes de réglage. Parce que ces équipes ont rencontré un succès significatif, le concept de couplage des tests de performance avec le réglage des performances a fait son chemin, et maintenant nous l'appelons l'ingénierie des performances.