Démarrez le test de charge. À présent. Vraiment.

Avec Test Studio, vous êtes bien placé pour commencer à obtenir des résultats utiles des tests de charge dès maintenant (et de meilleurs résultats à l’avenir).

Demander comment bien votre application fonctionne vous amène sur le territoire des « tests non fonctionnels ». Il existe une variété de tests non fonctionnels – expérience utilisateur, récupération après une panne, résilience aux interruptions, etc. – mais les tests qui permettent aux gens de dormir la nuit sont essais de charge: ceux qui vous indiquent si votre application peut prendre en charge les attentes (et etattendu) les charges que les utilisateurs y placent.

Soutenir la demande n’est peut-être pas quelque chose qui vous inquiète. Vous savez peut-être que vous disposez d’une puissance de calcul suffisante et que votre application, avec son nombre d’utilisateurs attendu, n’aura jamais d’impact significatif sur ces ressources informatiques. Mais c’est quelque chose sur lequel vous ne voulez pas vous tromper : Gartner estime que Temps d’arrêt informatique coûte en moyenne 5 600 $ la minute (entre 140 000 $ et 540 000 $ l’heure).

Pour qu’un test de charge soit pleinement efficace, il doit vous indiquer comment votre application se comporte sous des charges de pointe, des charges typiques et des charges suffisamment extrêmes pour provoquer l’échec de votre application. Évidemment, il est donc vrai que votre test de charge imite votre application réelle et les exigences que vos utilisateurs lui imposent. Ce serait un test de charge parfait.

Mais soyons clairs : cet article explique comment le parfait est l’ennemi du bien. Cette vérité évidente sur les tests de charge n’a pas Cela signifie que vous devez différer les tests de charge jusqu’à ce que vous puissiez imiter complètement votre application réelle et ses charges. Il n’est pas rare que, pour résoudre un problème de charge, vous ayez besoin de réécrire ou même de ré-architecturer votre application. Cela étant, vous voulez le savoir le plus tôt possible dans le développement si vous avez un problème de charge.

Cela signifie que vous voulez commencer votre essais de charge « dès que possible » – en gros, dès que tous les bogues « bloquants » ont été supprimés. Pour le dire autrement : Un test de charge « assez bon » précoce vaut mieux qu’un test de charge parfait plus tard.

Test Studio vous permettra de le faire.

Gestion du temps

De nos jours, la plupart des équipes commencent à créer des tests fonctionnels qui prouvent que leur application fait ce qu’il faut au début du processus de développement. L’un des avantages de l’utilisation de Test Studio pour créer ces scripts de test fonctionnels est que vous pouvez les convertir
tester des scripts dans des profils d’utilisateurs, qui sont au cœur d’un test de charge. Dès que votre application commence à réussir certains de vos tests fonctionnels, vous pouvez les convertir en profils utilisateur et commencer à exécuter des tests de charge.

Mais il existe deux catégories de tests (fonctionnels et non fonctionnels) pour une raison. Dans un test de charge, par exemple, vous n’êtes pas intéressé par la capacité d’un utilisateur à faire défiler une longue liste (ce qui est le but d’un test fonctionnel), mais vous êtes très intéressé par l’impact de la construction de cette liste sur le service Web. Ainsi, pendant que vos tests fonctionnels vous positionnent pour commencer test de charge plus tôt, un bon test fonctionnel n’est pas tout à fait la même chose qu’un bon test de charge.

Par conséquent, avant de profiter de la capacité de Test Studio à convertir vos tests fonctionnels en profils utilisateur, vous devez vous assurer que votre test fonctionnel agit comme un être humain. La première étape consiste à exécuter le script de test fonctionnel et à vérifier les pauses « inattendues ».

Par exemple, lorsque vous exécutez votre test fonctionnel, vous pouvez trouver une pause significative pendant que l’outil de lecture de Test Studio recherche un élément avec lequel le script de test est censé interagir. La cause habituelle de cette pause est que quelque chose a changé dans l’application depuis l’enregistrement du test et que le mécanisme par défaut utilisé par Test Studio pour trouver l’élément ne peut plus trouver l’élément. Heureusement, Test Studio utilise une série d’options pour localiser un élément (HTML, image d’écran, autres) et, après avoir donné à l’option par défaut un certain temps pour échouer, Test Studio passe simplement à une autre option.

C’est une bonne chose – cela rend vos tests très fiable face aux évolutions de votre application (vos tests sont, en effet, « self-healing »). Dans un test fonctionnel, cette pause n’a pas d’impact sur la validité du test. Cependant, pour créer un test de charge plus utile, vous devez résoudre ce problème mécanique. La façon la plus simple d’éliminer ces pauses est de :

1. Ouvrez le script de test dans l’éditeur de script de Test Studio.
2. Sélectionnez l’étape avec la pause et supprimez-la.
3. Faites un clic droit sur ce qui était l’étape précédente et choisissez l’option « Exécuter ici ».
4. Lorsque le script de test s’interrompt et que la barre d’outils Test Studio apparaît, effectuez l’action qui retardait formellement votre test. Test Studio capturera votre action et l’ajoutera à votre script à la place de l’ancienne version de l’étape.
5. Arrêtez votre test et exécutez votre test pour confirmer que la pause mécanique a disparu.

D’un autre côté, vos utilisateurs ne sont pas non plus des robots. Vos tests fonctionnels passent d’une étape à l’autre très rapidement, ce qui n’est pas une représentation réaliste du comportement de vos utilisateurs (avec un peu de chance, ils regardent réellement les pages de votre application). Ainsi, une fois que vous avez éliminé toutes les pauses mécaniques, vous êtes prêt à vous assurer que votre profil comporte les bonnes pauses humaines.

Lorsque vous convertissez un script de test fonctionnel en un profil utilisateur de test de charge, Test Studio insérera automatiquement des étapes de « temps de réflexion » dans votre test de charge. Vous devriez examiner ces pas de temps de réflexion et vous assurer qu’ils sont à la fois raisonnables et au bon endroit.

Création de parcours utilisateur

Une fois que vous avez défini le bon timing dans vos scripts, vous pouvez commencer à penser à représenter les activités typiques de vos utilisateurs, vos « parcours d’utilisateur ». Là encore, un test fonctionnel va être différent du test non fonctionnel idéal.

Un test fonctionnel typique peut impliquer de surfer sur une page (en contournant la sécurité en cours de route), de modifier certaines données, puis de surfer immédiatement sur une autre page pour vérifier que les données ont été correctement mises à jour. À moins que vous n’ayez un ensemble d’utilisateurs particulièrement paranoïaques, je parie que ce test ne reflète pas l’utilisation « typique » de l’application par un utilisateur. Vos tests fonctionnels se concentrent également probablement sur les fonctionnalités problématiques où vous vous attendez à trouver des bogues. Encore une fois, cela ne reflète probablement pas une transaction utilisateur typique, qui implique souvent de nombreuses pages, couvrant de nombreuses « fonctionnalités » et utilisant des fonctionnalités standard qui ont été dans l’application depuis sa création.

Étant donné que vos tests de charge doivent imiter la façon dont votre application sera réellement utilisée, chaque profil utilisateur doit être un parcours utilisateur typique. La bonne nouvelle ici est que vous pouvez souvent créer ces parcours utilisateur en combinant plusieurs tests fonctionnels existants (l’éditeur de scripts de Test Studio facilite la fusion de tests ou même l’utilisation d’un script comme étape dans un autre script).

Vous devrez peut-être, occasionnellement, créer un nouveau test fonctionnel à l’aide de l’enregistreur de Test Studio uniquement pour relier une partie du parcours de l’utilisateur entre deux tests fonctionnels.

Considérations pratiques

En s’éloignant de l’imitation de votre environnement réel, il est logique de réfléchir à la manière dont vous organiserez vos tests fonctionnels et non fonctionnels. Il peut, par exemple, être judicieux pour vous de conserver les tests fonctionnels et non fonctionnels liés à une application/version/fonctionnalité dans un seul projet. Il existe cependant de bonnes raisons de créer un nouveau projet qui ne contiendra que des tests de charge afin de réduire les frais généraux liés à la gestion de vos tests de charge.

Comme vous l’avez vu, au fil du temps, vos tests de charge évolueront loin de vos tests fonctionnels, généralement parce que vous combinerez plusieurs tests fonctionnels pour imiter une transaction utilisateur typique. Cela seul peut vous amener à vouloir conserver vos tests de charge dans un projet séparé. Test Studio vous permettra importer des tests fonctionnels d’autres projets dans votre projet de test de charge. Vous pouvez utiliser ces tests fonctionnels pour créer vos profils d’utilisateurs (et modifier ces tests fonctionnels pour en faire des tests non fonctionnels plus efficaces).

La planification est également différente pour les tests fonctionnels, car les tests de charge s’exécutent généralement sur des périodes plus longues (les tests d’immersion, par exemple, mesurent le comportement d’une application sur des heures ou des jours). En raison de la durée d’exécution des tests de charge, bien que vous puissiez exécuter vos tests fonctionnels en fonction d’événements (par exemple, après l’archivage du code dans le contrôle de code source), vous êtes plus susceptible d’exécuter des tests de charge en fonction de dates calendaires (chaque week-end ou dans le cadre de la préparation de votre prochaine version).

La création d’un projet distinct pour vos tests de charge simplifiera la recherche, la planification et la gestion de ces tests… ce qui vous encouragera à utiliser davantage ces tests.

Vous obtiendrez également des résultats plus utiles de vos tests de charge si le serveur de votre application (et, dans une certaine mesure, les clients) utilisé dans vos tests de charge ressemble davantage à votre serveur de production. Il en va de même pour tous les serveurs Web et bases de données auxquels votre application accède. Vous souhaiterez peut-être utiliser un ensemble de serveurs différent pour les tests de charge que celui que vous utilisez pour les tests fonctionnels.

Un autre élément à prendre en compte avec les tests de charge est leur impact sur les données partagées. Alors que les tests fonctionnels ont tendance à affecter un ou deux enregistrements dans la base de données, les tests de charge peuvent affecter plusieurs enregistrements. Par conséquent, les tests de charge doivent éviter d’apporter des modifications qui empêchent d’autres tests (ou même eux-mêmes) de s’exécuter.

Par exemple, un test de charge qui essaie de supprimer le même client à chaque exécution ne fonctionnera correctement que la première fois (et, à moins que vos utilisateurs essaient généralement de supprimer des clients qui n’existent pas, ce n’est pas une bonne représentation de la façon dont votre système est utilisé). Un profil qui supprime un client différent à chaque fois, s’il est exécuté comme un test d’imprégnation sur plusieurs jours, peut éventuellement supprimer tout vos clients – si vous avez l’intention d’exécuter ce profil en conjonction avec un profil qui met à jour les clients, ce test client de mise à jour peut ne trouver aucun client avec qui travailler.

Si ces considérations vous poussent à différer les tests de charge, vous manquez mon point. Ce sont des problèmes que vous devriez considérer et ajuster pour quand ils deviennent des problèmes.

Si, par exemple, vous utilisez votre serveur de développement pour un test de résistance et que ce test commence à échouer… eh bien, c’est le moment où vous devriez envisager de mettre en place un « meilleur » serveur pour votre stress test. En attendant, vous pouvez approximer le moment où votre test de résistance échouera sur votre serveur de production en calculant les différences de puissance CPU et de mémoire (donnez-vous une large marge d’erreur pendant que vous faites cela, cependant).

Par exemple, si votre test de résistance sur un serveur de développement à quatre cœurs échoue à 50 utilisateurs et que votre serveur de production a 64 cœurs, alors, pendant que vous attendez un meilleur serveur pour tester, je parie que vous pouvez vivre avec l’hypothèse raisonnable que votre application prendra en charge au moins 600 utilisateurs (64/4 * 50 = 800 avec une marge d’erreur de 25 %). Si je m’attendais à ce que ma charge maximale soit d’environ 400 utilisateurs, je serais assez à l’aise pour dire que je n’ai pas (actuellement) de problème de charge… encore une fois, en attendant ce « meilleur » serveur de test.

Il n’y a vraiment aucune raison de ne pas commencer. Maintenant, par exemple.