Test de charge avec criquet. 3e partie

Article final sur l'outil de test de stress acridien. Aujourd'hui, je partagerai les observations qui se sont accumulées au cours du processus. Comme toujours, la vidéo est jointe.

Partie 1 - test avec Locust
Partie 2 - Scénarios avancés

Se connecter

Lors de la rédaction de mes premiers tests avec Locust, j'étais confronté à la nécessité de me connecter à une ressource, d'obtenir un jeton d'autorisation, que j'utiliserais plus tard pour les tests de charge. Ensuite, la question s'est immédiatement posée - comment procéder, car l'outil est affiné pour envoyer toutes les demandes à une ressource, ce que nous indiquons dans la console lors du démarrage du test. Il existe plusieurs solutions au problème:

• désactivation de l'autorisation sur la ressource testée - si possible
• générer un jeton à l'avance et le mettre dans le code de test avant le lancement - l'option la plus faible, nécessitant un travail manuel à chaque lancement, mais ayant le droit d'exister dans de rares cas
• envoyer une demande en utilisant la bibliothèque de demandes et obtenir un jeton de la réponse - bon, la syntaxe est la même

J'ai choisi la troisième option. Ci-dessous je propose un exemple refait à partir du premier article avec différentes possibilités d'obtention d'un token. Google.com agira comme un serveur d'autorisation et ainsi
comme il n'y a pas de jeton, j'obtiendrai les valeurs les plus simples

from locust import HttpLocust, TaskSet, task import requests class UserBehavior(TaskSet): def on_start(self): response = requests.post("http://mysite.sample.com/login", {"username": "ellen_key", "password": "education"}) # get "token" from response header self.client.headers.update({'Authorization': response.headers.get('Date')}) # get "token" from response cookies self.client.cookies.set('Authorization', response.cookies.get('NID')) # get "token" from response body self.client.headers.update({'Authorization': str(response.content.decode().find('google'))}) 

Comme vous pouvez le voir dans l'exemple, avant de commencer à travailler, l'utilisateur envoie une demande à un serveur tiers et traite la réponse, en plaçant les données dans des en-têtes ou des cookies.

En-têtes

Lorsque vous travaillez avec des en-têtes de demande, vous devez prendre en compte plusieurs nuances importantes.
Pour chaque demande séparément, vous pouvez spécifier votre propre ensemble d'en-têtes comme suit

 self.client.post(url='/posts', data='hello world', headers={'hello': 'world'}) 

Lorsque l'exemple ci-dessus est exécuté, l'en-tête hello sera ajouté aux en-têtes existants de la session client, mais seulement dans cette demande ne sera pas dans tous les suivants. Pour rendre le titre persistant, vous pouvez l'ajouter à la session:

 self.client.headers.update({'aaa': 'bbb'}) 

Autre observation intéressante - si dans la requête nous précisons l'en-tête qui est déjà dans la session - il sera écrasé, mais uniquement sur cette requête. Vous ne pouvez donc pas avoir peur d'essuyer accidentellement quelque chose d'important.

Mais il y a des exceptions. Si nous devons envoyer un formulaire en plusieurs parties , la demande générera automatiquement un en - tête Content-Type , qui indiquera le séparateur de données du formulaire. Si nous forçons l'en-tête à être réécrit à l'aide de l'argument en- têtes , la demande échouera car le formulaire ne peut pas être traité correctement.

Il convient également de noter que tous les en-têtes sont nécessairement des chaînes. Si vous essayez de spécifier un nombre, par exemple {'aaa': 123} , la demande ne sera pas envoyée et le code lèvera une exception InvalidHeader

Tests distribués

Pour les tests distribués, locust fournit plusieurs arguments CLI: --master et --slave , pour définir clairement les rôles. Dans ce cas, la machine avec maître ne simulera pas la charge, mais collectera uniquement des statistiques et coordonnera le travail. Essayons d'exécuter notre serveur de test et plusieurs sessions en mode distribué en exécutant les commandes suivantes dans différentes consoles:

 json-server --watch sample_server/db.json locust -f locust_files\locust_file.py --master --host=http://localhost:3000 locust -f locust_files\locust_file.py --slave --master-host=localhost locust -f locust_files\locust_file.py --slave --master-host=localhost 

En ouvrant Locust dans le navigateur ( localhost: 8089 ), vous pouvez remarquer que dans le coin supérieur droit nous avons le nombre de machines qui porteront la charge

Test sans interface utilisateur

Lorsque tous les tests sont écrits et débogués, il serait intéressant de les inclure dans les tests automatiques de régression et de vérifier périodiquement les résultats. En utilisant la commande suivante, vous pouvez exécuter le test antiacridien sans interface utilisateur:

 locust -f locust_files\locust_file.py --host=http://localhost:3000 --no-web -c 10 -r 2 --run-time 1m --csv=test_result 

où

• --no-web - un argument qui vous permet d'exécuter des tests sans interface utilisateur
• -c 10 - nombre maximum d'utilisateurs
• -r 2 - croissance des utilisateurs par seconde
• --run-time 1m - temps d'exécution du test (1 minute)
• --csv = test_result - une fois le test terminé, 2 fichiers csv avec les résultats seront créés dans le dossier actuel, leurs noms commencent par test_result

Faits, observations et conclusions finales

Les tests distribués peuvent être combinés avec des tests de régression - afin de garantir que tous les nœuds de la charge sont démarrés, vous pouvez ajouter l'argument --expect-slaves = 2 sur le maître, auquel cas le test ne démarre que si au moins 2 nœuds sont démarrés.

Je suis tombé sur une situation plusieurs fois - la ressource testée ne fonctionne que sur HTTPS, tandis que le certificat est généré par le client et que le système d'exploitation le marque comme suspect. Pour que les tests fonctionnent correctement, vous pouvez ajouter un argument à toutes les requêtes qui ignorent le contrôle de sécurité, par exemple:

 self.client.get("/posts", verify=False) 

Comme je ne peux pas toujours être sûr de l'environnement dans lequel les tests seront exécutés, j'indique toujours cet argument.

C'est tout ce que je voulais partager. Pour ma part, j'ai découvert un outil simple et pratique avec de grandes capacités de test et une grande variabilité dans la création de requêtes et le traitement des réponses du serveur. Merci d'avoir lu jusqu'au bout.