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 implique quatre étapes principales : configurer les paramètres généraux, définir le scénario, définir les modèles de trafic et revoir 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, la description et les options de configuration générales.
Identification du test
-
Nom du test (obligatoire) : nom descriptif de votre scénario de test
-
Description du test (obligatoire) - Détails supplémentaires sur l'objectif et la configuration du test
-
Balises (facultatif) - Ajoutez jusqu'à 5 balises pour classer et organiser vos scénarios de test
Options de planification
Configurez le moment où le test doit être exécuté :
-
Exécuter maintenant : exécute le test immédiatement après sa création.
-
Exécuter une fois : planifiez le test pour qu'il soit exécuté à une date et à une heure spécifiques.
-
Exécuter selon un calendrier : utilisez la planification basée sur le cron pour exécuter des tests automatiquement à intervalles réguliers. Vous pouvez sélectionner des modèles courants (toutes les heures, tous les jours, toutes les semaines) ou définir une expression cron personnalisée.
Flux de travail de planification
Lorsque vous planifiez un test, le flux de travail suivant se produit :
-
Les paramètres de planification sont envoyés à l'API de la solution via Amazon API Gateway.
-
L'API transmet les paramètres à une fonction Lambda qui crée une règle d' CloudWatch événements dont l'exécution est planifiée à la date spécifiée.
-
Pour les tests ponctuels (Run Once), la règle CloudWatch Events s'exécute à la date spécifiée et la fonction
api-servicesLambda exécute le test. -
Pour les tests récurrents (Exécuter selon un calendrier), la règle CloudWatch Events s'active à la date spécifiée, et la fonction
api-servicesLambda crée une nouvelle règle qui s'exécute immédiatement et de manière récurrente en fonction de la fréquence spécifiée.
Données en direct
Cochez la case Inclure les données en temps réel pour afficher les métriques en temps réel pendant l'exécution de votre test. Lorsque cette option est activée, vous pouvez surveiller :
-
Temps de réponse moyen
-
Nombre d'utilisateurs virtuels.
-
Les demandes réussies comptent.
-
Les demandes ayant échoué sont comptabilisées.
La fonction de données en temps réel fournit des graphiques en temps réel avec des données agrégées à 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 framework de test préféré.
Sélection du type de test
Choisissez le type de test de charge que vous souhaitez effectuer :
-
Point de terminaison HTTP unique : testez un point de terminaison d'API ou une page Web unique avec une configuration simple.
-
JMeter- Téléchargez des scripts de JMeter test (fichiers .jmx ou archives .zip).
-
K6 - Téléchargez des scripts de test K6 (fichiers .js ou archives .zip).
-
Locust - Téléchargez des scripts de test Locust (fichiers .py ou archives .zip).
Configuration du point de terminaison HTTP image : :images/test-types.png [Sélectionnez le type de test à exécuter] Lorsque « Point de terminaison HTTP unique » est sélectionné, configurez les paramètres suivants :
- Point de terminaison HTTP (obligatoire)
-
Entrez l'URL complète du point de terminaison que vous souhaitez tester. Par exemple,
https://api.example.com/users. Assurez-vous que le point de terminaison est accessible depuis l'infrastructure AWS. - Méthode HTTP (obligatoire)
-
Sélectionnez la méthode HTTP pour vos requêtes. La valeur par défaut est
GET. Les autres options incluentPOSTPUTDELETE,PATCH,HEAD, etOPTIONS. - En-tête de demande (facultatif)
-
Ajoutez des en-têtes HTTP personnalisés à vos demandes. Les exemples les plus courants incluent :
-
Content-Type: application/json -
Authorization: Bearer <token> -
User-Agent: LoadTest/1.0Choisissez Ajouter un en-tête pour inclure plusieurs en-têtes.
-
- Charge utile du corps (en option)
-
Ajoutez le contenu du corps de la requête pour les requêtes POST ou PUT. Supporte les formats JSON, XML ou texte brut. Par exemple :
{"userId": 123, "action": "test"}.
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 de support. En JMeter effet, vous pouvez inclure des plugins personnalisés dans un /plugins dossier de votre archive .zip.
Important
Bien que votre script de test (JMeterK6 ou Locust) puisse définir la simultanéité (utilisateurs virtuels), les taux de transaction (TPS), les temps de montée en puissance et d'autres paramètres de chargement, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
Étape 3 : Forme du trafic
Configurez la manière dont le trafic sera distribué pendant votre test, y compris le support multirégional.
Configuration du trafic multirégional
Sélectionnez une ou plusieurs régions AWS pour répartir géographiquement votre test de charge. Pour chaque région sélectionnée, configurez :
- Nombre de tâches
-
Le nombre de conteneurs (tâches) qui seront lancés dans le cluster Fargate pour le scénario de test. Aucune tâche supplémentaire ne sera créée une fois que le compte aura atteint la limite « La ressource Fargate a été atteinte ».
- Simultanéité
-
Le nombre d'utilisateurs virtuels générés simultanément par tâche. La limite recommandée est basée sur les paramètres par défaut de 2 V CPUs par tâche. La simultanéité est limitée par les ressources du processeur et de la mémoire.
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 sur Amazon CloudWatch. Une fois que vous avez constaté 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 vCPU et 4 Go de mémoire).
Processus d'étalonnage
Vous pouvez commencer à déterminer les limites d'utilisateurs simultanés pour votre test en utilisant l'exemple suivant :
-
Créez un test avec un maximum de 200 utilisateurs.
-
Pendant le test, surveillez le processeur et la mémoire à l'aide de la CloudWatch console
: -
Dans le volet de navigation de gauche, sous Container Insights, sélectionnez Performance Monitoring.
-
Sur la page Surveillance des performances, dans le menu déroulant de gauche, sélectionnez ECS Clusters.
-
Dans le menu déroulant de droite, sélectionnez votre cluster Amazon Elastic Container Service (Amazon ECS).
-
-
Pendant la surveillance, surveillez le processeur et la mémoire. Si le processeur ne dépasse pas 75 % ou si la mémoire ne dépasse pas 85 % (ignorez les pics ponctuels), vous pouvez exécuter un autre test avec un plus grand nombre d'utilisateurs.
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.
Note
Pour obtenir des résultats précis, n'exécutez qu'un seul test à la fois pour déterminer les limites d'utilisateurs simultanés. Tous les tests utilisent le même cluster, et CloudWatch Container Insights agrège les données de performance en fonction du cluster. Les deux tests sont donc signalés simultanément à CloudWatch Container Insights, ce qui entraîne des mesures d'utilisation des ressources inexactes pour un seul test.
Pour plus d'informations sur le calibrage des utilisateurs par moteur, reportez-vous à la section Étalonnage d'un test Taurus
Note
La solution affiche les informations de capacité disponibles pour chaque région, ce qui vous aide à planifier votre configuration de test dans les limites disponibles.
Tableau des tâches disponibles
Le tableau des tâches disponibles indique la disponibilité des ressources pour chaque région sélectionnée :
-
Région : nom de la région AWS.
-
v CPUs par tâche : nombre de machines virtuelles CPUs allouées à chaque tâche (par défaut : 2).
-
Limite de tâches DLT : nombre maximum de tâches pouvant être créées en fonction des limites Fargate de votre compte (par défaut : 2000).
-
Tâches DLT disponibles : nombre actuel de tâches disponibles dans la région (par défaut : 2000).
Pour augmenter le nombre de tâches disponibles ou v CPUs par tâche, consultez le guide du développeur.
Durée du test
Définissez la durée de votre test de charge :
- Passez à la vitesse supérieure
-
Le temps nécessaire pour atteindre la simultanéité cible. La charge augmente progressivement de 0 au niveau de simultanéité configuré au cours de cette période.
- Maintenez pour
-
Durée nécessaire pour maintenir la charge cible. Le test se poursuit en simultané pendant cette période.
Étape 4 : vérifier et créer
Passez en revue toutes vos configurations avant de créer le scénario de test. Vérifier:
-
Réglages généraux (nom, description, calendrier).
-
Configuration du scénario (type de test, point de terminaison ou script).
-
Forme du trafic (tâches, utilisateurs, durée, régions).
Après examen, 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 :
-
Modifier : modifiez la configuration de test. Cas d’utilisation courants :
-
Affiner la forme du trafic pour atteindre le taux de transaction souhaité.
-
-
Copier : dupliquez un scénario de test existant pour créer des variantes. Cas d’utilisation courants :
-
Mettre à jour les points de terminaison ou ajouter des headers/body paramètres.
-
Ajouter ou modifier des scripts de test.
-
-
Supprimer : supprimez les scénarios de test dont vous n'avez plus besoin.