Testdecharge.com est une plate-forme self-service dédiée aux tests de charge. Ces tests sont exclusivement réalisés avec de vrais navigateurs.

Pourquoi réaliser des tests de charge ?

Prenons un exemple tiré de l’expérience. En 2011, lors d’une table ronde sur le e-commerce, Guillaume Victor-Thomas, fondateur et patron de l’agence de voyages en ligne Ecotour, racontait avoir démarré une importante campagne de publicité par un spot TV juste avant le journal de 20h de TF1. Par « excès de confiance » – ce sont ses mots – aucun test de charge ne fut réalisé en amont. Dès la diffusion du spot, Ecotour fut saturé de visiteurs, et le site devint indisponible. « Nous avons jeté 20 000 € à la poubelle », conclut M. Victor-Thomas.

Testdecharge.com permet d’éviter ce type d’incident.

Nous instancions et pilotons dans le Cloud des dizaines, centaines ou milliers de navigateurs web.
Durant les tests, ces navigateurs – appelés Real Browsers Virtual Users (RBVU) – reproduisent à grande échelle un scénario de navigation que vous aurez préalablement enregistré dans notre interface.
Les données récoltées sont traitées et analysées. L’objectif est d’en tirer les informations utiles permettant de mettre en évidence les points critiques.
Un utilisateur virtuel, dans les solutions de test traditionnelles, est un “thread” qui lance de simples requêtes HTTP pour simuler un navigateur.
Un RBVU est un utilisateur virtuel d’un genre nouveau : au lieu de se contenter de requêtes HTTP, il pilote un vrai navigateur – tout comme… vos internautes.

Parmi les nombreux avantages de cette nouvelle génération de tests, les trois principaux sont :

  • Le réalisme. Les requêtes HTTP ne permettent pas de voir votre site comme vous et vos clients le voyez : ce n’est qu’une suite d’échanges de requêtes client-serveur. L’interface n’est pas rendue, les fonctionnalités pas testées. Si votre site, lors d’un afflux de visiteurs, est capable de charger les pages, mais n’est dégradé qu’au niveau des fonctionnalités (par exemple, on ne peut plus ajouter un produit au panier), seul un test réalisé par de vrais navigateurs vous permettra de le détecter.
  • Le support complet de tous les framework : Ajax, Flash/Flex, et autres interfaces riches (RIA).
  • Les captures d’écran des étapes de vos scénarios, qui vous permettent de visualiser les erreurs et le rendu de votre page tel que vos clients la voient dans leur navigateur.

Votre infrastructure matérielle sera sollicitée par de vrais navigateurs, ce qui permettra de tester une résistance à la charge en conditions réelles.

Non, cela manquerait de réalisme ! Le temps d’attente entre deux pages de votre scénario est aléatoire lors du test, avec des valeurs minimum et maximum (que vous pouvez personnaliser). Cela garantit donc qu’à aucun moment la totalité de vos RBVU ne se trouvera à la même étape de votre scénario.
Il est possible de lancer plusieurs scénarios en même temps.

Oui, il vous suffit pour cela, dans l’écran de réglages de votre test, d’ouvrir le panneau déroulant « Domaines sortants pour ce scénario » et de décocher la case « Google Analytics » (ou tout autre outil de statistiques web).

Oui, sur la page de résultats d’un test, un bouton « Export CSV » est disponible à cet effet. L’export CSV contient des liens vers toutes les captures d’écran des erreurs.
Oui. Il vous suffit de cocher la case « Partager les résultats » sur la page de résultats d’un test. Une URL publique apparaîtra, que vous pourrez envoyer à vos contacts pour leur permettre de visualiser les résultats.

Oui, il est tout à fait possible de programmer plusieurs tests différents vers le même site en même temps. Le lancement des tests sera alors synchronisé : tous partiront exactement au même moment.

Oui. Si vos internautes proviennent de différents endroits dans le monde, il est effectivement intéressant, pour coller au plus près de la réalité, de réaliser des tests à partir de différentes régions.

Vous pouvez pour cela, dans les réglages de votre test, choisir l’origine géographique de votre choix parmi les options proposées : Europe de l’Ouest, Europe du Nord, Nord des Etats-Unis, Sud des Etats-Unis, Asie, Amérique du Sud, Australie, Japon. D’autres régions du monde seront proposées progressivement.

Le vôtre, que nous détectons automatiquement grâce à votre navigateur :-)

Pour des raisons de sécurité. Cela nous permet de vérifier que vous êtes bien le propriétaire du site à tester (et non un hacker mal intentionné tentant de réaliser une attaque par déni de service sur un site qui ne vous appartient pas).

Cela dépend en fait de la durée de votre scénario. Si vous lancez un test à 100 RBVUs, c’est bien que vous voulez simuler 100 internautes présents en même temps sur votre site. Or, si votre scénario de navigation ne dure que 5 minutes tandis que votre test dure 15 minutes, les RBVUs auront terminé leur navigation avant la fin du test, qui ne simulera donc plus de charge pendant les 10 minutes restantes.

Pour compenser cela, nous faisons jouer votre scénario en boucle. Cela signifie que lorsqu’un des RBVUs a terminé sa navigation, il est recréé, dans une nouvelle session, et rejoue votre scénario depuis le début. Cela permet de faire en sorte que la charge de 100 utilisateurs soit réellement présente jusqu’à la fin du test.

Ainsi, dans votre test de charge, ce qu’il est important de regarder n’est pas le nombre total de visites, mais le nombre de visiteurs surfant sur votre site en même temps. Les RBVUs ne correspondent donc pas au nombre de visites, mais au nombre de visiteurs simultanés.

Le taux d’erreur affiché correspond au pourcentage de RBVU ayant rencontré une erreur lors du chargement d’une page.

Dans le cas d’un scénario simple, les erreurs sont principalement de 2 types :

  • Soit le temps d’attente maximum de chargement de la page est dépassé (timedOut). Note : la valeur du timedOut est paramétrable dans les réglages du test.
  • Soit le texte recherché sur la page n’est pas présent (si un texte de vérification optionnel a été saisi).

Dans tous les cas, la cause de l’erreur est explicitement mentionnée dans le document CSV exportable à partir de la page de résultats du test. Dans ce même document, pour toutes les erreurs hors timedOut, un lien vers la capture d’écran de l’erreur dans le navigateur est disponible.

Afin d’assurer le réalisme du test (tous vos internautes ne font pas la même chose au même moment), le temps d’attente entre le chargement de deux pages de votre scénario par un RBVU est déterminé aléatoirement, entre certaines limites.
Ces limites sont le temps minimum d’attente entre deux pages, et le temps maximum d’attente entre deux pages. Leurs valeurs par défaut (5 secondes minimum, 10 secondes maximum) sont modifiables dans les réglages du test.

La durée moyenne du scénario est calculée en fonction du nombre de pages que comporte votre scénario, et de ces temps d’attente minimum et maximum. Il s’agit du temps moyen que prendront les RBVUs pour jouer votre scénario en entier.

Cet indicateur est utile pour deux choses :

  • Établir une durée moyenne de scénario qui soit proche du temps moyen passé sur le site par vos visiteurs réels. Cela accroîtra le réalisme de votre test.
  • Déterminer quelle devrait être la durée totale du test. Cf. question suivante : « Quelle devrait être la durée totale de mon test ? ».
La durée de votre test devrait dépendre de la durée moyenne de votre scénario (cf. question précédente « À quoi correspond l’indicateur “Durée moyenne du scénario” ? ») et de la courbe de montée en charge choisie. Nommée « Durée de la montée du trafic » sur la page de réglages du test, elle peut être plate ou progressive.

Nos recommandations :

  • Si la courbe de montée en charge est progressive (exemple : Pour un test à 100 RBVUs, on démarre à 1 RBVU et on augmente progressivement jusqu’à en atteindre 100). Choisir une durée totale du test légèrement supérieure au double de la durée moyenne de votre scénario.
  • Si la courbe de montée en charge est plate (exemple : Pour un test à 100 RBVUs, les 100 RBVUs sont présents dès le début). Choisir une durée totale du test légèrement supérieure à la durée moyenne de votre scénario.
Non, pas avec testdecharge.com.
Pour gérer les connexions, il faudra utiliser CloudNetCare avec la prise en compte des scénarios Selenium.
Contactez-nous pour en savoir plus sur la plate-forme CloudNetCare.
Une URL ne peut être utilisée de manière globale par un seul compte « testdecharge.com ».
Si un nouveau compte essaye de lancer un test sur une URL déjà utilisée par un autre compte utilisateur l’erreur suivante apparait « Vous ne pouvez pas lancer de test sur cette URL. L’URL est déjà utilisée. »
Cette contrainte est levée pour les Packs achetés.
Une fois que vous avez acheté un pack, la facture est disponible au format d’impression dans « Mon Compte », rubrique « Ma consommation ».
Il suffit de cliquer sur le bouton « Historique de la consommation », puis sur la ligne qui correspond au crédit du Pack cliquez sur « Voir » dans la colonne « Facture ». La facture s’affiche et vous pouvez l’imprimer directement.