Tests de performance basés sur les objectifs

Les tests de performance basés sur les objectifs sont une stratégie employée dans les tests de logiciels, en particulier les tests de performance, pour s’assurer que les systèmes logiciels répondent à des objectifs de performance spécifiques dans diverses conditions. Dans les tests de performance basés sur les objectifs, le processus de test est guidé par des buts ou des objectifs prédéfinis plutôt que de simplement tester pour le plaisir.

Les tests basés sur les objectifs fonctionnent selon les étapes suivantes :

1. Définition des objectifs de performance : La première étape consiste à définir quels objectifs de performance sont importants pour le système logiciel testé. Ces objectifs peuvent inclure des seuils de temps de réponse, des exigences de débit, des objectifs d’utilisation des ressources et des repères d’évolutivité.
2. Conception de scénarios de test : Les scénarios de test sont conçus en fonction des objectifs de performances que vous avez définis. Ces scénarios simulent différents comportements utilisateur, charges et configurations système afin d’évaluer les performances du logiciel dans diverses conditions. Par exemple, les scénarios peuvent inclure des périodes de pointe d’utilisation, des charges de transactions importantes ou des pics soudains d’activité des utilisateurs.
3. Exécution des tests : Les scénarios de test sont exécutés sur le système logiciel conformément aux exigences de test. Au cours de cette phase, les indicateurs de performance tels que les temps de réponse, le débit, l’utilisation des ressources et l’évolutivité du système sont mesurés et surveillés.
4. Analyse des résultats et amélioration : Les données de performance collectées sont analysées pour évaluer si le système répond aux objectifs prédéfinis. Cette analyse permet d’identifier les goulots d’étranglement des performances, les limitations d’évolutivité et les domaines dans lesquels le système peut ne pas répondre aux exigences de performances. Sur la base de l’analyse des résultats des tests, apportez les améliorations et optimisations nécessaires à votre système logiciel.
5. Répétition du processus : Les tests de performance basés sur les objectifs sont un processus itératif. Après avoir apporté des améliorations, le cycle de test est répété pour valider si les objectifs de performance ont été atteints et pour identifier tout nouveau problème de performance qui aurait pu survenir.

Les tests de performance se concentrent principalement sur la vérification de la vitesse et de la fiabilité d’une application, divisés en tests de charge (qui sont axés sur les objectifs) et en tests de résistance. Avec l’essor des méthodes de développement agiles, il est devenu crucial de s’assurer que les résultats des tests de charge peuvent être facilement reproduits.

L’importance de définir des objectifs de performance

La définition d’objectifs de performance est la pierre angulaire des tests de performance basés sur les objectifs. Ces objectifs servent de critère à l’aune duquel les performances du logiciel sont mesurées. Ils fournissent un cadre tangible pour évaluer si le logiciel répond à ses exigences de performance dans diverses conditions, y compris une utilisation normale, des pics de charge et des scénarios de stress.

Principales raisons d’effectuer des tests de performance basés sur les objectifs

• S’aligner sur les attentes des parties prenantes : En définissant des objectifs de performance spécifiques, vous vous assurez que les performances de votre logiciel correspondent aux attentes des parties prenantes, y compris les utilisateurs finaux, les clients et les sponsors de projet.
• Validation des exigences de performance : Les tests basés sur les objectifs permettent de valider si votre logiciel répond à ses exigences de performance, en fournissant des mesures concrètes pour évaluer l’adéquation des performances.
• Optimisation de l’utilisation des ressources : Les tests basés sur les objectifs permettent d’optimiser l’utilisation des ressources en identifiant les inefficacités ou la surutilisation des ressources système, ce qui permet une allocation plus efficace des ressources et des économies de coûts.
• Évolutivité : En mesurant les performances en cas d’augmentation des charges ou de la simultanéité des utilisateurs, les tests basés sur les objectifs évaluent l’évolutivité de votre logiciel, garantissant ainsi qu’il peut gérer des bases d’utilisateurs et des charges de travail croissantes.
• Atténuation des risques : Les tests proactifs par rapport à des objectifs de performance prédéfinis permettent d’identifier et d’atténuer les risques liés aux performances avant de déployer le logiciel, réduisant ainsi la probabilité de temps d’arrêt, d’insatisfaction des utilisateurs ou de pertes financières.

Cas d’utilisation basé sur les objectifs : problème

Supposons que 20 utilisateurs simultanés génèrent 2 000 transactions par heure dans votre nouvelle application CRM. Votre objectif est de concevoir un test de performance garantissant un temps de réponse de huit secondes pour les quatre prochaines versions. Les tests de résistance peuvent ne pas reproduire précisément le débit attendu dans ces versions à venir, car les temps de réponse peuvent varier de ceux de la version actuelle.

Cas d’utilisation basé sur les objectifs : solution

1. Intégrez ThinkTimes dans vos scripts pour introduire des pauses entre les actions de l’utilisateur.
2. Déterminez la ligne de base et mesurez le temps d’exécution des scripts mono-utilisateur pour calculer la durée de la session.
3. Configurez les paramètres de charge de travail, y compris le nombre maximal d’utilisateurs, le taux de transaction basé sur les objectifs et le temps de transaction basé sur les objectifs.
4. Exécutez le test de performance basé sur les objectifs pour simuler la charge attendue sur l’application.
5. Examinez le rapport de test pour vérifier si l’application a réussi à gérer la charge dans les limites de temps de réponse prédéfinies.
6. Répétez la série de tests dans les quatre versions suivantes pour évaluer si l’application maintient les seuils de débit et de temps de réponse au fil du temps.

Recommandations et conseils pour la configuration de l’outil EveryStep de LoadView

ThinkTime (obligatoire) :

• Créez de nouveaux mots-clés dans l’enregistreur Web EveryStep (ThinkTimes) ou réutilisez des mots-clés existants.
• Assurez-vous que les valeurs autorisées sont des virgules flottantes comprises entre 0,0 et 999,99.
• Autorisez les utilisateurs à ajouter manuellement des ThinkTimes à des scripts.
• N’oubliez pas que ThinkTimes représente les temps d’attente et qu’il est automatiquement ajouté par EveryStep Web Recorder lors de l’enregistrement des actions de l’utilisateur.
• Plusieurs ThinkTimes peuvent exister dans un seul script.
• Les ThinkTimes ne sont pas pris en compte dans les exécutions de tests à script unique.
• ThinkTimes sera utilisé dans Calibration/Get Baseline.
• ThinkTimes ne contribue pas aux mesures du temps de réponse.
• Les ThinkTimes sont ignorés dans les tests de résistance.

Simultanéité de l’utilisateur (facultatif) :

• Introduisez un nouveau mot-clé « WaitFor (Number of users) » dans l’enregistreur Web EveryStep.
• Ce point d’attente global bloque les utilisateurs simulés dans une section de script spécifique jusqu’à ce que le nombre attendu d’utilisateurs atteigne cette partie du script.

Seuils de temps de réponse (facultatif) :

• Implémentez le nouveau mot-clé SetBoundary dans EveryStep Web Recorder.
• Syntaxe : SetBoundary(Timername, Bound 1, Bound 2).

Ligne de base/étalonnage (obligatoire) :

• LoadView exécute une série de tests utilisateur unique.
• ThinkTimes sera utilisé comme scripté.
• LoadView calcule la durée de la session : Session Time = temps d’exécution du script + ThinkTime.

Configurer la charge de travail/le plan d’exécution (obligatoire) :

• Les clients spécifient le temps de montée en puissance.
• Les clients définissent leur objectif de taux de transaction.
• Les clients fixent un objectif de durée de session.
• Le système calcule le nombre d’utilisateurs.
• Les clients décident s’ils calculent ou non les temps de réponse lors de la montée en puissance.

Exécuter le test (obligatoire) :

• LoadView exécute le test en fonction de la charge de travail/du plan d’exécution configuré.
• LoadView collecte les temps de réponse des scripts ou des transactions simulés.
• LoadView ajuste dynamiquement ThinkTime pour atteindre le débit attendu. si l’application testée ralentit, les ThinkTimes sont réduits. Si les ThinkTimes sont égaux à zéro et que la durée de la session dépasse la durée de session cible, un message d’erreur s’affiche indiquant que le débit attendu n’a pas pu être atteint.
• LoadView calcule les temps de réponse des transactions réelles et des timers sans ThinkTimes.

Recommandations et conseils pour l’intégration avec Dotcom-Monitor

Enregistreur Web EveryStep

• Présentation de nouveaux mots-clés ThinkTime.
• Ignorez ThinkTime lors des exécutions de tests mono-utilisateur.
• Ajoutez ThinkTime pendant l’enregistrement du script.
• Introduisez le nouveau mot-clé WaitFor(Number user).
• Introduisez le nouveau mot-clé SetBoundary(TimerName, B1, B2).
• Le mot-clé WaitFor doit être ajouté manuellement aux scripts créés.
• Utilisez le mot-clé SetBoundary.

Étalonnage/Obtenir la ligne de base

• Calculez la durée de la session pendant l’étalonnage.

Plan d’exécution/charge de travail

Option 1:

• Ajoutez une nouvelle fonctionnalité de configuration de la charge de travail.
• Remplacez le plan d’exécution par la fonction Charge de travail.
• Créez une boîte de dialogue de configuration de la charge de travail pour prendre en charge les tests de contrainte, les objectifs de transaction et d’autres types.
• Spécifiez le temps de montée en puissance.
• Cochez la case de calcul des temps de réponse lors de la montée en puissance (oui/non).

Option 2:

• Utilisez la fonctionnalité de configuration améliorée du plan d’exécution.
• Sélectionnez le type de test (stress, basé sur les objectifs).
• Définissez les détails de l’objectif de transaction.
• Spécifiez le temps de montée en puissance.
• Cochez la case de calcul des temps de réponse lors de la montée en puissance (oui/non).

Exécuter le test

• Calculez le temps réel d’exécution du script/le temps de session.
• Ajustez dynamiquement ThinkTimes en fonction de la durée réelle de la session.
• Déclenchez un avertissement si le débit prévu n’a pas pu être atteint.

rapport

• Configurez une section pour le temps de réponse, les seuils réels et les seuils par minuteur.
• Configurez une section pour le débit, réel et attendu.

Conseils pour l’intégration avec Dotcom-Monitor : FAQ

Quelles sont les entrées utilisateur ?

• ThinkTimes (Point flottant, > 0)
• Transactions de but par heure (Integer)
• Nombre maximum d’utilisateurs (Integer)
• Temps de montée en puissance (minutes)
• Calculer le temps de réponse pendant la montée en puissance (Oui / Non)

Qu’est-ce que la ligne de base ?

Une exécution par un seul utilisateur de l’appareil ou du script, intégrant ThinkTimes. Le temps d’exécution du script est calculé et stocké en tant que temps de session, ainsi que des détails supplémentaires tels que les ressources d’exécution requises.

Comment pouvez-vous ajuster dynamiquement le test de charge si la vitesse de transaction change sur le système cible ?

• Calculer le temps de session pendant l’étalonnage
• Utilisez ThinkTimes pour atteindre le temps de session d’objectif demandé
• Recalculer le temps de session réel pendant l’exécution du test
• Ajuster dynamiquement ThinkTimes en fonction de l’heure réelle de la session
• Enregistrez le message d’erreur si le temps d’exécution du script est > le temps de la session d’objectif
• Spécifiez le nombre d’utilisateurs maximum dans le calcul de la charge de travail

Qu’est-ce que le mot clé WaitFor ?

Cela simule des scénarios utilisateur complexes, en particulier des situations de concurrence, ce qui est utile pour tester si certaines fonctionnalités fonctionnent correctement avec plusieurs utilisateurs accédant simultanément à une ressource.

Qu’est-ce que le mot clé SetBoundary ?

Permet de vérifier la vitesse réelle d’une action ou d’un minuteur par rapport aux limites de temps de réponse SLA spécifiées. Si la limite autorisée n’est pas respectée, un message d’erreur s’affiche et est consigné dans le rapport de test, ce qui simplifie la vérification du SLA.

Quels devraient être vos objectifs pour votre test de charge?

• Assurez-vous que les tests de performances sont comparables à 100 % sur différentes versions/exécutions.
• Incluez des fonctionnalités permettant de simuler des modèles de charge réguliers ou de pointe.
• Assurez-vous que le système testé peut supporter la charge attendue dans les limites convenues.
• Concentrez l’optimisation des performances sur les actions des utilisateurs qui enfreignent les limites convenues.

Quel type de rapports devez-vous configurer ?

• Créez des rapports similaires aux rapports actuels.
• Incluez les temps de réponse Avg, Min, Max, Stddev, Percentile.
• Suivi des transactions ok, Transactions échouées et Taux d’erreur.
• Tous les temps de réponse doivent être sans l’inclusion de ThinkTimes.

Limitations

Des durées de session élevées peuvent entraîner des délais d’attente de session et des faux positifs. Il est essentiel d’envisager des scénarios où les délais d’expiration des sessions Web sont faibles, en veillant à ce que les ThinkTimes soient correctement placés pour éviter les défaillances dues aux délais d’expiration des sessions.

Que se passera-t-il si nous n’atteignons pas l’objectif ?

• Si le temps de réponse d’une application en cours de test de charge ralentit et que la durée de la session dépasse la durée de session cible, le taux de transaction attendu ne peut pas être atteint.
• LoadView surveille le temps réel de la session pendant l’exécution des tests et ajuste ThinkTimes pour tenter d’atteindre le taux de transaction attendu en fonction de l’objectif.
• LoadView affiche des messages d’erreur sur l’écran de surveillance si la durée de la session dépasse la durée de session cible.
• LoadView poursuit l’exécution du test si le taux de transaction cible ne peut pas être atteint, en marquant la série de tests comme ayant échoué et en indiquant les périphériques concernés dans le rapport.

À quoi ressemble une charge de travail basée sur l’objectif de l’échantillon?

• Temps de montée en puissance : 15 minutes
• Mesurer les temps de réponse pendant la montée en puissance : Oui / Non
  ST : Durée de la session
• GST : Durée de la session d’objectif
• TPH: Transactions par heure
• Utilisateur : calculé par LoadView (3600 / TPH) * GST = 72