Tests de performances logicielles - Software performance testing

Dans l' assurance qualité des logiciels , les tests de performances sont en général une pratique de test effectuée pour déterminer les performances d'un système en termes de réactivité et de stabilité sous une charge de travail particulière. Il peut également servir à étudier, mesurer, valider ou vérifier d'autres attributs de qualité du système, tels que l' évolutivité , la fiabilité et l'utilisation des ressources.

Les tests de performances, un sous-ensemble de l' ingénierie des performances , sont une pratique informatique qui s'efforce d'intégrer des normes de performances dans la mise en œuvre, la conception et l'architecture d'un système.

Types de test

Test de charge

Le test de charge est la forme la plus simple de test de performance. Un test de charge est généralement effectué pour comprendre le comportement du système sous une charge attendue spécifique. Cette charge peut être le nombre d'utilisateurs simultanés attendus sur l' application effectuant un nombre spécifique de transactions dans la durée définie. Ce test donnera les temps de réponse de toutes les transactions critiques importantes pour l'entreprise. La base de données , le serveur d'applications , etc. sont également surveillés pendant le test, ce qui aidera à identifier les goulots d'étranglement dans le logiciel d'application et le matériel sur lequel le logiciel est installé.

Tests de résistance

Les tests de résistance sont normalement utilisés pour comprendre les limites supérieures de la capacité au sein du système. Ce type de test est effectué pour déterminer la robustesse du système en termes de charge extrême et aide les administrateurs d'applications à déterminer si le système fonctionnera suffisamment si la charge actuelle dépasse largement le maximum attendu.

Test de trempage

Les tests de trempage , également appelés tests d'endurance, sont généralement effectués pour déterminer si le système peut supporter la charge continue attendue. Pendant les tests de trempage, l'utilisation de la mémoire est surveillée pour détecter les fuites potentielles. La dégradation des performances est également importante, mais souvent négligée, c'est-à-dire pour s'assurer que le débit et/ou les temps de réponse après une longue période d'activité soutenue sont aussi bons ou meilleurs qu'au début du test. Il s'agit essentiellement d'appliquer une charge importante à un système pendant une période de temps prolongée et significative. L'objectif est de découvrir comment le système se comporte en utilisation soutenue.

Test de pointe

Le test de pointe se fait en augmentant ou en diminuant soudainement la charge générée par un très grand nombre d'utilisateurs, et en observant le comportement du système. L'objectif est de déterminer si les performances en souffriront, si le système tombera en panne ou s'il sera capable de gérer des changements spectaculaires de charge.

Test de point d'arrêt

Les tests de points d'arrêt sont similaires aux tests de stress. Une charge incrémentielle est appliquée au fil du temps tandis que le système est surveillé pour des conditions de défaillance prédéterminées. Le test de point d'arrêt est parfois appelé test de capacité car on peut dire qu'il détermine la capacité maximale en dessous de laquelle le système fonctionnera conformément aux spécifications requises ou aux accords de niveau de service. Les résultats de l'analyse des points d'arrêt appliqués à un environnement fixe peuvent être utilisés pour déterminer la stratégie de mise à l'échelle optimale en termes de matériel requis ou de conditions qui devraient déclencher des événements de mise à l'échelle dans un environnement cloud.

Tests de configuration

Plutôt que de tester les performances du point de vue de la charge, des tests sont créés pour déterminer les effets des modifications de configuration des composants du système sur les performances et le comportement du système. Un exemple courant serait d'expérimenter différentes méthodes d' équilibrage de charge .

Test d'isolement

Les tests d'isolement ne sont pas propres aux tests de performances, mais impliquent la répétition d'une exécution de test qui a entraîné un problème système. De tels tests peuvent souvent isoler et confirmer le domaine de pannes.

Test Internet

Il s'agit d'une forme relativement nouvelle de test de performance lorsque les applications mondiales telles que Facebook, Google et Wikipedia sont testées à partir de générateurs de charge placés sur le continent cible réel, qu'il s'agisse de machines physiques ou de machines virtuelles cloud. Ces tests nécessitent généralement une énorme quantité de préparation et de suivi pour être exécutés avec succès.

Fixer des objectifs de performances

Les tests de performance peuvent servir à différentes fins :

  • Il peut démontrer que le système répond aux critères de performance.
  • Il peut comparer deux systèmes pour trouver celui qui fonctionne le mieux.
  • Il peut mesurer quelles parties du système ou de la charge de travail causent un mauvais fonctionnement du système.

De nombreux tests de performance sont effectués sans définir d'objectifs de performance suffisamment réalistes et axés sur les objectifs. La première question d'un point de vue commercial devrait toujours être : "Pourquoi testons-nous les performances ?". Ces considérations font partie de l' analyse de rentabilisation des tests. Les objectifs de performances varient en fonction de la technologie et de l'objectif du système, mais doivent toujours inclure certains des éléments suivants :

Concurrence et débit

Si un système identifie les utilisateurs finaux par une certaine forme de procédure de connexion, alors un objectif de simultanéité est hautement souhaitable. Par définition, il s'agit du plus grand nombre d'utilisateurs système simultanés que le système est censé prendre en charge à un moment donné. Le flux de travail d'une transaction scriptée peut avoir un impact sur la véritable concurrence, en particulier si la partie itérative contient l'activité de connexion et de déconnexion.

Si le système n'a pas de concept d'utilisateurs finaux, l'objectif de performance sera probablement basé sur un débit ou un taux de transaction maximum.

Temps de réponse du serveur

Il s'agit du temps mis par un nœud du système pour répondre à la demande d'un autre. Un exemple simple serait une requête HTTP « GET » du client du navigateur vers le serveur Web. En termes de temps de réponse, c'est ce que tous les outils de test de charge mesurent réellement. Il peut être pertinent de définir des objectifs de temps de réponse du serveur entre tous les nœuds du système.

Temps de réponse du rendu

Les outils de test de charge ont du mal à mesurer le temps de réponse au rendu, car ils n'ont généralement aucune idée de ce qui se passe dans un nœud, à part reconnaître une période de temps où il n'y a pas d'activité « sur le fil ». Pour mesurer le temps de réponse du rendu, il est généralement nécessaire d'inclure des scripts de test fonctionnel dans le cadre du scénario de test de performance. De nombreux outils de test de charge n'offrent pas cette fonctionnalité.

Spécifications de performances

Il est essentiel de détailler les spécifications de performance (exigences) et de les documenter dans tout plan de test de performance. Idéalement, cela se fait pendant la phase de développement des exigences de tout projet de développement de système, avant tout effort de conception. Voir Ingénierie des performances pour plus de détails.

Cependant, les tests de performances ne sont souvent pas effectués par rapport à une spécification ; par exemple, personne n'aura exprimé quel devrait être le temps de réponse maximum acceptable pour une population donnée d'utilisateurs. Les tests de performances sont fréquemment utilisés dans le cadre du processus de réglage du profil de performances. L'idée est d'identifier le "maillon le plus faible" - il y a inévitablement une partie du système qui, si elle est amenée à répondre plus rapidement, entraînera un fonctionnement plus rapide du système global. Il est parfois difficile d'identifier quelle partie du système représente ce chemin critique, et certains outils de test incluent (ou peuvent avoir des modules complémentaires qui fournissent) une instrumentation qui s'exécute sur le serveur (agents) et rapporte les temps de transaction, les temps d'accès à la base de données , la surcharge du réseau et d'autres moniteurs de serveur, qui peuvent être analysés avec les statistiques de performances brutes. Sans une telle instrumentation, quelqu'un pourrait être accroupi sur le gestionnaire de tâches Windows sur le serveur pour voir combien de charge CPU les tests de performances génèrent (en supposant qu'un système Windows est en cours de test).

Les tests de performance peuvent être effectués sur le Web, et même dans différentes parties du pays, car il est connu que les temps de réponse d'Internet lui-même varient selon les régions. Cela peut également être fait en interne, bien que les routeurs doivent alors être configurés pour introduire le décalage qui se produirait généralement sur les réseaux publics. Les charges doivent être introduites dans le système à partir de points réalistes. Par exemple, si 50 % de la base d'utilisateurs d'un système accède au système via une connexion modem 56 K et l'autre moitié via un T1 , alors les injecteurs de charge (ordinateurs qui simulent de vrais utilisateurs) doivent soit injecter la charge sur le même mélange de connexions (idéal) ou simuler la latence réseau de telles connexions, en suivant le même profil d'utilisateur.

Il est toujours utile d'avoir une déclaration du nombre maximal probable d'utilisateurs susceptibles d'utiliser le système aux heures de pointe. S'il peut également y avoir un énoncé de ce qui constitue le temps de réponse maximal autorisé de 95 centile, alors une configuration d'injecteur pourrait être utilisée pour tester si le système proposé répond à cette spécification.

Questions a poser

Les spécifications de performances doivent au minimum poser les questions suivantes :

  • Dans le détail, quelle est la portée du test de performance ? Quels sous-systèmes, interfaces, composants, etc. sont dans et hors de la portée de ce test ?
  • Pour les interfaces utilisateur (UI) concernées, combien d'utilisateurs simultanés sont attendus pour chacune (précisez le pic par rapport au nominal) ?
  • À quoi ressemble le système cible (matériel) (spécifiez toutes les configurations de serveur et d'appliance réseau) ?
  • Quelle est la répartition de la charge de travail d'application de chaque composant du système ? (par exemple : 20 % de connexion, 40 % de recherche, 30 % de sélection d'article, 10 % de paiement).
  • Qu'est-ce que la répartition de la charge de travail du système ? [Plusieurs charges de travail peuvent être simulées dans un seul test de performance] (par exemple : 30 % de charge de travail A, 20 % de charge de travail B, 50 % de charge de travail C).
  • Quelles sont les exigences de temps pour tout/tout les processus batch back-end (spécifier le pic par rapport au nominal) ?

Conditions préalables

Une construction stable du système qui doit ressembler le plus possible à l'environnement de production.

Pour garantir des résultats cohérents, l'environnement de test de performances doit être isolé des autres environnements, tels que les tests d'acceptation par l'utilisateur (UAT) ou le développement. En tant que meilleure pratique, il est toujours conseillé d'avoir un environnement de test de performances séparé ressemblant autant que possible à l'environnement de production.

Conditions d'essai

Dans les tests de performance, il est souvent crucial que les conditions de test soient similaires à l'utilisation réelle attendue. Cependant, dans la pratique, cela est difficile à organiser et pas tout à fait possible, car les systèmes de production sont soumis à des charges de travail imprévisibles. Les charges de travail de test peuvent imiter autant que possible les occurrences dans l'environnement de production, mais ce n'est que dans les systèmes les plus simples que l'on peut reproduire exactement cette variabilité de la charge de travail.

Les implémentations architecturales faiblement couplées (par exemple : SOA ) ont créé des complexités supplémentaires avec les tests de performance. Pour répliquer véritablement des états de type production, les services d'entreprise ou les actifs qui partagent une infrastructure ou une plate-forme commune nécessitent des tests de performances coordonnés, tous les consommateurs créant des volumes de transaction de type production et se chargeant sur des infrastructures ou des plates-formes partagées. Étant donné que cette activité est si complexe et coûteuse en argent et en temps, certaines organisations utilisent désormais des outils pour surveiller et simuler des conditions de production (également appelées « bruit ») dans leurs environnements de test de performance ( PTE ) afin de comprendre les besoins en capacité et en ressources et vérifier / valider les attributs qualité.

Horaire

Il est essentiel pour la performance des coûts d'un nouveau système que les efforts de test de performance commencent au début du projet de développement et s'étendent jusqu'au déploiement. Plus un défaut de performance est détecté tardivement, plus le coût de la correction est élevé. C'est vrai dans le cas des tests fonctionnels, mais encore plus avec les tests de performances, en raison de la nature de bout en bout de sa portée. Il est crucial qu'une équipe de test de performance soit impliquée le plus tôt possible, car il faut du temps pour acquérir et préparer l'environnement de test et d'autres conditions de performance clés.

Outils

Les tests de performance sont principalement divisés en deux catégories principales :

Scripts de performances

Cette partie des tests de performances traite principalement de la création/de la scénarisation des flux de travail des principaux processus métier identifiés. Cela peut être fait à l'aide d'une grande variété d'outils.

Chacun des outils mentionnés dans la liste ci-dessus (qui n'est ni exhaustive ni complète) utilise soit un langage de script (C, Java, JS) soit une forme de représentation visuelle (glisser-déposer) pour créer et simuler les flux de travail de l'utilisateur final. La plupart des outils permettent quelque chose appelé "Enregistrer et rejouer", où le testeur de performances lancera l'outil de test, l'accrochera à un navigateur ou à un client lourd et capturera toutes les transactions réseau qui se produisent entre le client et le serveur. Ce faisant, un script est développé qui peut être amélioré/modifié pour émuler divers scénarios commerciaux.

Suivi de la performance

Cela constitue l'autre face des tests de performance. Avec la surveillance des performances, le comportement et les caractéristiques de réponse de l'application testée sont observés. Les paramètres ci-dessous sont généralement surveillés lors de l'exécution d'un test de performance

Paramètres matériels du serveur

  • Utilisation du processeur
  • Utilisation de la mémoire
  • Utilisation du disque
  • L'utilisation du réseau

Dans un premier temps, les motifs générés par ces 4 paramètres fournissent une bonne indication sur l'endroit où se situe le goulot d'étranglement. Pour déterminer la cause exacte du problème, les ingénieurs logiciels utilisent des outils tels que des profileurs pour mesurer quelles parties d'un appareil ou d'un logiciel contribuent le plus aux mauvaises performances, ou pour établir des niveaux de débit (et des seuils) pour maintenir un temps de réponse acceptable.

La technologie

La technologie de test de performance utilise un ou plusieurs PC ou serveurs Unix pour agir en tant qu'injecteurs, chacun émulant la présence d'un nombre d'utilisateurs et chacun exécutant une séquence automatisée d'interactions (enregistrées sous forme de script, ou comme une série de scripts pour émuler différents types d'utilisateurs interaction) avec l'hôte dont les performances sont testées. Habituellement, un PC distinct agit comme un conducteur de test, coordonnant et collectant les métriques de chacun des injecteurs et rassemblant les données de performance à des fins de rapport. La séquence habituelle consiste à augmenter la charge : commencer avec quelques utilisateurs virtuels et augmenter le nombre au fil du temps jusqu'à un maximum prédéterminé. Le résultat du test montre comment les performances varient avec la charge, exprimées en nombre d'utilisateurs par rapport au temps de réponse. Divers outils sont disponibles pour effectuer de tels tests. Les outils de cette catégorie exécutent généralement une suite de tests qui émulent de vrais utilisateurs par rapport au système. Parfois, les résultats peuvent révéler des bizarreries, par exemple, si le temps de réponse moyen peut être acceptable, il existe des valeurs aberrantes de quelques transactions clés qui prennent beaucoup plus de temps à se terminer - quelque chose qui peut être causé par des requêtes de base de données inefficaces, des images, etc.

Les tests de performance peuvent être combinés avec des tests de résistance , afin de voir ce qui se passe lorsqu'une charge acceptable est dépassée. Le système plante-t-il ? Combien de temps faut-il pour récupérer si une charge importante est réduite ? Son échec cause-t-il des dommages collatéraux ?

La modélisation analytique des performances est une méthode pour modéliser le comportement d'un système dans une feuille de calcul. Le modèle est alimenté par des mesures des demandes de ressources de transaction ( CPU , E/S disque, LAN , WAN ), pondérées par le mix de transactions (transactions commerciales par heure). Les demandes de ressources de transaction pondérées sont additionnées pour obtenir les demandes de ressources horaires et divisées par la capacité de ressources horaire pour obtenir les charges de ressources. En utilisant la formule du temps de réponse (R=S/(1-U), R=temps de réponse, S=temps de service, U=charge), les temps de réponse peuvent être calculés et calibrés avec les résultats des tests de performance. La modélisation des performances analytiques permet d'évaluer les options de conception et le dimensionnement du système en fonction de l'utilisation commerciale réelle ou prévue. Il est donc beaucoup plus rapide et moins cher que les tests de performances, bien qu'il nécessite une compréhension approfondie des plates-formes matérielles.

Tâches à entreprendre

Les tâches pour effectuer un tel test comprendraient :

  • Décidez si vous souhaitez utiliser des ressources internes ou externes pour effectuer les tests, en fonction de l'expertise interne (ou de son absence).
  • Recueillir ou obtenir des exigences de performance (spécifications) auprès des utilisateurs et/ou des analystes commerciaux.
  • Développer un haut niveau le plan (ou charte de projet), y compris les besoins, les ressources, les délais et les étapes.
  • Développez un plan de test de performance détaillé (y compris des scénarios et des cas de test détaillés , des charges de travail, des informations sur l'environnement, etc.).
  • Choisissez outil (s) de test .
  • Spécifiez les données de test nécessaires et l'effort de charte (souvent négligé, mais essentiel pour effectuer un test de performance valide).
  • Développer des scripts de validation de principe pour chaque application/composant à tester, en utilisant les outils et stratégies de test choisis.
  • Élaborer un plan de projet de test de performance détaillé, y compris toutes les dépendances et les échéanciers associés.
  • Installer et configurer les injecteurs/contrôleur.
  • Configurer l'environnement de test (matériel idéalement identique à la plate-forme de production), la configuration du routeur, le réseau silencieux (nous ne voulons pas que les résultats soient perturbés par d'autres utilisateurs), le déploiement de l'instrumentation du serveur, les ensembles de test de base de données développés, etc.
  • Exécuter les tests - avant d'exécuter réellement le test de charge avec des utilisateurs prédéfinis, un essai est effectué afin de vérifier l'exactitude du script.
  • Exécutez des tests - probablement à plusieurs reprises (de manière itérative) afin de voir si un facteur non pris en compte pourrait affecter les résultats.
  • Analysez les résultats - soit réussite/échec, soit enquête sur le chemin critique et recommandation de mesures correctives.

Méthodologie

Tester les performances des applications Web

Selon le Microsoft Developer Network, la méthodologie de test de performance comprend les activités suivantes :

  1. Identifiez l'environnement de test. Identifier l' environnement de test physique et l'environnement de production ainsi que les outils et ressources disponibles pour l'équipe de test. L'environnement physique comprend les configurations matérielles, logicielles et réseau. Avoir une compréhension approfondie de l'ensemble de l'environnement de test dès le départ permet une conception et une planification des tests plus efficaces et vous aide à identifier les défis de test au début du projet. Dans certaines situations, ce processus doit être revu périodiquement tout au long du cycle de vie du projet .
  2. Identifier les critères d'acceptation des performances. Identifiez le temps de réponse, le débit et les objectifs et contraintes d'utilisation des ressources. En général, le temps de réponse est une préoccupation de l'utilisateur, le débit est une préoccupation commerciale et l'utilisation des ressources est une préoccupation du système. De plus, identifier les critères de réussite du projet qui peuvent ne pas être pris en compte par ces objectifs et contraintes ; par exemple, utiliser des tests de performances pour évaluer quelle combinaison de paramètres de configuration donnera les caractéristiques de performances les plus souhaitables.
  3. Planifier et concevoir des tests. Identifiez les scénarios clés , déterminez la variabilité entre les utilisateurs représentatifs et comment simuler cette variabilité, définissez les données de test et établissez les métriques à collecter. Consolidez ces informations dans un ou plusieurs modèles d'utilisation du système à mettre en œuvre, à exécuter et à analyser.
  4. Configurez l'environnement de test. Préparez l'environnement de test, les outils et les ressources nécessaires pour exécuter chaque stratégie, à mesure que les fonctionnalités et les composants deviennent disponibles pour le test. Assurez-vous que l'environnement de test est instrumenté pour la surveillance des ressources si nécessaire.
  5. Mettre en œuvre la conception de test. Développer les tests de performance conformément à la conception des tests.
  6. Exécutez le test. Exécutez et surveillez vos tests. Valider les tests, les données de test et la collecte des résultats . Exécutez des tests validés pour l'analyse tout en surveillant le test et l'environnement de test.
  7. Analysez les résultats, ajustez et retestez. Analysez, consolidez et partagez les données de résultats. Faites un changement de réglage et retestez. Comparez les résultats des deux tests. Chaque amélioration apportée renverra une amélioration plus petite que l'amélioration précédente. Quand t'arrêtes-tu ? Lorsque vous atteignez un goulot d'étranglement du processeur, les choix sont alors soit d'améliorer le code, soit d'ajouter plus de processeur.

Voir également