tests-performance --depuis 2018 --langue fr
Mesurer la charge avant la production.
LoadRunner, NeoLoad, JMeter, VuGen : nouveautés des outils, scripts et méthode, par des praticiens du test de performance.
- 70articles
- 10catégories
- 16chapitres du guide
- 2018premier article
Derniers articles.
Tous les articlesOpenTelemetry : le File Log receiver écrit ses points de reprise en protobuf
Depuis la version 0.164.0 de opentelemetry-collector-contrib, le File Log receiver enregistre ses points de reprise en protobuf au lieu de JSON. Les mesures publiées par le projet montrent une écriture environ cinq fois plus rapide et un fichier plus petit d'un tiers.
- Le projet mesure 15,38 ms en JSON contre 3,21 ms en protobuf pour enregistrer les points de reprise de 1 000 fichiers.
- À la cadence par défaut (5 écritures par seconde) et avec 1 000 fichiers suivis, cela représente environ 77 ms de processeur par seconde en JSON contre 16 ms en protobuf.
- La mise à jour est transparente : les anciens points de reprise JSON sont relus puis réécrits en protobuf.
Relier un test de charge aux traces avec OpenTelemetry
Un rapport de tir dit qu'une transaction est lente, pas dans quel service. Propager l'en-tête traceparent depuis l'outil de test permet de retrouver la trace d'une requête lente. Démarche, essai rejoué avec k6 et limites.
- OpenTelemetry produit traces, métriques et journaux ; il ne les stocke ni ne les affiche.
- L'en-tête W3C traceparent, ajouté par l'outil de test à chaque requête, relie une transaction lente à sa trace dans l'outil d'observabilité.
- L'essai rejoué avec k6 prouve l'envoi de l'en-tête ; la recherche de la trace dans un outil d'observabilité n'a pas été rejouée ici.
Nouveautés NeoLoad 2026.1 et 2026.2 : Azure Service Bus, serveurs MCP et SecretVault
Ce que la documentation officielle de Tricentis annonce pour NeoLoad 2026.1 et 2026.2 : test d'Azure Service Bus, actions MCP pour charger un serveur MCP, cadre de corrélation SAP Fiori, variable SecretVault, et côté NeoLoad Web la V4 de l'API, la modification des utilisateurs virtuels en cours de test et les tests JMeter.
- 2026.1 : test d'Azure Service Bus (connexion, envoi, « peek », consommation, déconnexion). NeoLoad Web reçoit son interface moderne sur site, la V4 de l'API et un mode sombre.
- 2026.2 : NeoLoad devient client MCP (connexion, liste des outils, appel), corrèle SAP Fiori automatiquement, lit des secrets dans un coffre externe et exécute des fonctions SAP RFC en transaction.
- NeoLoad Web 2026.2 : comparaison de 4 résultats, ajout ou arrêt d'utilisateurs virtuels en cours de test, tests JMeter. Le DevOps Workspace n'est cité que dans le billet de l'éditeur.
Nouveautés LoadRunner 26.3 : Aviator, serveurs MCP et intégrations CI/CD
Ce que les notes de version officielles d'OpenText annoncent pour la 26.3 de la famille LoadRunner, avec la 26.2 de Cloud (il n'y a pas de 26.2 pour Professional, Enterprise ni VuGen) : Aviator mieux outillé, serveurs MCP étendus, protocole Blazor, protocole LLM enrichi, Harness, GitHub, GitLab et Kubernetes pour Enterprise.
- Pas de 26.2 pour Professional, Enterprise et VuGen : leur aide ne décrit que la 26.1 et la 26.3. Seul Cloud a une 26.2, avec un rapport d'usage de l'IA et une section Administration.
- 26.3 : Aviator gagne l'authentification unique, des invites prédéfinies et la gestion des conversations ; les serveurs MCP s'étendent (Controller Service en bêta privée, Enterprise, Cloud, DevWeb).
- Nouveau protocole Blazor - Web, Anthropic dans le protocole LLM, Wireshark vers DevWeb, plugin Harness, GitHub et GitLab sans Jenkins, volumes persistants Kubernetes.
Nouveautés LoadRunner 26.1 : Aviator disponible et premiers serveurs MCP
Ce que les notes de version officielles d'OpenText annoncent pour la version 26.1 de la famille LoadRunner (Professional, Enterprise, VuGen, Developer et Cloud) : les assistants Aviator passent de la bêta à la disponibilité générale, des serveurs MCP apparaissent, et Enterprise ouvre Google Cloud.
- Aviator for Scripting et Aviator for Analysis, en bêta en 25.3, sont « généralement disponibles » en 26.1 ; c'est un service payant d'OpenText.
- Le support MCP arrive : le serveur DevWeb se pilote depuis Copilot dans Visual Studio Code, et les serveurs Enterprise et Cloud servent les tests de ces produits.
- Enterprise ajoute Google Cloud, de nouveaux rôles d'administration et les scripts de démarrage ; Cloud permet de grouper les scripts ; VuGen, Windows 11 24H2 et Java 25 suivent.
L'IA dans les tests de performance : ce que les éditeurs documentent
OpenText, Tricentis, Gatling, Grafana, Microsoft et AWS annoncent des fonctions d'IA pour écrire des scripts, lancer des tirs et analyser les résultats. Ce que leurs pages décrivent, ce qu'elles ne démontrent pas, et comment s'en servir sans perdre le contrôle.
- Les fonctions documentées touchent trois étapes : écrire les scripts, lancer les tirs, analyser les résultats ; plusieurs sont en bêta ou en préversion, ou réservées à une édition payante.
- Aucune des pages lues ne mesure la justesse des scripts produits ni le temps gagné : ce sont des descriptions de fonctions, pas des résultats.
- La seule étude retrouvée sur les hallucinations en génération de tests porte sur des tests unitaires, pas sur des scripts de charge : relisez et rejouez à faible charge chaque script généré.
Gatling : transformer un parcours Playwright en test de charge avec un agent de code
Gatling décrit un flux où l'on parcourt son application dans un navigateur Playwright pendant qu'un agent de code écrit le test de charge correspondant. Le test rejoue les appels d'API, pas le navigateur, et ne mesure donc pas l'affichage.
- Le test généré rejoue le trafic d'API : il ne mesure pas le rendu côté navigateur.
- Le fichier d'enregistrement contient des cookies, des jetons et les identifiants saisis : à utiliser avec un compte de test.
- Le premier test lancé est un test à un seul utilisateur virtuel ; la charge reste à régler dans le profil d'injection.
Gatling plaide pour décentraliser la responsabilité de la performance, pas les tests de charge
Un article de Gatling soutient qu'une équipe de performance centrale qui teste en fin de cycle arrive trop tard, et que donner un outil aux développeurs ne suffit pas. Il propose des équipes propriétaires de leurs objectifs et une plateforme commune pour l'infrastructure et les tests système.
- Thèse : les équipes possèdent objectifs, scénarios et corrections ; la plateforme possède injecteurs, méthode et tests de capacité.
- Le texte s'appuie sur des cas publics et des études qu'il cite, non relus ici.
- Il vient d'un éditeur d'outil de charge, qui présente six pratiques assorties de ses propres fonctions.
Le guide
Guide des tests de performance.
Du besoin à la restitution : 16 chapitres pour comprendre une campagne de bout en bout.
Lire le guide- 01Pourquoi tester la performance
- 02Ce que sont (et ne sont pas) les tests de performance
- 03Les enjeux et la stratégie de test
- 04Les types de tests de performance
- 05Un environnement qui ressemble à la production
- 06Choisir les scénarios critiques
- 07La campagne en quatre phases
- 08Écrire le besoin de tests
- 09Écrire les scripts et choisir l'outil
- 10Modéliser la charge