test de charge/stress ASP.NET Core
Les tests de charge et les tests de contrainte sont importants pour s’assurer qu’une application web est performante et évolutive. Les tests de charge et de contrainte ont des objectifs différents, même s’ils partagent souvent des tests similaires.
Tests de charge : testez si l’application peut gérer une charge spécifiée d’utilisateurs pour un scénario donné tout en satisfaisant l’objectif de réponse. L’application est exécutée dans des conditions normales.
Tests de contrainte : testez la stabilité de l’application lors de l’exécution dans des conditions extrêmes, souvent pendant une longue période. Les tests placent une charge utilisateur élevée, soit des pics ou une augmentation progressive de la charge sur l’application, soit ils limitent les ressources informatiques de l’application.
Les tests de contrainte déterminent si une application en état de stress peut se remettre d’une défaillance et revenir correctement au comportement attendu. En cas de stress, l’application est exécutée à un niveau de stress anormalement élevé.
Test de charge Azure est un service complètement managé qui permet de générer une charge à grande échelle. Le service simule le trafic pour les applications, quel que soit l’emplacement où ils sont hébergés. La préversion du test de charge Azure vous permet d’utiliser des scripts Apache JMeter existants pour générer une charge à grande échelle.
Le test de charge de Visual Studio 2019 est déconseillé. Le service de test de charge cloud Azure DevOps correspondant a été fermé.
Outils tiers
La liste suivante contient des outils de performances web tiers avec différents ensembles de fonctionnalités :
- Apache JMeter
- ApacheBench (ab)
- Gatling
- jmeter-dotnet-dsl
- k6
- Locust
- West Wind WebSurge
- Netling
- Vegeta
- NBomber
Test de charge et de contrainte avec les builds de mise en production
Les tests de charge et de contrainte doivent être effectués en version et en mode de production et de mise en production et non en mode débogage et développement. Les configurations de mise en production sont entièrement optimisées avec une journalisation minimale. La configuration de débogage n’est pas optimisée. Le mode de développement permet une journalisation des informations supplémentaires qui peut avoir un impact sur les performances.