Published On: 4 octobre 20197,1 min read

Les 5 questions à se poser avant d’automatiser ses tests de charge.

Vous êtes dans le e-commerce ou votre site internet ou application est un incontournable stratégique pour votre buisiness : les tests de montée en charge sont donc indispensables. Vous en avez peut-être déjà réalisé, pour être sûr que votre site tienne le choc face à la connexion simultanée de plusieurs dizaines, voire milliers, d’utilisateurs.

Mais vous souhaitez aller encore plus loin. Vous ne voulez plus vous contenter d’un simple “stress tests” qui vous donne la performance de votre infrastructure. Vous voulez connaître la qualité du ressenti de vos internautes au fur et à mesure de leurs connexions ? Alors voici les questions à se poser avant de se lancer dans l’automatisation de vos tests de montée en charge. D’ores et déjà le point de vigilance : ne faites pas l’amalgame entre tests de montée en charge et tests fonctionnels.

Quels sont mes objectifs ?

Une campagne de tests de montée en charge répond souvent à un ou deux objectifs précis.

  1. Tester son site ou application jusqu’aux limites. Quand est-ce que mon site tombe ? Pour cela il faut réaliser une campagne de type “crash test”. Nous allons « tirer » sur l’environnement jusqu’à ce que ce dernier ne soit plus accessible. Toutefois cela ne permet pas d’obtenir le ressenti de l’utilisateur au fur et à mesure de l’évolution du trafic.
  2. Vous souhaitez que, par exemple, 100 internautes puissent naviguer sur votre site dans les meilleures conditions et puissent exécuter un parcours précis. Il ne s’agit plus de tester « aux limites », mais d’obtenir des métriques sur le ressenti de l’utilisateur au fur et à mesure de la montée en charge. Quels sont les temps de chargement ? Comment réagissent les services tiers ? À partir de quand l’expérience utilisateur ne permet plus de passer commande ? Autant de données qui vous permettront de mettre en place l’infrastructure nécessaire, d’effectuer les corrections sur votre application, d’adapter votre SGBD/R, .. pour atteindre vos objectifs

Ai-je assez d’éléments pour rédiger un cahier des charges ?

C’est le b.a-ba ! Bien trop souvent négligé, le cahier des charges est l’élément clé pour mener le projet à bien. Au-delà de l’expression du besoin il va permettre aux différents intervenants de s’approprier le projet avec la même : description, terminologie, besoins, … 

Il faut structurer et implémenter des scénarios qui vont reproduire au plus près les actions des internautes et il faut cartographier les parcours qui ont le plus de chance d’être impactés par la performance. 

Sur un site e-commerce, nous pouvons retrouver ces types de scénarios :

  1. Parcours d’un badaud, anonyme
  2. Parcours d’une création de compte
  3. Parcours d’une connexion
  4. Parcours d’un achat
  5. Parcours d’un internaute avec une carte de fidélité

Une campagne de tests de montée en charge sera réalisée avec au minimum un scénario et nous recommandons de ne pas aller au-delà de 5 scénarios, pour une capacité d’analyse et d’exploitation des résultats. Tout en n’oubliant pas que les scénarios sont variabilisables (utilisateurs différents, produits différents …).

Qui est le chef de projet dédié et aguerri pour coordonner la campagne de tests de montée en charge ?

Lorsque l’on réalise une campagne, plusieurs acteurs vont devoir intervenir :

  • Le représentant de l’équipe de développement
  • L’hébergeur de l’infrastructure
  • L’équipe métier
  • Le prestataire en charge de l’exécution de la campagne
  • Les partenaires des services tiers ; module de paiement, de livraison, …

Pour coordonner tout ce beau monde, il faut un interlocuteur responsable et coordinateur des différents intervenants. Celui-ci devra avoir le charisme, la compétence et le pouvoir de statuer face aux différents intervenants.

En général, le partenaire qui effectue les tirs est perçu comme le cailloux dans la chaussure. Il risque de mettre en exergue les éventuelles défaillances de l’application et donc d’un ou plusieurs intervenants précités. Si vous ne disposez pas d’un chef de projet capable de statuer et/ou imposer, vous pouvez vite vous retrouver à tourner en rond en regardant les acteurs se renvoyer la balle !! 

Quel est l’environnement sur lequel je vais effectuer mes campagnes de tests ?

  1. Recette/homologation : Avec la version xx.x « figée » sur un environnement technique « light » 
  2. Staging : Avec la version xx.x « figée sur environnement technique au plus proche de celui de production
  3. Production : Avec la version en production sur l’environnement mis à disposition pour vos internautes 

La question est clé car en fonction de l’environnement l’infrastructure sous-jacente est différente et la base de données n’est pas peuplée de la même manière. Le choix de faire les tests sur tel ou tel environnement va dépendre du niveau d’avancement de votre projet. 

Pour une première mise en ligne de vote site ou application, il est impératif de réaliser les tests de montée en charge à minima sur l’environnement de recette et, au mieux, sur un environnement de staging. L’environnement de production n’existant pas la question ne se pose pas ;-) 

Sur un environnement de staging nous allons pouvoir mener des campagnes sur un environnement stable et dédié à la campagne, avec un jeu de données non altéré et élaboré pour les tests.

Mais si vous disposez déjà d’une version en production et que vous souhaitez faire une mise à jour, la question peut se poser : est-ce qu’il est impératif de mettre en œuvre un environnement de staging ou est-ce que l’on peut se contenter de tirer sur l’environnement de production ? Quel est le ROI ? Quel est l’objectif ? 

Si l’objectif est de s’assurer que l’environnement de production tienne la charge : seule solution : tirer sur cet environnement. Evidemment si l’on décide de le faire il faut isoler la partie relative aux données en dupliquant la BDD pour « tirer » sur une réplique. Le revers de la médaille, il faut prévoir une indisponibilité de la plateforme lors des tirs. Avantages directs : sollicitation des frontaux de production (CDN, load balancer, webservices) et de l’application en production. Les métriques obtenues seront on ne peut plus fiables !

Est-ce que l’outil sélectionné pour exécuter vos tests répond à vos besoins ?

Il faut poser à nouveau le besoin :

  1. S’agit-il de vérifier que l’infrastructure technique est capable d’assumer la charge ?
  2. S’agit-il de mesurer le ressenti de l’internaute derrière l’écran. 

Dans le cas n°1, vous pouvez vous contenter d’utiliser des outils open source du type Jmeter. Les informations récoltées seront suffisantes à répondre à votre besoin.

Mais pour répondre aux deux besoins, il n’y a pas d’autres solutions que d’instancier des machines pour reproduire à la réalité les utilisateurs et y associer une plateforme adaptée, type CloudNetCare.

Pour conclure.

Ces 5 questions sont clés pour mener à bien vos tests de montée en charge. Si vous êtes capable de répondre à chacune il y a fort à parier que votre campagne se déroulera dans les meilleures conditions et vous apportera satisfaction. Mais si vous avez encore le moindre doute sur l’une d’entre elle, prenez le temps nécessaire pour y apporter une réponse fiable. Et, au besoin, nous sommes à votre disposition. Les équipes CloudNetcare réalise, entre autre, des campagnes de TMC depuis une décennie ;-)

Pour aller plus loin :

Testez plus vite et mieux avec les outils CloudNetCare

Une plateforme SaaS puissante au service de vos développements et de l’expérience de vos utilisateurs. Testez plus vite, plus souvent et mieux avec la plateforme d’automatisation des tests de CloudNetCare.

Testez plus vite
et mieux avec les outils
CloudNetCare

UX Functional testing

Plateforme SaaS de tests de montée en charge

UX Functional testing
UX Functional testing

Testez plus vite et mieux avec
les outils
CloudNetCare

UX Functional testing

Plateforme SaaS de tests de montée en charge

UX Functional testing
UX Functional testing