Comment effectuer une campagne de TMC sur votre e-commerce ?

Pour qualifier un applicatif, une architecture technique (matérielle ou logicielle) ou un service d’hébergement (Dédié ou Cloud), le test de montée en charge est l’outil indispensable, encore faut-il qu’il soit bien adapté au besoin, sous peine d’être inutile (résultats techniquement inadaptés) ou mal dimensionné (hors budget).

Pour rester pragmatique et ne pas s’éparpiller dans des détails trop techniques, nous allons garder une approche « Macro » et classifier les principaux outils de tests de charge en deux principales familles technologiques et en deux formes d’usages.

Pourquoi réaliser une campagne de test de montée en charge ?

Faire une campagne de test de montée en charge… Pas si utile que ça ? Bien au contraire. Les bons tests réalisés à des périodes clés, voire de manière récurrente, peuvent vous éviter d’importantes déconvenues en évaluant le degré performance de montée en charge. On vous explique en deux points simples pourquoi réaliser une campagne de test de montée en charge est indispensable.

Parce qu’ils ne sont souvent jamais réalisés, ni par l’équipe projet, ni par les hébergeurs

Dans les entreprises qui ont fait développer leur site (ou application, outil, etc.) en externe, une idée est largement répandue : « les équipes de mon prestataire auront forcément réalisé des tests de montée en charge, pour s’assurer qu’il reste accessible en cas de pic d’affluence. » C’est faux ! En fait, les développeurs ne réalisent quasiment jamais ces tests. Leur mission consiste à mettre à disposition un site en fonction de besoins exprimés (et c’est déjà une tâche conséquente !) Mais il ne leur est pas demandé de faire en sorte que l’infrastructure ou les lignes de codes « tiennent le choc » en cas de forte hausse de fréquentation.

Dans le cas où une entreprise fait développer son site en interne, le problème est sensiblement le même. Par défaut, l’équipe projet a uniquement un engagement de résultat sur les besoins exprimés et l’application mise à disposition. Si ce n’est pas demandé, une campagne de test de charge ne sera pas réalisée.

Alors… suffirait-il de demander à ses développeurs de réaliser cette typologie qu’est le test de montée en charge pour être tranquille ? Pas exactement. Car les batteries de tests mis à leur disposition sont des outils de stress tests qui bombardent les frontaux de requêtes http et qui ne feront que vérifier l’adéquation de l’infrastructure avec le cahier des charges. En clair, ces tests (utiles) vont contrôler des facteurs tels que : le pourcentage d’utilisation de la mémoire vive du serveur, l’utilisation du disque dur, de la bande passante… mais en aucun cas la perception du site par un vrai internaute, du point de vue end-user.

Alors peut-être est-ce de la responsabilité de l’hébergeur de vérifier qu’un site supporte le choc créé par une foule d’internautes s’y connectant en même temps ? Non plus. Dans le meilleur des cas, et si c’est prévu dans le contrat qui la lie à son client, l’entreprise hébergeuse pourra vérifier via des stress tests que l’infrastructure est conforme au cahier des charges. Mais pas que l’application reste accessible dans les meilleures conditions et à tout moment, y compris en cas de trafic et de forte affluence.

Pour éviter une perte de business, d’image, ou de crédibilité…

Alors quelles conséquences si ni l’équipe projet, ni les hébergeurs ne réalisent le bon test de montée en charge ? Cela peut aboutir à une fâcheuse mésaventure, comme cela a été le cas pour un grand groupe de e-commerce. Le jour des soldes d’été, catastrophe : leur site est indisponible. Son accès est resté inopérant durant 48 heures, puis dégradé pendant une semaine.

La note a été salée : plusieurs centaines de milliers d’euros de manque à gagner sur le marché. Pourtant, ce groupe pensait avoir agi de façon prudente. Leur hébergeur avait réalisé des stress tests permettant de vérifier que l’infrastructure pouvait théoriquement supporter une hausse brutale de fréquentation. À l’issue de ces tests, tous les indicateurs étaient « au vert ».

Mais contre toute attente, le jour des soldes, le site était bien inaccessible. Pourquoi ? Car les tests réalisés ne reproduisaient pas à l’identique de la réalité un internaute qui allume son ordinateur, ouvre une session entre le poste client et le serveur, se connecte à un navigateur puis au site de e-commerce… En somme : ils n’ont pas reproduit le parcours d’un internaute en conditions réelles, comme aurait pu le faire une campagne de test de montée en charge.

Pour aider cette entreprise à affronter les soldes suivantes sereinement, CloudNetCare a réalisé une campagne de test de montée en charge, mais en reproduisant cette fois des parcours clients réels. Cette stratégie a permis de déceler bon nombre de points de contention, qui n’avaient pas été repérés lors des précédentes campagnes. Par exemple, un blocage à 500 sessions simultanées a été identifié, tout comme un affichage anormalement lent d’une carte de points relais, mesuré à plus de 40 secondes. Grâce à ce travail, les soldes d’hiver se sont déroulés parfaitement.

On s’aperçoit donc que si des tests sont parfois réalisés en vue de prévoir des hausses de fréquentation, ce ne sont souvent pas les bons ou ils ne sont pas suffisants. Les stress tests réalisés par les hébergeurs ou par les développeurs sont très utiles, mais uniquement pour vérifier la solidité de l’infrastructure. Ils seront en revanche insuffisants pour contrôler la qualité de l’expérience utilisateur. Cette nuance peut donner un faux sentiment de sécurité, qui volera hélas en éclat lors d’un véritable pic d’affluence.

Les familles technologiques du test de montée en charge

• La première est basée sur des injecteurs de requêtes HTTP isolées (ex : jmeter).
• La seconde sur le pilotage de réels Devices (navigateurs Web, apps, clients lourds, …) qui sont pilotés via l’interface utilisateur dans un contexte d’exécution réel.

Les solutions basées sur l’émission de requêtes HTTP isolées n’embarquent pas de devices applicatifs et sont uniquement basées sur la reproduction de requêtes HTTP enregistrées au préalable. Suivant le type de service à tester, le fait d’embarquer et de piloter le device réel peut avoir un impact capital :

• Cas d’un navigateur Web (Desktop – IE/Egde/Firefox/Chrome/Safari) :
  Le navigateur joue un rôle de plus en plus central dans l’expérience utilisateur avec la multiplication des frameworks FrontEnd.Pour prendre en compte cela, il est important d’évaluer le degré de complexité FrontEnd du site à tester. Le navigateur va en effet réagir différemment en fonction du contexte réseau et des temps de réponse serveur. Les requêtes HTTP émises par le navigateur peuvent en effet être très différentes en fonction de la charge injectée sur les serveurs.Pour un site Web avec un FrontEnd simple, un injecteur de requête HTTP peut suffire. Par contre, pour un site où le FrontEnd est évolué, il est fortement recommandé de faire des tests avec de vrais navigateurs, sous peine d’avoir des résultats erronés et décorrélés du comportement réel.Il faut également garder à l’esprit que les injecteurs de requêtes HTTP isolées ne gèrent pas nativement les fonctions intrinsèques du navigateur : pas de session (pas compteur Google Analytics), pas de rendu d’éléments, pas d’exécution Javascript réelle, aucune mesure dans le navigateur.

• Cas d’un service Web API :Le but étant de tester directement les requêtes HTTP, les solutions basées sur des injecteurs de requêtes HTTP isolées sont parfaitement adaptées. L’utilisation de réels navigateurs n’apporte pas de valeur ajoutée.

• Cas d’un client lourd connecté : Etant donné la grande diversité technologique, une étude du système est nécessaire pour trouver la solution la plus adaptée. Le pilotage direct du client lourd via l’interface sera toujours plus réaliste mais la difficulté de mise en œuvre risque d’être prohibitive.

• SmartPhones :Le contexte est quasi-identique à celui du navigateur Web. Le contexte réel est optimal. La réelle difficulté reste d’avoir accès à des fermes de smartphones pour piloter de vrais devices. L’utilisation de Simulateurs / Emulateurs officiels (Android/iOS) en mode Cloud peut être un bon compromis. Les solutions basées sur des injecteurs de requêtes HTTP peuvent répondre à une logique de test du BackEnd, sans mesurer le comportement du smartPhone et le rendu utilisateur.Si l’applicatif à tester est purement Web (pilotage du navigateur Safari/Chrome) une alternative pertinente est de faire des tests de charge dans les navigateurs réels sur Desktop en redimensionnant la taille de l’écran à celui du mobile (Responsive Design) et en surchargeant le UserAgent.

• Objets connectés :Pour des objets avec un logique fonctionnelle simple, l’injection de requêtes HTTP peut suffire, mais si la logique applicative est évoluée, le test avec des devices réels s’impose. La problématique reste la même que pour les smatphone, à savoir, avoir accès à une ferme de devices significative.

Alors que les solutions embarquant et pilotant de réels Devices seront dans tous les cas plus proches du contexte réel, les solutions basées sur l’émission de requêtes HTTP isolées nécessitent moins de ressources matérielles et sont plus adaptées à des solutions On-Premise. Le Cloud permet de rendre les solutions pilotant des devices réel accessibles tant au niveau du coût que des technologies.

Les formes d’usage.

• La première est On-Premises (installation et le paramétrage des injecteurs sur sa propre infrastructure)
• La seconde est en mode SaaS (Cloud)

Les modes de licences sont également souvent couplés aux formes d’usage. Achat de licences pour un déploiement On-Premises contre un mode purement locatif en SaaS.

Le mode de test de montée en charge On-Premises nécessite également d’acquérir des serveurs et surtout de prévoir les ressources humaines qualifiées pour le paramétrage et la maintenance des systèmes. Cela peut être une solution à moindre coût dans le cadre de petits tests récurrents sur un service simple à tester (API ou site Web simple) mais peut rapidement être très onéreux pour des tests réalistes à forte puissance.

Le mode SaaS de test de montée en charge est plus adapté aux méthodes complexes à grande échelle et pour mieux reproduire le contexte de charge réel. (Tests depuis des IP publiques depuis Internet).

La facturation à l’usage est aussi un facteur à prendre en compte.

Fonction de type de solution à tester, une famille technologique couplée à une forme d’usage sera plus adaptée qu’une autre pour collecter les bonnes métriques dans le meilleur contexte à un coût adapté.

Type de solutions à tester :

Les 3 clés pour améliorer la disponibilité de votre site web.

Votre entreprise commercialise ses produits sur internet et effectue un niveau plus ou moins élevé de transaction en ligne ? Vous réalisez tout ou partie de votre chiffre d’affaires grâce aux ventes en ligne ? Il est donc indispensable de veiller à la disponibilité de votre site e-commerce. C’est-à-dire de s’assurer qu’à tout moment, chaque internaute peut accéder dans les meilleures conditions de confort à l’ensemble de ses fonctionnalités.

Tout l’enjeu est de veiller (et d’améliorer !) la disponibilité du site lors d’événements délicats : un pic d’affluence, la mise en ligne d’une nouvelle version ou de nouvelles fonctionnalités… À chacun de ces moments, votre site e-commerce doit être entièrement accessible. On l’aura compris, le test de montée en charge en fait partie !

Voici donc trois clés pour vous en assurer que votre site e-commerce sera toujours disponible.

Perfectionner les mises en production

Avant chaque nouvelle mise en production, l’objectif est de s’assurer que toutes les fonctionnalités continuent de bien s’articuler ensemble. Le test de montée en charge ou la non-régression permettent d’y remédier.

Par exemple, la sélection, la mise au panier puis le paiement d’un produit sont à la fois indispensables à la vie du site e-commerce, et inextricables les unes par rapport aux autres. Mettre en place des tests de non régression, en préproduction, pourra permettre de s’assurer que chaque fonctionnalité garde son accessibilité avant et après la mise en production.

Il faut également s’assurer du bon paramétrage de la solution e-commerce que vous utilisez : Magento, Prestashop ou Hybris par exemple. Le confort de navigation des internautes sera maximisé si elle est paramétrée avec soin. Par exemple, si la fonction autocomplétion du moteur de recherche a été calibrée avec précision, il y aura moins de chances que cette fonctionnalité soit rendue indisponible ou ne sature.

Retracer puis vérifier le tunnel d’achat via test de montée en charge

Le tunnel d’achat constitue la pierre angulaire du site e-commerce. Mais après des améliorations de version, des nouvelles fonctionnalités mises en ligne, la résolution d’un dysfonctionnement… le tunnel d’achat complet est-il toujours conforme ? Si on ne peut réaliser qu’un seul test, il doit donc se porter sur cette fonction-clé, composée de la sélection, de la mise au panier et du paiement d’un produit. Il est pertinent de vérifier leur fonctionnement grâce à une batterie de tests de non-régression, réalisés en préproduction.

Il est aussi très utile de mettre en place des tests de supervision applicative individuels sur le tunnel d’achat. Ils permettront de s’assurer, toutes les 5 ou 10 minutes, que cette fonctionnalité essentielle à la vie du site est bien accessible

Anticiper les pics d’affluence

Au fur et à mesure de son cycle de vie, le site e-commerce connait des moments critiques où sa disponibilité peut être mise à mal. Parmi les plus dangereux : le pic d’affluence. S’il est redouté, il est pourtant souvent prévisible. Pour la plupart des sites marchands, ce sont les soldes d’été et d’hiver, les passages dans la presse ou à la télévision… Mais chaque secteur d’activité a aussi ses spécificités. Par exemple, un site de jardinerie devra se méfier de l’approche de l’été, car dans son domaine cette période génère de l’affluence.

Des campagnes de test de montée en charge doivent donc impérativement être mises en place avant chaque événement majeur qui ponctue la vie du site. Ces tests reproduisent à l’identique de la réalité un grand nombre d’internautes se connectant au site ou à ses fonctionnalités. Cette stratégie peut éviter de grosses déconvenues, parmi lesquelles une importante perte de business. Au vu des investissements mis en place, un site web inaccessible car saturé est toujours un événement catastrophique.

L’idéal dans la mise en œuvre d’une campagne à base de test de montée en charge est de pouvoir tester l’infrastructure du site utilisé en charge (les frontaux, le CDN, le load balancer…), tout en accédant à une simple copie de la base de données de production. Il faudra donc avoir préalablement réalisé un back-up de cette base. Cela évitera de polluer la base de données en production, et de perturber les véritables internautes qui pourraient naviguer sur le site pendant la période de tests.

Encore une fois, le tunnel d’achat reste la fonction essentielle à tester via test de montée en charge, avec cette horde d’internautes reproduite à l’identique.

Pour conclure.

Ainsi donc, à partir d’un certain chiffre d’affaires réalisé sur internet, il est indispensable de mettre en place des campagnes de testing. La première typologie à réaliser est celle du test de montée en charge, puis viennent les tests de non régression.

S’il est possible de recourir à des solutions de testing gratuites, il faut garder à l’esprit qu’elles ne feront que simuler des parcours utilisateurs et non les reproduire à l’identique. Les conséquences sont parfois dommageables, par exemple des résultats éloignés de la réalité qui donneront un faux sentiment de sécurité. Ensuite, ces outils ne sont pas utilisables clé en main, et les résultats ne sont pas livrés avec leur interprétation précise, les KPIs utiles, les rapports de tests, la traçabilité sur ce qui a été effectué… Il peut donc être plus pertinent d’externaliser ces prestations auprès d’entreprises disposant d’une véritable expertise, notamment en matière de test de montée en charge.

On s’aperçoit donc que si des tests sont parfois réalisés en vue de prévoir des hausses de fréquentation, ce ne sont souvent pas les bons ou ils ne sont pas suffisants. Les stress tests réalisés par les hébergeurs ou par les développeurs sont très utiles, mais uniquement pour vérifier la solidité de l’infrastructure. Ils seront en revanche insuffisants pour contrôler la qualité de l’expérience utilisateur. Cette nuance peut donner un faux sentiment de sécurité, qui volera hélas en éclat lors d’un véritable pic d’affluence. La solution ? Le test de montée en charge CloudNetCare !