Test de performance basé sur les objectifs

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

Les tests basés sur des 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 cibles d’utilisation des ressources et des références de scalabilité.
2. Conception des scénarios de test : Les scénarios de test sont conçus en fonction des objectifs de performance définis. Ces scénarios simulent différents comportements d’utilisateurs, charges et configurations système pour évaluer comment le logiciel performe sous diverses conditions. Par exemple, les scénarios peuvent inclure des périodes de forte utilisation, des charges transactionnelles importantes, ou des pics soudains d’activité utilisateur.
3. Exécution des tests : Les scénarios de test sont exécutés sur le système logiciel selon les exigences de test. Durant cette phase, les mesures de performance telles que les temps de réponse, le débit, l’utilisation des ressources et la scalabilité du système sont mesurées et surveillées.
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 aide à identifier les goulets d’étranglement, les limitations de scalabilité et les domaines où le système peut ne pas satisfaire les exigences de performance. Sur la base de l’analyse des résultats, 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 des objectifs sont un processus itératif. Après avoir effectué des améliorations, le cycle de test est répété pour valider si les objectifs de performance ont été atteints et pour identifier de nouveaux problèmes de performance éventuellement apparus.

Les tests de performance se concentrent principalement sur la vérification de la rapidité et de la fiabilité d’une application, répartis en tests de charge (orientés objectifs) et tests de stress. Avec la montée des méthodes de développement agile, il est devenu crucial d’assurer que les résultats des tests de charge puissent être facilement reproduits.

L’importance de définir les objectifs de performance

Définir les objectifs de performance est la pierre angulaire des tests de performance basés sur des objectifs. Ces objectifs servent de référence contre laquelle la performance du logiciel est mesurée. Ils fournissent un cadre concret pour évaluer si le logiciel répond à ses exigences de performance dans diverses conditions, y compris une utilisation normale, des charges maximales et des scénarios de stress.

Principales raisons des tests de performance basés sur des objectifs

• Alignement avec les attentes des parties prenantes : En définissant des objectifs de performance spécifiques, vous assurez que la performance de votre logiciel correspond aux attentes des parties prenantes, y compris les utilisateurs finaux, les clients et les sponsors du projet.
• Validation des exigences de performance : Les tests basés sur des objectifs aident à valider si votre logiciel répond à ses exigences de performance, fournissant des métriques concrètes pour évaluer l’adéquation de la performance.
• Optimisation de l’utilisation des ressources : Les tests basés sur des objectifs aident à optimiser l’utilisation des ressources en identifiant les inefficacités ou la surutilisation des ressources système, conduisant à une allocation plus efficace et à des économies de coûts.
• Scalabilité : En mesurant la performance sous des charges croissantes ou une concurrence d’utilisateurs accrue, les tests basés sur des objectifs évaluent la scalabilité de votre logiciel, assurant qu’il peut gérer une base d’utilisateurs et des charges de travail croissantes.
• Atténuation des risques : Tester de manière proactive contre des objectifs de performance prédéfinis permet d’identifier et de réduire les risques liés à la performance avant le déploiement du 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 un objectif : 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 stress peuvent ne pas reproduire précisément le débit attendu dans ces versions à venir, car les temps de réponse pourraient varier par rapport à la version actuelle.

Cas d’utilisation basé sur un objectif : Solution

1. Intégrez ThinkTimes dans vos scripts pour introduire des pauses entre les actions des utilisateurs.
2. Déterminez la référence et mesurez le temps d’exécution des scripts mono-utilisateur pour calculer le temps de session.
3. Configurez les paramètres de la charge de travail, y compris le nombre maximal d’utilisateurs, le taux de transaction basé sur l’objectif et le temps de transaction basé sur l’objectif.
4. Exécutez le test de performance basé sur l’objectif 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 le test lors des 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 configurer l’outil EveryStep de LoadView

ThinkTime (obligatoire) :

• Créez de nouveaux mots-clés dans The EveryStep Web Recorder (ThinkTimes) ou réutilisez des mots-clés existants.
• Assurez-vous que les valeurs autorisées sont des nombres flottants de 0.0 à 999.99.
• Permettez aux utilisateurs d’ajouter manuellement des ThinkTimes aux scripts.
• Rappelez-vous que les ThinkTimes représentent des temps d’attente et sont automatiquement ajoutés par EveryStep Web Recorder durant l’enregistrement des actions utilisateur.
• Plusieurs ThinkTimes peuvent exister dans un script.
• Les ThinkTimes sont ignorés lors des exécutions de test mono-script.
• Les ThinkTimes seront utilisés lors de la Calibration/Obtention de la référence.
• Les ThinkTimes ne contribuent pas aux mesures des temps de réponse.
• Les ThinkTimes sont ignorés dans les tests de stress.

Concurrence utilisateur (optionnelle) :

• Ajoutez un nouveau mot-clé “WaitFor (Nombre d’utilisateurs)” dans EveryStep Web Recorder.
• Ce point d’attente global bloque les utilisateurs simulés à une section spécifique du script jusqu’à ce que le nombre attendu d’utilisateurs atteigne cette partie du script.

Seuils de temps de réponse (optionnels) :

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

Référence/Calibration (obligatoire) :

• LoadView exécute un test mono-utilisateur.
• Les ThinkTimes seront utilisés tels que scriptés.
• LoadView calcule le temps de session : Temps de session = 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 charge.
• Les clients définissent leur taux de transaction cible.
• Les clients définissent le temps de session cible.
• Le système calcule le nombre d’utilisateurs.
• Les clients décident s’ils veulent calculer les temps de réponse pendant la montée en charge ou non.

Exécuter le test (obligatoire) :

• LoadView exécute le test selon le plan de charge/exécution configuré.
• LoadView collecte les temps de réponse des scripts simulés ou des transactions.
• LoadView ajuste dynamiquement les ThinkTimes pour atteindre le débit attendu ; si l’application testée ralentit, les ThinkTimes sont réduits. Si les ThinkTimes sont nuls et que le temps de session dépasse le temps de session cible, un message d’erreur est déclenché indiquant que le débit attendu n’a pas pu être atteint.
• LoadView calcule les temps de réponse des transactions et timers réels sans ThinkTimes.

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

EveryStep Web Recorder

• Introduction de nouveaux mots-clés ThinkTime.
• Ignorer ThinkTime lors des exécutions de test mono-utilisateur.
• Ajouter ThinkTime lors de l’enregistrement de scripts.
• Introduire un nouveau mot-clé WaitFor(Nombre utilisateur).
• Introduire un nouveau mot-clé SetBoundary(NomTimer, B1, B2).
• Le mot-clé WaitFor doit être ajouté manuellement aux scripts créés.
• Utiliser le mot-clé SetBoundary.

Calibration/Obtention de la référence

• Calculer le temps de session durant la calibration.

Plan d’exécution / Charge de travail

Option 1 :

• Ajouter une nouvelle fonctionnalité de configuration de charge de travail.
• Remplacer le plan d’exécution par la fonction de charge de travail.
• Créer une boîte de dialogue de configuration de charge de travail prenant en charge les tests de stress, les objectifs de transaction et autres types.
• Spécifier le temps de montée en charge.
• Cochez la case pour calculer les temps de réponse pendant la montée en charge (oui/non).

Option 2 :

• Utiliser la fonctionnalité améliorée de configuration du plan d’exécution.
• Sélectionner le type de test (stress, basé sur objectif).
• Définir les détails de l’objectif de transaction.
• Spécifier le temps de montée en charge.
• Cochez la case pour calculer les temps de réponse pendant la montée en charge (oui/non).

Exécution du test

• Calculer le temps d’exécution réel du script/temps de session.
• Ajuster dynamiquement les ThinkTimes selon le temps de session réel.
• Lancer un avertissement si le débit attendu n’a pas pu être atteint.

Rapport

• Configurer une section pour le temps de réponse, réel vs seuils par timer.
• Configurer une section pour le débit, réel vs attendu.

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

Quelles sont les entrées utilisateur ?

• ThinkTimes (nombre flottant, >0)
• Transactions cibles par heure (entier)
• Nombre maximal d’utilisateurs (entier)
• Temps de montée en charge (minutes)
• Calculer le temps de réponse pendant la montée en charge (Oui / Non)

Qu’est-ce que la référence ?

Une exécution mono-utilisateur de l’appareil ou du script, incluant les ThinkTimes. Le temps d’exécution du script est calculé et stocké comme temps de session, avec des détails supplémentaires tels que les ressources d’exécution requises.

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

• Calculer le temps de session lors de la calibration
• Utiliser ThinkTimes pour atteindre le temps de session demandé
• Recalculer le temps de session réel lors de l’exécution du test
• Ajuster dynamiquement les ThinkTimes selon le temps de session réel
• Enregistrer un message d’erreur si le temps d’exécution du script est > au temps de session cible
• Spécifier le nombre maximal d’utilisateurs dans le calcul de charge de travail

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

Il 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 ?

Aide à vérifier la vitesse réelle d’une certaine action ou timer par rapport aux limites de temps de réponse SLA spécifiées. Si la limite autorisée est dépassée, un message d’erreur apparaît et est enregistré dans le rapport de test, simplifiant la vérification des SLA.

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

• Assurer des tests de performance 100 % comparables entre différentes versions/exécutions.
• Inclure des fonctionnalités pour simuler des modèles de charge réguliers ou de pointe.
• Atteindre la confiance que le système testé peut gérer la charge attendue dans les limites convenues.
• Concentrer l’optimisation des performances sur les actions utilisateur qui violent les limites convenues.

Quel type de rapports devriez-vous configurer ?

• Créer des rapports similaires aux rapports actuels.
• Inclure les temps de réponse moyens, minimaux, maximaux, écart-type, centiles.
• Suivre les transactions réussies, transactions échouées et taux d’erreur.
• Tous les temps de réponse doivent être sans inclusion des ThinkTimes.

Limitations

Des temps de session cibles élevés peuvent entraîner des expirations de session et des faux positifs. Il est crucial de considérer les scénarios où les expirations de session web sont faibles, en veillant à ce que les ThinkTimes soient placés de manière appropriée pour éviter les échecs dus aux expirations de session.

Que se passe-t-il si vous n’atteignez pas l’objectif ?

• Si le temps de réponse d’une application sous test de charge ralentit et que le temps de session dépasse le temps de session cible, le taux de transaction attendu ne peut être atteint.
• LoadView surveille le temps de session réel pendant l’exécution du test et ajuste les ThinkTimes pour tenter d’atteindre le taux de transaction basé sur l’objectif attendu.
• LoadView affiche des messages d’erreur à l’écran de surveillance si le temps de session dépasse le temps de session cible.
• LoadView continue l’exécution du test si le taux de transaction cible ne peut être atteint, marquant l’exécution du test comme échouée et indiquant les appareils affectés dans le rapport.

À quoi ressemble une charge de travail basée sur un objectif type ?

•  Temps de montée en charge : 15 minutes
• Mesurer les temps de réponse pendant la montée en charge : Oui / Non
  ST : Temps de session
• GST : Temps de session cible
• TPH : Transactions par heure
• Utilisateur : Calculé par LoadView (3600 / TPH) * GST = 72