Le test de charge est l’une des formes les plus cruciales de tests de performance. Son but principal est de comprendre comment un système se comporte sous une charge prévue. Les applications Web mal performantes peuvent nuire à votre entreprise, à vos revenus, à votre taux de conversion, à votre taux de rebond et à votre réputation. Comprendre les heures ou les délais les plus occupés pour votre entreprise, et se préparer à ce genre de charge sur votre système tout en automatisant l’ensemble du processus peut être lourd. Pour satisfaire à cette exigence non fonctionnelle de servir les utilisateurs, votre site Web, applications, services Web ou API en moins de quelques secondes est essentiel pour augmenter le taux de conversion tout en abaissant les taux d’abandon. Tester votre système sous un grand nombre d’utilisateurs simultanés et d’enquêter sur le point de rupture, ou goulot d’étranglement, (Processeur, allocation de mémoire, ou réseau), du logiciel et le matériel qu’il est installé sur, donne aux entreprises un excellent aperçu pour améliorer leurs temps de service. Les tests de charge n’ont pas toujours besoin de commencer après la sortie minimale viable du produit. S’il est démarré sur une base de module ou de fonction dans les premiers temps de développement, il a beaucoup à offrir en termes de diminution des risques avant le lancement.
Test de charge pour différentes interfaces Web
Des outils comme Pagespeed ou des outils de développeur peuvent donner un aperçu limité du comportement de votre site Web pour une demande spécifique. La plate-forme LoadView est un excellent atout dans votre boîte à outils pour comprendre où les goulots d’étranglement existent afin que vous puissiez les corriger rapidement.
Sites Web de test de charge
Cette option convient pour tester une seule page Web pour les utilisateurs simultanés. Le champ URL est la page Web qui va être testée de charge. Différents types de navigateur peuvent être sélectionnés (Chrome, Firefox, Internet Explorer pour le bureau – iOS, Android, Windows Phone et Blackberry pour mobile).
Applications Web de test de charge
Utilisateurs simultanés effectuant une série d’actions scriptées dans Chrome. En utilisant cette option, les applications Web peuvent être testées pour créer des scripts préenregistrés et alimenter ce script pour charger le test de l’application.
Par exemple, une fonctionnalité de caisse de panier e-commerce peut être facilement testée à l’aide d’un script préenregistré. Les mesures que vous devez prendre sont les suivantes :
1) Entrez une URL de départ (page d’accueil, page produit, page de résultat de recherche, etc.)
2) Type d’appareil utilisateur (mobile ou bureau)
3.a) S’il s’agit d’un appareil de bureau, le type de navigateur doit être sélectionné (Internet explorer, chrome)
3.b) S’il s’agit d’un appareil mobile, le type d’appareil doit être choisi (à partir d’une grande variété d’appareils mobiles)
4) Résolution à enregistrer (pour le type d’appareil mobile, le paysage ou les modes portrait sont disponibles)
Avec tous les champs requis entrés, en cliquant sur le bouton enregistrer commence maintenant la session d’enregistrement. Il navigue vers l’URL de départ et vous permet d’interagir avec le site Web. Désormais, vous pouvez simuler un comportement de l’utilisateur, comme trouver un produit à partir du site, l’ajouter au panier et passer à la page de caisse.
Une fois que toutes les étapes souhaitées sont simulées, l’arrêt de clic met en pause le script.
Vous pouvez soit continuer à enregistrer le script à partir de l’endroit où vous vous êtes arrêté en utilisant le bouton «continuer l’enregistrement» ou enregistrer le script en cliquant sur jouer maintenant. Comme l’indique la capture d’écran, les scripts enregistrés doivent être lésés au moins une fois pour vérifier s’il y en a avant d’enregistrer. Après avoir lu le script enregistré une fois, un popup indique que tout est en place, et les interactions qui ont été enregistrées comme un script ont été jouées avec succès. Par conséquent, nous pouvons procéder à sa sauvegarde.
Les paramètres d’enregistrement de script sont enregistrés et maintenant nous pouvons passer à des paramètres d’appareil supplémentaires.
Ici, vous pouvez configurer divers paramètres supplémentaires pour votre appareil.
Délai d’attented’achèvement : si le script est bloqué quelque part dans le plan d’exécution, un délai d’attente fixe permettra à votre script de lancer une erreur.
Abort script sur la première erreur: si cette option est définie à oui, le script va s’avorter sur la première erreur. Sinon, il réessayera l’étape qu’il n’a pas réussi à accomplir.
Options DNS :en utilisant cette option, vous pouvez créer un nom de domaine personnalisé — cartographies IP, ce qui est idéal pour tester le code en développement.
API de test de charge
Similaire à l’option site Web, il ya un champ URL, où vous devez entrer le point de terminaison de l’API qui va être testé de charge. HTTP ou HTTPS peuvent être sélectionnés pour le protocole.
Paramètres d’appareil supplémentaires pour les tests de charge API :
1. Délai d’achèvement: Si la demande prend plus de secondes, elle lancera une erreur.
2. Type de demande: Toutes les méthodes de demande de http peuvent être testées ( GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS,TRACE,PATCH)
3. Vérification SSL/Certificat. Pour une tâche HTTP, plusieurs options SSL sont disponibles :
3a. Autorité :si le certificat racine est fiable ou non
3b. Nom commun (CN): vérifie l’URL et le certificat correspond ou non au nom commun
3c. Date : vérifiela date d’expiration du certificat
3d. Révocation: vérifie si la chaîne SSL a ou non un certificat révoqué.
3e. Utilisation :vérifie s’il y a une utilisation inappropriée d’un certificat intermédiaire
3f. Les certificats clients peuvent être installés sur un agent de surveillance.
4. Validation du contenu: Le contenu peut être recherché pour des mots clés spécifiques et configuré pour lancer une erreur si les spécifications requises ne sont pas respectées. De nombreux mots clés peuvent être regroupés à l’aide d’opérateurs logiques : {[(«keyword1» et keyword2) | !» mot clé3»]}
5. Authentification de base: Nom d’utilisateur et authentification basée sur le mot de passe
6. En-têtes: Les en-têtes personnalisés peuvent être réglés pour la demande d’API. (Nom de l’en-tête = Valeur)
7. Options DNS : Attribuezdes noms d’hôtes personnalisés à des adresses IP spécifiques en utilisant l’option DNS.
Services soap d’essai de charge
À l’aide de cet appareil, vous pouvez charger des services Web basés sur XML. Des champs d’entrée similaires comme l’appareil REST API sont présents.
URL: Url du service SOAP.
ACTION SOAP: Ce champ peut être utilisé pour indiquer l’intention de la demande. La chaîne vide «» est traduite comme l’intention du message SOAP est donnée par l’URI. Aucune valeur n’est traduite comme aucune intention pour la demande.
Authentification debase : Authentification basée sur le nom d’utilisateur et le mot de passe pour le service WEB SOAP.
En-têtes: Des en-têtes personnalisés peuvent être envoyés à l’aide d’une paire de valeur clé.
Validation du contenu :Le contenu peut être recherché à l’aide de mots clés.
Options DNS:
1. Dispositif mis en cache : le cache de périphérique sera utilisé pour la résolution DNS. Ces informations de cache sont récupérées de la tâche précédente.
2. Non mis en cache : Chaque exécution fera l’enquête sur les serveurs DNS.
3. TTL mis en cache : Si le cache de l’appareil manque l’adresse nécessaire, le serveur DNS local sera utilisé.
4. Serveur DNS externe : L’adresse IP donnée sera traitée comme un serveur DNS.
Mise en place de tests de charge
LoadView offre trois façons différentes de définir la courbe de charge que votre système va rencontrer. Ces différentes options offrent une grande capacité de personnalisation pour divers cas d’utilisation complexes à expérimenter.
Courbe d’étape de charge
Les courbes d’étape de charge sont grandes pour l’essai pour la quantité brute d’utilisateurs. Vous pouvez augmenter, diminuer ou retenir un certain nombre d’utilisateurs pendant le nombre de minutes désiré.
Courbe basée sur les objectifs
Au lieu de définir le nombre prédéterminé d’utilisateurs simultanés, une courbe basée sur des objectifs permet de définir le nombre d’utilisateurs pour atteindre un montant transaction/objectif par minute. Ces transactions peuvent être la génération de plomb, les commandes de paniers, les actions d’inscription, etc.
Courbe réglable dynamique
En fixant un point de départ et une valeur maximale, vous pouvez passer d’un nombre à l’autre d’utilisateurs simultanés pendant l’exécution de votre test. C’est la même chose que de dessiner un graphique à l’aide d’un outil à main levée. L’option courbe réglable dynamique répond même aux cas d’utilisation et aux pointes de charge les plus complexes que ces états peuvent encourir.
Charge utile injecteur de charge
Ce paramètre décide du nombre d’utilisateurs par injecteur de charge. Le numéro recommandé peut être défini à l’aide du bouton calibré.
Géolocalisation de l’injecteur de charge
Différents géolocalisations peuvent être définies pour différents injecteurs de charge. Cela permet de tester votre système en utilisant différentes demandes de différents emplacements. La plate-forme LoadView vous permet de choisir parmi plus de 15 sites dans le monde entier.
Comprendre les résultats des tests de performance
À partir de la section rapports, des informations graphiques supplémentaires sur les tests de charge peuvent être trouvées.
Dans le graphique du plan d’exécution, vous pouvez déterminer si le test de charge a été exécuté comme prévu ou non. Par exemple, dans le graphique ci-dessus, après la marque de 30 secondes à 1 minute, nous pouvons voir que le nombre réel d’utilisateurs ne pouvait pas atteindre neuf utilisateurs pour une raison quelconque. Le nombre maximum d’utilisateurs a été atteint après la marque de 4 minutes et 30 secondes.
Plan d’exécution
Le graphique moyen du temps de réponse est idéal pour comprendre comment votre système se comporte sous différentes charges. Dans ce test, nous pouvons voir que le temps de réponse du système testé a augmenté de façon spectaculaire sur la marque de 0-30 sec. ( ~50 secondes, indique un goulot d’étranglement) Après le premier temps de réponse moyen de pointe était d’environ 10 secondes, ce qui est assez lent pour les attentes des utilisateurs aujourd’hui (tous les sites Web devraient viser moins de 2 secondes pour le taux de rebond minimum et le taux de conversion maximum).
Temps de réponse moyen
Nombre cumulatif de sessions
Nombre cumulatif de séances tout au long du cours d’essai de charge. À partir du graphique ci-dessus, le nombre total de sessions que le système peut gérer peut être déduit. Dans ce cas, après 150-200 sessions, certaines nouvelles sessions ne pouvaient pas commencer et ont jeté une erreur.
Serveur de référence
À partir de l’onglet Rapport de session, vous pouvez filtrer les sessions pour inclure uniquement l’injecteur de charge de référence. Cet injecteur de charge de référence exclut le stress matériel (il n’exécute qu’un seul utilisateur virtuel) pendant l’exécution du test afin que vous puissiez le comparer avec les versions lourdement chargées.
Après avoir filtré les sessions d’injecteur de charge de référence, vous pouvez lire la vidéo d’exécution pour comparer les injecteurs de charge et l’utilisateur de référence à l’aide du bouton vidéo.
Graphiques de chute d’eau
Enfin, les graphiques de chute d’eau donnent des connaissances approfondies sur votre interface Web et les goulots d’étranglement. Par exemple, un site Web se compose de demandes de fichiers faites au serveur Web (fichiers CSS, fichiers JavaScript, fichiers HTML, etc.). En utilisant le graphique cascade, nous pouvons comprendre quelle demande est le facteur de blocage, augmentant la vitesse de charge. L’élimination de l’élément de blocage, l’asynchrone des demandes ou le chargement du CSS critique d’abord, puis le reste du CSS après peuvent réduire le temps de chargement.
La compréhension de ces facteurs de blocage au début du développement ou du lancement peut faire économiser beaucoup de budget et de temps, ce qui se traduit par une meilleure gestion du trafic et de la capacité. Pour plus d’informations approfondies sur les graphiques cascade, lisez notre article de blog sur l’optimisation des performances web en comprenant les graphiques cascade.
Conclusion : Aperçu des tests de charge et compréhension des rapports et des graphiques des chutes d’eau
Si votre site Web ou votre application est soumis à un accord de niveau de service (SLA), le test de charge devient un must pour montrer à vos clients que le logiciel est prêt pour la quantité de charge prévue. Par exemple, si vous avez déjà un objectif de transaction prédéterminé, ou si vous connaissez (approximativement) le nombre de visiteurs que vous attendez sur votre site Web ou votre application au cours d’une période donnée, l’exécution d’un test de courbe basé sur des objectifs aidera à confirmer que votre site ou application répond aux exigences prédéfini.
En outre, générer une charge accrue sur un site Web ou des applications peut aider à prédire les performances de l’application pour une charge utilisateur plus lourde à l’avenir. Cela se fait généralement à des fins de planification de la capacité. Les résultats de vos tests de charge peuvent vous aider à déterminer les éléments individuels qui ont besoin d’une attention immédiate. En outre, LoadView conserve vos résultats de test précédents afin qu’ils puissent être utilisés comme repères par rapport aux nouvelles mesures de performance après avoir apporté des modifications à votre site ou application.
Essayez LoadView dès aujourd’hui ! Inscrivez-vous et recevez jusqu’à 5 tests de charge gratuitement !