Tests de charge et de performance avec Azure DevOps - Load Tests

Cloud-based load testing avec Azure DevOps

J’évoquerai uniquement les tests de charge basés sur des requêtes http dans un navigateur, effectués à partir d’Azure DevOps. A noter qu’il est également possible d’effectuer des tests de charge à partir d’Azure Portal, ceci fera éventuellement l’objet d’un autre post. Dans ce post, nous mettrons en place un test de charge simple ; puis, un test avec des paramètres.

NB : la plupart des fonctionnalités de tests de charge de Microsoft vont devenir obsolètes en 2020.

source

Les tests de performance web (web performance tests) et les tests de charge (load tests)

Que m’apporte les tests de performance web et les tests de charge ?

Ils permettent de

Simuler l’activité des utilisateurs sur mon site web
Tester la capacité/l’aptitude de mon site web à accueillir de multiples utilisateurs simultanément au travers des tests de charge
Comprendre comment analyser les résultats des tests de performance et de charge afin d’identifier les points de blocage liés à la performance et à la fluidité de mon site

source

Introduction

Avec les load tests d’Azure DevOps, je peux facilement créer un jeu de tests reproductible qui peut m’aider d’une part, à analyser la performance de mon application web ; et, d’autre part, à identifier de potentiels points de blocage. Je peux donc créer des tests de performance qui répliquent mes actions telles que lors de l’utilisation de mon application. Un test de performance web n’est rien d’autre qu’une série d’interactions prédéfinies avec une application web qui simule la manière dont un utilisateur donné peut interagir avec mon application. Concrètement, les tests de performance envoient de manière ordonnée une série de requête http(s) à l’application cible et vérifie que cette dernière adopte le comportement escompté. Sur la base des tests de performance, je vais mettre en place les tests de charge qui ne font que compiler l’ensemble des résultats des tests de performance, et qui permet de simuler ce qui se passe lorsqu’un grand nombre d’utilisateurs essaie d’accéder à mon application simultanément. Nous allons voir dans ce post comment créer, éditer, lancer des tests de performance et de charge et comment en analyser les résultats.

Avant la mise en production d’une application, il est crucial de vérifier comment cette dernière se comporte lorsque plusieurs personnes l’utilisent de manière concurrente. La fonctionnalité de tests de charge d’Azure DevOps permet d’exécuter une série de tests de manière répétée tout en suivant la performance de l’application. En somme, cela consiste à effectuer un crash test de son application.

Remarque, ici nous faisons un test de performance imbriqué dans un test de charge. Ceci se fait au détriment de règles d’extraction ou de validation qui vérifieraient par exemple que la valeur donnée est bien retournée.

source

Tests de charge à partir d’une URL

Les tests de charge à partir d’une URL, ou tests de stress ne s’intéressent qu’à la performance brute de mon application. Ils n’intègrent donc pas de notions de règles de validation par exemple.

Avec les tests de charge, je peux vérifier que mon application fonctionne correctement même lorsqu’elle est sollicitée / mise sous pression par plusieurs utilisateurs de manière concurrente. Je peux configurer les niveaux et les types de charge que je souhaite simuler et ensuite exécuter le test de charge. Une série de requête est générée vers l’application cible. Azure DevOps renvoie l’analyse du résultat des tests de charge relatifs à l’application qui est mise sous pression au travers d’un système d’indicateurs clefs et de logs.

Mise en place des tests

1 - Accès : Azure DevOps – Test Plans – Load Tests – URL based test

2 - Configuration de tests simples

Donner un nom au Test de charge (1), puis renseigner l’url que l’on veut tester (2). On peut ajouter autant d’url que nécessaire. Pour chaque url, il faut sélectionner la méthode que l’on souhaite (GET, POST, PUT). Laisser le http method à Get pour des tests simples.

3 - Paramétrer les settings

Aller dans Settings (1). Je peux changer les paramètres de tests tels que la durée, le type de chargement, le nombre d’utilisateurs virtuels, le lieu (choisir un lieu proche des utilisateurs), le type de navigateur (2) etc. et cliquer sur Save (3).

Quelques explications

Load pattern : Le load pattern ou schéma de charge permet de simuler la charge utilisateur de deux manières distinctes : constante ou séquentielle.

Une charge constante permet de définir une charge utilisateur qui va rester inchangée, constante donc, pendant toute la durée des tests. Si je définie une base d’utilisateurs virtuels à 400, la performance de mon application sera analysée avec une base constante de 400 utilisateurs virtuels pendant toute la durée des tests.

Le step load ou charge séquentielle définit un certain nombre d’utilisateurs virtuels au début des tests ainsi qu’un nombre maximal d’utilisateurs pendant la durée des tests. Dans ce cas de figure, je dois préciser la durée d’une séquence (step duration en secondes) ainsi que le nombre d’utilisateurs virtuels (step user count) pendant cette séquence. Lorsque la durée de la première séquence expire, le nombre d’utilisateurs virtuels s’incrémente en fonction du nombre d’utilisateurs spécifié pour la prochaine séquence, à moins que le nombre maximal d’utilisateurs n’ait déjà été atteint. Les tests de charge séquentiels sont très utiles dans le processus d’identification du nombre d’utilisateurs que mon application peut supporter avant qu’elle ne commence à rencontrer des problèmes sérieux de performance.

Warmup duration : Le paramètre warm-up duration sert à définir un laps de temps pendant lequel aucune information relative aux tests ne sera enregistrée / recueillie / observée bien que le test soit en cours d’exécution. Après ce laps de temps d’ « échauffement » (permettant d’exclure les délais éventuels de compilation et de gestion du cache), la collecte de données débute et se poursuit jusqu’à ce que le temps défini dans le paramètre du temps d’exécution (run duration) soit atteint.

Browser mix : Le paramètre browser mix permet de préciser la répartition par type de navigateur que nous souhaitons simuler. Attention, la sélection du type de navigateur n’a pas pour but de déterminer si l’application aura tel ou tel rendu en fonction du navigateur. En effet, les tests de performance n’analysent uniquement les réponses aux requêtes http(s) et non pas le rendu des pages. Le type de navigateur n’a de sens, en ce qui concerne les tests de performance, que si l’application testée a été configurée différemment afin de tenir compte du poste (desktop, mobile, etc.).

Load agent : Les machines « agent » sont les machines qui vont être utilisées pour les tests, versus les machines « client » qui sont la machine du développeur. Les machines agent exécutent les tests de charge. Ces tests étant exécutés sur le cloud Azure, il est préférable de sélectionner un agent qui se trouve proche, d’un point de vue géographique, des utilisateurs de l’application.

Test rig : Un test rig est composé d’un contrôleur (qui coordonne les actions d’une ou plusieurs machines agent) et de n agent(s). Dans cet exemple nous utiliserons les agents prédéfinis par Azure.

4 - Lancer les tests

Lancer les tests en cliquant sur Run Test.

Lorsque je clique sur Run pour exécuter mes tests, les requêtes http définies sont envoyées à mon application, dans l’ordre défini dans mon scénario Web.

Comment visualiser et interpréter les résultats de mes tests ?

source

Je peux visualiser un résumé de mes tests, des graphes, un diagnostic et des logs. L’analyse des données de mes tests de charge me permet d’identifier des points de blocage, des erreurs et de mesurer l’impact des améliorations dans mon application.

Attention, l’exécution de mes tests peut générer des erreurs qui n’incomberaient pas uniquement à mon application mais qui peuvent être inhérentes à la rédaction et configuration de mes tests.

Dans la section Summary, je peux visualiser entre autres quelques métriques / statistiques relatives au nombre d’utilisateurs qui a été chargé, le nombre de requêtes par seconde, le pourcentage de requêtes qui ont échoué, le temps moyen de réponse, le nombre d’erreurs, mes top 5 des pages les plus lentes (ainsi que le nombre de fois que chaque page a été sollicitée, la moyenne du temps de réponse de chacune), etc. L’usage et le VUM (Virtual User Minutes) ont trait au décompte qui sera appliqué à la souscription et donc à la tarification Azure eu égard à ce test.

Dans la section graphique (charts), je bénéficie de quatre graphiques d’indicateurs clefs qui sont des compteurs qui décrivent de manière basique les aspects des tests de performance tels que la charge utilisateur, le délai de réponse, le débit, etc.

Le user load (la charge utilisateur) représente le nombre d’utilisateurs virtuels simulés pendant l’exécution des tests.

Le page response time (temps de réponse des pages) est le temps moyen nécessaire d’accès à chaque page web. C’est le temps de réponse de mon application lorsqu’elle reçoit une requête. Ce temps de réponse peut augmenter de manière drastique lorsque plusieurs utilisateurs tentent d’accéder à mon application simultanément. Ceci peut résulter d’une utilisation / sollicitation maximale des ressources telles que le processeur ou la base de données.

Le test response time (temps de réponse des tests) est le temps d’exécution des tests.

Les failed requests sont le nombre de requêtes qui ont échoué. Les requêtes en échec peuvent s’expliquer par le fait que l’application n’a pas répondu à la requête ou peuvent être du fait d’erreurs de connexion. En raison d’un trop grand nombre de sollicitations, mon application pourrait par exemple ignorer de nouvelles requêtes afin de tenter de finir le traitement des requêtes déjà en cours de traitement.

Dans la section Diagnostics (accessible aussi en cliquant sur Errors à partir de l’onglet Summary), je peux visualiser entre autres, les erreurs qui se sont produites durant les tests, leur typologie (type (1) et sous-type (2)), l’occurrence des erreurs ou le nombre de fois qu’elles se sont produites (3), ainsi que les derniers messages d’erreurs enregistrés (4).

Les messages de type Threshold indiquent que des violations de seuil ont été franchi pendant l’exécution des tests. Je peux voir la valeur seuil ainsi que la valeur de dépassement qui a été enregistrée pendant le test. Les règles prédéfinies de seuil permettre de surveiller l’utilisation des ressources du système. Le principe des règles de seuil consiste à comparer la valeur du compteur de performance de notre application avec une valeur constante prédéfinie. Les règles de seuil ont deux niveaux d’alerte possibles : Warning et Critical. Une violation de seuil indique qu’un compteur de performance a enregistré une valeur en « sur » ou « sous » performance eu égard aux règles de seuil prédéfinies.

L’onglet Logs fournit les logs provenant de l’ensemble des agents qui ont généré les tests. Ces logs disponibles au format .har (HTTP archive) permettent d’avoir le détail des erreurs rencontrées lors des échanges simulés entre le navigateur et l’application. On peut visualiser le détail de chaque requête ainsi que la réponse à cette dernière.

Tests de charge avec paramètres

Je peux également effectuer des tests de charge avec des paramètres. Voici les étapes à suivre :

Allez sur l’url de son application
Cliquer sur F12 puis sur l’onglet Network (1)
Sur votre application cliquer sur la fonctionnalité que vous souhaitez tester
Dans la colonne Name (2) de la fenêtre F12, cliquer sur la fonction que vous souhaitez tester
Exploiter l’ensemble des informations sur la droite pour compléter les paramètres de test dans Azure DevOps

Exemple d’une méthode Get

Au niveau du navigateur

Au niveau d'Azure DevOps

Exemple d’une méthode Post

Conclusion

L’objectif final de la mise en place de tests quels qu’ils soient est d’identifier des problèmes en amont pour éviter à tout prix que ce soit l’utilisateur final qui les remonte. Ensuite, il faudra définir un niveau de criticité pour les dysfonctionnements rencontrés. Ceci permettra de prioriser les actions à mettre en œuvre pour les corriger. De manière générale, il est donc préférable de tester le site en cours de développement et non pas la version mise en production.