Quand il s’agit de l’expérience theuser, il n’y a rien de plus important pour les utilisateurs que d’expérimenter des fonctionnalités lisses et stables des applications Web. Ces aspects sont comme les parties fondamentales de tout site Web ou application Web, et essentiels à son succès. Cependant, comme plus d’utilisateurs commencent à accéder à l’application, plus de ressources sont utilisées, et généralement, plus elle devient lente. C’est une expérience terrible pour les utilisateurs car ils ont commencé à recevoir des messages d’erreur système étranges, des délais d’attente, une réponse lente à la page et des erreurs de serveur. Pour nous sauver de tout cela Questions, nous devons passer à l’étape suivante et effectuer des tests non fonctionnels, tels que : Test de charge ou test de résistance, ce qui permet de valider si l’application peut gérer un grand nombre de utilisateurs simultanés, ainsi que de déterminer comment le système réagit à mesure que le trafic évolue.

Avant de commencer votre parcours de test de charge, il est important de comprendre les meilleures pratiques sur la façon de simuler des tests de contrainte sur l’application, qui est aussi proche que l’environnement de production. La stratégie de test de performance de base consiste à répondre à des questions telles que les suivantes :

  • Nombre d’utilisateurs simultanés requis pour notre test de charge.
  • Simulant de vrais scénarios de test utilisateur.
  • Charges virtuelles géo-distribuées.
  • Rampe de montée et de montée en puissance des périodes.
  • Durée du test.

Discutons de chacun d’eux et comprenons pourquoi ils devraient être dans notre liste de contrôle avant d’exécuter nos tests de charge.

 

Utilisateurs simultanés requis pour les tests de charge

Avant de mettre en place un test qui reflète un comportement proche du comportement réel de l’utilisateur, nous devons passer un certain temps à déterminer combien d’utilisateurs simultanés sont nécessaires pour simuler pour notre test. Les utilisateurs simultanés définissent le nombre d’utilisateurs qui navigueront sur notre site Web ou notre application Web et effectueront des transactions sur une période de temps spécifique. Le trafic vers vos sites et applications diminue probablement et coule tout au long de la semaine, mais afin de tester correctement vos sites et applications, vous voudrez configurer votre test à des heures de pointe supérieures au trafic. Mais comment trouvez-vous correctement le bon nombre d’utilisateurs simultanés ?

Nous pouvons utiliser des outils d’analyse Web pour déterminer les statistiques de trafic actuelles sur notre site Web avec des détails à rechercher comme le nombre de visites, la durée des sessions sur le site Web. Google Analytics et de nombreux autres outils d’analyse peuvent fournir des mesures de sessions que votre site Web a par temps régulier et la durée moyenne de la session, et le temps passé par les utilisateurs sur le site. Nous pouvons utiliser la formule ci-dessous pour estimer le nombre d’utilisateurs simultanés :

Utilisateurs simultanés = Sessions horaires x Avg. Durée de la session (en minutes)/60

Si nous n’avons pas de données d’analyse web, nous pouvons utiliser le nombre prévu de visites d’utilisateurs pour calculer le nombre d’utilisateurs simultanés :

Utilisateurs simultanés = Nombre de visites prévues par minute * Durée de la visite (en minutes)

Pour plus d’informations et de conseils sur la configuration des utilisateurs actuels, visitez notre base de connaissances et lisez notre article sur le calcul des utilisateurs simultanés à partir de l’analyse web.

Simulation de scénarios réels de test utilisateur

Comme nous sommes maintenant prêts avec les utilisateurs simultanés, nous devons trouver les scénarios de tests de trafic fréquents et élevés pour faire partie de nos tests de résistance. Gardez à l’esprit qu’il n’est pas nécessaire d’utiliser de nombreux scripts pour chaque situation. En règle générale, vous constaterez que seul un petit nombre de cas d’utilisation sont nécessaires pour déterminer la charge réelle pour toutes vos transactions.

Une fois que nous avons déterminé le niveau pertinent des utilisateurs simultanés, nous devrions choisir l’approche appropriée de simulation de tâche de test de charge, basée sur l’application à l’essai.

Chargement testant les applications Web et les pages Web

Pour simuler des scénarios d’utilisateurs et des transactions pour des applications web et des sites Web, nous devons scripter les trajets des utilisateurs pour simuler notre scénario de test. Pour ce cas d’utilisation, nous pouvons utiliser l’enregistreur Web EveryStep, qui enregistre les interactions de notre navigateur et crée un script qui peut être utilisé pour notre test de charge. L’enregistreur Web EveryStep est facile à utiliser, mais capable de scripter les scénarios les plus complexes. En outre, les utilisateurs peuvent définir des retards, modifier des mots clés ou des variables de champ, définir la limitation du réseau, et bien plus encore. Pour en savoir plus sur l’édition d’un script avec l’enregistreur Web EveryStep, visitez notre base de connaissances pour plus d’informations.

Pour exécuter des tests de charge pour les pages Web, les équipes peuvent utiliser l’option Page Web dans LoadView, qui commence le processus de test des pages Web avec des utilisateurs simultanés.

De plus, la plate-forme LoadView permet aux équipes de développement de charger des API de test et des médias en streaming. Pour plus d’informations sur les API et les pages multimédias en streaming, visitez notre page Produits .

 

Configuration du test LoadView

 

Charges virtuelles géolocal distribuées

Comme vous le savez probablement déjà, la latence du réseau a un impact énorme sur les sites Web, donc alors que notre test de résistance, nous ne devrions pas négliger les utilisateurs simultanés d’être géographiquement répartis charge, de sorte que nous simulons le même comportement que nous voyons dans l’environnement de production, ainsi que vérifier les temps de réponse pour les utilisateurs situés loin de votre centre de données. Considérez une page Web qui télécharge 2 Mo de contenu pendant la mise à jour et 10ms pour chaque demande back-end. Le temps de chargement dans votre centre de données sera inférieur à cinq secondes en raison de la proximité et de la faible latence.

Sur des sites spécifiques à l’étranger, comme l’Asie, avec une latence de 200ms, les temps de réponse de ce site seront de cinq secondes pour l’arrière, et plus de 200ms pour le transfert de réseau. Nous ne devrions pas faire d’erreur et mesurer les temps de réponse uniquement à l’intérieur de notre centre de données. Nous pouvons utiliser LoadView ici qui donne une large gamme de machines d’injection de charge à travers le monde. Parmi toutes ces options, nous pouvons sélectionner tous ceux qui représentent l’emplacement habituel de nos clients.

 

Période de montée en puissance entre l’échelle

Habituellement, nos sites Web ont dispersé les utilisateurs simultanés à différents moments de la journée, nous avons peu des heures de pointe au cours de laquelle nous avons le trafic le plus élevé. Nous devrions utiliser la même approche pour mettre à l’échelle et mettre à l’épreuve les applications en utilisant la même stratégie de montée en puissance. LoadView vous donne la possibilité de configurer votre montée en puissance, les temps de attente, et à quel rythme vous devez descendre.

 

Durée des tests de charge

La durée du test est un facteur très important lors des tests de charge pour la seule raison de fournir suffisamment de temps à l’application afin qu’elle génère des résultats réalistes avec des détails tels que le temps de réponse, le débit et si un mécanisme de cache est présent dans l’application, il est mis en cache pendant notre période de montée en puissance. Pour décider de la durée du test, nous devons nous attendre à notre scénario de test et à nos exigences. Nous pouvons envisager les cas suivants tout en décidant de la durée du test pour un test de charge :

  • Nous devons nous assurer que chaque étape de demande/test doit être exécuté au moins 10 fois. Nous devrions maintenir la durée du test plus élevée pour les scénarios longs par rapport aux scénarios plus petits.
  • Nous devrions également décider quel type de test de charge prévoyons-nous d’exécuter parce que nous pourrions avoir besoin de définir une plus longue durée de temps si nous devons vérifier la stabilité de l’application et les caractéristiques de performance sur une période prolongée.
  • Gardez toujours quelques minutes tampon supplémentaires pour réchauffer l’application comme mentionné ci-dessus.

 

Conclusion : Comment simuler correctement le trafic sur des sites Web ou des applications Web

Comme vous pouvez le voir, il y a de nombreux facteurs qui doivent être pris en considération avant de mettre en place et d’exécuter vos tests de charge. S’assurer que votre application Web et vos sites fonctionnent parfaitement pour vos clients est essentiel au succès de votre entreprise. La plate-forme LoadView a été conçue d’une manière qui vous permettra de vous faire passer rapidement et facilement le processus étape par étape pour la mise en place de vos tests. La plate-forme peut configurer des scénarios réels et aider à évaluer les performances à partir de plusieurs emplacements.

Inscrivez-vous à l’essai gratuit de LoadView et obtenez des tests de charge gratuits pour commencer, ou inscrivez-vous à une démo LoadView. Un de nos ingénieurs de performance vous aidera à travers toute la solution et répondre à toutes les questions sur la plate-forme ou répondre à vos questions spécifiques sur le processus de test de charge.