Tests de performances

Que sont les tests de performance ?

Le test de performance (PT) est un ensemble de pratiques de test qui permet de s'assurer que les utilisateurs peuvent utiliser la solution fournie sans éprouver trop de frustration, quelle que soit la masse d'utilisateurs simultanés (voir aussi " Indice de performance des applications " - APDEX). PT est un terme générique qui inclut tout type de test axé sur la réactivité du système ou du composant sous différents volumes de charge [ISTQB 2018-1].

Voici quelques types de PT [ISO25010] [Molyneaux 2014] [ISTQB 2018-1] [Meier 2007] :

• Test du temps de réponse - à quelle vitesse le système sous test (SUT) répond-il , c'est-à-dire la capacité d'un composant ou d'un système à répondre aux entrées de l'utilisateur ou du système dans un délai et des conditions spécifiés [ISTQB 2018-2]. Ce critère de performance est souvent utilisé comme un SLA. 
• Test des volumes

• Utilisation des ressources: comment les ressources sont utilisées lorsqu'elles atteignent la charge standard afin de diagnostiquer où/quoi optimiser/supprimer les goulets d'étranglement tels que l'utilisation de l'unité centrale, de la mémoire/du stockage/du réseau (en particulier lorsque les données sont chargées) ou la consommation de la batterie sur les mobiles.
• Capacité : comment le service se comporte-t-il lorsqu'il est submergé par les demandes. Ce test permet d'identifier la limite de charge du système à partir de laquelle il ne sera pas disponible pour toutes les requêtes - détermine le nombre d'utilisateurs et/ou de transactions qu'un système donné pourra prendre en charge tout en respectant les objectifs de performance fixés
• Débit: combien de transactions peuvent être traitées en même temps ?
• Test d'endurance: (alias "Soak" ou test de stabilité) - comment le SUT se comporte lorsqu'il est exposé à une charge pendant une période prolongée.

• Test des limites

• Stress testing: vise à atteindre le seuil au-delà duquel le système ou une partie de celui-ci s'effondrerait et à voir comment il gère les pics de charge autour de limites connues - en termes de Panarchie, cela signifie "atteindre l'état Ω et voir son impact sur les écocycles liés".
• Test de concomitance: comment le système gère les situations où des actions spécifiques se produisent simultanément à partir de différents côtés.
• Essai de pointe: comment le système réagit à de brusques pics de charge et revient ensuite à un état stable.
• Test d'évolutivité: comment le système peut croître et s'adapter à une demande croissante sans réduire les performances jusqu'à ce que les limites soient atteintes - ces limites sont alors traitées par des mécanismes d'alerte et améliorées pour répondre aux besoins de disponibilité.

• Techniques de diagnostic :

• Test de fumée : PT axé sur ce qui a été modifié depuis la dernière version.
• Test d'isolement: utilisé pour localiser un problème identifié.
• Les tests detype "pipe-clean": la vitesse de réaction d'un cas d'utilisation commerciale sans autre activité pour obtenir une base de référence - cette approche est la base de l'analyse comparative [Meier 2007] et de la comparaison avec d'autres conceptions ou concurrents.

La combinaison de ces techniques d'essai permet au système d'évoluer.

À titre d'exemple, l'approche typique pour réaliser des tests de performance serait [Molyneaux 2014] :

• Étape 1 : Capture des exigences non fonctionnelles
• Étape 2 : Construction de l'environnement de test de performance
• Étape 3 : Scripting de cas d'utilisation : scénario
• Étape 4 : Construction du scénario de test de performance
• Étape 5 : Exécution et analyse des tests de performance
• Étape 6 : Analyse post-test et rapport

Étape 1 : Capture des exigences non fonctionnelles

Selon le principe "Les tests dépendent du contexte" [ISTQB 2018-1], le contexte de la solution à fournir est extrêmement important. Pour cette raison, vous devez connaître des éléments tels que [Molyneaux 2014].

• Combien d'utilisateurs utiliseront l'application ?
• Où sont situés ces utilisateurs ?
• Combien de personnes utiliseront votre produit en même temps ?
• Comment se connecteront-ils à l'application ?
• Comment vos utilisateurs vont-ils évoluer dans le temps ?
• Quelle sera l'architecture finale du réseau ?
• Quel effet l'application aura-t-elle sur la capacité du réseau ?
• Quelles sont les attentes à l'égard du produit ?
• Que devrions-nous construire pour mesurer cela ?
• Quel cas d'utilisation devrait être touché par le PT ?
• Quels sont les objectifs de performance ?
• Quel est le modèle de charge ?
• Quelles sont les organisations, les compétences et les outils de test nécessaires pour atteindre les objectifs ?

Négliger l'une de ces questions aura un impact drastique sur l'ensemble de tests et la fiabilité du produit. En fait, la performance est une"Architecturally Significant Requirement" (ASR) [ASR 2021] [Chen 2013] [Moustier 2019-1]. Elle figure parmi les plus grands catalyseurs de changement d'architecture [Meier 2007] ; c'est pourquoi la PT doit arriver le plus tôt possible dans le SDLC [Singh 2021] car, comme pour toute ASR, plus vous la découvrez tard, plus le coût et l'effort auxquels vous serez confronté seront importants [Molyneaux 2014].

Étape 2 : Construction de l'environnement de test de performance

Voici un exemple d'architecture classique pour PT :

‍

En ce qui concerne les nombreux environnements, il existe des différences naturelles sur le réseau parce que le LAN se comporte différemment du WAN ; alors que le temps de réponse peut avoir de plus grandes variations sur le WAN, le LAN sera plus rapide et donc il n'est pas représentatif de l'expérience réelle de l'utilisateur. C'est pourquoi il est nécessaire d'impliquer différents modèles de réseau, notamment en fournissant des injecteurs de charge à distance ou en simulant des retards sur certains backends [Molyneaux 2014]. Une attention particulière doit être portée au contexte de sécurité organisationnelle qui peut empêcher l'installation de certains outils et cette question informatique doit être prise en compte lors de la conception.

En ce qui concerne les données de test, gardez à l'esprit qu'elles doivent reproduire la vie réelle. Par conséquent, la fréquence des cas d'utilisation testés doit être modélisée pour générer ensuite l'ensemble de données de test. De plus, la base de données de test doit être significativement chargée en données pour refléter les comportements de stockage en production. Ensuite, une fois le scénario de test terminé, la base de données doit être restaurée à son état précédent pour faciliter les reprises. Les données jointes pourraient alors être migrées depuis la production avec les mises à jour nécessaires dues à la nouvelle version, et finalement anonymisées pour se conformer aux contraintes du GDPR [Molyneaux 2014].

En ce qui concerne le ressuage, il semble que plus l'environnement est proche de la production, plus les mesures seront significatives ; malheureusement, ce n'est pas toujours possible pour des raisons de coût et aussi si des tiers sont impliqués. En fait, il existe des alternatives aux copies exactes de l'environnement de production [Molyneaux 2014], notamment avec un sous-ensemble de l'environnement de production avec moins de pièces ou des pièces plus petites et toutes les pièces attendues et essayer une certaine extrapolation pour imaginer la capacité du système.

Étape 3 : Scripting de cas d'utilisation

Pour être significatif, le ressuage doit être appliqué aux scénarios d'entreprise. Cependant, étant donné que le ressuage implique des efforts et des délais importants, seuls les cas d'utilisation ou les parties critiques pour l'entreprise doivent être considérés avec le ressuage. Dans ces cas d'utilisation, les exigences en matière de données de session, les entrées et les points de contrôle doivent ensuite être définis. 

À cette étape, les parties surveillées doivent être séparées des parties non significatives du scénario du cas d'utilisation, de sorte que l'analyse de premier niveau des zones problématiques potentielles du cas d'utilisation soit fournie dès qu'elles sont disponibles.

Les scripts doivent ensuite être testés pour des utilisateurs uniques et multiples. Des journaux appropriés et des mesures de performance doivent être générés pour permettre des analyses futures.

Étape 4 : Construction du scénario de test de performance

Une fois les scripts disponibles, il faut organiser la session de test de performance, notamment en ce qui concerne le contexte du produit. Par exemple, avant d'exécuter chaque scénario, vous pouvez lancer un test "pipe-clean" pour établir une base de référence ou passer directement au cas le plus critique si le temps presse !

À partir du scénario de test de performance, le modèle de charge doit également être défini de sorte que les injecteurs de charge stimulent le SUT comme il serait utilisé en production, ce qui inclut notamment

• quand / à quelle fréquence les utilisateurs stimulent-ils le SUT ?
• que font-ils ?
• quel est le poids des données qu'ils utilisent ?
• comment les injecteurs doivent être lancés contre le SUT ? Big bang ? Linéairement ? De manière exponentielle ? Dans une courbe de type Gauss ? Y a-t-il des étapes dans la progression ?

‍

Quel que soit votre modèle de charge, il devrait vous aider à atteindre vos objectifs en matière de SLA [Molyneaux 2014].

Il convient d'accorder une attention particulière aux ensembles de données qui ne peuvent être utilisés qu'une seule fois ou qui sont sensibles au temps pour permettre leur relecture. Cela peut vous amener à générer des données de test [Meier 2007].

Étape 5 : Exécution et analyse des tests de performance

Puisque cette étape est cruciale, en termes de résultats et de temps, elle doit se dérouler de manière simple plutôt que d'être un exercice de correction de bug[Molyneaux 2014]. C'est pourquoi vous devez vous assurer que 

• l'application est prête, au moins sur les cas d'utilisation testés
• les scripts sont robustes et fonctionnent parfaitement jusqu'à la fin du scénario.
• rien n'a été omis dans la configuration qui pourrait faire échouer la session de PT
• idéalement, réinitialiser la base de données entre les sessions de ressuage pour récupérer des mesures aussi proches que possible de la ligne de base.

Étape 6 : Analyse post-test et rapport

Comme pour toute activité de test, les hypothèses formulées par rapport aux objectifs peuvent être vérifiées ou rejetées à partir des données collectées. À partir des résultats, une analyse des causes profondes devrait vous aider à fournir les améliorations de performance appropriées.

L'analyse peut être facilitée par des capteurs insérés tels que des extraits de code JavaScript qui permettraient de suivre les appels ou même d'utiliser des outils de profilage de code pour isoler les problèmes de performance.

Impact sur la maturité des tests

Dans un environnement de type chute d'eau, il est crucial de prévoir suffisamment [Molyneaux 2014].

• Délai de préparation de l'environnement de test
• Lead time to provision sufficient load injectors - le tir peut durer plusieurs heures
• Temps pour identifier et rédiger les cas d'utilisation
• Temps nécessaire pour identifier et créer suffisamment de données d'essai
• Temps pour instrumenter l'environnement de test
• Temps pour traiter les problèmes identifiés

Tout ce temps requis génère inévitablement un besoin de gel du code [Molyneaux 2014], ce qui signifie que le flux doit être arrêté, ce qui est un problème dans l'esprit agile et génère un "mur de confusion" [Kawaguchi 2020] et une compréhension profonde de la théorie des contraintes pour gérer de tels goulots d'étranglement, à moins que vous ne le fassiez à la manière agile...

Pour avoir un indice sur la façon dont le PT pourrait se produire dans une configuration agile, nous devons nous en tenir à Takeuchi & Nonaka [Nonaka 1986] [Moustier 2019-1] :

• Les entreprises detype A, comme la NASA, qui divisent le travail en phases bien définies et ne passent pas à la phase suivante tant que la précédente n'est pas terminée. C'est du pur gatekeeping. Cette approche permet une session de PT "sans faille" à partir d'un gel du code.
• Les entreprises detype B, où les phases se chevauchent légèrement, sur la base de l'observation qu'il est concevable, par exemple, de commencer à préparer la session de PT lorsque 80% du code a été réalisé.
• et les entreprises de type C où tout se fait en même temps, comme dans une mêlée de rugby.

‍

Pour atteindre une organisation de type C, les choses doivent être pensées dans une démarche inclusive, progressive et itérative. Par exemple les données utilisées pour les tests qui sont extraites de la production doivent être migrées, la migration des données fait donc partie du codage d'un US/Feature [Moustier 2019-1].

L'une des contraintes qui empêche la PT d'atteindre la configuration de type C est lorsque la PT est détenue par des équipes indépendantes des équipes de développement. Ce service de PT interne est un cas traité notamment par le modèle Agile@Scale [Sutherland 2019] qui conduit à une approche par étapes qui ramène à un type B ou même A si les managers ne soutiennent pas une migration progressive des compétences de PT détenues au sein du service de PT à travers l'organisation pour faciliter le déplacement vers la gauche. Cet objectif peut être atteint lorsque l'EA est envisagé à trois niveaux [Singh 2021] :

• Niveau du code
• Nouvelles fonctionnalités
• Niveau du système

Le "niveau Code" traite de :

• Évaluation de la complexité et de l'efficacité des algorithmes
• Evaluer la performance du code notamment grâce aux outils de profilage du code - ceci anticipe la 6ème étape
• Optimiser les requêtes SQL [Yevtushenko 2019][Iheagwara 2021] ou toute autre technique d'optimisation dépendant de la technologie qui permettrait de réduire le temps passé sur certaines opérations.

Le PT au "New features level" consiste notamment à rechercher des performances relatives plutôt que des valeurs absolues. Tant que les tests sont reproductibles avec des résultats statistiquement identiques [ISTQB 2018-1], il existe une base de référence à partir de laquelle des mesures comparatives peuvent être déduites. Dans cette situation, les " pipe-clean test " sont les plus utiles pour obtenir une ligne de base et surveiller la dégradation des performances due au nouveau code [Gordon 2021] [Singh 2021].

PT au "niveau du système" peut être atteint par :

• jouer avec le flux de branches SCM pour assurer des "tests unitaires de performance" (tests d'isolation) sur une base régulière [Gordon 2021] [Singh 2021] et effectuer un PT de bout en bout (E2E) tout en fusionnant à une branche de libération
• Améliorer les tests unitaires de performance en associant des testeurs de performance à des développeurs [Meier 2007].
• Surveillance des tendances d'utilisation des ressources et des temps de réponse [Meier 2007].
• Collecte de données pour la planification de l'évolutivité et de la capacité [Meier 2007].
• Traiter la performance avec des objectifs progressifs lorsque c'est possible [Moustier 2019-1] en séparant les exigences des objectifs intermédiaires qui peuvent provenir de différents points de vue, principalement des utilisateurs, de l'entreprise, du côté technique, des normes, de la conformité et des contrats [Meier 2007].
• Limitation de l'E2E PT aux processus métier les plus critiques selon le modèle du fromage suisse lorsqu'on essaie de multiplier les types de tests sur la solution.

Cela peut être facilité au moment de la planification [Singh 2021] en développant un plan de test de performance à partir d'un US contenu notamment avec des critères d'acceptation de performance. Les réunions de raffinement et la planification du sprint devraient inclure les "quadrants de test agiles" [Marick 2003][Bach 2014][Crispin 2021] pour aborder ces trois niveaux de PT. La planification du sprint devrait également inclure des pics/éléments facilitateurs pour mettre à jour petit à petit l'environnement de PT qui permet réellement le PT. N'oubliez pas qu'il faut du temps pour que les environnements de test fonctionnent correctement et reflètent des tests réalistes [Meier 2007]. Lorsque les pratiques d'EA sont fermement intégrées dans l'organisation, elles peuvent faire partie du DoD [Gordon 2021].

Pour améliorer les tests de performance, vous pouvez également introduire une approche structurée et automatisée où les tests de performance sont dérivés de représentations de modèles abstraits du système. Cette approche de Model-Based Testing (MBT) [Armholt 2011] [Da Silveira 2011] permettrait de tirer parti de l'effort de conception des tests de performance [Abbors 2010].

Quelles que soient les pratiques, il apparaît que les scripts SUT et PT doivent être solides comme le roc pour supporter des centaines de lancements. Comme en musique, de nombreuses répétitions assureront une bonne fiabilité de l'environnement de test, des données de test, des scénarios de PT et de la capture des métriques. Pour cela, l'approche itérative agile sur les cas d'utilisation métier est d'une grande aide car elle devrait vous fournir de nombreuses occasions d'affiner votre PT tout en effectuant des tests de régression de performance en même temps. Une approche complémentaire pour renforcer la robustesse du PT est d'introduire Jidoka dans vos scripts de PT afin qu'ils soient capables de faire face aux exceptions connues et aux comportements inattendus sans interrompre l'exécution des scripts.

Si l'effet big bang peut être évité au stade du déploiement, les techniques de Shift Right peuvent être utilisées par le biais de capteurs qui équiperaient le système afin de fournir des mesures de performance. En combinaison avec Canary Releasing et de petits cycles de livraison, les utilisateurs réels fourniront des mesures de performance et des problèmes sans perturber l'ensemble des clients. Vous pouvez également perturber volontairement l'environnement du produit localement avec une charge artificielle et voir comment l'infrastructure s'adapterait aux situations de charge. Cette approche est parfois appelée "Exploratory Stress Testing" qui consiste à soumettre un système ou une partie de celui-ci à un ensemble de conditions inhabituelles qui ont peu de chances de se produire [Meier 2007] ; cette stratégie est plus souvent connue sous le nom de "Chaos Engineering". Cette stratégie d'ingénierie du chaos repose essentiellement sur des injecteurs de charge programmables pour assurer une surveillance active.

La surveillance passive peut également être utilisée pour analyser le trafic des véritables utilisateurs à l'aide de l'automatisation des observables (par exemple, un tag JS sur une page qui est exécuté à partir du navigateur du visiteur, permettant la capture des événements de l'utilisateur/souris, au niveau de l'API ou de l'adresse IP). Ces observables indiquent où effectuer le PT mais aident également Andon à enregistrer le parcours des clients dans le produit proposé et à modéliser les éventuels injecteurs de charge. Les approches actives et passives doivent être combinées pour trianguler les résultats. La surveillance passive est effectuée avec des outils APM qui fournissent des outils de surveillance sur étagère.

Le point de vue d'Agilitest sur cette pratique

La gestion du PT va inévitablement de pair avec les outils, car il est impossible d'engager des centaines de personnes et de les laisser travailler 24 heures d'affilée selon un modèle de charge. Même si Agilitest peut être utilisé pour mettre en œuvre un outil maison pour les tests de performance avec des observables codés en dur dans le produit pour suivre précisément quand les actions sont déclenchées pendant l'exécution d'un cas d'entreprise, ce n'est pas une option durable car elle a un impact sur le code de production et la charge de travail des développeurs. C'est pourquoi un connecteur a été construit entre Agilitest et Octoperf pour faciliter le PT.

En matière de PT mobile, il est possible de faire une combinaison simple :

• Agilitest est capable de piloter des scripts de test automatisés sur des mobiles, aussi bien Android qu'Apple.
• Des outils tels que Greenspector sont capables de mesurer la consommation d'énergie sur un mobile

Ces deux outils pourraient alors être utilisés conjointement pour mesurer le degré de sécurité, sur le plan énergétique, d'une application mobile.

De plus, lorsqu'il s'agit de PT avec des processus d'affaires de bout en bout et complexes, le processus doit être robuste pour supporter les nombreuses situations déduites par l'ensemble des données. Agilitest fournit des moyens simples pour automatiser ces contrôles avec une approche basée sur les données.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍