Nous contacter au +33 1 84 20 44 13

Quelles solutions pour effectuer des tests de montée en charge ?

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.

I. Les familles technologiques

.

  • 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.

II. 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 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 est plus adapté aux tests 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 dernières actualités

Les 5 étapes nécessaires pour rédiger une fiche de tests efficace

Vous venez de passer des jours, des mois voire des années à travailler sur la mise en production d’une mise à jour, d’une nouvelle fonctionnalité ou pour corriger une régression ? Vous ne pouvez pas vous permettre, lors de la mise en ligne, de générer, potentiellement à nouveau, des régressions ?

ESSAYER GRATUITEMENT
2018-07-04T11:07:46+00:00