NBomber est un FrameWork .NET développé pour effectuer des tests de charges sur vos applications.
Cet outil n'est pas Open Source mais propose une version gratuite qui me semble suffisante pour effectuer des tests de charge complet sur nos applications.
Les tests de charge sont, selon Microsoft, importants pour garantir qu'une application Web est performante et évolutive.
Testez si l'application peut gérer une charge d'utilisateurs spécifiée pour un certain scénario tout en satisfaisant l'objectif de réponse.
L'application est exécutée dans des conditions normales.
Il existe de nombreux outils tiers pour les tests de charge. Ils ont chacun leurs spécificités, comme Jmeter sous licence Apache, West Wind WebSurge, un outils plus graphique s'appuyant sur Fiddler ect... Ci-dessous une liste exhaustive de ces outils.
Pourquoi NBomber ?
Outils pratique et simple, c'est du développement .NET, les tests sont écris en F# ou C#.
Et en plus, c'est une application console, il sera donc facile de l'intégrer à votre solution.
Code
Installation des packages
Naturellement on monte une application console avec Visual Studio. Pour utiliser la librairie NBomber il faut installer ces packages :
- NBomber
- NBomber.HTTP - plugin to simplify defining and handling of HTTP
Tester une application API Rest
Le test de charge avec NBomber se définit par un Scenario, qui représenterait par exemple, une centaine d'utilisateurs qui se connectent et accède à un produit.
Step, représente une étape dans notre scenario, on reconnaitra nos Step par 1 connexion des utilisateurs et le second Step, accéder au produit.
Chaque Step contient un objet Request qui représente la requête http exécutée.
Pour faire simple dans mon exemple j'utiliserais le Template d'API Rest "WeatherForecast" de Visual Studio proposé par défaut.
Le code Nbomber
Notre code sera donc developpé dans une application Console.
Il se compose en 4 Parties, Scénario qui contient des Steps qui contiennent des Requests.
Dans cet exemple, il s'agira d'un scénario avec une étape pour obtenir les prévisions météorologiques de notre application REST "WeatherForecast".
Nous vérifierons uniquement si la réponse est valide (code d'état HTTP OK – 200).
- Scenario
Notre scenario est nommé "get weather", important pour la lecture du rapport. Nous définissons un "warm up" de 5 secondes.
C'est le temps que l'on s'accorde pour charger l'application lors de la première requête Http.
On injecte une moyenne de 10 requêtes par seconde pendant 30 secondes.
- Step
Le step est donc l'étape defini dans notre scenario, il peut se composer de plusieurs étapes, ici nous en définissons qu'une.
- Request
La requête est exécutée dans notre étape, ici le "NPoint" "weatherforecast", nous testerons uniquement si le "Status Code" est OK.
- Runner
Le Runner se charge de configurer notre programme de notre test puis de l'exécuter.
Quelques options notoires sont configurées comme le nom du fichier de rapport, le nom du répertoire de stockage du rapport et les différents formats que l'on souhaite générer.
- Rapports de test
Comme nous le souhaitons nous avons plusieurs fichiers de rapport au format différent.
- Rapport au format Console
- Rapport au format HTML
- Rapport au format TXT
Recommandation :
Il est préférable d'intégrer le test de charge dès le début des développements de votre application.
Cela permet de mesurer votre application et poussera les développeurs à écrire un code capable de supporter les pics de charge important.
Dans l'idéal intégrer NBomber dans Azure Devop.
Il faut quand même noté que le test de charge risque d'avoir un cout important selon le plan Azure que vous avez,
il sera alors préférable de ne pas le déclencher à chaque livraison.
L'analyse des Logs AppInsight serait aussi un gros plus pour analyser le comportement de votre application lors du test de charge, observer les accès à la base de données, les exceptions ect...
Xavier Raboteur 