Menu

Différence entre le plan de test de performance et la stratégie de test de performance

  • Principal
  • Autre
  • Différence entre le plan de test de performance et la stratégie de test de performance

difference between performance test plan

Essayez Notre Instrument Pour Éliminer Les Problèmes

Quelle est la différence entre le plan de test de performance et la stratégie de test?

Dans ce Série de tests de performance , notre précédent tutoriel, expliqué sur Test fonctionnel vs test de performance en détail.

=> Cliquez ici pour une série complète de didacticiels sur les tests de performance

Dans ce didacticiel, vous découvrirez la différence entre le plan de test de performance et la stratégie de test et le contenu à inclure dans ces documents.

Plan de test de performance vs stratégie de test

Comprenons la différence entre ces deux documents.

Ce que vous apprendrez:

Stratégie de test de performance

Le document de stratégie de test de performance est un document de haut niveau qui nous donne des informations sur la façon de réaliser des tests de performance pendant la phase de test. Il nous indique comment tester une exigence commerciale et quelle approche est nécessaire pour livrer avec succès le produit au client final.

Cela aura toutes les informations sur le processus d'affaires à un niveau très élevé.

Ce document est généralement rédigé par les responsables des tests de performance en fonction de leur expérience antérieure car les informations disponibles seront limitées car ce document est préparé pendant les étapes initiales du projet, c'est-à-dire pendant la phase d'analyse des exigences ou après la phase d'analyse des exigences.

Donc, en d'autres termes, un document de stratégie de test de performance n'est rien d'autre qu'une direction que vous définissez au début du projet avec l'approche que vous allez adopter, afin d'atteindre les objectifs de test de performance.

Un document de stratégie de test de performance typique contient l'objectif global des tests de performance comme ce qui sera testé? quel environnement sera utilisé? quels outils seront utilisés? quels types de tests seront effectués? Critères d'entrée et de sortie, quels risques d'une partie prenante sont atténués? et quelques autres que nous examinerons en détail au fur et à mesure que nous avancerons dans ce tutoriel.

Stratégie de test de performance

Le diagramme ci-dessus explique que le document de stratégie de test de performance est créé pendant ou après la phase d'analyse des exigences du projet.

Plan de test de performance

Le document du plan de test de performance est rédigé à un stade ultérieur du projet, lorsque les exigences et les documents de conception sont presque figés. Le document du plan de test de performance contient tous les détails du calendrier de mise en œuvre de la stratégie ou de l'approche qui a été décrite pendant la phase d'analyse des besoins.

À partir de maintenant, les documents de conception sont presque prêts, le plan de test de performance contient tous les détails sur les scénarios à tester. Il contient également plus de détails sur les environnements utilisés pour les tests de performance, le nombre de cycles de tests, les ressources, les critères d'entrée-sortie, etc. Le plan de test de performance est rédigé par le gestionnaire de performances ou par le responsable du test de performance.

Plan de test de performance

Le diagramme ci-dessus explique clairement que le plan de test de performance est créé pendant la conception du projet ou après la phase de conception en fonction de la disponibilité des documents de conception.

Contenu du document de stratégie de test de performance

Voyons maintenant tout ce qui doit être inclus dans un document de stratégie de test de performance:

#1. Introduction: Donnez un bref aperçu de ce que contiendra un document de stratégie de test de performance pour ce projet particulier. Mentionnez également les équipes qui utiliseront ce document.

comment ajouter maven à l'éclipse

# 2) Portée: La définition de la portée est très importante car elle nous indique quelles seront exactement les performances testées. Nous devons être très précis lors de la définition de la portée ou de toute autre section.

N'écrivez jamais rien de généralisé. Scope nous indique ce qui sera exactement testé pour l'ensemble du projet. Nous avons In scope et Out of scope comme faisant partie de l'étendue, In scope décrit toutes les fonctionnalités qui seront testées en performance et Out of scope décrit les fonctionnalités qui ne seront pas testées.

# 3) Test Approcher: Ici, nous devons mentionner l'approche que nous allons suivre pour nos tests de performance, car chaque script sera exécuté avec un seul utilisateur pour créer une ligne de base, puis ces tests de base seront utilisés comme référence pour l'analyse comparative à un stade ultérieur de temps pendant les essais.

De plus, chaque composant sera testé individuellement avant de les intégrer ensemble et ainsi de suite.

# 4) Test Les types: Nous mentionnons ici les différents types de tests à couvrir, comme le test de charge, le test de stress, le test d'endurance, le test de volume, etc.

# 5) Test Livrables: Mentionnez ce que tous les livrables seront fournis dans le cadre des tests de performance du projet, comme le rapport de test, le rapport de synthèse, etc.

# 6) Environnement: Ici, nous devons mentionner les détails de l'environnement. Les détails de l'environnement sont très importants car ils décrivent les systèmes d'exploitation qui seront utilisés pour les tests de performances.

Si l'environnement sera une réplique de la production ou sera-t-il dimensionné à la hausse ou à la baisse par rapport à la production, ainsi que le rapport entre le dimensionnement et le dimensionnement, c'est-à-dire la moitié de la taille de la production ou le double de la taille de la production ?

De plus, nous devons mentionner clairement tous les correctifs ou mises à jour de sécurité à prendre en compte dans le cadre de la configuration de l'environnement et également lors du test de performance.

# 7) Outils: Ici, nous devons mentionner tous les outils qui seront utilisés comme les outils de suivi des défauts, Outils de gestion , Tests de performance et outils de surveillance. Quelques Exemples des outils de suivi des défauts est JIRA , Pour la gestion de documents comme Confluence, pour les tests de performance Jmètre et pour la surveillance Nagios .

# 8) Ressources: Les détails des ressources requises pour l'équipe de test de performance sont documentés dans cette section. Par exemple , Responsable des performances, responsable des tests de performances, testeurs de performances, etc.

# 9) Entrée & Sortir Critères: Les critères d'entrée et de sortie seront décrits dans cette section.

Par exemple,

Critères d'admission - L'application doit être fonctionnellement stable avant de déployer la version pour les tests de performances.

Critère de sortie - Tous les défauts majeurs sont résolus et la plupart des SLA sont respectés.

# 10) Risque et atténuation: Tous les risques qui affecteront les tests de performance doivent être énumérés ici avec le plan d'atténuation correspondant. Cela aidera tous les risques à se produire pendant les tests de performance ou au moins une solution de contournement pour le risque sera planifiée bien à l'avance. Cela aidera à compléter les calendriers des tests de performance à temps sans affecter les livrables.

# 11) Abréviations: Utilisé pour les abréviations. Par exemple, PT - Test de performance.

# 12) Historique du document: Celui-ci contient la version du document.

Contenu du document de plan de test de performance

Jetons un coup d'œil à tout ce qui doit être inclus dans un document de plan de test de performance:

#1. Introduction: C'est la même chose que celle indiquée dans le document de stratégie de test de performance, nous mentionnons plutôt le plan de test de performance au lieu de stratégie de test de performance.

# 2) Objectif: Quel est l'objectif de ces tests de performance, ce qui est réalisé en effectuant des tests de performance, c'est-à-dire quels sont les avantages de faire des tests de performance doivent être clairement mentionnés ici.

# 3) Portée : La portée des tests de performance, à la fois dans la portée et hors du processus métier est définie ici.

# 4) Approche: L'approche globale est décrite ici, comment les tests de performance sont-ils effectués? Quels sont les prérequis pour la mise en place de l'environnement? etc sont inclus.

# 5) Architecture: Les détails de l'architecture d'application doivent être mentionnés ici, comme le nombre total de serveurs d'application, serveurs Web, serveurs de base de données, pare-feu, 3rdd application de partie Machines de générateur de charge etc.

# 6) Dépendances: Toutes les actions de test de pré-performance doivent être mentionnées ici, comme les composants à tester les performances sont fonctionnellement stables, l'environnement est mis à l'échelle pour une production comme celle-ci et est disponible ou non, la date de test est disponible ou non, les outils de test de performance sont disponibles avec des licences le cas échéant et ainsi de suite.

# 7) Environnement: Nous devons mentionner tous les détails du système comme l'adresse IP, le nombre de serveurs, etc. Nous devons également mentionner clairement comment l'environnement doit être configuré comme les prérequis, les correctifs à mettre à jour, etc.

# 8) Scénarios de test: La liste des scénarios à tester est mentionnée dans cette section.

# 9) Mélange de la charge de travail: Le mix de charge de travail joue un rôle essentiel dans la réussite de l'exécution du test de performance et si le mix de charge de travail ne permet pas de prédire l'action de l'utilisateur final en temps réel, alors tous les résultats des tests sont vains et nous nous retrouvons avec des performances médiocres en production. lorsque l'application sera mise en ligne.

Il est donc nécessaire de bien concevoir la charge de travail. Comprendre comment les utilisateurs accèdent à l'application en production et si l'application est déjà disponible ou bien essayer d'obtenir plus de détails de l'équipe commerciale pour bien comprendre l'utilisation de l'application et définir la charge de travail.

# 10) Cycles d'exécution des performances: Les détails du nombre de tests de performances seront décrits dans cette section. Par exemple, Test de ligne de base, test utilisateur du cycle 1 50, etc.

meilleur utilitaire de nettoyage gratuit de windows 10

# 11) Mesures de test de performance: Les détails des métriques collectées seront décrits ici, ces métriques doivent être en critères d'acceptation avec les exigences de performance convenues.

# 12) Livrables du test: Mentionnez les livrables et intégrez également les liens vers les documents, le cas échéant.

# 13) Gestion des défauts: Ici, nous devons mentionner comment les défauts sont traités, le niveaux de gravité et niveaux de priorité devrait également être décrit.

# 14) Gestion des risques: Mentionnez les risques impliqués dans le plan d'atténuation, par exemple si l'application n'est pas stable et si des défauts fonctionnels de haute priorité sont toujours ouverts, cela affectera-t-il le calendrier des exécutions de tests de performance et comme indiqué précédemment, cela aidera tout risque à se produire pendant les tests de performance ou au moins une solution de contournement pour le risque sera planifiée bien à l'avance.

# 15) Ressources: Mentionnez les détails de l'équipe ainsi que leurs rôles et responsabilités.

# 16) Historique des versions: Garde une trace de l'historique du document.

# 17) Examens et approbations de documents: Cela contient la liste des personnes qui examineront et approuveront le document final.

Ainsi, fondamentalement, la stratégie de test de performance a une approche des tests de performance et le plan de test de performance contient les détails de l'approche, donc ils vont de pair. Certaines entreprises ont juste un plan de test de performance qui a une approche ajoutée au document, tandis que d'autres ont à la fois un document de stratégie et de plan séparément.

Conseils pour développer ces documents

Suivez les directives ci-dessous lors de la conception de la stratégie ou d'un document de plan pour une exécution réussie des tests de performance.

  • N'oubliez pas que lors de la définition d'une stratégie de test de performance ou d'un plan de test, nous devons nous concentrer sur l'objectif et la portée du test. Si notre stratégie ou plan de test n'est pas conforme aux exigences ou à la portée, nos tests sont invalides.
  • Essayez de concentrer et d'incorporer les métriques qu'il est important de capturer pendant l'exécution du test pour identifier les goulots d'étranglement dans le système ou pour voir les performances de l'application.
  • Planifiez les exécutions de test de manière à ne pas tester tous les scénarios à la fois et à faire planter le système. Effectuez plusieurs tests et augmentez progressivement les scénarios et la charge utilisateur.
  • Dans votre approche, essayez d'ajouter tous les appareils à partir desquels votre application sera accessible, cela s'applique généralement aux appareils mobiles.
  • Ayez toujours une section Risque et atténuation dans votre document de stratégie car les exigences changent de temps en temps et ces changements auront beaucoup d'impact sur les cycles d'exécution et les délais qui doivent être adressés au client bien à l'avance.

Conclusion

Je suis sûr que ce didacticiel vous aurait expliqué les différences entre une stratégie et un plan de test de performances ainsi que son contenu, l'approche pour les tests de performances des applications mobiles et les tests de performances des applications cloud de manière détaillée avec des exemples.

Consultez notre prochain tutoriel pour en savoir plus sur les moyens de booster vos tests de performance.

=> Visitez ici pour une série complète de didacticiels sur les tests de performances

Tutoriel PREV | Tutoriel SUIVANT

lecture recommandée

^