Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création d'un scénario de test

La création d'un scénario de test comporte quatre étapes principales : configuration des paramètres généraux, définition du scénario, modification des modèles de trafic et révision de votre configuration.

Étape 1 : Paramètres généraux

Configurez les paramètres de base de votre test de charge, notamment le nom du test, sa description et les options de configuration générales.

Identification des tests

Options de planification

Configurez le moment où le test doit être exécuté :

Workflow de planification

Lorsque vous planifiez un test, le flux de travail suivant s'exécute :

Données en direct

Cochez la case Inclure les données en temps réel pour afficher les mesures en temps réel pendant l'exécution de votre test. Lorsque cette option est activée, vous pouvez surveiller :

La fonction de données en temps réel fournit des graphiques en temps réel avec des données agrégées à des intervalles d'une seconde. Pour plus d'informations, reportez-vous à la section Surveillance à l'aide de données en temps réel.

Étape 2 : Configuration du scénario

Définissez le scénario de test spécifique et sélectionnez votre cadre de test préféré.

Sélection du type de test

Choisissez le type de test de charge que vous souhaitez effectuer :

Mode de forme du trafic

Choisissez le côté qui contrôle la charge générée par le test. Le mode que vous sélectionnez modifie les champs affichés par la console à l'étape 3 : Forme du trafic.

Native nécessite le téléchargement d'un script. Vous ne pouvez donc pas le sélectionner lorsque vous choisissez le type de test Simple HTTP Endpoint. Pour obtenir des définitions complètes et des conseils sur le mode à choisir, reportez-vous à la section Modes liés à la forme du trafic.

Configuration du point de terminaison HTTP

Lorsque « Simple HTTP Endpoint » est sélectionné, la solution génère un plan de test JMeter à partir de votre configuration et l'exécute avec le binaire Apache JMeter fourni. Configurez ces paramètres :

Scripts du framework de test

Lorsque vous utilisez JMeter, k6 ou Locust, téléchargez votre fichier de script de test ou une archive .zip contenant votre script de test et les fichiers associés.

Pour JMeter, vous pouvez inclure des plugins personnalisés dans un /plugins dossier de votre archive .zip.

Pour Locust, un script de test dans une archive .zip doit être nommé. locustfile.py Pour installer des packages Python tiers dans le conteneur au moment de l'exécution, incluez un requirements.txt fichier dans l'archive et, éventuellement, un packages sous-répertoire de fichiers Wheel pour les installer sans accès à Internet. Pour plus d'informations, reportez-vous à la section Tests Tests acridiens antiacridiens.

Durée de sécurité (mode natif)

Lorsque vous sélectionnez le mode natif, la console affiche un champ Durée de sécurité à côté du téléchargement du script. La valeur par défaut est de 4 heures et la durée maximale est de 24 heures.

En mode natif, la durée de sécurité met fin à un test qui s'exécute plus longtemps que prévu, car c'est votre script qui décide de la fin de l'exécution. C'est un gardien, pas un calendrier. Si le test est toujours en cours à l'expiration de la durée, la solution arrête le framework de test. Il conserve les résultats pour la partie exécutée et enregistre l'exécution comme étant terminée plutôt que comme ayant échoué. Réglez-le au-dessus de l'exécution la plus longue dont vous pensez que le script aura besoin.

Étape 3 : Forme du trafic

Configurez la façon dont le trafic sera distribué pendant votre test, y compris la prise en charge multirégionale.

Modes de circulation

La solution propose deux modes de configuration du trafic, Standard et Native. Ils diffèrent selon le côté qui contrôle le chargement : la solution ou le script que vous téléchargez. Vous sélectionnez le mode à l'étape 2 : Configuration du scénario, et il détermine lequel des champs ci-dessous s'applique.

Standard

Le mode standard permet à la solution de contrôler la charge. Vous définissez le nombre de tâches Fargate par région, le nombre d'utilisateurs virtuels simultanés par tâche, une période de montée en puissance et une durée d'attente. La solution exécute votre test via le framework d'automatisation Taurus, qui traduit ces valeurs dans les propres contrôles de charge du framework sous-jacent. Taurus a la priorité sur le chargement déclaré par votre script, donc un bloc d'options k6, un groupe de threads Locust LoadTestShape ou JMeter est réécrit ou ignoré. Les utilisateurs virtuels d'une région sont le nombre de tâches multiplié par la simultanéité pour chaque tâche, et la forme est la même quel que soit le cadre que vous avez choisi. C'est ainsi que tous les tests étaient exécutés avant la version 4.3.0, de sorte que les scénarios créés précédemment continuent de se comporter exactement comme ils le faisaient et ne nécessitent aucune modification.

Choisissez Standard lorsque la forme de charge n'appartient pas au script, qu'elle est définie depuis la console, l'interface de ligne de commande ou un agent. Le mode Standard est le seul qui vous permet de définir un nombre exact d'utilisateurs virtuels et de modifier la forme de montée en puissance et de maintien sans toucher au script. Seul Standard prend en charge le type de point de terminaison HTTP simple, dans lequel la solution génère le plan de test pour vous. Utilisations typiques : un contrôle de capacité échelonné entre 500 et 5 000 utilisateurs virtuels, une régression nocturne avec 1 000 utilisateurs pendant dix minutes, ou toute comparaison nécessitant une rampe identique. Sa limite est l'expressivité. Tout ce que Taurus ne peut pas représenter n'est pas disponible ici, y compris plusieurs scénarios pondérés, des seuils par étape et des exécuteurs testamentaires.

Autochtone

Le mode natif permet à votre script de contrôler la charge. La solution exécute le fichier que vous avez chargé via la propre ligne de commande du framework : jmeter -n -tk6 run, oulocust --headless. Il ne transmet aucun indicateur de chargement. Votre script est donc la seule autorité sur le trafic qu'il génère et la solution ne le réécrit jamais. Deux paramètres restent à régler : le nombre de tâches Fargate à lancer par région et la durée de sécurité requise pouvant aller jusqu'à 24 heures. La durée de sécurité est une protection contre un script qui n'existe jamais, pas un calendrier. Si un test est toujours en cours à l'expiration de la durée, la solution arrête le framework, collecte les résultats de la partie exécutée et enregistre l'exécution comme terminée plutôt que comme ayant échoué. Chaque tâche s'exécute comme un processus cadre indépendant sans coordination entre les tâches. Ainsi, une région génère une copie complète de la charge déclarée de votre script pour chaque tâche. Par exemple, un script k6 contenant 200 utilisateurs virtuels, exécuté sur cinq tâches, place 1 000 utilisateurs virtuels sur la cible. Le nombre de tâches est donc le seul contrôle de charge que Native vous donne, et il se déplace en multiples entiers de ce que le script déclare. Pour modifier la rampe, le temps d'attente ou le nombre d'utilisateurs virtuels lui-même, vous devez modifier le script.

Choisissez Native si vous souhaitez exécuter un script exactement tel qu'il a été écrit. Un script qui s'exécute déjà localement ou dans CI s'exécute inchangé sur la solution, ce qui est la principale raison pour laquelle vous avez choisi Native. Native préserve tout ce que le framework peut exprimer : scénarios, étapes et seuils k6 ; LoadTestShape classes Locust et ensembles de tâches pondérés ; temporisateurs JMeter et groupes de threads. Choisissez-le lorsque la forme de la charge fait partie de la signification du test, et il est plus important de la reproduire fidèlement que de la diriger de l'extérieur. Utilisations typiques : réutilisation d'un script k6 à partir d'un pipeline sans le réécrire, profil spike-then recover ou scénarios pondérés qu'un seul numéro de simultanéité ne peut pas exprimer. Deux contraintes découlent de l'exécution du framework tel qu'il a été créé. Native nécessite le téléchargement d'un script. Simple HTTP Endpoint n'est donc pas disponible. Les scripts Locust ne doivent pas être définisprocesses, car la solution ne compte les demandes que lorsque Locust s'exécute en tant que processus unique.

Choix d'un mode

Multi-Region configuration du trafic

Sélectionnez une ou plusieurs régions AWS pour distribuer votre test de charge géographiquement. Pour chaque région sélectionnée, configurez :

Déterminer le nombre d'utilisateurs

Le nombre d'utilisateurs qu'un conteneur peut prendre en charge pour un test peut être déterminé en augmentant progressivement le nombre d'utilisateurs et en surveillant les performances d'Amazon CloudWatch. Une fois que vous constatez que les performances du processeur et de la mémoire approchent de leurs limites, vous avez atteint le nombre maximum d'utilisateurs qu'un conteneur peut prendre en charge pour ce test dans sa configuration par défaut (2 processeurs virtuels et 4 Go de mémoire).

Ce calibrage définit la valeur de simultanéité, de sorte qu'elle s'applique au mode Standard. Les limites de conteneurs qu'il établit s'appliquent également au mode natif. C'est là que vous augmentez ou diminuez la charge déclarée par votre script, au lieu de définir le champ Concurrency.

Processus d'étalonnage

Vous pouvez commencer à déterminer les limites d'utilisateurs simultanés pour votre test en utilisant l'exemple suivant :

Répétez les étapes 1 à 3 si le test n'a pas dépassé les limites de ressources. Vous pouvez éventuellement augmenter les ressources du conteneur pour permettre un plus grand nombre d'utilisateurs simultanés. Cela entraîne toutefois un coût plus élevé. Pour plus de détails, consultez le Guide du développeur.

Pour plus d'informations sur l'étalonnage des utilisateurs par moteur, reportez-vous à la section Étalonnage d'un test Taurus dans la documentation. BlazeMeter

Tableau des tâches disponibles

Le tableau des tâches disponibles affiche la disponibilité des ressources pour chaque région sélectionnée :

Pour augmenter le nombre de tâches ou de processeurs virtuels disponibles par tâche, consultez le Guide du développeur.

Durée du test

Définissez la durée d'exécution de votre test de charge. La console affiche cette section uniquement en mode Standard. En mode natif, votre script détermine la durée d'exécution du test, limitée par la durée de sécurité que vous avez définie à l'étape 2 : Configuration du scénario.

Étape 4 : vérifier et créer

Passez en revue toutes vos configurations avant de créer le scénario de test. Vérifier:

Après avoir vérifié, choisissez Créer pour enregistrer votre scénario de test.

Gestion des scénarios de test

Après avoir créé un scénario de test, vous pouvez :