Comment distribuer le stress dans les scénarios de tests de charge ? RADVIEW

Businessman with tablet

L’un des défis posés par les tests de charge est d’arriver à prévoir et à décider quelles activités utilisateur inclure et comment combiner différents scénarios d’utilisation. Notre article précédent « comment prévoir des scénarios de test de charge réalistes » donnait quelques conseils pour identifier les transactions utilisateur. Mais envisageons que vous en soyez déjà à l’étape suivante, se pose maintenant la question de savoir comment définir la proportion à attribuer aux différentes activités.

Partons donc d’un exemple pratique. Disons que vous testez un site de commerce en ligne. Votre scénario de charge simulera probablement les activités liées à l’intégralité du site : pages produits, recherche, page boutique, procédure de commande, panier et paiement. Mais savez-vous comment bien distribuer la charge entre ces différents domaines ? Quelle proportion du scénario doit être dédiée aux pages produits par rapport à la fonction recherche ?

Disons que vous dédiez 10 % du scénario à la recherche de produit, puisque cela représente le nombre moyen d’utilisateurs qui effectuent cette action sur le site. Mais, et si cette hypothèse était erronée et qu’il y avait plus de recherches effectuées sur le site, et que lorsque la proportion de charge des recherches passait à 15 % les problèmes commençaient à apparaître ? Même si une augmentation de 5 % semble presque négligeable, elle correspond à une augmentation de 50 % de la charge placée sur les recherches dans la base de données. Si la base de données dorsale est en fait un lien sensible, alors elle peut avoir un impact sur la stabilité de toute l’application. Mais elle doit être soumise à un stress suffisant pour mettre à jour ses faiblesses. Pour le dire clairement, si vous ne placez pas suffisamment de stress aux bons endroits, alors votre scénario de charge ne remplira pas ses objectifs.

Alors, que pouvez-vous faire ? Bien évidemment, vous pouvez toujours charger votre système avec plus d’utilisateurs/de stress que prévus par vos données « brutes ». Mais de même, vous devez aussi essayer de modifier et d’augmenter/diminuer les proportions entre les différentes transactions. Votre rôle en tant qu’ingénieur de performance est de tester même l’inattendu et d’identifier les emplacements ou scénarios où une augmentation du stress met votre système « en échec ». 

Db David BUCH, Directeur innovation de Radview 

Related Topics
Author
By
@coesteve1
Related Posts

Readers Comments


Add Your Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

In The News

Comment distribuer le stress dans les scénarios de tests de charge ? RADVIEW

Businessman with tablet 8th février, 2016

L’un des défis posés par les tests de charge est d’arriver à prévoir et à décider quelles activités utilisateur inclure et comment combiner différents scénarios d’utilisation. Notre article précédent « comment prévoir des scénarios de test de charge réalistes » donnait quelques conseils pour identifier les transactions utilisateur. Mais envisageons que vous en soyez déjà à l’étape suivante, se pose maintenant la question de savoir comment définir la proportion à attribuer aux différentes activités.

Partons donc d’un exemple pratique. Disons que vous testez un site de commerce en ligne. Votre scénario de charge simulera probablement les activités liées à l’intégralité du site : pages produits, recherche, page boutique, procédure de commande, panier et paiement. Mais savez-vous comment bien distribuer la charge entre ces différents domaines ? Quelle proportion du scénario doit être dédiée aux pages produits par rapport à la fonction recherche ?

Disons que vous dédiez 10 % du scénario à la recherche de produit, puisque cela représente le nombre moyen d’utilisateurs qui effectuent cette action sur le site. Mais, et si cette hypothèse était erronée et qu’il y avait plus de recherches effectuées sur le site, et que lorsque la proportion de charge des recherches passait à 15 % les problèmes commençaient à apparaître ? Même si une augmentation de 5 % semble presque négligeable, elle correspond à une augmentation de 50 % de la charge placée sur les recherches dans la base de données. Si la base de données dorsale est en fait un lien sensible, alors elle peut avoir un impact sur la stabilité de toute l’application. Mais elle doit être soumise à un stress suffisant pour mettre à jour ses faiblesses. Pour le dire clairement, si vous ne placez pas suffisamment de stress aux bons endroits, alors votre scénario de charge ne remplira pas ses objectifs.

Alors, que pouvez-vous faire ? Bien évidemment, vous pouvez toujours charger votre système avec plus d’utilisateurs/de stress que prévus par vos données « brutes ». Mais de même, vous devez aussi essayer de modifier et d’augmenter/diminuer les proportions entre les différentes transactions. Votre rôle en tant qu’ingénieur de performance est de tester même l’inattendu et d’identifier les emplacements ou scénarios où une augmentation du stress met votre système « en échec ». 

Db David BUCH, Directeur innovation de Radview 

By
@coesteve1
backtotop