complete performance testing guide with examples
Qu'est-ce que le test de performance?
Le test de performance, également appelé «test de performance», est un type de test effectué pour vérifier les performances des applications ou des logiciels sous la charge de travail en termes de réactivité et de stabilité. L'objectif du test de performance est d'identifier et de supprimer les goulots d'étranglement des performances d'une application.
Ce test est principalement effectué pour vérifier si le logiciel répond aux exigences attendues en termes de vitesse, d'évolutivité et de stabilité de l'application.
application de feuille de temps gratuite pour iphone et android
Dans cette série de didacticiels, nous couvrirons des détails complets tels que - Types de tests de performance, processus et rédaction d'un document de stratégie de test de performance à partir de zéro.
Ceci est une série de tutoriels détaillés que vous voudrez peut-être ajouter à vos favoris!
Explorons!
Liste de TOUS les didacticiels de test de performance de cette série:
Tutoriel n ° 1: Guide complet des tests de performance (Ce tutoriel)
Tutoriel n ° 2: Différence entre les tests de performance, de charge et de contrainte
Tutoriel n ° 3: Test fonctionnel vs test de performance
Tutoriel n ° 4: Plan de test de performance et stratégie de test
Tutoriel n ° 5: Moyens de booster vos tests de performance
Tutoriel n ° 6: Guide de test des performances du cloud
Tutoriel n ° 7: Guide de test des performances des applications mobiles
Tutoriel n ° 8: Comment effectuer des tests de performances manuels
Tutoriel n ° 9: Tutoriel de test des performances de site Web
Tutoriel n ° 10: Entreprises de test de performance
Tutoriel n ° 11: Test de performances avec LoadRunner (Séries)
Outils:
Tutoriel n ° 12: Meilleurs outils de test de performance
Tutoriel n ° 13: Tutoriel de test de performance Neoload
Tutoriel n ° 14: Tutoriel de test de performances BlazeMeter Mobile
Tutoriel n ° 15: Tutoriel de test de charge, de stress et de performance WAPT
Tutoriel n ° 16: Tutoriel de test des performances du site Web SmartMeter.io
Ce que vous apprendrez:
- Types de tests de performance
- Processus de test de performance
- Comment rédiger un document de stratégie de test de performance?
- Exemple de modèle de stratégie de test de performance
- #1. Introduction
- # 2) Portée
- # 3) Approche
- # 4) Données de test
- # 5) Critères d'entrée et de sortie
- # 6) Gestion des défauts
- # 7) Outils et techniques de test
- # 8) Critères de suspension et de reprise
- # 9) Livrables du test
- # 10) Rôles et responsabilités
- # 11) Risques potentiels et plan d'atténuation
- # 12) Hypothèses
- # 13) Dépendances
- # 14) Abréviations
- Meilleures pratiques pour des tests de performances réalistes
Types de tests de performance
Test de charge
Le test de charge est un type de test de performance où l'application est testée pour ses performances en utilisation normale et maximale. Les performances d'une application sont vérifiées par rapport à sa réponse à la demande de l'utilisateur et sa capacité à répondre de manière cohérente dans une tolérance acceptée sur différentes charges d'utilisateurs.
Les principales considérations sont:
- Quelle est la charge maximale que l'application peut supporter avant que l'application ne commence à se comporter de manière inattendue?
- Quelle quantité de données la base de données est-elle capable de gérer avant que le système ne ralentisse ou que la panne ne soit observée?
- Y a-t-il des problèmes liés au réseau à résoudre?
Test de stress
Les tests de résistance sont utilisés pour trouver des moyens de briser le système. Le test fournit également la plage de charge maximale que le système peut supporter.
En règle générale, les tests de résistance ont une approche incrémentielle où la charge est augmentée progressivement. Le test démarre avec une charge pour laquelle l'application a déjà été testée. Ensuite, plus de charge est ajoutée lentement pour stresser le système. Le point auquel nous commençons à voir des serveurs ne répondant pas aux demandes est considéré comme le point de rupture.
Les questions suivantes doivent être abordées:
- Quelle est la charge maximale qu'un système peut supporter avant de tomber en panne?
- Comment le système se décompose-t-il?
- Le système est-il capable de récupérer une fois qu'il est tombé en panne?
- De combien de façons un système peut-il casser et quels sont les nœuds faibles lors de la gestion de la charge inattendue?
Test de volume
Le test de volume consiste à vérifier que les performances de l'application ne sont pas affectées par le volume de données traitées par l'application. Afin d'exécuter un test de volume, un énorme volume de données est entré dans la base de données. Ce test peut être un test incrémentiel ou constant. Dans le test incrémentiel, le volume de données est augmenté progressivement.
Généralement, avec l'utilisation de l'application, la taille de la base de données augmente et il est nécessaire de tester l'application par rapport à une base de données lourde. Un bon exemple de cela pourrait être un site Web d'une nouvelle école ou d'un collège ayant de petites quantités de données à stocker au départ, mais après 5 à 10 ans, les magasins de données dans la base de données du site Web sont bien plus.
Test de capacité
=> L'application est-elle capable de répondre au volume d'affaires dans des conditions de charge normales et de pointe?
Les tests de capacité sont généralement effectués pour les perspectives futures. Les tests de capacité abordent les points suivants:
- L'application pourra-t-elle supporter la charge future?
- L'environnement est-il capable de supporter la charge accrue à venir?
- Quelles sont les ressources supplémentaires nécessaires pour rendre l'environnement suffisamment performant?
Le test de capacité est utilisé pour déterminer le nombre d'utilisateurs et / ou de transactions qu'une application Web donnée prendra en charge et atteindra toujours les performances. Au cours de ce test, des ressources telles que la capacité du processeur, la bande passante du réseau, l'utilisation de la mémoire, la capacité du disque, etc. sont prises en compte et modifiées pour atteindre l'objectif.
Les services bancaires en ligne sont un parfait exemple des domaines dans lesquels les tests de capacité pourraient jouer un rôle majeur.
Fiabilité / Récupération Essai
Test de fiabilité ou test de récupération - consiste à vérifier si l'application est en mesure de revenir à son état normal après une panne ou un comportement anormal et combien de temps cela prend-il pour le faire (en d'autres termes, l'estimation du temps).
Si un site de trading en ligne rencontre un échec où les utilisateurs ne sont pas en mesure d'acheter / vendre des actions à un certain moment de la journée (heures de pointe) mais sont en mesure de le faire après une heure ou deux, nous pouvons dire que l'application est fiable ou récupéré du comportement anormal.
Processus de test de performance
Voici toutes les activités effectuées dans ce test:
# 1) Analyse / collecte des exigences
L'équipe de performance interagit avec le client pour l'identification et la collecte des exigences - techniques et commerciales. Cela comprend l'obtention d'informations sur l'architecture de l'application, les technologies et la base de données utilisées, les utilisateurs prévus, les fonctionnalités, l'utilisation de l'application, exigence de test , exigences matérielles et logicielles, etc.
# 2) Sélection POC / Outil
Une fois la fonctionnalité clé identifiée, POC (Proof Of Concept - qui est une sorte de démonstration de l'activité en temps réel mais dans un sens limité) se fait avec les outils disponibles.
La liste des outils disponibles dépend du coût de l'outil, du protocole utilisé par l'application, des technologies utilisées pour construire l'application, du nombre d'utilisateurs que nous simulons pour le test, etc. Pendant le POC, des scripts sont créés pour la clé identifiée fonctionnalité et exécuté avec 10-15 utilisateurs virtuels.
# 3) Plan de test de performance et conception
En fonction des informations collectées au cours des étapes précédentes, la planification et la conception des tests sont effectuées.
La planification des tests implique des informations sur la manière dont le test de performance va avoir lieu - environnement de test, charge de travail, matériel, etc.
Plus d'informations sur le document de stratégie de test ci-dessous.
# 4) Développement de tests de performance
- Des cas d'utilisation sont créés pour la fonctionnalité identifiée dans le plan de test comme étant la portée de PT.
- Ces cas d'utilisation sont partagés avec le client pour approbation. Ceci permet de s'assurer que le script sera enregistré avec les étapes correctes.
- Une fois approuvé, le développement du script commence par un enregistrement des étapes dans les cas d'utilisation avec l'outil de test de performance sélectionné lors du POC (Proof of Concepts) et amélioré en effectuant la corrélation (pour gérer la valeur dynamique), le paramétrage (substitution de valeur) et les fonctions personnalisées comme selon la situation ou le besoin. Plus d'informations sur ces techniques dans nos tutoriels vidéo.
- Les scripts sont ensuite validés contre différents utilisateurs.
- Parallèlement à la création de scripts, l'équipe de performance continue également de travailler sur la mise en place de l'environnement de test (logiciel et matériel).
- L'équipe de performance s'occupera également des métadonnées (back-end) via des scripts si cette activité n'est pas reprise par le client.
# 5) Modélisation des tests de performance
Le modèle de charge de performance est créé pour l'exécution du test. L'objectif principal de cette étape est de valider si les mesures de performance données (fournies par les clients) sont atteintes ou non pendant le test. Il existe différentes approches pour créer un modèle de chargement. ' La loi de Little »Est utilisé dans la plupart des cas.
# 6) Exécution des tests
Le scénario est conçu en fonction du modèle de chargement dans Controller ou Performance Center, mais les tests initiaux ne sont pas exécutés avec le nombre maximum d'utilisateurs qui sont dans le modèle de chargement.
L'exécution des tests se fait de manière incrémentielle. Par exemple, Si le nombre maximum d'utilisateurs est de 100, les scénarios sont d'abord exécutés avec 10, 25, 50 utilisateurs et ainsi de suite, pour finalement passer à 100 utilisateurs.
# 7) Analyse des résultats des tests
Les résultats des tests sont le produit le plus important pour le testeur de performance. C'est là que nous pouvons prouver le ROI (retour sur investissement) et la productivité qu'un effort de test de performance peut fournir.
Certaines des meilleures pratiques qui aident le processus d'analyse des résultats:
- Un nom unique et significatif pour chaque résultat de test - cela aide à comprendre le but du test.
- Incluez les informations suivantes dans le résumé des résultats du test:
- Raison de l'échec / des échecs
- Changement des performances de l'application par rapport au test précédent
- Modifications apportées au test à partir du point de création de l'application ou de l'environnement de test.
- Il est recommandé de faire un résumé des résultats après chaque exécution de test afin que les résultats d’analyse ne soient pas compilés à chaque fois que les résultats de test sont référencés.
- PT nécessite généralement de nombreux essais pour parvenir à la conclusion correcte.
- Il est bon d'avoir les points suivants dans le résumé des résultats:
- Objectif du test
- Nombre d'utilisateurs virtuels
- Résumé du scénario
- Durée du test
- Débit
- Graphiques
- Comparaison des graphiques
- Temps de réponse
- Erreur est survenue
- Recommandations
# 8) Rapport
Les résultats des tests devraient être simplifiés afin que la conclusion soit plus claire et ne devrait nécessiter aucune dérivation. L'équipe de développement a besoin de plus d'informations sur l'analyse, la comparaison des résultats et des détails sur la manière dont les résultats ont été obtenus.
logiciel pour ripper des dvd sur pc
Le rapport d'essai est considéré comme bon s'il est bref, descriptif et précis.
Comment rédiger un document de stratégie de test de performance?
Ce didacticiel explique comment écrire un exemple de stratégie de test de performances pour une application de messagerie.
N'oubliez pas que ce n'est qu'un exemple et que les exigences seront différentes d'un client à l'autre, nous apprendrons également à connaître les meilleures pratiques pour les tests de performance dans ce tutoriel.
Exemple de modèle de stratégie de test de performance
À propos de l'application de chat ABC - Supposons qu'il s'agit d'un atelier de discussion utilisé dans une entreprise par leur agent de support client, cette application de discussion utilise le protocole XMPP, c'est-à-dire le protocole de messagerie et de présence extensible et le serveur Open Fire pour l'envoi et la réception de messages instantanés.
Certaines améliorations ont été apportées à ce client de chat existant comme le contrôle à distance du PC, le diagnostic du PC, les outils de réparation, le chat en ligne, etc., donc cette stratégie de test de performance est un exemple de ces applications.
Pour cette application, supposons que l’équipe du projet a décidé d’utiliser JMeter pour les tests de performance et JIRA pour le suivi des défauts.
La première page du document de stratégie de test de performance doit contenir le titre du document et les droits d'auteur de la société.
La deuxième page doit contenir le contrôle des documents qui comprend l'historique des versions du document, la liste des réviseurs et approbateurs et la liste des contributeurs.
La troisième page doit contenir la table des matières, suivie des sujets ci-dessous.
#1. Introduction
Le but de ce document est de définir / expliquer comment les tests de performance seront effectués sur l'application de chat ABC pour l'état actuel et futur.
L'application de chat ABC est un atelier d'agent de support à distance interne. Cet atelier sera utilisé pour répondre aux demandes des clients. Cet atelier a des capacités telles que le chat en ligne, l'identification du client, le contrôle à distance du PC, le diagnostic du PC et les outils de réparation.
Objectif
Les principaux objectifs des tests de performance sont les suivants:
- Pour avoir l'assurance que les modifications apportées à l'application de chat existante sont conformes à l'accord de niveau de service défini.
- Pour garantir que les performances de l'application, la disponibilité du service et la stabilité de l'application ne sont pas affectées par les nouvelles améliorations.
- Les temps de réponse des transactions restent dans la tolérance acceptable sur le profil de charge croissant.
- Les JVM affichent une utilisation de la mémoire stable sur les profils de charge croissants.
L'image ci-dessous explique clairement le processus de test et d'optimisation des performances:
Architecture
Vous devez intégrer le diagramme d'architecture de votre projet dans cette session.
# 2) Portée
Portée
Vous trouverez ci-dessous la portée des tests de performances pour l'atelier de discussion ABC:
- Acquisition de connaissances sur les transactions commerciales clés et construction de la répartition de la charge après une étude détaillée du système.
- Identifiez les scénarios critiques pour les tests de performance avec l'aide de différentes pistes de projet.
- Utilisez les résultats de la version précédente comme référence pour les versions futures.
- Vérifiez et validez l'environnement de test des performances et l'infrastructure de l'outil de test Performance / Charge pour toute machine agent supplémentaire.
- Préparation de scripts de test de performance à l'aide de JMeter pour les scénarios identifiés qui imitent la charge de pointe identifiée.
- Configurez la surveillance des performances sur les serveurs pour surveiller le test afin d'identifier les goulots d'étranglement pendant la phase d'exécution du test.
- Publiez les résultats des tests de performance.
- Coordonner avec diverses parties prenantes pour résoudre les problèmes de performance identifiés.
- Basez le niveau de performance pour les versions futures.
Hors de portée
- Test fonctionel , UAT, test système et test de sécurité.
- Test de performance / surveillance de toutes les interfaces tierces.
- L'optimisation des performances. (La plupart du temps, le réglage est effectué par une équipe différente, si vous avez des ingénieurs de performance pour régler le système, vous pouvez l'ajouter dans l'Inscope).
- Profilage de code / dimensionnement du matériel / planification de la capacité.
- Sécurité / Test de vulnérabilité / UAT / Test de la boîte blanche .
- Génération de données pour les tests de performance.
- Tests non fonctionnels ( Par exemple, basculement, reprise après sinistre, sauvegarde, utilisabilité) autres que les tests de performances.
- Test de toute solution mobile.
- Test et réglage des performances des applications tierces.
- La réalisation des recommandations de performances, des modifications du code d'application et des modifications de la configuration des produits / serveurs prises en charge par le fournisseur sera hors de portée du point de vue de l'équipe de performance.
- Prise en charge de l'infrastructure / déploiement de la construction / préparation de l'environnement / restauration de la base de données / prise en charge du réseau, etc.
# 3) Approche
Les tests de performances pour le chat ABC seront effectués à l'aide de Jmeter en écrivant des plugins XMPP personnalisés qui utilisent une bibliothèque smack pour les connexions XMPP. Ces bibliothèques sont utilisées pour configurer les connexions, se connecter et envoyer des messages de discussion au serveur XMPP.
Ces bibliothèques sont regroupées dans un fichier jar qui est déployé dans le Jmeter et est conçu en fonction des scénarios à tester. Le banc de travail Jmeter est installé sur la machine locale qui se connecte au serveur JMeter qui possède les générateurs de charge pour générer la charge requise sur le système de serveur de conversation afin de surveiller le comportement du système.
Le scénario de test sera scripté à l'aide de l'outil JMeter. Les scripts seraient personnalisés selon les besoins. Le calendrier sera créé avec la montée en puissance requise pour simuler les scénarios du monde réel.
Le scénario de test serait divisé et mesuré dans les aspects ci-dessous:
a) Test de base: Pour exécuter chaque scénario avec 1 Vuser et plusieurs itérations afin d'identifier si les performances de l'application respectent ou non l'accord de niveau de service métier.
b) Test de charge de base: Pour répondre au Business Benchmark sous test de charge, l'équipe de test de performance effectuera un test de charge de base qui aidera à identifier tout problème de performance du système avec une charge croissante et créera la base de référence pour le prochain niveau de test de performance.
c) Test de charge de pointe / évolutivité: L'équipe de test de performance effectuera plusieurs tests avec des Vusers croissants pour répondre à la charge attendue et également pour mesurer les performances de l'application pour établir la courbe de performance et déterminer si le déploiement peut prendre en charge les accords de niveau de service sous la charge maximale des utilisateurs.
Il aide au réglage ou à la planification de la capacité des différentes machines virtuelles Java (JVM), du nombre total de JVM requis et des processeurs. Ceci sera réalisé en augmentant le nombre de Vusers à 50%, 75%, 100% et 125% de la capacité de pointe.
ré) Test d'endurance: L'équipe de test des performances exécutera ce test pendant une période de 8 heures / 16 heures / 24 heures pour identifier les fuites de mémoire, les problèmes de performances au fil du temps et la stabilité globale du système. Lors des tests d'endurance, l'équipe des tests de performance surveille les indicateurs de performance clés, tels que les temps de réponse des transactions et la stabilité de l'utilisation de la mémoire.
Les ressources système telles que le processeur, la mémoire et les E / S doivent être surveillées avec l'aide de l'équipe de projet.
L'environnement de test de performances est supposé être une réplique de l'environnement de production. Les tests seront exécutés avec une charge incrémentielle pour identifier où l'application échoue.
Scénarios de test de performance
Incluez l'Excel avec l'ensemble des scénarios.
Par exemple,
Scénario 1: Pour valider le chat Agent et client pour X no. de sessions simultanées.
Types de tests de performance
Le tableau ci-dessous explique les différents types de tests de performance ainsi que leurs objectifs.
Type de test | Objectif |
---|---|
UAT | Test d'acceptation des utilisateurs |
Test de base | Établissez les meilleures performances sous des volumes spécifiques qui seront utilisés comme référence pour les mesures ultérieures. |
Test de chargement | Mesurez les performances du système sous la charge de production maximale prévue. |
Test d'endurance | Mesure de la stabilité du système sous un volume élevé pendant une période prolongée. |
Test de stress | Mesurez les performances du système dans des conditions défavorables. |
Indicateurs de performance
- Mesures côté client
S. Non | Métrique | Description | Format |
---|---|---|---|
1 | Temps de réponse à la transaction | Temps de réponse des pages pendant l'état stable du test de performance | Graphique |
deux | Débit | La quantité de données que les VUsers ont reçues du serveur au fil du temps | Graphique |
3 | Hits / seconde | Le nombre de requêtes HTTP effectuées par les VUsers au serveur Web pendant l'exécution du scénario | Graphique |
4 | Nombre de transactions réussies / échouées | Nombre total de transactions réussies et échouées lors de l'exécution du test | Exceller |
5 | Taux d'erreur de transaction | Le pourcentage de transactions qui ont échoué lors de l'exécution du test | Graphique |
- Mesures de performances du système et du réseau
Activités de test de performance et produits livrables
# 4) Données de test
On suppose que les données d'environnement de performance seront une copie des données de production et que les données de test requises seront fournies par l'équipe de projet.
quel est le dernier système d'exploitation
# 5) Critères d'entrée et de sortie
- Accès à toutes les applications de l'environnement.
- Préparation de l'environnement terminée.
- Préparation des données de test de performance.
# 6) Gestion des défauts
- Le module de gestion des défauts dans JIRA sera utilisé dans le projet pour la journalisation des défauts et pour le suivi jusqu'à la fermeture.
- L'identification des défauts détectés pendant la phase d'exécution des tests sera capturée dans JIRA et ces défauts seront résolus par l'équipe de développement en fonction des niveaux de gravité ci-dessous.
- Des réunions d'examen des défauts auraient lieu quotidiennement avec la participation des tests, du développement, des analystes qualité et des équipes commerciales.
- Les critères de correction des défauts deviendraient rigoureux à mesure que le projet approche de la date de mise en service. Lignes directrices pour les critères de correction des défauts à publier lors des réunions d'examen des défauts.
Définition de la gravité des défauts
Les définitions des codes de gravité sont les suivantes:
Gravité | Description des problèmes de développement et d'amélioration |
---|---|
Bloqueur | Erreur système, show stopper, problèmes de réseau |
Critique | Erreurs système, pas de solution de contournement claire, interruption ou fonctionnalité métier manquante |
Majeur | Un problème grave a été détecté pour lequel il existe une solution de contournement qui peut ne pas être claire pour tous les utilisateurs, cependant, le produit ne doit pas être publié sans correction |
Moyen | Un problème existe avec une solution de contournement facile / simple, mais ce type de défaut peut être résolu après approbation par l'entreprise et / ou le chef de projet |
Faible | Problèmes cosmétiques qui n'interfèrent pas avec les fonctionnalités commerciales ou autres problèmes intermittents qui ne sont pas reproductibles à chaque fois |
# 7) Outils et techniques de test
Outils | But |
---|---|
Jmètre | Pour vérifier la charge et les performances de l'application ABC Chat. |
# 8) Critères de suspension et de reprise
Vous trouverez ci-dessous les critères critiques de suspension et de reprise qui auront un impact sur les activités de test:
Suspension | Impacter | Reprise |
---|---|---|
Environnement non configuré | Le test ne peut pas continuer | Préparation de l'environnement. |
Application jugée instable | Le test ne peut pas continuer. | Problème résolu |
Données de test non disponibles | Le test ne peut pas continuer. | Données de test prêtes |
# 9) Livrables du test
Les produits livrables du test de performance comprennent:
- Stratégie de test de performance
- Document sur les exigences de performance
- Document de scénario de test de performance
- Scripts de test de performance
- Résultats des tests de performance
# 10) Rôles et responsabilités
Les rôles et responsabilités sont clairement expliqués dans le tableau ci-dessous.
# 11) Risques potentiels et plan d'atténuation
S. Non | Risque | Probabilité | Impacter | Plan d'atténuation | Propriétaire |
---|---|---|---|---|---|
1 | Indisponibilité des données de test pour les exécutions de tests de charge de performance | H | H | Les dates estimées des exécutions des tests de performances doivent être revues et mises à jour. Support de l'équipe fonctionnelle / de développement requis pour la collecte de données. | - |
deux | Problèmes environnementaux | L | M | Re prioriser les livrables | - |
3 | Changement de fonctionnalité / conception pendant l'exécution du test de performance | M | H | Cela nécessite de retravailler les scénarios de test de performance | - |
4 | Des performances supplémentaires s'exécutent pour résoudre les problèmes de performances | M | H | Les calendriers des tests de performance seraient modifiés et mis à jour pour l'équipe produit. | - |
5 | Les estimations sont préparées sur la base d'une version de correction de bogue pour les performances. Plusieurs versions de correctifs de bogues retarderont les cycles de test et finalement cela dépendra du moment où la prochaine version sera disponible pour une réexécution. | H | H | Redéfinissez la priorité des cycles d'exécution des tests de performance. | - |
6 | Disponibilité du matériel | M | H | La date de début du calendrier serait déplacée en conséquence. | - |
# 12) Hypothèses
- L'environnement de test de performance sera une réplique du paysage de l'architecture du produit. (c'est-à-dire le matériel, les logiciels, les interfaces, les couches d'intégration, etc. corrects).
- Les scripts de performance seront conçus en fonction des flux critiques pour lesquels l'utilisation est élevée.
- Tous les problèmes d'infrastructure doivent être résolus avant le début des tests de performances. Toute modification de la configuration du système effectuée ultérieurement invalidera les résultats du test.
- Une application est stable et prête à être utilisée dans l'environnement de test de performances.
- Les ressources matérielles et logicielles nécessaires (comme les machines / logiciels générateurs de charge, les machines contrôleur / agent) sont mises à disposition.
- Toute modification de la portée passera par un processus de contrôle des modifications et l'équipe de test de performance évaluera l'impact des délais et des ressources.
- Les serveurs respectifs doivent gérer la charge.
- Les journaux de suivi des applications doivent être activés pour les systèmes de prise en charge à des fins de surveillance.
# 13) Dépendances
- Disponibilité de l'environnement de test de performance qui est une réplique du paysage de l'architecture du produit.
- Support requis de la part de diverses équipes fonctionnelles, de développement, de bases de données et d'infrastructure pendant les étapes de préparation et d'exécution des tests.
- Aucun changement de code n'est implémenté pendant toute la phase de test de performance car le temps est très limité.
- En cas de problèmes imprévus qui entraînent des restrictions dans les délais, si les délais ne permettent pas de respecter toutes les étendues de test dans les délais d'origine, une assistance est disponible auprès des responsables de la publication, afin de fournir une décision de cadrage et de hiérarchisation.
- Les utilisateurs professionnels des applications / experts en la matière seront mis à disposition pour des clarifications fonctionnelles et la signature des transactions commerciales.
- Le responsable du programme de discussion ABC examinera et approuvera.
# 14) Abréviations
Abréviation | Description |
---|---|
DB | Base de données |
Http | Protocole de transfert hypertexte |
JDBC | Connectivité de base de données Java |
AQ | Assurance qualité |
SALADE | Accord de niveau de service |
PME | Expert en la matière |
À présent, vous devez avoir clairement compris comment rédiger une stratégie de test de performance efficace pour une application de messagerie.
Meilleures pratiques pour des tests de performances réalistes
Afin de mener à bien un projet de test de performance, nous devons nous assurer que nous le faisons de la bonne manière dès la phase de planification, c'est-à-dire la planification, le développement, l'exécution et l'analyse.
Examinons chaque étape en détail afin de réaliser efficacement les tests de performances.
# 1) Planification
- Essayez d'identifier les workflows les plus courants, c'est-à-dire les scénarios commerciaux à tester. Si l'application est existante, vérifiez les journaux du serveur pour comprendre les scénarios les plus fréquemment utilisés. Si l'application est nouvelle, parlez-en à l'équipe de gestion de projet pour comprendre le flux commercial majeur.
- Planifiez le test de charge de manière à couvrir un large éventail de flux de travail tels que l'utilisation légère, l'utilisation moyenne et les charges de pointe.
- Vous devez effectuer de nombreux cycles du test de charge, essayez donc de créer un cadre afin de pouvoir utiliser les mêmes scripts encore et encore. Essayez également d'avoir une sauvegarde des scripts.
- Essayez d'analyser la durée d'un test, est-ce une heure? 8 heures? Un jour ou une semaine? Habituellement, les tests de longue durée découvriront de nombreux défauts majeurs tels que les bogues du système d'exploitation, les fuites de mémoire, etc.
- Si votre organisation utilise un APM (Application Monitoring Tool), vous pouvez l'inclure lors des tests afin de pouvoir facilement identifier les problèmes de performances et identifier la cause première plus facilement.
# 2) Développement
- Lors du développement des scripts, c'est-à-dire de l'enregistrement, essayez de donner un nom de transaction plus significatif en fonction des noms de flux métier mentionnés dans le plan.
- N'enregistrez aucune application tierce et si elle est enregistrée, essayez de la filtrer tout en améliorant les scripts.
- Toutes les valeurs dynamiques ne peuvent pas être corrélées à l'aide de la fonction d'autocorrélation de l'outil, essayez donc de faire une corrélation manuelle pour éviter les erreurs.
- Essayez de concevoir vos tests de performances de manière à toucher le backend de l'application et pas seulement le serveur de cache.
# 3) Exécution
- Assurez-vous d'exécuter les tests dans un environnement de production, y compris des facteurs tels que SSL, l'équilibreur de charge et les pare-feu. Ceci est nécessaire pour simuler une charge réaliste sur le système.
- Essayez de créer une charge de travail très réaliste, vous pouvez l'obtenir en vérifiant les journaux du serveur s'il s'agit d'une application existante et s'il s'agit d'une nouvelle application, vous devez obtenir ces informations auprès de l'équipe commerciale. N'oubliez pas que la charge de travail est très importante pour réussir les tests de performance.
- Ne parvenez jamais à une conclusion en exécutant des tests avec la moitié de l'environnement de production, il est toujours conseillé de réaliser des tests dans un environnement qui est exactement le même que la production.
- Lors de l'exécution de tests de longue durée, essayez de regarder l'analyse à intervalles fréquents afin de vous assurer que le test se déroule correctement.
# 4) Analyse
- Essayez d'analyser l'application en ajoutant d'abord quelques compteurs importants, lorsqu'un goulot d'étranglement est détecté, puis essayez d'ajouter des compteurs supplémentaires par rapport au goulot d'étranglement. Ceci, à son tour, aidera à trouver le problème plus facilement.
- Une application peut échouer pour de nombreuses raisons, comme elle peut ne pas répondre à une demande, répondre avec un code d'erreur, échouer votre logique de validation ou répondre trop lentement. Essayez donc d'examiner tout cela avant d'arriver à une conclusion.
Conclusion
Je suis sûr que ce didacticiel vous aurait donné d'immenses connaissances sur les tests de performance et comment rédiger un document de stratégie de test de performance avec des exemples détaillés.
Dans notre prochain tutoriel, nous apprendrons en détail les différences entre les tests de performance, de charge et de contrainte.
Vérifiez également => Série de formation approfondie gratuite LoadRunner
lecture recommandée
- Test de performance vs test de charge vs test de stress (différence)
- Test de charge avec les didacticiels HP LoadRunner
- Cloud Performance Testing: fournisseurs de services de test de charge basés sur le cloud
- Test de charge, de stress et de performance des applications Web à l'aide de WAPT
- Outils et services de test des performances du site Web
- Comment effectuer des tests de performances manuels?
- Test des performances des applications mobiles à l'aide de BlazeMeter
- Test des performances des services Web à l'aide du script LoadRunner VuGen