Modèle de plan de test de performance

Un modèle de plan de test de performance qui peut être utilisé tel quel ou modifié pour répondre aux besoins de votre projet en termes d'exigences de performance.



1. Objet

Le but de cette section est de fournir un aperçu de haut niveau de l'approche de test de performance à suivre pour le projet. Cela doit être présenté à toutes les parties prenantes concernées et doit être discuté afin de parvenir à un consensus.



2. Présentation

Dans le cadre de la livraison du , il est nécessaire que la solution réponde aux critères d'acceptation, tant en termes de domaines fonctionnels que non fonctionnels. Le but de ce document est de fournir un aperçu des tests non fonctionnels de solution.


Ce document couvre les points suivants:

  • Critères d'entrée et de sortie
  • Exigences environnementales
  • Approche de test de volume et de performance
  • Activités de test de performance


3. Critères d'entrée

Les éléments de travail suivants doivent être complétés / convenus à l'avance afin de procéder aux activités de test de performance proprement dites:


  • Document d'exigences de test non fonctionnel fourni par , avec des NFR quantifiés si possible
  • Les cas d'utilisation critiques doivent être testés fonctionnellement et sans aucun bogue critique en suspens
  • Conception des schémas architecturaux approuvés et disponibles
  • Les principaux cas d'utilisation ont été définis et cadrés
  • Types de tests de performance convenus
  • Configuration des injecteurs de charge
  • Toute configuration de données nécessaire - par ex. Nombre approprié d'utilisateurs créés dans


4. Critères de sortie

L'activité de test de performance sera terminée lorsque:

  • Les objectifs NFR ont été atteints et les résultats des tests de performance ont été présentés à l'équipe et approuvés.


5. Exigences environnementales

Les tests de performances seront exécutés sur une version stable de solution (qui a déjà passé les tests fonctionnels) et effectuée sur un environnement de production dédié (pré-production?) affecté aux tests de performances sans déploiements sur cet environnement au cours des tests de performances.

5.1 Injecteurs de charge

Il y aura un ou plusieurs «injecteurs de charge» dédiés mis en place pour initier la charge requise pour les tests de performance. L'injecteur de charge peut être une machine virtuelle ou plusieurs machines virtuelles sur lesquelles une instance de JMeter est en cours d'exécution, initiant les requêtes.

5.2 Outils de test

Les outils de test utilisés pour les tests de volume et de performance seront:


5.2.1 JMeter

Un outil de test de charge open-source. Principalement utilisé pour les tests de volume et de performance.

5.2.2 Splunk

Splunk sera utilisé pour la journalisation (pourrait utiliser un autre outil - besoin de confirmer avec l'équipe de test de perf).



6. Approche des tests de volume et de performance

Le La solution doit être suffisamment performante pour gérer les critères de charge suivants.

N.B. Les nombres dans le tableau suivant ne sont donnés qu'à titre d'exemple - les valeurs réelles doivent être insérées une fois finalisées par Document NFR.


6.1 Volumes de service cible

Les objectifs horaires sont découverts à partir de la solution actuelle pour [Y2019]. Suppression des autres valeurs «d’exemple» du modèle de plan.

Étant donné que les valeurs de pointe horaires ne sont pas élevées, elles seront prises comme cible pour le test de charge fixe. Le facteur d'échelle est à déterminer pour le moment.

6.2 Nombre d'utilisateurs

Les tests de performances seront exécutés avec un maximum de 1 000 [?] Utilisateurs. Les utilisateurs seront créés dans au préalable et être accessible via API de connexion. Chaque demande se connectera avec un ID utilisateur différent.

6.3 Assertions

L'outil JMeter sera utilisé pour exécuter des scripts de test de performance. Dans les scripts, il y aura des assertions déclarées pour vérifier les métriques ci-dessus ainsi que des vérifications fonctionnelles de base pour s'assurer que les réponses correctes sont reçues pour chaque demande.


6.4 Profils de charge

Les profils de charge doivent être conçus pour imiter le trafic d'une journée moyenne typique vers placer. Veuillez noter que le trafic est uniquement réparti et limité à la partie Identité client et gestion des accès du site, c.-à-d.

  • Connexion
  • S'inscrire
  • réinitialiser le mot de passe
  • Mot de passe oublié
  • Définir le client
  • Obtenir le client

Voici un exemple de profil pour une journée:

6.4.1 Fondement

Le premier plan d'action consiste à trouver une ligne de base. En utilisant un seul utilisateur, nous exécuterons une simulation pendant une période de temps (par exemple 5 minutes) pour obtenir une moyenne des temps de réponse pour chaque point de terminaison. Cela garantit qu'avec un seul utilisateur, nous sommes en mesure d'atteindre les pics de demandes par seconde.


6.4.2 Test de charge

Une fois les métriques de base rassemblées, la même simulation, qui simule un profil de charge, est exécutée avec un nombre accru d'utilisateurs pour tester les volumes cibles. L’idée de ce test de charge est de tester le système par rapport à une charge quotidienne typique, en simulant les montées en puissance, les pics de la journée et les ralentissements.

6.4.3 Test de résistance

Le but des tests de résistance est de trouver le point de rupture du système, c'est-à-dire à quel moment le système devient-il insensible. Si la mise à l'échelle automatique est en place, le test de résistance sera également un bon indicateur à partir duquel le système évolue et de nouvelles ressources sont ajoutées. Pour les tests de résistance, la même simulation utilisée pour les tests de charge est utilisée mais avec une charge plus élevée que prévu.

6.4.4 Test de pointe

Le test de pointe introduit une charge importante sur le système dans un laps de temps relativement court. Le but de ce test est de simuler un événement de vente par exemple, lorsqu'un grand nombre d'utilisateurs accède simultanément à leur compte dans un laps de temps relativement court.

6.4.5 Test de trempage

Le test de trempage exécutera un test de charge pendant une période prolongée. Le but est de révéler toute fuite de mémoire, absence de réponse ou erreur au cours du test d'imprégnation. Nous utiliserions généralement 80% de la charge (utilisée pour les tests de charge) pendant 24 heures et / ou 60% de la charge pendant 48 heures.

6.4.6 Test du point de saturation

Dans le test du point de saturation, nous continuons d'augmenter la charge régulièrement pour déterminer à quel point le système ne répond plus, c'est-à-dire trouver le point de rupture du système en termes de charge.



7. Activités de test de performance

Les activités suivantes sont suggérées pour avoir lieu dans l'ordre, pour terminer les tests de performance:

7.1 Construction de l'environnement de test de performance

  • Les injecteurs de charge doivent avoir une capacité suffisante et doivent être gérés à distance. En outre, l'emplacement des injecteurs doit être convenu
  • Un mécanisme de surveillance et d'alerte en temps réel doit être en place et doit couvrir l'application, les serveurs ainsi que les injecteurs de charge.
  • Les journaux d'application doivent être accessibles.

7.2 Script de cas d'utilisation

  • L'outil de test de performance qui sera utilisé est JMeter
  • Toutes les exigences en matière de données ont été discutées pour les cas d'utilisation à script

7.3 Construction du scénario de test

  • Le type de test à exécuter (charge / contrainte, etc.)
  • Le profil de charge / modèle de charge doit être convenu pour chaque type de test (montée / descente, étapes, etc.)
  • Incorporer le temps de réflexion dans les scénarios

7.4 Exécution et analyse des tests

Les tests suivants doivent être exécutés dans l'ordre suivant:

  • Test de base
  • Test de chargement
  • Test de stress
  • Test de pointe
  • Test de trempage
  • Test du point de saturation

Idéalement, 2 exécutions de test de chaque type de test seront effectuées. Après chaque test, l'application peut être affinée afin d'augmenter ses performances, puis un autre cycle de test commencera.

7.5 Analyse et rapport post-test

  • Capturez et sauvegardez tous les rapports et archives de données pertinents.
  • Déterminez le succès ou l'échec en comparant les résultats du test aux objectifs de performance. Si les objectifs ne sont pas atteints, les modifications appropriées doivent être apportées et un autre cycle d'exécution de test commencera. On ne sait pas combien de cycles d’exécution seront nécessaires pour atteindre les objectifs convenus.
  • Documentez et présentez les résultats des tests à l'équipe.