Définir des tests de charge basés sur des flux utilisateur clés
Le test de charge est une partie importante de la validation continue. Pour commencer, vous devez identifier les flux d’application. Dans cette unité, vous allez découvrir les flux utilisateur et système, pourquoi ils sont importants, et les critères de conception pour les tests.
Qu’est-ce qu’un flux d’application ?
Un flux est composé d’interactions d’application requises pour effectuer une tâche.
Flux utilisateur
Ces flux indiquent comment les utilisateurs interagissent avec votre application. Dans le scénario Contoso Shoes, le processus d’achat d’articles est un exemple de flux utilisateur. Il présente les composants suivants qui participent à la gestion des stocks :
- Applications web front-end
- Logique de paiement dans Azure Functions
- Base de données back-end dans Azure Cosmos DB
D’un point de vue stratégique, ces composants doivent être hautement disponibles et résilients aux défaillances. Par exemple, la page web front-end doit se charger rapidement, car l’organisation attend un grand nombre d’utilisateurs simultanés.
Flux système
Ces flux ne sont généralement pas exposés à l’utilisateur, mais une panne ou une dégradation des composants de flux système peut avoir un impact sur l’expérience utilisateur. Il peut s’agir par exemple d’une activité asynchrone qui récupère des commandes à partir d’une base de données et génère des étiquettes d’expédition.
Notes
La plupart des applications ont plusieurs flux. Chaque flux peut toucher différents composants de l’architecture. En outre, un composant peut apparaître dans plusieurs flux. Il est important de comprendre quels flux sont affectés en cas de défaillance d’un composant.
Définir un test de charge et ses valeurs de seuil
Un test de charge simule le trafic réel pour tester les performances de votre application. Toutefois, l’objectif n’est pas de générer une charge importante pour interrompre votre système. Cet objectif peut être atteint par des tests de contrainte.
Un test de charge peut aider à identifier les performances, les limites de performances, l’utilisation des ressources et le comportement de mise à l’échelle optimal des composants d’un flux utilisateur. Vos tests de charge doivent refléter chaque flux utilisateur et flux système pertinent. Une bonne conception nécessite une connaissance de l’application. Commencez par vous poser des questions du type :
- Quels appels d’API doivent être effectués ?
- Quelle est la séquence d’appels d’API ?
- Quelles données de test doivent être utilisées avec les appels d’API ?
En fonction des réponses :
Identifiez les scénarios clés, les dépendances, l’utilisation attendue, et les cibles en matière de disponibilité, de performances et de scalabilité.
Définissez un ensemble de valeurs de seuil mesurables pour quantifier les performances attendues des scénarios clés. Par exemple, pour un composant d’application, vous pouvez envisager des valeurs de seuil pour le nombre attendu de connexions utilisateur, de requêtes par seconde d’une API et d’opérations par seconde d’un processus en arrière-plan.
Utilisez les valeurs de seuil pour définir un test de charge qui génère un trafic réaliste pour tester les performances des applications, valider les opérations de mise à l’échelle attendues, et les activités connexes. Utilisez ces valeurs de seuil pour développer un modèle d’intégrité pour l’application qui couvre à la fois les tests et la production.
Dans l’exemple de flux de processus d’achat, vous pouvez définir le seuil de la durée de chargement moyenne de la page pour chaque étape afin qu’elle soit inférieure à 500 millisecondes et prendre en charge jusqu’à 100 utilisateurs simultanés.
Une fois toutes les valeurs de seuil définies, vous êtes prêt à implémenter des tests de charge. Ce module utilise Test de charge Azure.
Bien que vous puissiez configurer et déployer Test de charge Azure via le portail Azure, une approche par programmation est vivement recommandée. Utilisez des API pour déployer, configurer et exécuter les tests de manière automatisée. Cette approche est abordée dans l’unité suivante.