Concevoir des tests de charge avec Test Studio & Fiddler en 6 étapes

Les tests de charge peuvent sembler une tâche intimidante : les tests de charge en tant qu'ensemble de requêtes REST sont compliqués et difficiles à lire. Mais avec le bon ensemble d'outils et d'approche, les tests de charge peuvent être assez simples et faciles à créer, quelle que soit l'expérience de test automatisé précédente.

Dans cet article, je vais démontrer un cas d'utilisation de test de charge et vous guider pas à pas. par étape via la création d'un test de charge à l'aide de Test Studio et Fiddler.

Qu'est-ce que le test de charge ?

Les tests de charge relèvent de la catégorie des tests non fonctionnels car ils permettent de garantir les performances contrairement au comportement fonctionnel. Les tests de charge vérifient les performances des applications Web ou des serveurs lorsqu'ils sont exposés à des conditions de charge attendues et inattendues (extrêmes). Cet article se concentrera sur les tests de charge d'applications Web.

Quel est l'objectif des tests de charge ?

Les tests de charge étaient auparavant une pratique de grandes équipes de test avec des ingénieurs de performance dédiés chargés de sécuriser le comportement des applications Web critiques dans des conditions extrêmes. charge. Cependant, comme les applications Web sont omniprésentes et que presque tout, du B2B à nos routines quotidiennes personnelles, se déroule sur le Web, les équipes de test ont commencé à explorer l'intérêt de mieux comprendre les caractéristiques de leurs applications lors de l'interaction avec l'utilisateur. . Ainsi, les tests de charge sont devenus une pratique de test beaucoup plus courante.

Les tests de charge peuvent vous aider à collecter des informations sur :

• La stabilité et les performances de l'application sous certaines charges
• Le nombre d'utilisateurs simultanés que l'application peut prendre en charge. 19659009]Nombre de requêtes que l'application peut gérer
• Durabilité du trafic réseau généré par toutes les requêtes au sein d'une session utilisateur
• La capacité de fonctionnement de l'application ou l'évolutivité de l'infrastructure du serveur

Comment fonctionne le test de charge ?

L'objectif principal des tests de charge est de mettre une certaine infrastructure d'application sous charge et de comprendre comment elle se comporte pour éventuellement éviter les problèmes de production. Certains cas d'utilisation courants consistent à extraire des données d'une base de données, à saisir de nouvelles données et à évaluer les performances de l'application sous charge afin de mesurer le nombre d'erreurs de serveur pour une période donnée sous charge.

Les informations que nous devons collecter sur la base d'un test de charge sont principalement associées à la mesure des capacités de l'infrastructure de notre application, de sa résistance à la charge et de la manière dont l'expérience utilisateur est affectée lorsque cette infrastructure est mise à l'épreuve.[19659007]Lorsque vous concevez un test de charge, vous devez vous assurer que les éléments dynamiques sont uniques pour chaque session utilisateur. Si ce n'est pas le cas, les résultats du test de charge peuvent ne pas représenter la réalité. Par exemple, si le scénario utilise un identifiant de session stocké en tant que cookie, lorsque chaque utilisateur utilise le même cookie (identifiant de session), cela peut entraîner un problème d'équilibrage de charge.

Si vous souhaitez créer un test de charge à partir d'un test Web, puis exécutez ce test de charge pour 30 utilisateurs simultanés avec des données identiques, ce qui peut entraîner de nombreux problèmes, de sorte que toute analyse résultant du test de charge pourrait être inexacte.

Comment les tests de charge sont-ils pris en charge dans Test Studio ?

Les tests de charge sont un ensemble de requêtes REST ordonnées, que le moteur Test Studio Load Testing essaiera d'exécuter aussi vite que possible et en parallèle (en fonction des paramètres d'exécution du test). Il est important de se rappeler que les requêtes elles-mêmes sont générées et envoyées à l'aide du Telerik Testing Framework et qu'elles ne proviennent pas d'un navigateur client, il n'y a donc pas d'interface utilisateur à prendre en compte pour les tests de charge.

Test Studio prend en charge la personnalisation des tests de charge pour répondre à vos besoins spécifiques en matière de tests de charge. Dans Test Studio, les éléments dynamiques ne sont pas créés dans le code mais sont définis en tant que cibles dynamiques avec un éditeur d'interface utilisateur. six étapes faciles avec un exemple pratique. Pour les besoins de la démo, j'utiliserai Test Studio et Fiddler. Pour plus d'informations et de conseils, vous pouvez toujours vous référer à la documentation technique expliquant en détail comment configurer Test Studio et les tests de charge de conception.

Étape 1 : Définir le scénario de test

La première étape est de décider du scénario réel qui nécessite la création d'un test de charge. Dans cet exemple, je vais utiliser le processus de connexion d'une application de démonstration. En termes d'API, le processus de connexion consiste à échanger un nom d'utilisateur et un mot de passe contre un cookie ou un jeton (selon le type d'authentification), puis à obtenir cet utilisateur authentifié autorisé et doté de certaines capacités et droits d'utilisateur au sein de l'application. L'autorisation de l'utilisateur peut être la base de la plupart des scénarios de test, mais elle peut également servir de scénario autonome.

Étape 2 : Obtenez un aperçu de l'API de l'application

L'étape suivante consiste à comprendre comment l'API de l'application sous les tests fonctionnent. Ici, Fiddler est utile. L'objectif principal est d'obtenir toutes les requêtes réseau qui seront envoyées au cours de notre scénario et de les organiser de manière à nous permettre de les utiliser pour un test de charge. Les informations les plus importantes que nous devons obtenir de ces demandes sont les éléments dynamiques utilisés par le scénario de connexion. Les données dynamiques peuvent provenir de requêtes POST, de cookies, de requêtes URL ou d'en-têtes (généralement l'en-tête d'autorisation).

Étape 3 : identifier toutes les demandes dont nous avons besoin pour le test de charge

Dans cette étape, nous requêtes exactes dont nous avons besoin pour créer le test de charge. Cependant, toutes les demandes ne sont pas pertinentes pour notre test de charge. Par exemple, toute demande à des services tiers doit être supprimée. Le scénario de chargement doit tester des fonctionnalités spécifiques.

Étape 4 : Importer les requêtes dans le test de charge

Enfin, la liste vierge des requêtes HTTP, sélectionnée à l'étape ci-dessus, doit être importée dans un test de charge dans Test Studio.

Étape n° 5 : définir des cibles dynamiques

Maintenant, avec les informations de l'étape 2, les éléments dynamiques des requêtes HTTP doivent être traités. La partie la plus critique est de s'assurer que l'authentification puis l'autorisation sont gérées de manière dynamique, ce qui signifie que chaque utilisateur pour lequel ces demandes doivent être exécutées se verra « présenter » sa propre session utilisateur unique.

Les cookies dynamiques, les en-têtes , les données et les requêtes POST peuvent être définies à l'aide de cibles dynamiques. Habituellement, chaque demande réussie obtiendra une réponse où ces éléments sont définis. Par exemple, de nouveaux cookies sont définis dans la réponse. Les données utilisateur telles que les clés, les identifiants et d'autres éléments dynamiques spécifiques au scénario de chargement réel peuvent également être trouvées dans les données de réponse des requêtes POST/GET. L'identification des cookies et des en-têtes dynamiques, uniques pour chaque session utilisateur, est l'un des aspects clés de la conception des tests de charge.

Étape #6 : Testez le test de charge nouvellement créé

Une fois le scénario terminé et chaque demande définie en utilisant des données dynamiques, il est temps de tester le test de charge lui-même. Pour ce faire, la bonne approche consiste à configurer le test de charge pour qu'il s'exécute pendant un nombre défini de minutes avec un seul utilisateur. Pendant l'exécution du test, nous pouvons capturer les requêtes émises par le moteur de test de charge dans Fiddler et les inspecter. Le but est de vérifier que le scénario sera terminé avec succès. Une fois cela fait, il peut être mis à l'échelle pour s'exécuter avec un plus grand nombre d'utilisateurs simultanés.

Scaling Your Load Test

Pour mettre ces étapes dans un contexte réel, je vais créer un scénario de charge à partir de zéro. Le scénario consiste à s'authentifier auprès d'un utilisateur et à télécharger un fichier sur un serveur en tant qu'utilisateur déjà autorisé.

Ma première action sera d'exécuter le scénario manuellement et de capturer les requêtes dans Fiddler. Les étapes fonctionnelles incluront « Connexion », puis « Cliquer sur un bouton » qui ouvre une boîte de dialogue pour le téléchargement de fichiers.

Voici à quoi devrait ressembler la session enregistrée dans Fiddler :

Le moment est venu de filtrer les demandes et d'obtenir celles dont nous avons besoin pour le test de charge, comme décrit ci-dessus à l'étape 3. Un grand nombre des demandes REST enregistrées ne sont pas pertinentes pour notre test de charge, mais impliquent l'obtention de ressources mises en cache, analytique, etc. Un moyen simple de filtrer est de trier toutes les demandes capturées par nom de domaine, de supprimer tout ce dont nous n'avons pas besoin, puis de ne conserver que les demandes nécessaires à l'autorisation de l'utilisateur et la demande POST qui télécharge l'exemple de fichier.

L'étape suivante consiste à exécuter le test fonctionnel et à capturer à nouveau toutes les requêtes. Le but de cette action est de se retrouver avec deux ensembles de requêtes identiques capturées à partir du même scénario fonctionnel que nous allons utiliser dans le test de charge.

Lorsque nous comparons les deux requêtes, les différences dans les données de session utilisateur seront évidentes. La raison en est que chaque exécution est associée à une session utilisateur unique. Notre objectif ici est de répliquer ces différences de manière dynamique dans le test de charge. jeton, cookie ou autre) nous obtenons une authentification réussie. Il y a une demande atteignant le point de terminaison de connexion où nous obtenons dans la réponse le jeton en échange du nom d'utilisateur et du mot de passe.

Dans d'autres scénarios, les sections dynamiques peuvent être l'URL, les données POST le cas échéant, les en-têtes, etc. Il est important de les identifier et de s'assurer que chaque utilisateur virtuel apparaîtra aussi unique que possible lorsque les demandes sont envoyées par des utilisateurs simultanés en temps réel.

Dans cet esprit, nous pouvons prendre l'une des sessions enregistrées et l'importer dans Test Studio comme test de charge. Il ne reste plus qu'à définir les parties dynamiques du test en tant que cibles dynamiques, en utilisant les informations que nous avons recueillies avec Fiddler.

Conclusion

Concevoir des tests de charge dans Test Studio est simple, mais vous devez tout de même suivre certaines étapes pour que votre test de charge réussisse. L'approche que j'ai démontrée vous aidera à concevoir des tests de charge stables, quelles que soient les spécificités de l'application. En particulier, les testeurs avec peu ou pas d'expérience en codage bénéficieront grandement de ce workflow de test de charge dans Test Studio car ils n'auront pas besoin d'écrire du code.

Les solutions d'automatisation de test modernes comme Test Studio devraient se concentrer sur la fourniture de workflows de test de charge efficaces pour travail des développeurs et des testeurs. Si vous n'avez pas consulté Test Studio récemment mais que vous recherchez une solution de test de charge, il est temps de l'essayer. Avec votre essai gratuit de 30 jours, vous pourrez créer et exécuter le scénario de test de charge décrit ci-dessus immédiatement.

Essayer maintenant