Lorsqu’il s’agit de tests de charge, il y a toujours la question à un million de dollars: « En termes de performances, que veut faire le client avec son application et son système? » Je suis sûr que vous n’obtiendrez jamais une réponse facile à cette question, et la plupart d’entre nous toujours assumer certaines choses et effectuer les tests de performance, qui peuvent finir par manquer des pièces critiques de test, et se retrouver avec un client malheureux. Un client malheureux signifie une perte d’entreprise pour votre organisation et une carrière en déclin en tant qu’ingénieur de performance. Mais ne vous inquiétez pas, dans cet article, nous allons parler de la création d’une liste de contrôle qui vous aidera avec ces questions.
Cette liste de contrôle ressemble davantage à un processus étape par étape que vous pouvez suivre et adapter à votre cycle de vie de test de performance. Dans le scénario discuté, nous ne pouvons pas toujours blâmer nos clients, parce qu’au départ, ils ne savent peut-être pas quels sont les résultats exacts de performance qu’ils veulent, mais ils ont une connaissance claire sur la façon dont l’application fonctionne dans des conditions différentes. Un bon testeur de performance peut gérer cette ambiguïté avec un questionnaire bien défini. Et c’est le tout premier point de la liste de vérification, le questionnaire de collecte des exigences.
Questionnaire de collecte des besoins
Vous trouverez ci-dessous un format de questionnaire que vous pouvez suivre dans votre projet. Nous devons obtenir le plus de réponses possible à ces questions. Il sera préférable que vous puissiez avoir un appel pour discuter de ces questions. Assurez-vous que l’architecte ou le développeur de l’application se joint à l’appel avec vous et le client. Avoir du personnel supplémentaire peut vous aider à fournir un aperçu et à découvrir des questions que vous n’avez peut-être pas déjà examinées. Les questions ci-dessous vous fournissent une feuille de route pour créer un test de charge plus efficace et plus efficace.
Non | sujet | questionne |
1 | application | Type d’application à considérer pour les tests (par exemple, application Web/ application mobile, etc.). |
2 | Architecture d’application et technologie/plate-forme. | |
3 | Technique d’équilibrage de charge utilisée. | |
4 | Protocole de communication entre le client et le serveur (par exemple: HTTP/S, FTP). | |
5 | Objectif de test de performance. Mesures de performance à surveiller (par exemple, temps de réponse pour chacune des actions, utilisateurs simultanés, etc.). | |
6 | Scénarios critiques à prendre en compte pour les tests de performance. | |
7 | Détails des travaux/processus planifiés d’arrière-plan, le cas échéant. | |
8 | Technique utilisée pour la gestion des sessions et nombre de sessions parallèles prises en charge. | |
9 | Client SLA/ Exigences | Nombre prévu d’utilisateurs simultanés et base totale d’utilisateurs. Distribution par les utilisateurs pour les scénarios en portée. |
10 | SLA pour toutes les transactions en portée pour PT (débit attendu, temps de réponse, etc.). | |
11 | Types de tests de performance à effectuer (tests de charge, tests d’endurance, etc.). | |
12 | Système/Environnement | Testez les détails de l’environnement (web/app/DB, etc., ainsi que le nombre de nœuds). Environnement de production recommandé pour l’exécution des tests de performance. |
13 | Comparaison de l’environnement de production et de l’environnement de test de performance. | |
14 | Si l’application doit être isolée lors de l’exécution du test de performance pour éviter l’interaction avec d’autres applications. | |
15 | Détails du mécanisme d’enregistrement intégré ou du mécanisme de surveillance. | |
16 | autrui | Résultats de base des performances de l’application. |
17 | Problèmes de performances actuels, le cas échéant. |
Les réponses à ces questions vous aideront à créer une stratégie de test de qualité / plan de test. Si le client n’est pas en mesure de fournir des réponses à toutes ces questions, pas besoin de s’inquiéter. Nous pouvons toujours explorer l’application à l’essai et trouver les réponses. Par exemple, si un outil APM/log est en place, nous pouvons déduire les utilisateurs simultanés, le débit et le temps de réponse du système de production. Ne présumez jamais que vous obtiendrez ce dont vous avez besoin sans demander.
Trouver un outil de test de performance approprié
Un testeur de performance doit choisir soigneusement le meilleur outil de test de performance. Il ya beaucoup de facteurs qui doivent prendre en considération avant de finaliser et de proposer l’outil. N’oubliez pas que le budget du client est toujours un facteur important lors du choix de l’outil de test de performance.
Si vous êtes à la recherche d’un outil de test de performance qui est rentable, facile à utiliser, et peut fournir une solution de performance complète, vous devriez certainement essayer LoadView. Par rapport aux outils de test de charge traditionnels, LoadView ne nécessite aucun investissement coûteux, aucune configuration fastidieuse ou aucune connaissance préalable des frameworks de script. En outre, la plate-forme fournit plus de 20 emplacements mondiaux pour les injecteurs de charge spin-up à partir, de sorte que vous pouvez tester et mesurer les performances à partir de plusieurs emplacements au cours de chaque test.
Tous les types de tests de performance nécessitent du temps et des efforts. Effectuer des tests de charge peut sauver une organisation de l’humiliation potentielle, mais en même temps les tests sur l’outil open source gratuit comme JMeter ne justifieront pas l’investissement. Lorsqu’il s’agit de vraiment comprendre les performances d’un site Web ou d’une application du point de vue de l’utilisateur final, les tests basés sur des protocoles ne suffisent pas. Vous devez également mesurer les performances des interactions et des étapes côté client. Voici une comparaison de LoadView avec d’autres solutions de test de performances/charge et pourquoi devriez-vous choisir LoadView pour vos exigences de test de performances.
Lorsqu’il s’agit de ralentir le chargement des sites et des applications, les clients peuvent s’impatienter rapidement et partir et trouver un remplaçant si votre site/application ne répond pas à leurs attentes. Savoir combien votre site / application peut gérer est très important pour diverses raisons, mais il ya plusieurs scénarios importants que la plate-forme LoadView peut aider avec:
- Adaptabilité et évolutivité. Déterminer pourquoi votre site ou application ralentit lorsque plusieurs utilisateurs y accèdent.
- Infrastructure. Comprendre les mises à niveau matérielles nécessaires, le cas échéant. Le coût de la mise en œuvre du matériel supplémentaire et de son entretien pourrait être un gaspillage potentiel de ressources.
- Exigences de performance. Votre site ou application peut gérer correctement quelques utilisateurs, mais que se passe-t-il dans des situations réelles ?
- Services tiers. Voyez comment les services externes se comportent lorsque les conditions normales, voire maximales, de charge sont présentées.
Plan/stratégie de test de performance
Une fois que vous avez recueilli les exigences des clients et sélectionné un outil de test de performance approprié, nous devons documenter notre plan de test / stratégie de test. Assurez-vous d’obtenir l’inscription du plan de test du client avant de commencer toutes les activités de performance. C’est très important, et il vous aidera à éviter tout pépin inutile plus tard. Ce sont quelques points qui doivent être inclus dans le plan de test.
- Objectifs de test de performance. Ce que nous allons réaliser.
- Portée du projet. Quelle est la portée du projet, exemple: Nombre de scripts, combien de temps nous devons tester, etc.
- Architecture de l’application. Détails de l’application tels que le serveur d’application, serveur DB, vous pouvez inclure diagramme architectural si vous l’avez.
- Détails de l’environnement. Détails sur l’environnement que nous allons tester. Il est toujours bon d’avoir un environnement isolé pour les tests de performance.
- Configuration de l’infrastructure. Configuration initiale pour les tests de performances (par exemple, environnement cloud, installation d’outils, etc.).
- Approche de test de performance. Comment on va faire le test. Nous devrions commencer par un test de base avec un plus petit nombre d’utilisateurs, puis progressivement nous pouvons augmenter les utilisateurs et effectuer différents types de tests comme le stress, l’endurance, etc.
- Critères d’entrée et de sortie. C’est très important. Nous devrions toujours commencer les tests de performance lorsqu’il n’y a pas de défauts fonctionnels. De la même façon que nous devrions documenter quand nous pouvons arrêter les tests de performance.
- Gestion des défauts. Nous devrions suivre le même outil et les mêmes pratiques suivies par le client pour enregistrer les défauts liés aux tests de performances.
- Rôles et responsabilités. Détails sur les porteurs de participation impliqués dans les différentes activités lors des tests de performance.
- Hypothèses et risques. S’il y a des objectifs qui peuvent être un risque pour les tests de rendement, nous devrions le documenter.
- Stratégie de données de test. Détails sur la stratégie de données de test et comment pouvons-nous l’extraire.
- Calendrier du plan de test et livrables clés. Chronologie du script, de l’exécution des tests, de l’analyse et des livrables pour l’examen des clients.
Les tests de performance réels reposent sur une combinaison de techniques. Pour atteindre les objectifs escomptés, nous devons préparer une stratégie différente pour différentes exigences en matière de tests de performance. Il existe différentes mesures, telles que la charge utilisateur, les utilisateurs simultanés, les modèles de charge de travail, etc., qui doivent être pris en compte avant de planifier la charge. Si vous avez déjà travaillé sur la modélisation de la charge de travail, vous auriez entendu parler de la loi de Little. Vous devez l’apprendre et le mettre en œuvre avant de planifier un test pour obtenir les résultats souhaités.
Scripts/scénarios de performances en temps réel
Une fois que nous avons conclu une entente avec le client sur le plan/stratégie de performance, nous devrions commencer la préparation pour le script à l’aide de l’outil convenu de test de performance.
Les éléments bulleted suivants sont quelques-uns des points que nous devons nous rappeler de construire des scripts de qualité:
- Passez toujours avec les étapes documentées de cas de test tout en faisant des scripts.
- Rejouez et corrigez les exigences de corrélation pour un seul utilisateur.
- Rejouez et corrigez les exigences de paramétrisation pour un seul utilisateur. La paramétrisation peut être n’importe où les en-têtes, les cookies et les paramètres du corps.
- Une fois que le script est réussi avec des données utilisateur unique, exécutez plusieurs itérations avec différents utilisateurs. Une corrélation/paramétrisation supplémentaire peut être nécessaire pour différentes données utilisateur.
- Dans certains cas, pour atteindre certains cas d’utilisation, nous pouvons avoir besoin d’écrire bloc de code. Par exemple, sélectionner une donnée de réponse particulière pour un utilisateur et la manipuler à une autre demande.
- Ajoutez du temps de réflexion, du rythme, du traitement des erreurs pour le script en fonction du modèle de charge de travail.
- Vérification de texte/vérification d’image également étape très importante dans le script.
En plus des étapes ci-dessus, il y aura des exigences pour la simulation de cache / cookies et les conditions du réseau. Un bon ingénieur de performance doit tenir compte de tous ces facteurs avant de commencer l’exécution. L’ingénieur de test de performance devrait également développer les modèles les plus réalistes de comportement des utilisateurs virtuels. Pour ce faire, il est crucial d’obtenir la bonne réponse par le biais du questionnaire de collecte des besoins.
- Quel est le nombre total d’utilisateurs travaillant avec l’application, en supposant un nombre moyen par heure d’ouverture?
- Quelles actions les utilisateurs effectuent-ils et à quelle fréquence ?
- Combien d’utilisateurs travaillent avec l’application pendant les heures de pointe ?
Les réponses aux questions ci-dessus peuvent être obtenues au moyen d’un questionnaire de collecte d’exigences ou d’une donnée statistique recueillie à l’aide d’outils d’analyse web tels que les outils APM/Google Analytics. L’analyse des transactions permet de trouver d’importantes transactions commerciales et de concevoir des scénarios de test de performances qui seront utilisés pour l’exécution des tests de performance.
Modélisation de la charge de travail
Nous pouvons planifier notre modèle de charge de travail de différentes façons. Les ingénieurs en performance devraient apprendre et mettre en pratique le concept de « loi de Little » avant de choisir un modèle de charge de travail. Voici quelques-uns des modèles de charge de travail existants. Encore une fois, l’ingénieur de performance doit choisir le modèle de charge de travail en fonction des exigences en main.
Modèle de charge de travail 1. C’est juste un modèle simple, où le nombre d’utilisateurs sera augmenté en permanence au fur et à mesure que le test progresse. Exemple : un utilisateur par seconde jusqu’à ce que le test soit terminé.
Modèle de charge de travail 2. Dans ce modèle, le nombre d’utilisateurs sera augmenté comme une étape pendant toute la durée du test. Par exemple, les 15 premières minutes seront de 100 utilisateurs et les 15 prochaines minutes seront de 200, etc. Nous pouvons planifier ce type de test pour les tests d’endurance.
Modèle de charge de travail 3. Il s’agit du modèle de test de performance le plus courant. Le nombre d’utilisateurs sera continuellement augmenté pendant un certain temps (Nous appelons cela la période de montée en puissance). Après cela, les utilisateurs auront un état stable pour une certaine durée. Ensuite, les utilisateurs commenceront la rampe vers le bas et le test se terminera. Par exemple, si nous prévoyons 1,5 heure de test, nous pouvons donner 15 minutes pour augmenter les utilisateurs et 15 minutes pour la montée en puissance. L’état stable sera d’une heure. Lorsque nous analysons les résultats, nous ne prendons que l’état stable pour examen.
Modèle de charge de travail 4. Dans ce modèle, le nombre d’utilisateurs sera augmenté et diminué soudainement pendant toute la durée. Il existe différents noms pour ce type de test, comme les tests de singes, les tests de pointes, etc.
Nous devons établir un ensemble complet d’objectifs et d’exigences pour les tests de performance. Définissez les paramètres de test de performance et ce qui constitue des critères d’acceptation pour chacun d’eux. Si vous ne connaissez pas les exigences de test, ni le résultat souhaité, les tests de performance sont une perte de temps.
Collecte de données
Voici quelques-unes des mesures très importantes à observer lors de la modélisation de la charge de travail de performance.
Temps de réponse : Le temps de réponse est le temps que le serveur a pris pour répondre à la demande du client. Il ya beaucoup de facteurs qui affecteront le temps de réponse du serveur. Le test de charge aidera à trouver et à éliminer les facteurs qui dégradent le temps de réponse.
Temps de réponse moyen : Il s’agit de la valeur moyenne du temps de réponse pendant toute la durée de l’état stable dans un test de charge.
Temps de réponse de 90 percentiles : Le temps de réponse du 90e percentile signifie que 90 p. 100 du temps de réponse est inférieur à cette valeur. Par exemple, si vous aviez 500 demandes et que chacune a un temps de réponse différent, alors le 90e percentile est une valeur dont 90 pour cent de toutes les autres valeurs sont inférieures à 90 le percentile. Seulement 10 p. 100 du temps de réponse sera supérieur à la valeur de 90 percentiles. Ceci sera utile si une partie de votre demande a un temps de réponse énorme et ils sont biaisant le résultat moyen du temps de réponse.
Demandes par seconde : Nous devons trouver cette valeur à partir des outils APM ou à l’aide de journaux de production. Sur la base des utilisateurs simultanés, nous pouvons planifier la demande par seconde au serveur.
Utilisation de la mémoire : Il s’y a des mesures côté infrastructure qui vous aident à découvrir les goulots d’étranglement. En outre, vous devez planifier votre charge de travail en temps réel que possible. Assurez-vous que nous ne bombardons pas le serveur de demandes continues.
Utilisation du Processeur : Même que la mémoire et le besoin d’avoir un œil sur ces mesures tout en exécutant les tests de performance.
Taux d’erreur: Nous devrions garder une trace du ratio de transactions passées/erreurs. Le taux d’erreur ne devrait pas être supérieur à 2 % des transactions passées. Si les taux d’erreur augmentent au fur et à mesure que les utilisateurs simultanés augmentent, il peut y avoir un goulot d’étranglement potentiel.
Utilisateurs simultanés : Nous devons trouver cette valeur à partir des outils APM ou à l’aide de journaux de production. Habituellement, nous trouvons cette valeur basée sur un jour ouvrable typique.
Débit: Le débit affichera la capacité du serveur à gérer les utilisateurs simultanés. Il existe une connexion directe entre les utilisateurs simultanés et le débit. Le débit devrait augmenter à mesure que le nombre d’utilisateurs augmente pour accéder à l’application. Si le débit diminue à mesure que le nombre d’utilisateurs augmente, c’est une indication possible de goulots d’étranglement.
Répartition de la charge utilisateur : La répartition de la charge utilisateur est l’un des facteurs importants qui doivent être pris en compte lors de la conception de la charge de travail. Si nous avons cinq scripts qui effectuent cinq fonctionnalités différentes d’une application, nous devons diviser la charge utilisateur en réel que possible sur la base de notre enquête sur la production ou les outils APM.
Ce sont des mesures très importantes que nous devrions garder à l’esprit lors de la conception du modèle de charge de travail. Il y aura d’autres mesures ainsi que dépend de l’architecture d’application client et les exigences.
Liste de contrôle pour l’environnement de test de performance (avant l’exécution)
L’exemple de liste de contrôle ci-dessous est généralement suivi de tests de performance de bout en bout au niveau de l’entreprise, où il y a un grand nombre de systèmes impliqués. Il est toujours recommandé de suivre une liste de contrôle de l’environnement pour les tests de performance à petite échelle. Les activités changeront en fonction des environnements d’application, car il y a une énorme différence lorsque nous la comparons avec l’application sur le cloud par rapport à l’application sur place.
Conclusion : Liste de vérification de préparation des tests de charge
Le succès des tests de performances logicielles ne se fait pas par hasard. Les architectes, les propriétaires de produits, les développeurs et l’équipe de test de performance doivent travailler ensemble et répondre aux exigences de test de performance avant d’évaluer le logiciel. Pour un contexte plus détaillé sur la plate-forme LoadView, lisez notre article Aperçu technique pour voir comment tirer parti au maximum de vos tests de performances. Les tests de performance devraient être un processus continu. Lorsque votre site Web ou votre application Web commence à croître, vous devrez apporter des modifications pour répondre à une plus grande base d’utilisateurs. Il ya toujours une chance d’amélioration dans toute application et des tests.
Nous espérons que cela vous a donné un bon aperçu des meilleures pratiques en matière de tests de performance. Si vous souhaitez une démonstration complète de la solution LoadView, inscrivez-vous à une démo avec un ingénieur de performance. Ils vous emmèneront étape par étape à travers chaque partie du processus, de la création de scripts de test de charge et de configuration de test, à l’exécution des tests et l’analyse des résultats.
Ou inscrivez-vous à l’essai gratuit LoadView pour commencer à exécuter des tests de charge dès maintenant. Nous vous donnerons des tests de charge gratuits pour commencer! Joyeux test de charge!