CloudNetCare est une plate-forme complète de tests logiciels, disponible en mode SaaS.
Elle couvre les environnements de développement et de pré-production avec les tests fonctionnels et les tests de charge.
Elle couvre également les environnements de production avec la supervision applicative et la supervision des services tiers.

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.

CloudNetCare sert, par exemple, à prévenir 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.
Suivant les usages, les données récoltées sont traitées et analysées avec pour objectif d’en tirer les informations utiles et mettre en évidence les points critiques.
Par exemple :
– point de rupture pour un test de charge
– message d’erreur pour un test fonctionnel
– vidéo du parcours en erreur pour la supervision

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 utilise pilote un vrai navigateur – tout comme… vos internautes.

Parmi les nombreux avantages de cette nouvelle génération de tests, les 3 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é dans 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 permet de tester la véritable 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 en même temps …

Oui, vous pouvez. Il vous suffit de lancer le processus de Nouveau Test dans CloudNetCare et de :

  • (Page « Nouveau scénario ») : créer un scénario Selenium au cours duquel vous vous connectez à un compte sur votre site.
  • (Page « Validation du scénario ») : trouver l’étape de votre scénario correspondant au moment où vous avez saisi l’identifiant (ce qui est très simple à repérer grâce aux captures d’écran) et la définir comme “champ de login”, puis trouver l’étape correspondant à la saisie du mot de passe, et la définir comme “champ de mot de passe”.
  • (Page « Réglages du test ») : Si vous souhaitez que tous les RBVU se connectent au même compte, vous n’avez rien à faire de plus. Si, pour davantage de réalisme, vous souhaitez que les RBVU se connectent chacun à un compte différent, il vous suffit d’ouvrir la rubrique “Import d’une base d’identifiants”, et d’uploader un fichier CSV (réalisable sous Excel) contenant la liste de tous les identifants et mots de passe à utiliser. Vous pouvez également saisir ces paires login/mot de passe directement dans notre interface, si vous préférez.
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 RBVU, 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 RBVU 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 RBVU 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 RBVU 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é (timeout). Note : la valeur du timeout 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 à parti de la page de résultats du test. Dans ce même document, pour toutes les erreurs hors timeout, un lien vers la capture d’écran de l’erreur dans le navigateur est présent.

Pour les scénarios Selenium, une autre cause d’erreur est possible. En effet, les scénarios Selenium sont séquentiels et chaque nouvelle page dépend d’une action sur la page précédente (Clic sur un lien, sur un bouton…). Si l’élément (lien, bouton…) nécessaire à l’action n’est pas trouvé dans la page, cela génère alors une erreur. Une capture d’écran de la page permet alors de voir la page incriminée et comprendre pourquoi le lien ou le bouton n’est pas présent.

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 page, 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 RBVU 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. Voir 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 (voir question précédente “A 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 (ex : Pour un test à 100 RBVU, 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 (ex : Pour un test à 100 RBVU, les 100 RBVU 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.