Les tests de performance à l’aide de la roue de Deming ou La démarche PDCA

La roue de Deming est plus communément appelée la démarche PDCA : Plan, Do, Check, Act.

Le but des tests de performance est de trouver les points faibles d’une architecture dans le but de l’améliorer : performance, stabilité sous charge, coût, etc.

On rapproche donc les étapes du PDCA avec un processus de tests de charge :

• Le P (ou plan) a pour but d’établir, préparer et de planifier un plan d’action. Que doivent mesurer, améliorer nos tests pour cette itération.
• Le D (ou do) est la phase de faire, celle où on effectue les tests à proprement parler.
• Le C (ou check) est le moment où l’on vérifie les résultats renvoyés par nos tests. C’est aussi dans cette phase que l’on se préoccupe du rapprochement et de l’agrégation des métriques recueillies dans la phase précédente.
• Le A (ou act) sert à améliorer le système que l’on test. C’est la phase d’optimisation.

Avant de faire des tests

Avant de se lancer dans ce cercle vertueux d’amélioration, il est important de déterminer le but de ces tests.

Est-il de :

• S’assurer qu’un système fonctionne sans erreur sous certaines conditions de charge ?
• S’assurer qu’un système répond aux critères d’acceptabilité des performances ?
• Optimiser les temps de réponse pour augmenter la satisfaction utilisateur ?
• Optimiser les coûts d’infrastructure et du run du système testé ?
• Connaître la capacité du système ?

En fonction des réponses à ces questions, on peut déterminer quel type de tests effectuer.

Type(s) de tests à effectuer

Tests de performance

Objectif : Tester sur un ou plusieurs scénarios sous une charge modérée du système complet et/ou d’un sous système nécessitant un point d’attention.

Exemple : La souscription est testée pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps

passé dans les différents composants de l’application.

Test de vieillissement

Objectif : Déterminer la capacité de l’application à fonctionner sur une période étendue.

Exemple : On simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge Moyenne.

Test de charge

Objectif : Mesurer la tenue en charge de l’application sur la population cible.

Exemple : On simule l’utilisation de l’application par 200 utilisateurs (avec des scénarios différents) en parallèle pendant 2h.

Test de rupture / Stress test

Objectif : Déterminer les limites de l’application

Exemple : On augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables.

Une fois choisis le ou les types de tests à effectuer, il faut déterminer les profils de charge des tests. C’est-à-dire les scénarios à tester, ainsi que leur typologie.

Choix des scénarios

Le choix des scénarios doit être fait en prenant en compte :

Que veux-t-on tester ? Quelles fonctionnalités ? Ex : Le tunnel de paiement d’un site d’e-commerce.

Quels scénarios utilisateurs ? Ex : Mes utilisateurs s’enregistrent sur mon site, ils passent 10 secondes sur la page d’inscription, etc.

Qu’est-ce que les utilisateurs utilisent à l’heure actuelle sur le système ? Comment l’utilisent-ils ? Exemple : Mes utilisateurs ont un think-time (temps passé entre deux actions d’un utilisateur) de 15 secondes sur la page de login.

Est-ce que l’utilisation de certaines fonctionnalités va augmenter dans un proche futur (action marketing, publicité, montée en charge, etc.) ? Exemple : Le marketing va lancer une grande campagne sur le parrainage de ma banque.

Choix des métriques

La dernière étape est de décider quelles métriques mesurer et celles que l’on veut améliorer. Il faut garder à l’esprit que trop de métriques tue les métriques. En effet, si on regarde trop de données, on risque de perdre de vue le but de notre campagne de tests. De plus, il faut séparer les métriques « business » qui sont celles à améliorer, et les métriques techniques qui vont nous permettre d’investiguer a posteriori les points de contentions de notre système.

Les métriques les plus classiques sont :

L’intégration des métriques est un point critique de la démarche d’amélioration des performances.

Il est aussi intéressant de calculer l’écart type, qui va nous donner comment les valeurs sont réparties autour de la moyenne. Plus cette valeur est petite plus les données sont uniformes (proche de la moyenne).

Préparation de la campagne de tests

Une fois toutes ses données intégrées, il faut préparer la campagne de tests. Tout d’abord il faut choisir les outils pour :

Il est important de pouvoir mettre en relation les données envoyées par l’injecteur et les sondes, ce qui va permettre de relever rapidement les relations entre les données remontées et les actions faites par l’injecteur.

De même, il faut générer un rapport, à l’usage des non-experts, à partir des métriques.

Ainsi, avant de commencer toute campagne de test, il est important d’automatiser au maximum toute la chaîne des tests. Le but ultime étant que toute la chaîne test + agrégation + génération du rapport se fasse automatiquement.

Il faut néanmoins raccourcir au maximum la phase entre la fin des tests et la génération du rapport, ce qui permet de faire une modification rapidement pour relancer des tests le plus vite possible.

Établir une mesure de référence (Plan du PDCA)

La première étape d’une itération de test de performance est de savoir où l’on veut aller. Cette étape doit nous garantir que 2 tests consécutifs sans modification doivent avoir des résultats équivalents.

Si cette itération est la première, elle va servir de référence pour toutes les itérations suivantes, c’est le point de départ de notre système. Il est même préférable de faire quelques itérations de « rodages », donc sans amélioration du système à tester, mais uniquement pour effectuer des améliorations sur le processus de tests.

Dans un cas idéal, on peut réaliser plusieurs itérations de constructions de la démarche de tests, avec la méthode des petits pas.

Exécuter les tests (Do du PDCA)

La phase d’exécution des tests de performance est l’étape que l’on pense naturellement à automatiser. Il est en effet peu envisageable de réaliser un test de charge manuellement.

Même s’il est possible de réaliser un test d’optimisation unitaire manuellement, l’automatisation permettra de :

• Fiabiliser le résultat obtenu
• Accélérer l’exécution des tests
• Exécuter les tests régulièrement dans une intégration continue (Ceux-ci permettent d’assurer la non-regression de la performance du système testé)

Afin de fiabiliser le résultat des tests et de s’assurer qu’ils sont exécutés dans les mêmes conditions à chaque fois, la phase d’initialisation de l’environnement testé gagnera à être automatisée. En effet, réalisées manuellement, les étapes d’initialisation peuvent devenir rapidement fastidieuses (initialiser la base de données, vider les caches, purger les files de messages, …) et sujettes à erreurs et/ou oublis faussant ainsi les résultats.

De plus, l’environnement de tests doit être entièrement dédié pour garantir la stabilité des tests.

Recueillir et analyser les mesures de performance (Check duPDCA)

Le recueil des métriques

Une fois les tests exécutés, les métriques doivent être recueillis à la fois côté injecteur mais aussi sur le système testé.

Cette phase peut être manuelle ou automatique.

Tout dépend de la complexité du système testé : si vous n’avez qu’un seul serveur d’application, une base de données, les métriques pourront être exploitées en allant voir chacun des outils de collecte des métriques ; l’agrégation automatique des métriques de chacun des sous-systèmes devient nécessaire pour ne pas perdre son temps à collecter ces ressources.

Tracer les résultats des tests de performance

Cette traçabilité permettra d’identifier les différences et de comprendre l’origine des résultats constatés.

Analyse des mesures de performance

Il est nécessaire de présenter de façon concise et compréhensible les mesures recueillies. Sans ce type de communication, l’effort de test de performance risque de ne pas être reconnu à sa juste valeur.

Les outils de test de performance éditeur, sont souvent complétés par des outils de reporting offrant une représentation graphique des mesures de performance. Sans ces derniers, l’utilisation d’Excel est possible malgré une exploitation plus manuelle.

Optimiser le système (Act du PDCA)

Chaque modification ayant pour objectif d’améliorer les performances ou ayant un potentiel impact sur les performances (tuning DB, VM, …) doit être testé pour au moins confirmer que ces modifications n’ont pas un impact négatif (non-assumé) sur les temps de réponse du système.

Il est à noter que toutes les optimisations ne valent pas le coût d’être entreprises (Constant Tweak Syndrome). En effet, il y aura toujours des optimisations possibles, mais si celles-ci n’ont pas d’impact réel sur le système ou si elles coûtent plus à implémenter que la valeur qu’elles pourraient apporter, il est nécessaire de savoir se poser la question sur leur utilité.

La place de la qualité

L’importance de l’utilisateur

L’utilisateur, autrefois cantonné au rôle de simple usager des solutions de gestion, est aujourd’hui un maillon important de tout projet ERP.

Plus au fait des innovations technologiques et connecté en permanence à des applications et logiciels tiers, l’utilisateur est devenu prescripteur et son expérience influe sur le degré d’adoption d’un nouvel outil.

Les principaux indicateurs de performance vue par l’utilisateur sont :

• Le temps requis pour effectuer une tâche ou un ensemble de taches
• Nombre d’erreurs par la tache

 

 

Dans le domaine du logiciel, satisfaire les besoins de l’utilisateur suppose une démarche qualité qui prenne en compte :

• La qualité de son processus de développement (coûts, délais, méthodes, organisation, personnel,
• techniques, outils)
• La qualité intrinsèque du produit (modularité, simplicité, …)
• La qualité du service fourni par le logiciel en exploitation.

La qualité du processus de développement est basée sur l’utilisation de méthodes de développement et de gestion de projet généralement définies dans le Manuel Qualité de l’entreprise rédigé au cours de la mise en place d’une politique d’assurance qualité.

L’évaluation de la qualité intrinsèque du logiciel est effectuée sur le produit en développement en fonction des facteurs de qualité attendus, définis lors de la commande (spécifications).

Celle du service porte sur le logiciel en exploitation chez l’utilisateur (ou client) et consiste notamment à vérifier son adéquation aux exigences spécifiées.

La qualité

Les principaux facteurs de qualité d’un logiciel sont la conformité aux besoins, la fiabilité, l’ergonomie (dont la facilité d’emploi), la flexibilité, la maintenabilité, l’intégrité et la disponibilité. Au vu de son utilisateur, un logiciel de qualité doit donc présenter ces caractéristiques sans que son efficacité, ses performances (temps de réponse, place mémoire minimum, …) en pâtissent.

Ce sont des facteurs que l’on retrouve notamment dans la norme ISO 9126. Cette norme ISO 9126 (« Technologies de l’Information : Qualités des produits logiciels ») définit un ensemble d’indicateurs pour la qualité logicielle, et « facilite » ainsi le processus d’évaluation logiciel et la spécification d’exigences fonctionnelles ou non-fonctionnelles.

Cette norme est en application depuis 1992. Elle définit 6 caractéristiques permettant de décrire la qualité du logiciel, elles-mêmes détaillées en sous caractéristiques.

Capacité fonctionnelle

Il s’agit d’un ensemble d’attributs permettant de vérifier si le logiciel répond aux besoins fonctionnels exprimés. On y retrouve notamment les notions de pertinence, d’exactitude, d’interopérabilité, de sécurité et de conformité.

Fiabilité

Il s’agit ici de décrire les attributs permettant d’évaluer l’aptitude d’un système à maintenir son niveau de service : tolérance aux pannes, conditions de remise en service, maturité…

Facilité d’utilisation

On retrouve dans cette caractéristique un ensemble d’attributs permettant de caractériser l’effort nécessaire à un utilisateur potentiel pour utiliser le système : facilité de compréhension, d’apprentissage, d’exploitation ou encore pouvoir d’attraction.

Rendement ou efficacité

Elle permet de qualifier le rapport entre le service rendu par le logiciel et les efforts qu’il faut entreprendre pour le faire fonctionner (quantité de ressources utilisées notamment).

Maintenabilité

Il s’agit ici d’évaluer les possibilités de faire évoluer le système dans le cas de nouveaux besoins : facilité d’analyse, de modification, stabilité et testabilité de la solution.

Portabilité

Cette caractéristique décrit la possibilité de transférer le logiciel d’une plateforme à une autre, et les efforts nécessaires pour le faire : facilité d’adaptation et d’installation, coexistence, interchangeabilité.

L’assurance qualité

Une assurance qualité peut également garantir auprès de l’utilisateur une meilleure appréciation du logiciel.

L’assurance qualité est définit comme l’ensemble des mesures, procédures, méthodes utilisées dans le cadre du processus de développement du logiciel afin d’obtenir le niveau de qualité souhaitée. La mise en œuvre d’une politique d’assurance qualité passe par la rédaction d’un Manuel Qualité présentant toutes les procédures qui pourront (devront) être utilisées dans le cadre d l’activité informatique de l’entreprise.

Les outils de test

L’impact de la performance

La performance d’un logiciel, d’une application affecte l’entreprise. Les meilleures organisations d’ingénieries ne considèrent pas la performance comme quelque chose d’acquis mais comme une caractéristique cruciale de leur produit. La performance a un impact direct sur l’expérience de l’utilisateur et en fin de compte sur leurs résultats. Malheureusement, la plupart des équipes d’ingénieries ne teste pas régulièrement la performance et l’extensibilité de leur infrastructure.

Il existe quelques statistiques sur l’impact commercial de la performance, comme par exemple, chez les principales entreprises sur Internet :

• Amazon et Walmart a augmenté le revenu de 1% pour chaque 100 millisecondes d’amélioration
• Microsoft a constaté que les recherches avec Bing qui étaient deux secondes plus lentes peuvent entrainer une perte de 4.3% des revenus par utilisateur
• Lorsque Mozilla gagne 2.2 secondes sur leur page d’accueil, Firefox voit une augmentation de 15.4% de ses téléchargements (60 million de téléchargements en plus)
• Quand on a rendu le site de Barack Obama 60% plus rapide, la conversion en donsa augmenté par 14% (30 millions de dollars en plus)
• Shopzilla a accéléré le temps moyen de chargement de page de 6 secondes à 1.2 secondes, et a augmenté ses revenu s de 12% et les vues de page de 25%

L’impact commercial de la performance peut être très élevé.

Les outils de test de performance

Les outils de test de performance surveillent et rapportent sur la façon dont se comporte un système selon une grande variété de conditions d’usage simulées en termes de nombre d’utilisateurs simultanés, de leur modèle de montée en charge, de fréquence et de pourcentage relatif de transactions. La simulation de la charge est réalisée au moyen de la création d’utilisateurs virtuels effectuant un ensemble choisi de transactions diffusées à travers diverses machines de test identifiés comme injecteurs de charge. Il possède généralement deux composantes principales :

• La génération de charge qui peut simuler soit de multiples utilisateurs, soit de larges volumes de données d’entrée
• La mesure des transactions de tests : Pendant l’exécution, la mesure des temps de réponse est effectuée pour certaines transactions et ces informations sont stockées. Les outils de test de performances fournissent normalement des rapports basés sur les informations de mesure stockées, et des graphiques de charge par rapport au temps de réponse.

Ainsi les outils de surveillance analysent continuellement, vérifient et rendent compte de l’utilisation de ressources systèmes spécifiques, et donnent des alertes sur de possibles problèmes de service.

Il est à noter que les performances peuvent être moindre quand un outil de test est utilisé (effet de sonde)

Annexe

Définitions :

Rendement : la capacité du produit logiciel à fournir des performances appropriées, relatives au niveau de ressources utilisées dans des conditions spécifiées. [ISO 9126]

Performance : degré en fonction duquel le système ou composant accomplit les fonctions qui lui sont affectées dans le respect de contraintes données en ce qui concerne son temps d’exécution et taux de débit. [D’après IEEE 610]

Indicateur de performance : une métrique de haut niveau de rentabilité et/ou d’efficacité utilisé pour guider et contrôler le développement progressif, p.ex. Pourcentage de Détection des défauts (DDP) pour les tests [CMMI]

Profilage des performances : La tâche d’analyser, par exemple, en identifiant les goulots d’étranglement des performances sur la base de métriques générées, et en réglant la performance d’un composant logiciel ou d’un système en utilisant des outils.

Définition des profils d‘utilisateurs pour le test de performance, de charge ou de stress. Les profils devraient refléter l‘usage attendu ou réel, basé sur le profil opérationnel d‘un composant ou système, et par conséquent la charge de travail attendue.

Récupérabilité : capacité d’un produit logiciel à rétablir un niveau de performances spécifié et récupérer les données directement affectées en cas de défaillance [ISO 9126]

Niveau d’intégrité logicielle : Le degré auquel un logiciel est conforme ou doit être conforme à un ensemble de caractéristiques logicielles choisies par des parties prenantes et/ou à un ensemble de caractéristiques logicielles système (par exemple la complexité logicielle, l’évaluation du risque, le niveau de sûreté, le niveau de sécurité, la performance désirée, la fiabilité ou le coût) qui sont définies Version 2.2F Page 61 de 94 9 Août 2012 © 2006 CFTL + International Software Testing Qualifications Board en vue de refléter l’importance du logiciel pour ses parties prenantes.

Effet de sonde : l’effet sur le composant ou le système quand il est mesuré (ex. par un moniteur ou un outil de test de performances). Les performances peuvent être moindres quand un outil de test est utilisé.

Liens :

https://fr.wikipedia.org/wiki/Test_de_performance

ISTQB Glossary 27/77

http://www.cftl.fr/wp-content/uploads/2015/03/Glossaire-des-tests-de-logiciel-2-2-F-P1.pdf

The art of application performance testing – Ian Molineaux (pdf)

Doc Insee : page 32 Dans définition : Il faut retenir que ce test vérifie le comportement entre ?) 3.5.2. : Deuxième paragraphe du cadre : manque « l » le recueil.

Les différents outils de test de performance :

HP :Loadrunner 12.50,StormRunner Load ,HP Performance Center ,Network Virtualization

PYLOT ,Multi-Mechanize ,Tsung ,Apache JMeter ,WCat (Web Capacity Analysis

Tool) ,AB ,http_load ,Web Polygraph ,Fwptt ,Curl-Loader ,Selenium ,Microsoft AZURE

Applause ,Silk Performer, Dynatrace load testing web, WebLOAD, LoadUI NG Pro,Apica

LoadTest, RationalPerformanceTester, NeoLoad, LoadComplete,WAPT, Loadster,

LoadImpact, Testing Anywhere, Appvance UTP,OpenSTA,QEngine (ManageEngine)

Loadstorm,SOASTA CloudTest

Httperf,Neotys / néoload