Les tests de performance vérifient principalement la vitesse et la fiabilité d’une application et sont divisés en tests de charge (basés sur des objectifs) et des tests de résistance. Depuis l’essor des méthodes de développement agiles, être capable de reproduire les résultats des tests de charge est devenu une priorité absolue.
Quelles sont les raisons des tests de résistance?
La façon la plus simple de configurer les tests de performances est de permettre à un certain nombre d’utilisateurs d’exécuter itérativement des scripts de test. Ce type de test est appelé test de résistance et est souvent utilisé pour identifier les points de rupture dans les applications métier. L’inconvénient est que le temps de réponse réel de votre application est principalement responsable de la charge simulée et vous ne pouvez pas contrôler le débit réel. Dans les tests d’évolutivité, ce n’est pas un problème, mais pour une comparaison des performances entre les différentes versions, il peut être problématique.
Quelles sont les raisons des tests de performance axés sur les objectifs?
Le principal avantage de ce type d’essai est qu’il permet des mesures de vitesse dans des conditions réalistes et reproductibles et des limites de débit. Les tests de performance basés sur des objectifs sont souvent utilisés pour valider les accords de niveau de service dans des environnements similaires à la production.
Considérez la situation suivante :
Supposons que 20 utilisateurs simultanés créeront 2 000 transactions dans votre nouvelle application CRM par heure. Vous êtes chargé de créer un test de performance qui vérifie que le temps de réponse de huit secondes pour cette application pourrait être atteint dans les quatre prochaines versions. Un test de résistance ne permettra probablement pas la simulation exacte du débit attendu dans vos quatre tests de performances de version, car vous ne pouvez pas supposer que le temps de réponse restera le même que dans votre version réelle.
solution:
- Ajouter ThinkTimes à vos scripts
- Trouvez la ligne de base et le temps d’exécution du script utilisateur unique pour obtenir le temps de session
- Configurer la charge de travail, y compris, les utilisateurs maximaux, le taux de transaction basé sur les objectifs et le temps de transaction basé sur les objectifs
- Exécutez le test de performance basé sur les objectifs pour simuler la charge attendue
- Examiner le rapport d’essai et vérifier si la demande en cours d’essai a été en mesure de gérer la charge dans les délais de réponse convenus
- Répétez ce test dans vos quatre prochaines versions et vérifiez si votre application a été en mesure de maintenir les seuils de débit et de temps de réponse
Conseils pour configurer l’outil EveryStep
ThinkTime (requis)
Créez de nouveaux mots clés dans l’enregistreur Web EveryStep (ThinkTimes) ou réutilisez les mots clés existants
Assurez-vous que les valeurs autorisées sont des points flottants 0,0 – 999,99
S’assurer que les utilisateurs peuvent ajouter ThinkTimes manuellement aux scripts
N’oubliez pas que ThinkTimes sont des temps d’attente et ajoutés automatiquement par EveryStep Web Recorder lors de l’enregistrement des actions des utilisateurs.
Il peut y avoir N ThinkTimes dans un script
ThinkTimes sont ignorés dans les séries de tests de script unique
ThinkTimes sera utilisé dans Étalonnage / Obtenez baseline
ThinkTimes ne font pas partie des mesures du temps de réponse
ThinkTimes sont ignorés dans les tests de résistance
Concomence utilisateur (facultatif)
Nouveau mot clé «WaitFor (Nombre d’utilisateurs)» dans l’enregistreur Web EveryStep
Il s’agit d’un point d’attente global qui bloque les utilisateurs simulés à un certain point dans les scripts jusqu’à ce que le nombre prévu d’utilisateurs a atteint cette section du script
Seuils de temps de réponse (facultatif)
Nouveau mot clé SetBoundary dans l’enregistreur Web EveryStep
Syntaxe: SetBoundary (Timername, Bound 1, Bound 2)
Ligne de base/étalonnage (requis)
LoadView exécute un test utilisateur unique
ThinkTimes sera utilisé comme script
LoadView calculera le temps de session
Temps de session = temps d’exécution du script + ThinkTime
Configurer le plan charge de travail/exécution (requis)
Le client met en place une montée en puissance du temps
Le client fixe le taux de transaction d’objectif
Le client fixe le temps de session d’objectif
Le système calcule le nombre d’utilisateurs
Le client décide s’il doit calculer les temps de réponse pendant la montée en puissance ou non
Exécuter le test (requis)
LoadView exécute le test selon le plan de charge de travail/exécution configuré
LoadView recueille les temps de réponse des scripts ou transactions simulés
LoadView ajuste dynamiquement ThinkTime pour atteindre le débit attendu, si l’application sous test ralentit ThinkTimes sont réduits. Si ThinkTimes est nul et que le temps de session obtient > le temps de session d’objectif, un message d’erreur sera soulevé qui indique 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.
Conseils pour s’intégrer à Dotcom-Monitor
Enregistreur Web EveryStep
Introduire de nouveaux mots clés ThinkTime
Ignorer ThinkTime pendant les tests utilisateur unique
Ajouter ThinkTime pendant l’enregistrement du script
Introduire le nouveau mot clé WaitFor (Number user)
Introduire le nouveau mot clé SetBoundary (TimerName, B1, B2)
WaitFor mot clé doit être ajouté manuellement aux scripts créés
Utiliser le mot clé SetBoundary
Étalonnage/Obtenir la ligne de base
Calculer le temps de session pendant l’étalonnage
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 Charge de travail
Créer le dialogue de configuration workload pour prendre en charge le test de résistance, l’objectif de transaction et d’autres types
Spécifiez le temps de montée en puissance
Cochez la case pour calculer les temps de réponse pendant la montée en puissance (oui/non)
Option 2:
Utilisez la fonction de configuration améliorée du plan d’exécution
Sélectionnez le type de test (stress, basé sur les objectifs)
Définir les détails de l’objectif de transaction
Spécifiez le temps de montée en puissance
Cochez la case pour calculer les temps de réponse pendant la montée en puissance (oui/non)
Exécuter le test
Calculer le temps d’exécution du script/temps de session réel
Ajuster dynamiquement ThinkTimes en fonction du temps de session réel
Augmenter l’avertissement si le débit prévu n’a pas pu être atteint
rapport
Configurer une section pour le temps de réponse, réel vs seuils par chétrie
Configurer une section pour le débit, réel vs prévu
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 «Baseline?»
Une exécution utilisateur unique de l’appareil ou du script. Pensez que les temps sont utilisés dans le paramètre. Le temps d’exécution du script est calculé et stocké en temps de session. Des détails supplémentaires sont également calculés 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 permet de simuler des scénarios utilisateur complexes tels que des situations de concurrence. Il est très utile si vous devez tester si certaines fonctionnalités fonctionnent correctement si x nombre d’utilisateurs accèdent à une ressource en même temps.
Qu’est-ce que le mot clé SetBoundary ?
Les A SL Spécifient les limites de temps de réponse pour les actions des utilisateurs telles que la recherche d’un client. Le mot clé SetBoundary vous aide à vérifier la vitesse réelle d’une certaine action ou d’une certaine insurité. Si la limite autorisée est violée, un message d’erreur apparaît et sera enregistré dans le rapport de test. La vérification SLA est beaucoup plus facile avec ce nouveau mot clé SetBoundary
Quels devraient être vos objectifs pour votre test de charge?
- Tests de performances 100 % comparables dans différentes versions/exécutions
- Fonction de simulation des modèles de charge régulière ou maximale
- Confiance que le système testé peut gérer la charge attendue dans les limites convenues
- Concentrer l’optimisation des performances sur les actions des utilisateurs qui ont violé les limites convenues
Quel type de rapports devez-vous configurer ?
- Créez des rapports similaires à vos rapports actuels
- Avg, Min, Max, Stddev, Temps de réponse percentile
- Transactions ok, Transactions échouées
- Taux d’erreur
- Tous les temps de réponse doivent être sans les ThinkTimes
Limitations
Des temps de session de but élevés peuvent conduire à des temps d’attente de session et à des faux positifs. Considérez les situations où votre délai d’attente de session Web est très faible, comme 10 minutes. Si vous exécutez un test de performances basé sur des objectifs avec un script simple qui exécute une connexion et une recherche client, vous devez placer le ThinkTime entre la connexion et la recherche. Dans cette situation hypothétique, le temps de session doit être de 10 secondes le temps de session d’objectif 700 secondes. Dans ce scénario, le ThinkTime sera plus élevé que le délai d’attente de session de votre application à l’essai. Toutes vos transactions simulées échoueront parce que votre script s’exécutera dans le délai d’attente de la session Web et ne sera pas en mesure d’effectuer la recherche client.
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 le temps de session est supérieur au temps de session d’objectif, le taux de transaction prévu ne peut pas être atteint.
LoadView regarde le temps de session réel pendant l’exécution du test et ajuste ThinkTimes afin d’atteindre le taux de transaction basé sur les objectifs attendus.
LoadView affiche également le message d’erreur dans l’écran de surveillance si le temps de session devient supérieur au temps de session d’objectif.
LoadView continue également avec l’exécution du test si le taux de transaction d’objectif ne peut pas être atteint. Dans ce cas, le test sera marqué par l’état d’échec. Le rapport du test montrerait clairement que le débit prévu n’a pas pu être atteint en raison du ralentissement des temps de réponse et indiquerait quels appareils sont touchés.
À quoi ressemble une charge de travail basée sur l’objectif de l’échantillon?
| Script / Dispositif | ST (sec)
Non modifiable |
TPS (sec)
Entrée utilisateur |
Tph
Entrée utilisateur |
utilisateur
Non modifiable |
| Search_User | 25 | 10 | 500 | 72 |
| Inser_User | 25 | 60 | 1000 | 216 |
Temps de montée en puissance : 15 minutes
Mesurez les temps de réponse pendant la montée en puissance : Oui / Non
ST: Temps de session
TPS : Temps de séance d’objectif
TPH: Transactions par heure
Utilisateur: Calculé par LoadView (3600 / TPH ) * TPS = 72