Test de charge NBomber : le framework .NET passé en revue

21 octobre 2026 7 min de lecture

NBomber est un framework de test de charge pour .NET : vous écrivez chaque test comme un scénario C# ou F#, vous l’ajoutez à un projet ordinaire et vous le lancez comme n’importe quel programme. Le test de charge avec NBomber convient aux équipes qui développent déjà en .NET et veulent leurs tests de charge dans le même langage, le même dépôt et le même lanceur de tests. NBomber n’est gratuit que pour un usage personnel et académique ; une entreprise a besoin d’une licence payante, et ce seul point tranche plus d’évaluations que n’importe quelle fonctionnalité.

Nous n’avons pas exécuté NBomber pour cette revue. Les faits proviennent de la documentation, de la page de tarifs, du dépôt GitHub et du paquet NuGet de NBomber, vérifiés le 21 octobre 2026, et les appréciations sont les nôtres.

Sujet	NBomber
Licence	Gratuit pour un usage personnel et académique ; payant pour les organisations
Prix pour une entreprise	Business 1 500 $ par an, Enterprise 2 500 $ par an
Version actuelle	6.7.1 (16 octobre 2026)
Environnement d’exécution	.NET Standard 2.1, donc .NET Core 3.0 ou plus récent
Tests écrits en	Scénarios C# ou F#
Modèle de charge	Inject (taux d’arrivée) ou copies constantes
Contrôles de réussite	Seuils pendant l’exécution, asserts sur les statistiques finales
Montée en échelle	NBomber Cluster, licence Enterprise

Qui développe NBomber, et est-il gratuit ?

NBomber LLC le développe, avec le code source sur GitHub. Il est gratuit pour un usage personnel, de loisir et académique, et la page de licence dit clairement que NBomber n’est pas gratuit pour les organisations.

La page de licence range les benchmarks, les tutoriels et les contenus de revue dans l’usage personnel. En entreprise, il faut une licence Business ou Enterprise, attribuée par organisation et non par poste de développeur, sans limite d’instances ni d’exécutions parallèles. La page de tarifs indique 1 500 $ par an pour Business et 2 500 $ par an pour Enterprise, toutes deux avec une garantie de remboursement de 30 jours. La clé de licence se passe au lanceur avec .WithLicense(...) ou un argument --license, et NBomber a besoin d’un accès à internet pour la valider, une validation hors ligne étant possible sur demande par e-mail (vérifié le 21 octobre 2026).

La dernière version est la v6.7.1, publiée le 16 octobre 2026, quatre jours après la 6.7.0 (vérifié le 21 octobre 2026).

Comment fonctionne un scénario NBomber ?

Un scénario, c’est un nom et une fonction asynchrone que NBomber chronomètre à chaque appel. Vous y attachez des simulations de charge et des seuils, vous l’enregistrez auprès de NBomberRunner et vous lancez le programme.

Ce test saute le warm-up, fait monter le taux d’arrivée à 50 nouvelles copies du scénario par seconde en deux minutes, le maintient dix minutes et se termine avec le code de sortie 1 si 1 % ou plus des requêtes ont échoué. Il utilise le plugin NBomber.Http pour la requête :

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

La page du client HTTP recommande Http.CreateDefaultClient() plutôt qu’un simple new HttpClient() et indique que le plugin suit les codes de statut et les données transférées (vérifié le 21 octobre 2026). Un seuil seul ne fait que consigner l’échec dans le rapport : c’est la dernière ligne qui en fait un code de sortie lisible par un pipeline. Sans .WithoutWarmUp(), NBomber lance d’abord un warm-up de 30 secondes avec les simulations du scénario, d’après la page des scénarios (vérifié le 21 octobre 2026). Comme le scénario est du C# ordinaire, tout ce qu’une bibliothèque .NET peut appeler se teste en charge de la même façon.

Quels modèles de charge NBomber propose-t-il ?

Les deux. Les simulations inject lancent de nouvelles copies à un rythme fixé, quoi que fassent les copies précédentes, ce qui donne un modèle de charge ouvert ; les simulations constant maintiennent un nombre fixe de copies, ce qui donne un modèle fermé.

La page des simulations de charge les énumère (vérifié le 21 octobre 2026) :

Ouvertes : Inject, RampingInject, InjectRandom et IterationsForInject.
Fermées : KeepConstant, RampingConstant et IterationsForConstant.
Temporisation : Pause, qui retarde le démarrage d’un scénario ou le suspend pendant une durée donnée.

Notre article sur le modèle de charge ouvert ou fermé explique lequel correspond à votre trafic. Un site public se comporte en général comme le modèle ouvert, un groupe fixe de clients internes plutôt comme le modèle fermé.

Comment fonctionnent les seuils et les contrôles de réussite ?

Les seuils évalués pendant l’exécution contrôlent les statistiques en cours, toutes les 5 secondes par défaut, et apparaissent dans le rapport HTML. Les asserts, écrits avec xUnit ou NUnit, contrôlent les statistiques finales après l’exécution, et un assert en échec termine l’exécution avec un statut d’échec.

La page des seuils montre des contrôles sur le pourcentage d’erreurs, les codes de statut, les percentiles de latence (p50, p75, p95, p99 et maximum), les requêtes par seconde et les octets transférés. Par défaut, un seuil n’arrête pas le test ; abortWhenErrorCount l’arrête après un nombre donné de contrôles en échec (vérifié le 21 octobre 2026). La page n’indique pas de code de sortie, c’est pourquoi l’exemple ci-dessus en renvoie un à partir du résultat. Notre guide des critères de réussite d’un test de charge aide à choisir les limites.

Quels protocoles NBomber peut-il tester ?

Tout protocole qu’une bibliothèque .NET sait parler, car NBomber ne fait que chronométrer le code que vous lui donnez. Des plugins prêts à l’emploi couvrent HTTP, WebSockets, MQTT et AMQP, plus une option WebBrowser.

La page de présentation décrit le framework comme indépendant du protocole, et la page de tarifs inclut ces plugins dans toutes les formules, y compris la gratuite. Cela couvre aussi les bases de données et les files de messages que vous appelez avec leurs propres clients .NET (vérifié le 21 octobre 2026). La contrepartie : en dehors des plugins, c’est à vous d’écrire et de maintenir le code client.

Comment répartir un test NBomber sur plusieurs machines ?

Avec NBomber Cluster : un Coordinator orchestre l’exécution et des Agents exécutent les scénarios, le tout via un broker de messages NATS. Cluster fait partie de la licence Enterprise.

La présentation du cluster décrit les rôles, et la page de licence précise que les développeurs peuvent l’essayer en local avec un Local Dev Cluster avant d’acheter ; la page du Local Dev Cluster le limite à 1 Coordinator et 2 Agents et arrête chaque exécution au bout d’une minute (vérifié le 21 octobre 2026). L’intégration Kubernetes de NBomber Studio, elle aussi réservée à Enterprise, met en place NATS et les pods Agent à votre place. Sans Cluster, un processus NBomber tourne sur une seule machine ; la page de configuration requise conseille 4 à 8 cœurs CPU pour une charge élevée.

LoadFocus, qui publie ce site, n’exécute pas de tests NBomber. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud.

Quels sont les points forts et les limites de NBomber ?

Il est solide pour les équipes .NET : les tests sont du code C# ou F#, n’importe quel client .NET devient un test de charge et les deux modèles de charge sont intégrés. Ses limites sont la licence d’entreprise, un écosystème à un seul langage et des exécutions distribuées payantes.

Les tests vivent à côté du code de l’application, avec le même IDE, les mêmes paquets et les mêmes revues de code.
Les seuils sont intégrés, et les asserts tournent dans les tests xUnit ou NUnit que vous avez déjà.
L’usage commercial demande une licence, même pour un seul développeur.
Les exécutions distribuées demandent Enterprise et un broker NATS.
Des testeurs sans culture .NET devront d’abord apprendre C# ou F#.

Quand choisir plutôt k6, Gatling ou JMeter ?

Choisissez un autre outil si votre équipe n’écrit pas en .NET, ou si le coût de la licence ne convient pas.

Choisissez k6 pour des scripts JavaScript et un outil open source sans frais de licence en entreprise : son dépôt est sous AGPL-3.0 (vérifié le 21 octobre 2026). LoadFocus exécute des scripts k6 depuis 25 régions cloud, mais lance les scénarios arrival-rate avec un nombre fixe d’utilisateurs. Choisissez Gatling pour un outil orienté code sur la JVM ; notre revue de Gatling le couvre. Choisissez JMeter si vos testeurs préfèrent une interface graphique ou si vous avez besoin de samplers JDBC, JMS ou LDAP sans extension. Le panorama des outils de test de charge open source les compare côte à côte.

FAQ

NBomber est-il gratuit pour un usage commercial ? Non. NBomber n’est gratuit que pour un usage personnel et académique. Une entreprise a besoin d’une licence Business à 1 500 $ par an ou d’une licence Enterprise à 2 500 $ par an.

Quelles versions de .NET NBomber prend-il en charge ? Il cible .NET Standard 2.1, il tourne donc sur .NET Core 3.0 et toutes les versions de .NET suivantes. La documentation recommande .NET 10.

LoadFocus peut-il exécuter des tests NBomber ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour faire tourner NBomber sur plusieurs machines, utilisez NBomber Cluster, qui demande une licence Enterprise.