Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Apprendre à enregistrer un script et le rejouer avec JMeter, un outil de test de montée en charge,
Un tutoriel de Antonio Gomes-Rodrigues

Le , par Mickael Baron

0PARTAGES

6  0 
Bonjour,

Antonio Gomes Rodrigues nous propose un tutoriel pour apprendre à enregistrer un script et le rejouer avec JMeter, un outil de test de montée en charge.

L'URL de l'article est : http://arodrigues.developpez.com/tut...meter-partie2/

Mickael

Les meilleurs cours et tutoriels pour apprendre la programmation en Java

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 31/10/2016 à 19:47
Plutôt bien pour commencer mais je pense que quelques éléments supplémentaires s'imposent (une occasion de compléter l'article ?):
  • Concernant la variabilisation, il est conseillé de créer des variables (User Defined Variables) dans le plan de travail afin que l'enregistreur variabilise automatiquement. S'il détecte la valeur dans un élément (URL, paramètres, headers) de la requête.
  • Il est également possible de préciser à l'enregistreur que les valeurs que nous avons pré-définies contiennent des expressions régulières !
  • Les requêtes de redirection sont par défaut enregistrées mais désactivées. Il est également possible de ne pas les enregistrer du tout.
  • Lors de l'utilisation d'une source CSV, je recommande de ne pas spécifier le nom des variables dans le composant JMeter et de les placer en entête du fichier CSV. Si la structure du fichier change, le scénario JMeter n'est pas impacté.
  • Pour contrôler le pacing, plusieurs éléments:
    • Placer le compteur de temps dans un action test qui fait une pause de 0. Cela évitera de multiplier votre pacing en fonction du nombre d'échantillons. D'autant que les "attentes" entre les échantillons d'un même scénario sont indépendants de la fréquence du scénario.
    • Il existe principalement deux techniques pour variabiliser le pacing. Soit utiliser un fichier CSV dont le chemin est dynamique en fonction d'une propriété JMeter. Ou bien utilise une propriété qui définit un "load factor" (ex: [CODEINLINE]${__BeanShell(${__P(loadfactor,1.0)}*6.0)}
    • Il existe différentes manières de calculer un débit constant. En général, j'utilise le mode "all active threads in current thread group (shared)". Ceci permet de définir une charge indépendante du nombre de V user(s) (ie Thread) et de remote(s) (ie agents distribués).
    • s'il y a plusieurs threads ou remotes, tous les scénarios débutent exactement en même temps. Il est donc recommandé d'ajuster le "ramp up" (durée de montée en charge) pour ajuster cette simultanéité (ou pas).
  • Plutôt que modifier le fichier ${JMETER_HOME}/bin/user.properties, il est possible de spécifier un fichier de paramétrage spécifique via -G[propertyfile]
  • S'il y a des variables qui dépendent de l'environnement. Je recommande d'avoir un premier composant User Defined Variables dans lequel, on définit un chemin de base en fonction de l'OS (exemple: basedir=${__BeanShell(System.getProperty("os.name").startsWith("Windows") ? "C:/my_project" : "/home/my_project")}). Puis un deuxième composant de variables qui définit des variables reposant sur les variables du premier composant (exemple: inputdir=${basedir}/input})
0  0