L'un des problèmes que rencontrent souvent les éditeurs de logiciels multiproduits est la duplication des compétences des ingénieurs - développeurs, testeurs et administrateurs d'infrastructure - dans presque toutes les équipes. Cela vaut également pour les ingénieurs coûteux - experts dans le domaine des tests de charge.Au lieu de s'engager dans leurs responsabilités directes et d'utiliser leur expérience unique pour construire le processus de test de charge, en choisissant une méthodologie, des mesures optimales et en écrivant des autotests en fonction des profils de charge, les ingénieurs doivent souvent déployer l'infrastructure de test à partir de zéro, configurer les outils de chargement et les intégrer. dans les systèmes CI, configurer la surveillance et la publication des rapports.Vous pouvez trouver des solutions à certains problèmes d'organisation dans les tests que nous utilisons chez Positive Technologies dans un autre article . Et je parlerai ici de la possibilité d’intégrer des tests de charge dans un pipeline CI commun en utilisant le concept de «test de charge en tant que service». Vous apprendrez comment et quelles images Docker des sources de charge peuvent être utilisées dans le pipeline CI; Comment connecter des sources de charge à votre projet CI à l'aide d'un modèle d'assemblage; à quoi ressemble un tube de démonstration pour exécuter des tests de charge et publier des résultats. Cet article peut être utile aux ingénieurs de test logiciel et aux ingénieurs d'automatisation de CI qui ont pensé à l'architecture de leur système de charge.Essence du concept
Le concept de test de charge en tant que service implique la capacité d'intégrer les outils de charge Apache JMeter, Yandex.Tank et ses propres cadres dans un système d'intégration continue arbitraire. Une démonstration sera faite pour GitLab CI, mais les principes sont communs à tous les systèmes CI.Le test de charge en tant que service est un service centralisé pour effectuer des tests de charge. Les tests de charge sont exécutés dans des pools d'agents dédiés, les résultats sont publiés automatiquement dans GitLab Pages, Influx DB et Grafana ou dans les systèmes de rapports de test (TestRail, ReportPortal, etc.). L'automatisation et la mise à l'échelle sont réalisées aussi simplement que possible - en ajoutant et en paramétrant le modèle gitlab-ci.yml habituel dans le projet GitLab CI.L'avantage de l'approche est que l'ensemble de l'infrastructure CI, les agents de charge, les images docker des sources de charge, les pipelines de test et la publication des rapports sont pris en charge par le service d'automatisation central (ingénieurs DevOps), et les ingénieurs de test de charge peuvent concentrer leurs efforts sur le développement de tests et l'analyse de leurs résultats, sans aborder les problèmes d'infrastructure.Pour simplifier la description, nous supposons que l'application ou le serveur de test cible est déjà déployé et configuré à l'avance (pour cela, des scripts automatisés en Python, SaltStack, Ansible, etc. peuvent être utilisés). Ensuite, tout le concept du stress testing en tant que service s'inscrit en trois étapes: préparation, test, publication des rapports . Plus de détails sur le schéma (toutes les photos sont cliquables):
Lors des tests de résistance, nous essayons d'adhérer aux normes et à la méthodologie de l'ISTQB , nous utilisons la terminologie appropriée et les mesures recommandées. Je vais donner une courte liste de concepts de base et de définitions dans les tests de charge.Agent de chargement (agent de chargement) - la machine virtuelle sur laquelle l'application sera lancée - la source de la charge (Apache JMeter, Yandex.Tank ou module de chargement auto-écrit).Le but du test (cible) est un serveur ou une application installée sur le serveur qui sera soumis à une charge.Cas de test (cas de test) - un ensemble d'étapes paramétrées: actions de l'utilisateur et réactions attendues à ces actions, avec demandes et réponses de réseau fixes, en fonction des paramètres spécifiés.Profil ou plan de charge (profil) - dans la méthodologie ISTQB (Section 4.2.4, p. 43), les profils de charge déterminent les métriques critiques pour un test particulier et les options pour changer les paramètres de charge pendant le test. Vous pouvez voir des exemples de profils sur la figure. Test est un script avec un ensemble de paramètres prédéfinis. Plan de test - suite de tests et profil de charge. Testrun (testrun) - une itération d'exécution d'un test avec un scénario de charge entièrement exécuté et un rapport reçu. Requête réseau (requête) - Une requête HTTP envoyée de l'agent à la cible. Réponse du réseau (réponse) - Une réponse HTTP envoyée de la cible à l'agent.
L'état de réponse HTTP est un code de réponse standard du serveur d'applications.Transaction (transaction) - un cycle complet de «demande - réponse». Une transaction est comptée depuis le début de l'envoi d'une demande (demande) jusqu'à la fin de la réception d'une réponse (réponse).Statut de transaction (statut de transaction) - était-il possible de terminer avec succès le cycle "demande-réponse". S'il y a eu une erreur dans cette boucle, alors la transaction entière est considérée comme infructueuse.Temps de réponse (latence) - temps entre la fin de l'envoi d'une demande (demande) et le début de la réception d'une réponse (réponse).Métriques de chargement (métriques) - les caractéristiques du service chargé et de l'agent de chargement définies au cours du processus de test de charge.Mesures de base pour mesurer les paramètres de charge
Certaines des mesures les plus courantes et recommandées dans la méthodologie ISTQB (p. 36, 52) sont présentées dans le tableau ci-dessous. Des mesures similaires pour l'agent et la cible sont affichées sur la même ligne.Le schéma de base des tests de charge est très simple et se compose de trois étapes principales, que j'ai déjà mentionnées: Préparer - Tester - Rapport , c'est-à-dire préparer des objectifs de test et définir des paramètres pour les sources de charge, puis effectuer des tests de charge et, enfin, générer et publier un rapport sur les tests. Notes sur le schéma:
- QA.Tester - expert en stress tests,
- Target est l'application cible pour laquelle vous devez connaître son comportement sous charge.
Classificateur des entités, étapes et étapes du diagramme
CI-
Passons à la partie pratique. Je veux montrer comment, sur certains projets de Positive Technologies, nous avons mis en œuvre le concept de test de charge en tant que service.Tout d'abord, avec l'aide de nos ingénieurs DevOps, nous avons créé un pool d'agents dédié dans GitLab CI pour exécuter des tests de charge. Afin de ne pas les confondre dans les modèles avec d'autres, tels que les pools d'assemblages, nous avons ajouté des balises à ces agents, balises : load. Vous pouvez utiliser toutes les autres balises claires. Ils sont définis lors de l'inscription des coureurs GitLab CI.Comment connaître la puissance requise par le matériel? Les caractéristiques des agents de charge - une quantité suffisante de vCPU, de RAM et de disque - peuvent être calculées sur la base du fait que Docker, Python (pour Yandex.Tank), l'agent GitLab CI, Java (pour Apache JMeter) doivent être exécutés sur l'agent. Pour Java sous JMeter, il est également recommandé d'utiliser un minimum de 512 Mo de RAM et, comme limite supérieure, 80% de la mémoire disponible .Ainsi, sur la base de notre expérience, nous recommandons d'utiliser au moins 4 vCPU, 4 Go de RAM, 60 Go de SSD pour les agents de charge. La bande passante de la carte réseau est déterminée en fonction des exigences du profil de charge.Nous utilisons principalement deux sources de charge - les images docker Apache JMeter et Yandex.Tank.Yandex.Tank- Il s'agit de l'outil open source de Yandex pour les tests de stress. Son architecture modulaire est basée sur le générateur de requêtes HTTP asynchrone à hautes performances basé sur les hits Phantom. Le réservoir a une surveillance intégrée des ressources du serveur testé en utilisant le protocole SSH, peut arrêter automatiquement le test selon les conditions données, peut produire les résultats à la fois sur la console et sous forme de graphiques, vous pouvez y connecter vos modules pour étendre les fonctionnalités. Soit dit en passant, nous avons utilisé Tank alors qu'il n'était pas encore courant. Dans l'article « Yandex.Tank et automatisation des tests de charge », vous pouvez lire l'histoire de la façon dont, en 2013, nous l'avons utilisé pour effectuer des tests de charge de PT Appllication Firewall - l'un des produits de notre société.Apache JMeterEst un outil open source pour effectuer des tests de résistance Apache. Il peut également être utilisé pour tester des applications Web statiques et dynamiques. JMeter prend en charge un grand nombre de protocoles et de façons d'interagir avec les applications: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), les services Web SOAP / REST, FTP, TCP, LDAP, SMTP (S), POP3 (S ) et IMAP (S), des bases de données via JDBC, peuvent exécuter des commandes shell et travailler avec des objets Java. JMeter dispose d'un IDE pour créer, déboguer et exécuter des plans de test. Il existe également une CLI pour travailler sur la ligne de commande de tout système d'exploitation Java compatible (Linux, Windows, Mac OS X). L'outil peut générer dynamiquement un rapport de test HTML.Pour faciliter l'utilisation au sein de notre entreprise, pour permettre aux testeurs de changer et d'ajouter l'environnement, nous avons créé des images de docker des sources de charge sur GitLab CI avec publication dans le docker-register interne sur Artifactory . De cette façon, il s'avère plus rapide et plus facile de les connecter dans des pipelines pour les tests de charge. Comment faire docker pousser le registre via GitLab CI - voir les instructions .Le fichier docker de base pour Yandex.Tank nous avons pris ceci:Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]
Et pour Apache JMeter celui-ci:Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]
Vous pouvez lire le fonctionnement de notre système d'intégration continue dans l'article « Automatisation des processus de développement: comment nous avons implémenté les idées DevOps dans les technologies positives ».Modèle et pipeline
Un exemple de modèle pour effectuer des tests de charge est disponible dans le projet de démonstration . Vous pouvez lire les instructions d'utilisation du modèle dans le fichier Lisezmoi . Dans le modèle lui-même (le fichier .gitlab-ci.yml ), il y a des notes sur ce dont telle ou telle étape est responsable.Le modèle est très simple et illustre les trois étapes du test de charge décrites ci-dessus dans le diagramme: préparation, test et publication des rapports. Responsable du répertoire des étapes : préparation, test et rapport .- Prepare . , - docker registry: Test. .
- Test , . : Yandex.Tank, Apache JMeter, . job-. :
: CI- . , bash-. , — QA-. . ./tests.
- Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .
, :
:
Dans un exemple de démonstration, un pipeline avec des tests de charge et deux sources de charge (vous pouvez désactiver inutiles) ressemble à ceci: Apache JMeter peut générer un rapport HTML lui-même, il est donc plus rentable de l'enregistrer dans les pages GitLab à l'aide d'outils standard. Voici à quoi ressemble le rapport Apache JMeter: Dans la démo de Yandex.Tank, vous ne verrez qu'un faux rapport de texte dans la section des pages GitLab. Pendant les tests, le Tank est capable d'enregistrer les résultats dans la base de données InfluxDB, et à partir de là, ils peuvent être affichés, par exemple, dans Grafana (la configuration est effectuée dans le fichier ./tests/example-yandextank-test.yml ). Voici à quoi ressemble le rapport de Tank à Grafana:
Sommaire
Dans l'article, j'ai parlé du concept de "test de charge en tant que service" (test de charge en tant que service). L'idée principale est d'utiliser l'infrastructure de pools préconfigurés d'agents de chargement, d'images Docker des sources de charge, de systèmes de reporting et d'un pipeline les unissant dans GitLab CI basé sur un simple modèle .gitlab-ci.yml (exemple par référence ). Tout cela est pris en charge par une petite équipe d'ingénieurs en automatisation et est reproduit à la demande des équipes de produits. J'espère que cela vous aidera à préparer et à mettre en œuvre un programme similaire dans votre entreprise. Merci de votre attention!PS Je tiens à remercier chaleureusement mes collègues, Sergey Kurbanov et Nikolay Yusev, pour leur assistance technique à la mise en œuvre du concept de test de charge en tant que service dans notre entreprise.Auteur :Timur Gilmullin - député. Responsable Technologie et Processus de Développement (DevOps), Technologies Positives