MilamberSpace

Affinage du scénario de tests

JMeter avec sa fonction de proxy permet de faire automatiquement un gros travail d’écriture du scénario de tir. Cependant il reste un travail de vérification et d’affinage à faire.

Ajout des ID item HTTP Request

Afin de mieux retrouver les différents éléments testés dans les items de résultats, nous allons ajouter un ID dans le nom des items HTTP Request. Donc avant le champ Name correspondait à l’URI de la page, maintenant ce sera un ID +l’URI de la page.

Voici un petit nettoyage à faire : dans le deuxième appel à la servlet SessionExample, il y a eu le jssessionid qui a été ajouté à l’URI, on va le supprimer du champ Path.

Le résultat du nettoyage donne ceci :

Ajout d’item de type Listener

Maintenant nous allons ajouter à notre scénario de tir des nouveaux items afin de pourvoir “voir” les résultats d’un test de charges. Pour cela, on se place sur l’item Thread Group, un clic droit avec la souris, et on ajoute un Summary Report.

Et on termine avec un item Listener, View Results Tree.

On a donc pour finir, deux items listeners différents pour notre scénario de tir.

Premier test de tir de charges

Maintenant nous sommes prêts pour faire un premier test de tir, ce dernier nous permettra de vérifier une première validité du tir. L’item Thread Group indique les valeurs suivantes :

• Number of Threads (users), valeur : 1
  Il s’agit du nombre de thread que JMeter va lancer pour exécuter le scénario de tir. En d’autres termes, il s’agit du nombre d’utilisateurs virtuels qui vont exécuter le scénario. Pour ce premier tir, on laisse 1 utilisateur, puisqu’il s’agit de vérifier la validité du tir.
• Ramp-Up Period (in seconds), valeur : 1
  Il s’agit de la période de montée en charge des utilisateurs virtuels, ici on est à 1 seconde. Imaginons avoir une période de montée en charge de 20 secondes avec 10 utilisateurs virtuels, cela signifierait que un nouvel utilisateur commence son scénario de tir chaque deux secondes.
  
  
• Loop Count, valeur : 1
  Ce paramètre permet d’indiquer le nombre de fois qu’un utilisateur virtuel doit exécuter le scénario de tir à la suite.

Pour lancer le tir, on peut utilise le raccourci clavier Ctrl + R ou bien le menu Run > Start. Une fois terminé, on se place sur l’item Summary Report pour consulter les résultats.

Nous détaillerons les résultats affichés plus tard, pour l’instant on remarquera la colonne Error % qui indique pour le test 03 et le test 06, 100% d’erreur. Ce qui signifie qu’il y a un souci dans le test d’assertion.

Regardons le détail de l’erreur en utilisant l’item View Results Tree :

Pratique, les tests en erreur sont en rouge, on remarquera le code HTTP à 304 pour le test 03 et le test 06. Ici c’est normal d’avoir un code 304, puisque la page demandée est 1/ une page statique (pas une servlet, ni une jsp), 2/ cette page a déjà été demandée (test 01), donc normal d’avoir un code 304.

Pour éviter d’avoir cette erreur d’assertion, le mieux est d’aller modifier le test d’assertion effectué au niveau de l’item HTTP Sampler du test 03. Pour cela, il faut se placer sur l’item Check response, et modifier le champ Response Field to Test, en la passant de Text Response à Response Code. Et également en modifiant le champ Patterns to Test à la valeur 304. Voir capture ci-dessous :

On fera les mêmes changements sur le test 06.

Ensuite on peut relancer le test de charges, en commençant par effacer les anciens résultats avec le raccourci clavier Ctrl + E ou le menu Run > Clear All. Puis on lance à nouveau le tir (Ctrl + R)

Maintenant tous les résultats sont Ok. Cependant ce n’est pas totalement vrai. En effet, les tests d’assertion effectués sur les tests 01, 02, 04 et 05 sont juste des tests pour dire qu’il y a du texte qui a été renvoyé. On ne vérifie pas réellement la réponse reçue. Il faut donc aller personnaliser les tests d’assertion de chaque page demandée pour préciser le résultat attendu.

Personnalisation du test d’assertion TEST01

On commence avec l’item View Results Tree, onglet Response data. Cet écran nous donne le code HTML reçu de la page. Nous allons sélectionner une partie de code HTML, cette dernière doit être représentative d’une bonne exécution de la page.

Ensuite on va dans l’item Check response du test 01, et on modifie le champ Patterns to Test en ajoutant le texte représentatif d’une bonne exécution.

On refait la même opération pour le test 02

On modifie le test d’assertion pour le test 02.

On continu avec le test 04.

On modifie le test d’assertion pour le test 04.

On finit pas le test 05. La particularité de ce test est qu’il s’agit d’un test de résultat de l’exécution d’un formulaire dynamique. Il faut donc choisi un texte représentatif en relation avec le résultat attendu.

On modifie le test d’assertion pour le test 05.

Il nous reste donc à tester si tout ce passe bien au niveau des tests d’assertion lors d’un nouveau tir de charges de vérification. On fait donc un Ctrl + E, suivi d’un Ctrl + R.

Et voilà le test du test de charges est concluant.

Passons à l’étape suivante : le test de charges.