I. Introduction

Dans cet article, nous verrons comment réaliser un plan de tests le plus réaliste possible.

II. Importance du choix des scénarios

Si les scénarios ne sont pas bien identifiés, les tests ne seront pas conformes à ce qui se passera en production, et donc inutiles, voire dangereux.

III. Avoir une stratégie de tests

Avant de commencer il est important de définir une stratégie de tests.
Et pour cela, il faudra réaliser un certain nombre d'actions.

III-A. Pourquoi ?

En tout premier lieu il faudra répondre à la question "Quels sont les enjeux ?".
Car de la réponse dépendra en grande partie la stratégie qu'il faudra adopter.

Par exemple :

  • résoudre des problèmes de performance d'une application ;
  • dimensionner une infrastructure de production pour un déploiement national ;
  • rassurer la DSI sur la montée en charge d'une application ;
  • valider les performances/l'endurance/la robustesse d'une application ;
  • comparer des solutions ;
  • etc.

III-B. Identifier les scénarios critiques

Il est très important d'identifier les scénarios pertinents et de les pondérer.

Pour définir ces scénarios on peut :

  • récupérer les statistiques de l'utilisation de l'application si elles existent (par exemple le nombre quotidien ou mensuel de transactions « métier », l'analyse des statistiques Web (access_log), etc.) ;
  • définir avec les utilisateurs les scénarios majeurs d'utilisation (les fonctions les plus utilisées) de leur application (suites d'écrans et nombre d'utilisateurs).

Ces scénarios devront être :

  • réalistes (écrans consultés, champs saisis dans les formulaires, temps entre chaque action...) ;
  • importants.

Il y a trois types de scénarios à prendre en compte.

III-B-1. Fréquents

Ceux de tous les jours (consultations...).

III-B-2. Vitaux

Ceux qui sont vitaux (déclenchement de la paye...).

III-B-3. Risqués

Et ceux qui sont risqués d'un point de vue performance pour l'application (recherches complexes, générations de document...).

III-C. Combien faut-il de scénarios ?

Pour le nombre de scénarios, je préconise d'appliquer la loi de Pareto. Par exemple, en ne simulant pas différents navigateurs, différentes vitesses de connexion...

Ma deuxième préconisation est de faire une étude de risque afin de prioriser les tests. Cela permettra de choisir les tests en cas de réduction du planning (application livrée plus tard que prévu, serveur non disponible...).

III-D. Définir le type de test

Une fois les scénarios choisis, il faudra se poser la question du type de test que l'on veut exécuter.

En voici une sélection.

Nom Objectif Remarques
Test standard S'assurer du bon fonctionnement de l'application en utilisation réelle.
Obtenir un référentiel de temps de réponse de l'application
Nous ne cherchons pas à atteindre les limites de l'application ou de l'infrastructure mais uniquement à mesurer les temps de réponse moyens lors d'une utilisation normale (fonctions utilisées, nombre d'utilisateurs).
Test de stress Ce test permet de simuler un pic de charge réel et de détecter certaines failles (fuite de mémoire, dead lock...) en poussant les conditions de tests au-delà de l'utilisation normale de l'application. La détection de ces failles n'est possible que dans un contexte de stress de l'application. En utilisation normale ces failles sont souvent invisibles.
Test d'endurance S'assurer du bon fonctionnement de l'application en utilisation réelle et sur la durée.
Utile lorsqu'il y a un engagement sur le taux de disponibilité de l'application.
Consiste à faire fonctionner l'application à un rythme normal, pendant une période de temps relativement longue pour voir si une dégradation des temps de réponse, une fuite mémoire ou un blocage n'apparaît pas au bout d'un certain temps.
Test de robustesse S'assurer du bon fonctionnement de l'application avec une charge importante sur la durée. Nécessite qu'il y ait eu au préalable un test d'endurance complet.
Test de montée en charge Observer les limites que peut supporter l'application ou un de ses composants. On augmente le nombre d'utilisateurs simulés de manière régulière et on recherche le point de 'rupture', c'est-à-dire le moment où l'application ne répond plus dans le temps maximum accepté par l'utilisateur.

Le type de test choisi définira les paramètres du test (nombre d'utilisateurs simultanés, temps de pause entre chaque action, nombre d'itérations, etc.).
Une liste plus complète est disponible sur Wikipédia

III-E. Quels outils de tests

Il est important de choisir des outils que l'on maîtrise.

Les critères de sélection sont :

  • support de la technologie utilisée (HTTP, HTTPS...) ;
  • type de licence (faire attention au prix qui peut augmenter rapidement si on a besoin de faire beaucoup de tirs (l'application n'est pas stable)...) ;
  • simplicité pour la partie scripting et sa modification ;
  • les contraintes de sécurité (impossibilité de monitorer certains serveurs...).

Ne pas oublier de faire un POC (Proof Of Concept) pour les valider.

III-F. Avoir des SLA réaliste

Le test de charge consiste à simuler une utilisation réelle et voir si dans ces conditions l'application (ou le matériel) tient la route.
Pour cela il faut définir un certain nombre d'objectifs chiffrés et réalistes.

On peut classer ces objectifs en trois parties :

  • critères utilisateurs : temps d'affichage d'une page maximum acceptable ;temps d'affichage d'une page en mode dégradé acceptable ;
  • critères business : nombre d'utilisateurs simultanés ;
  • critères systèmes : taux d'occupation CPU maximum ;bande passante maximum ;taux d'occupation mémoire maximum.

Si votre entreprise n'en a pas déjà, définissez-en.

III-G. identifier les KPI

Une fois les SLA défini, il faut regarder quels KPI mesurer.

Par exemple :

  • temps de réponses ;
  • nombre de requêtes par session ;
  • taux CPU ;
  • nombre de sessions en mémoire ;
  • etc.

III-H. Avoir une base line

Et afin de pouvoir comparer nos résultats, il est utile d'avoir une base line.

Par exemple :

  • KPI avec un seul utilisateur ;
  • KPI de la version précédente de l'application.

III-I. Environnement de test

Penchons nous maintenant sur le côté matériel.

Il est important de tester les performances de l'application sur une configuration la plus proche possible de celle de production, bien qu'en raison du coût d'un tel choix, cela soit souvent compliqué.  Cette configuration devra être équivalente d'un point de vue matériel, logiciel (même version des logiciels) mais aussi d'un point de vue des données.
De plus il faut s'assurer de la disponibilité exclusive de l'environnement afin de garantir la fiabilité des résultats.

III-J. Jeux de données

Pour les données, il est important d'avoir un jeu de données suffisant et de qualité. Si elles n'existent pas, il faudra les créer (par exemple avec une réplication de la base de données de production ou à l'aide d'un outil de création de jeux de données comme Benerator).
Si elles existent déjà, il faut faire attention à ce qu'elles correspondent bien aux futurs besoins (par exemple si les données pour la V1 existent et que l'on va tester la future version, il faut bien vérifier que cette nouvelle version aura bien le même volume de données).

IV. À quoi faire attention

Avant d'aller plus loin, il est important de prendre en compte un certain nombre de points.
En voila un certain nombre sans ordre particulier.

IV-A. Application stable

Si l'application a des problèmes de performances avec seulement un utilisateur ou des problèmes fonctionnels, commencer la campagne de test sera une perte de temps.

IV-B. Attention à la surenchère

Les tests doivent être les plus réalistes possibles mais il est important de ne pas devenir trop perfectionniste et de perdre du temps sur des détails sans importance.

IV-C. Limite de l'application/hardware testé

Pour ne pas faire des tests inutiles ou mal interpréter les résultats des tests, il faut connaitre les limites hardware et software de la cible testée.
Par exemple si l'application ne supporte pas plus de dix utilisateurs en même temps (à cause de la licence, de limite fonctionnelle...), il est important de le savoir.
De même s'il y a des normes de sécurité (firewall...) qui empêchent certaines actions (installation de certains outils...).

IV-D. Limite hardware des injecteurs

En plus des limites de la cible testée, il faut faire attention à la partie hardware des injecteurs pour les mêmes raisons.

Et donc il faudra :

  • monitorer les injecteurs ;
  • utiliser toutes les machines disponibles.

IV-E. Freeze du Code

Afin de contrôler les paramètres qui changent entre chaque test, il est important d'avoir une application stable techniquement et qu'elle soit figée (le code ne change plus). Sans cela il faut prévoir beaucoup plus de temps ou pire des interprétations des résultats faussées. 

IV-F. Appel à des spécialistes

Dans certain cas, il peut être nécessaire de faire appel à des spécialistes (administrateur base de données, administrateur système/réseau, développeur...).
Par exemple s'il y a des gros problèmes niveau base de données, réunir le développeur du module posant problème et du dba fera gagner énormément de temps.
Donc il faut prévoir ces spécialistes dans le planning et dans le budget.

V. Paramètres à prendre en compte lors de leurs réalisations

Maintenant que nous avons une stratégie et un certain nombre de conseils, nous allons regarder ce qui permet de rendre un scénario plus réaliste.
Voici une liste non exhaustive.

V-A. Varier les entrées utilisateurs

Afin d'éviter de ne tester que les performances du ou des caches, il faut varier les entrées utilisateurs (valeurs dans les formulaires, identifiant/mot de passe...). Cela permet aussi d'avoir une couverture de test plus large car il se peut que certaines requêtes (SQL...) dépendent des données en entrée.
Attention à ne pas trop diversifier les valeurs des entrées utilisateurs afin de se retrouver avec un cache inutile. Car il ne faut pas oublier que la gestion d'un cache a un coût et donc les résultats seraient faussés.

V-B. Réutiliser les mêmes valeurs

Par rapport au conseil précédent, dans certains cas il peut être utile d'utiliser régulièrement la ou les mêmes valeurs afin de tester les contentions possibles.

V-C. Varier le type des utilisateurs

Pour chaque scénario, il faut identifier le type d'utilisateurs et leur ratio.
Par exemple pour un site d'achat il y a les visiteurs qui n'achèteront rien et les acheteurs.  De même, il peut être utile de différencier les nouveaux utilisateurs et les autres car cela a un impact sur le cache du serveur et du navigateur Web.

V-D. Varier et ajuster les temps de réflexion

Le temps de réflexion (ou think time) est le temps entre deux actions de l'utilisateur.
Il faut trouver le juste milieu pour sa durée afin de refléter la réalité. Une durée différente et bornée pour chaque temps de réflexion est une bonne solution.
Attention à ce qu'il ne soit pas trop court car les résultats du test seraient mauvais et on se retrouverait à essayer de résoudre un problème qui n'existe pas.

V-E. Prendre en compte les appels à un service extérieur

Attention au cas où l'application fait appel à un service extérieur (serveur de cartographie, serveur de validation du numéro de Carte Bleue...).

Et cela pour plusieurs raisons :

  • se faire bannir par le service car il se croit attaqué ;
  • avoir des faux positifs ;
  • etc.

V-F. Ajuster la durée du Ramp up

Le "Ramp up" est la durée de la période de montée en charge des utilisateurs.

Il faut la choisir assez longue pour que le serveur ne s'effondre pas sous la charge. Car durant cette période des traitements lourds seront réalisés (augmentation de la taille des pools, compilation JIT par la JVM...) sur une période courte alors que dans la réalité, le serveur aura surement plus de temps pour traiter ce surplus de travaille.

V-G. Ajuster la durée du test

Afin de laisser le temps aux caches de s'initialiser et de détecter plus facilement les fuites de mémoire/thread/connexions, il peut être judicieux dans certains tests d'avoir une durée de tests assez longue (temps variables en fonction de l'architecture).

V-H. Gestion des erreurs

Il est important de prendre en compte le nombre d'erreurs renvoyées par l'application afin d'éviter les faux positifs et de valider ou pas le test.
Par exemple pour le temps de réponse d'une page Web.

Temps de réponse
10 ms
8 ms
7 ms
erreur
erreur
erreur
erreur



Si on ne tient pas compte des erreurs on se retrouve avec une moyenne de 8,33 ms alors qu'en réalité, si les erreurs correspondent à un "time out" et/ou à une impossibilité de l'application de répondre pour cause de surcharge, le temps de réponse est mauvais. Et donc on passera à côté d'un problème.

V-I. Type de navigateur

Dans certains cas il peut être utile de faire les tests avec différents navigateur Web. En particulier lorsque le rendu de la page dépend du navigateur utilisé.
Par exemple, la vitesse d'exécution des scripts JavaScript dépend énormément du navigateur et de sa version. 

Toutefois une bonne gestion du cache peut diminuer le risque de ce problème et donc je pense qu'il est plus judicieux de traiter ce problème avec un outil du type PageSpeed, ou YSlow afin d'optimiser la gestion du cache et de réduire la différence entre les navigateurs.

V-J. Type de connexion utilisateur

Si une majorité des utilisateurs a un type de connexion (par exemple en 3G sur un téléphone), il peut être judicieux de tester l'application avec cette limite. Dans les autres cas, faire la même chose qu'au conseil précédent.

VI. Conclusion

Nous venons de voir un certain nombre de conseils pour réaliser une campagne de tests la plus réaliste. Bien sûr on pourrait en citer d'autres (ajuster la durée des itérations...) mais à moins d'être sur une application très critique et d'avoir le temps et le budget nécessaire, cela est largement suffisant.

De plus malgré tous les tests qui seront réalisés, il faut bien comprendre que :

  • le risque zéro est impossible à atteindre ;
  • le fait ne pas avoir eu de problèmes lors des tests ne permet pas de conclure que l'application n'en aura pas dans le futur.

Donc une fois l'application mise en production, la mettre sous surveillance à l'aide d'outils de monitoring.

VII. Remerciements

Merci à eusebe19 pour sa correction orthographique.