Outil de test LoadRunner – Composants et Architecture

Qu'est-ce que LoadRunner ?

LoadRunner est un outil de test de performances 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 opérations. Test de performance. Les résultats des tests de performances produits par le logiciel LoadRunner sont utilisés comme référence par rapport à d'autres outils.

Vidéo LoadRunner

Pourquoi LoadRunner ?

LoadRunner n'est pas seulement un outil pionnier en matière de tests de performances, mais il reste également 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 le secteur des tests de performances.

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 Prise. Il n'existe aucun outil concurrent sur le marché qui puisse offrir une telle variété de protocoles dans un seul outil.

Ce qui est plus convaincant pour choisir LoadRunner dans les tests logiciels, c'est la crédibilité de cet outil. L'outil LoadRunner a depuis longtemps établi une réputation comme vous le constaterez souvent les clients vérifient vos références de performances à l’aide de LoadRunner. Vous trouverez un soulagement si vous utilisez déjà LoadRunner pour vos besoins en matière de tests de performances.

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

LoadRunner fonctionne sur le principe de la 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 lors de la réussite d'une transaction.

Pourquoi avez-vous besoin de tests de performances ?

On estime que perte de 4.4 milliards de revenus est enregistré chaque année en raison de mauvaises performances Web.

À l’ère actuelle du Web 2.0, les utilisateurs cliquent si un site Web ne répond pas dans les 8 secondes. Imaginez-vous attendre 5 secondes lorsque vous recherchez Google ou que vous faites une demande d'ami sur Facebook. Les répercussions des interruptions de 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 Services Web, Intuit ou Blackberry.

Selon Dunn & Bradstreet, 59 % des entreprises Fortune 500 connaissent environ 1.6 heure d'indisponibilité chaque semaine. Si l'on considère qu'une entreprise moyenne du classement Fortune 500 comptant au moins 10,000 56 employés paie 896,000 dollars de l'heure, la part de main-d'œuvre dans les coûts d'indisponibilité d'une telle organisation serait de 46 dollars par semaine, soit plus de millions de dollars par an.

On estime qu'une interruption de seulement 5 minutes de Google.com (19 août 13) coûtera au géant de la recherche jusqu'à 545,000 dollars.

On estime que les entreprises ont perdu des ventes d'une valeur de 1100 dollars par seconde en raison d'un récent Amazon Panne du service 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édant au système à la fois par rapport au passé

Qu'est-ce que LoadRunner Architecture ?

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 de Amazon.com pour 5000 utilisateurs

Dans une situation réelle, 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 utilisateur virtuel Generator est un IDE (Integrated Development Environment) ou un éditeur de codage riche. VUGen est utilisé pour reproduire le comportement du système sous charge (SUL). VUGen fournit une fonctionnalité « d'enregistrement » qui enregistre les communications 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 produits de Amazon.com
2. Régler votre commande
3. Traitement des paiements
4. Vérification de la page Mon compte

Une fois un script VUser finalisé, Controller est l'un des principaux composants de LoadRunner qui contrôle la simulation de Load 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.

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

1) 3500 utilisateurs sont Surfer sur la page produits de Amazon.com

2) 750 utilisateurs sont présents Régler votre commande

3) 500 utilisateurs sont effectuer le traitement des paiements

4) 250 utilisateurs sont Vérification de 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. Initiez 5 VUsers toutes les 2 secondes jusqu'à une charge de 3500 VUsers (surf Amazon page produit) est atteint.
2. Itérer pendant 30 minutes
3. Suspendre l'itération pour 25 VUsers
4. Redémarrez 20 VUSers
5. Initiez 2 utilisateurs (dans la caisse, le traitement des paiements, la page Mes comptes) chaque seconde.
6. 2500 VUsers seront générés sur la machine A
7. 2500 VUsers seront générés sur la machine B

Agents Machine/Charge Generators/Injecteurs

HP LoadRunner Controller est chargé de simuler des milliers de VUsers – ces VUsers consomment des ressources matérielles, par exemple le processeur et la mémoire – imposant ainsi une limite à la machine qui les simule. En outre, Controller simule ces VUsers à partir de la même machine (où réside le contrôleur) et les résultats peuvent donc ne pas être précis. Pour répondre à ce problème, tous les VUsers sont répartis sur différentes machines, appelées 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 prenant l'analogie de notre Amazon Exemple, la sortie de ce composant sera

Analyse

Une fois les scénarios de chargement exécutés, le rôle de «Analyse"Les composants de LoadRunner entrent 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éder à la base de données, 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 défaillances sous charge ; aide ainsi à déterminer si une optimisation est requise dans SUL, Server (par exemple JBoss, Oracle) ou des infrastructures.

Vous trouverez ci-dessous un exemple dans lequel 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 suivants. Pour déterminer que le système répond à ces besoins, Performance Engineer doit analyser le comportement des applications avec une charge anormale. Vous trouverez ci-dessous un graphique généré par LoadRunner pour obtenir de la bande passante.

Comment effectuer des tests de performances

La feuille de route des tests de performances 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 ajustement du système)

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

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

É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

Lorsque vous démarrez avec LoadRunner Testing, il est préférable de documenter qui participera à l'activité de chaque équipe impliquée pendant le processus.

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 Fonction/Analyste Métier :

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 performances automatisés et exécute des scénarios de charge

Système Archidétecter :

Fournit un plan du SUL

Développeur Web et PME :

• Maintient le site Web et assure les aspects de surveillance
• Développe le site Web et corrige les bugs

Administrateur du système:

• Maintient les serveurs impliqué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 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, 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 un contrat financier et le soumet pour révision.
• 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 « 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éculez chaque facteur susceptible d’affecter les performances d’un système. Par exemple, avoir réduit le matériel aura un impact potentiel sur les performances SUL (System Under Load).

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)
• Flux de données (calculez la quantité de données transférées vers et depuis le client et le serveur, puis calculez si la capacité de la carte réseau est suffisante pour simuler un nombre X d'utilisateurs)

Étape 2) Créer des scripts VUGen

La prochaine étape après la planification consiste à créer Scripts VUtilisateur.

Étape 3) Création de scénario

L'étape suivante consiste à créer votre scénario de chargement

É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 une tension sur le serveur et un comportement anormal. C’est le but même des tests de performances. Les résultats tirés sont ensuite utilisés pour 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 du scénario, LoadRunner enregistre les performances de l'application sous différentes charges. Les statistiques tirées de l'exécution des tests sont enregistrées et une analyse détaillée est effectuée. L'outil « HP Analysis » génère divers graphiques qui aident à identifier les causes profondes d'un retard dans les performances du système, ainsi que d'une panne du 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

QFP