Whitepaper
Guide pratique des tests de performance

Introduction aux tests de performance

Les applications sont de plus en plus complexes avec des cycles de développement de plus en plus courts qui nécessitent de nouvelles méthodes efficaces de test et de développement. Les performances d’une application en termes d’expérience globale de l’utilisateur constituent désormais le facteur clé de la qualité d’une application.

Les projets séquentiels traditionnels avec des phases statiques de qualification/implémentation/test qui repoussent les tests de performance à la fin du projet présentent un risque de performance. Ce risque n’est plus acceptable au vu des normes de qualité d’aujourd’hui des applications. Ce livre blanc fournit des informations pratiques sur la façon d’exécuter des tests de performance efficaces dans ce nouvel environnement plus exigeant.

Name
Guide pratique du test des tests de performance
Type

État de complexité des applications modernes

 

L’un des principaux moteurs de l’évolution actuelle vers des tests de charge modernes est la complexité croissante du paysage informatique :

  • La plupart des utilisateurs utilisent des appareils mobiles, des clients légers, des tablettes ou d’autres appareils pour accéder aux informations
  • Des applications complexes, partagées par plusieurs applications à la fois, sont créées régulièrement
  • Les nouvelles technologies offrent une gamme de solutions (cadre d’application AJAX, RIA, WebSocket, etc.) qui améliorent l’expérience utilisateur dans les applications.

Traditionnellement, vous testiez les applications pour valider leur qualité dans plusieurs domaines : fonctionnel, performance, sécurité, etc. Ces phases de test répondent aux exigences des utilisateurs et aux risques de l’activité.

Toutefois, le discours a changé ; la discussion ne porte plus sur la qualité, mais sur l’expérience utilisateur. L’expérience utilisateur est une combinaison d’apparence et de ressenti, de stabilité, de sécurité et de performance.

Performances : essentielles à la garantie d’une expérience utilisateur réussie

 

Les performances sont un facteur clé d’une expérience utilisateur réussie. Cela est dû aux progrès technologiques, à la complexité de l’architecture et aux emplacements et réseaux des utilisateurs. Les tests de charge ont été un ajout judicieux au processus de développement. Ils sont d’ailleurs maintenant devenus une étape essentielle des tests.

Les tests de charge et de performance répondent aux questions suivantes :

  • L’application est-elle capable de gérer un certain nombre d’utilisateurs simultanés ?
  • Le temps de réponse moyen pour le chargement des pages est-il acceptable sous cette charge définie ?
  • L’application se comporte-t-elle à nouveau normalement après un pic de charge ?
  • Combien d’utilisateurs l’application peut-elle gérer en maintenant un temps de réponse acceptable ?
  • Quel est le seuil de charge au-dessus duquel les serveurs commencent à générer des erreurs et/ou à refuser des connexions ?
  • Les serveurs restent-ils fonctionnels lorsqu’ils sont soumis à une forte charge ou se bloquent-ils ?

Comme toute activité de test, les tests de performance requièrent des méthodes et une logique appropriées.

Lorsqu’une application réussit les tests de performance mais échoue ensuite en production, cela est souvent dû à des tests non réalistes. Dans ce cas, il est facile, bien que peu recommandé, de blâmer les tests eux-mêmes ou les outils utilisés pour les exécuter. Le vrai problème repose généralement sur une conception des tests qui ne prend pas en compte la base appropriée. Il faut se demander : « Que fallait-il savoir qui, si nous l’avions su, nous aurait permis de prédire cet échec avant la mise en production ? ». En d’autres termes : « Comment pouvons-nous fournir des tests de performance efficaces? »

Phases d’un projet de test de charge

 

Les méthodes de développement actuelles telles qu’Agile et DevOps permettent la création d’applications répondant rapidement aux besoins des clients. Ces méthodes impliquent la mise à jour de l’organisation du projet et nécessitent une collaboration étroite entre les équipes.

Dans ces méthodes, le cycle de vie du projet est organisé en plusieurs sprints, chaque sprint fournissant une partie de l’application.

Dans cet environnement, le processus de test de performance devrait suivre le workflow ci-dessous.

Une stratégie de test de performance devrait être mise en oeuvre à un stade précoce du cycle de vie du projet. Première étape : qualification des performances. Elle définit l’effort de test de l’ensemble du projet.

Une approche traditionnelle des tests de performance obligerait le projet à attendre que l’application soit assemblée avant de commencer la validation des performances. Dans un cycle de vie de projet moderne, la seule façon d’inclure la validation des performances à un stade précoce consiste à tester les composants individuels après chaque build et à mettre en oeuvre des tests de performance de bout en bout une fois l’application assemblée.

Essayez NeoLoad, la plateforme de tests de performance la plus automatisée pour les entreprises testant APIs et Applications critiques en continue

 

Établir une stratégie de test de performance

 

Il s’agit de la première et de la plus importante étape des tests de performance. Elle définit :

  • La portée des tests de performance ;
  • La stratégie de charge ;
  • Les contrats de niveau de service (SLA, Service Level Agreements) et/ou les objectifs de niveau de service (SLO, Service Level Objectives).

Il n’est jamais possible de tout tester, il faut donc prendre des décisions conscientes sur les points où concentrer l’intensité des tests. Généralement, 10 à 15 % des scénarios d’essai les plus fructueux révèlent entre 75 et 90 % des problèmes.

Tests basés sur le risque

L’évaluation des risques fournit un mécanisme permettant de hiérarchiser les efforts de test. Ce dernier permet de déterminer où diriger les efforts de test les plus poussés, et où il est préférable de tester seulement brièvement afin de préserver suffisamment de ressources pour les tests poussés.

Les tests basés sur les risques peuvent identifier les problèmes importants plus rapidement et plus tôt dans le processus, en portant uniquement sur les aspects les plus risqués d’un système.

La plupart des problèmes de performance et de robustesse d’un système surviennent dans les domaines suivants :

  • Fonctions gourmandes en ressources
  • Utilisations urgentes
  • Goulots d’étranglement potentiels (basés sur l’architecture interne et la mise en oeuvre)
  • Impact sur les clients ou les utilisateurs, y compris en termes de visibilité
  • Historique des défauts antérieurs (observations d’autres systèmes similaires en fonctionnement direct)
  • Caractéristiques et fonctionnalités nouvelles et modifiées
  • Forte demande : fonctionnalités utilisées de façon intensive
  • Fonctionnalités complexes
  • Exceptions
  • Parties problématiques (mal élaborées ou entretenues) du système
  • Maintenance de la plateforme

Automatisez vos tests de performances d'APIs et d'Applications end-to-end grâce à NeoLoad, la plateforme de test de performance en continue.

 

L’expert de l’industrie Ross Collard a élaboré la liste de questions ci-dessous pour identifier les différents risques de performance :

Vue situationnelle

  • Quels domaines de l’exploitation du système, s’ils ont des performances insuffisantes, ont le plus d’impact sur les résultats (revenus et bénéfices) ?
  • Quelles utilisations du système sont susceptibles de consommer un niveau élevé de ressources système par événement, quelle que soit la fréquence de l’événement ? Les ressources consommées doivent être significatives pour chaque événement et non pas élevées dans l’ensemble simplement parce que l’événement se produit fréquemment et que le nombre total d’événements est élevé.
  • Quels domaines du système peuvent être testés de façon minimale sans trop augmenter le risque, afin de conserver les ressources requises pour les domaines qui nécessitent des tests poussés ?

Vue des systèmes

  • Quelles utilisations du système ont une priorité critique ?
  • Quelles sont les utilisations les plus populaires (autrement dit, les plus fréquentes) ?
  • Quelles utilisations sont les plus visibles (ont une visibilité élevée) ?
  • Quelles sont les circonstances susceptibles de provoquer une forte demande du système de la part des utilisateurs externes (par exemple, des visiteurs distants d’un site web public qui ne sont pas des employés internes) ?
  • Existe-t-il des fonctions particulièrement complexes dans le système, par exemple dans le domaine du traitement des exceptions ?
  • Existe-t-il des domaines dans lesquels des technologies nouvelles et immatures, ou des méthodes inconnues et non éprouvées, ont été utilisées ?
  • Existe-t-il d’autres applications secondaires qui partagent la même infrastructure et sont-elles censées interférer ou concurrencer de manière significative les ressources système (par exemple, les serveurs partagés) ?

Intuition/Experience

  • Que pouvons-nous apprendre du comportement des systèmes existants qui sont actuellement remplacés, comme leurs charges de travail et leurs caractéristiques de performance ? Comment pouvons-nous appliquer ces informations dans les tests du nouveau système ?
  • Quelle a été votre expérience antérieure dans des situations similaires ? Quels aspects des fonctionnalités, styles de conception, sous-systèmes, composants et systèmes ont généralement présenté des problèmes de performance ? Si vous n’avez aucune expérience avec des systèmes similaires, veuillez ignorer cette question.
  • Parmi les facteurs que vous avez identifiés en répondant aux questions précédentes, quels sont-ceux qui méritent d’être testés en priorité ? Quelles activités sont susceptibles de se produire simultanément et peuvent causer une charge et des contraintes importantes sur le système ?
  • Selon votre compréhension de l’architecture du système et de l’infrastructure de support, où se trouvent les éventuels goulets d’étranglement ?

Vue des exigences

  • Dans quelles circonstances une forte demande interne peut-elle avoir lieu (par exemple, en raison des employés internes d’un site web) ?
  • Quelle est la stratégie d’archivage des bases de données ? Quel est le taux de données ajoutées par an ?
  • Le système doit-il être disponible pendant 7 heures, 24 heures, etc. ?
  • Des tâches de maintenance sont-elles exécutées pendant les heures d’ouverture ?

Les réponses à ces questions aident à identifier :

  • Les domaines qu’il convient de tester
  • Le type de test requis pour valider les performances de l’application

Commencez à tester avec Neoload, la plus rapide, la plus réaliste, et la plus automatisée des plateformes de test de performance en continue

 

Test des composants

 

Une fois que les domaines fonctionnels requis pour les tests de performance ont été identifiés, décomposez les étapes métier en workflows techniques qui mettent en lumière les composants techniques.

Pourquoi les actions commerciales devraient-elles être fractionnées en composants ? Puisque l’objectif est de tester les performances à un stade précoce, le fait de répertorier tous les composants importants aide à définir une stratégie d’automatisation des tests de performance. Une fois qu’un composant a été codé, il est logique de le tester séparément et de mesurer :

  • Le temps de réponse
  • Le nombre maximal d’appels que le composant est capable de gérer

De plus, les tests des composants prennent en charge JMS, API, Service, Messages, etc., ce qui permet de créer et de gérer facilement des scénarios. Un autre avantage majeur de cette stratégie est que les interfaces des composants ont moins de chance d’être affectées par les mises à jour techniques. Une fois qu’un scénario de composant est créé, il peut être inclus dans le processus de génération et il est possible de recevoir un feed-back sur les performances de la build en cours.

Après chaque sprint, il est nécessaire de tester l’application assemblée en exécutant des tests utilisateur réalistes (impliquant plusieurs composants). Même si les composants ont été testés, il est obligatoire de mesurer :

  • Le comportement du système lorsque plusieurs processus d’entreprise s’exécutent en parallèle
  • Le temps de réponse réel de l’utilisateur
  • La disponibilité de l’architecture
  • La taille de l’architecture
  • Stratégie de mise en cache

L’effort de test devient plus complexe à mesure que le projet avance. Au début, l’accent est mis sur la qualité des applications, puis toute l’attention est portée sur l’environnement cible, l’architecture et le réseau. Cela signifie que les objectifs des tests de performance varieront en fonction du calendrier du projet.

Environnement de test

 

Il est impératif que le système testé soit correctement configuré et que les résultats obtenus puissent être utilisés dans le système de production. Les considérations liées à l’environnement et à l’installation doivent rester prioritaires lors du développement de la stratégie de test.
En voici quelques-unes :

  • Quelles sont les données utilisées ? S’agit-il de données de production réelles, de données générées artificiellement ou de quelques enregistrements aléatoires ? Le volume des données correspond-il au volume prévu pour la production ? Si ce n’est pas le cas, quelle est la différence ?
  • Comment les utilisateurs sont-ils définis ? Les comptes sont-ils définis avec les droits de sécurité appropriés pour chaque utilisateur virtuel ou un seul ID administrateur sera-t-il réutilisé ?
  • Quelles sont les différences entre les environnements de production et de test ? Si le système de test n’est qu’un sous-ensemble du système de production, peut-on simuler la totalité de la charge ou seulement une partie de cette charge ?

Il est important que l’environnement de test reflète le mieux possible l’environnement de production, mais certaines différences peuvent subsister. Même si les tests portaient sur l’environnement de production avec les données de production réelles, ils ne représenteraient qu’un seul point dans le temps. D’autres conditions et facteurs devraient également être pris en compte.

Testez vos APIs et applications avec NeoLoad, la plateforme de test de performance en continue la plus automatisée

 

Concevoir un plan de test

 

Le plan de test est un document décrivant la stratégie de performance. Il doit inclure :

  • Des évaluations du risque de performance mettant en évidence les exigences de performance
  • Une modélisation des performances expliquant la logique de calcul d’une autre stratégie de charge
  • La transposition du parcours utilisateur principal en composants
  • La description des différents parcours utilisateur avec le temps de réflexion spécifique par transaction métier
  • Le ou les jeux de données
  • Le contrat de niveau de service (SLA)
  • La description de chaque test à exécuter pour valider les performances
  • Les environnements de test

Le plan de test constitue le fondement d’une stratégie de test de performance bien conçue et exécutée. Il est la preuve qu’une équipe a pris en compte comme il se doit le rôle essentiel des performances dans l’expérience finale des utilisateurs.

Dans de nombreux cas, les équipes de projet garantissent la livraison des plans de test de performance au cours des cycles de développement et de planification, en les exigeant pour considérer le projet comme prêt à démarrer. Bien que chaque histoire ou chaque cas d’utilisation ne nécessite pas le même niveau de tests de performance, il est primordial de placer le processus de réflexion au coeur du projet pour obtenir de meilleurs systèmes et une meilleure appréciation globale de la qualité de bout en bout livrée par l’équipe.

Modélisation des tests de performance

L’objectif des tests de charge est de :

 

 

simuler une activité utilisateur réaliste sur l’application. Si un parcours utilisateur non représentatif est sélectionné ou si la bonne stratégie de charge n’est pas définie, le comportement de l’application sous charge ne pourra pas être correctement validé.
La modélisation des tests de performance ne nécessite aucune compétence technique, mais seulement du temps pour comprendre pleinement l’application :

You have read 30% of the article