Le chargement lent ou les pages Web non réactives ont un impact direct sur les revenus financiers. Il est essentiel de vous assurer que vous configurez vos tests de performance avec la bonne simulation de charge. Si elle n’est pas faite correctement, elle pourrait avoir des effets désastreux. Les utilisateurs frustrés abandonneront très probablement tout ce qu’ils faisaient et ne reviendront pas. Même si vous et votre équipe avez résolu ce problème, il est probablement trop tard. Ils ont probablement déjà trouvé une solution alternative. Et une fois qu’ils l’ont fait, il est peu probable qu’ils reviennent en arrière.
Non seulement vous devez vous soucier de la perte de revenus, mais d’autres facteurs, tels que la confiance des consommateurs, l’intégrité de la marque, etc., sont probablement plus préjudiciables à l’entreprise. Plus la question dure longtemps, plus il est difficile de regagner la confiance des consommateurs. Non seulement cela, le retour sur les investissements que vous avez faits dans votre produit, les équipes et l’organisation va prendre plus de temps à réaliser, le cas du tout. Par conséquent, les tests de performance (et la surveillance) sont devenus un élément fondamental et critique de la chaîne de développement de logiciels et d’applications. La nécessité d’une solution qui peut exécuter correctement et avec précision des tests de performances étroitement à l’expérience de l’utilisateur est en forte demande.
Les plates-formes de test de performance offrent un large éventail de méthodes de simulation de charge telles que HTTP/S, des tests sans tête et réels basés sur le navigateur. Dans cet article, nous exposerons les principaux aspects de chacun, suivi d’une matrice de comparaison que vous pouvez utiliser pour choisir une approche de simulation appropriée.
Simulation de charge basée sur HTTP
Au début de notre ère numérique, les tests http étaient très populaires. Avec l’essor de la technologie client Web riche, cette approche est devenue de plus en plus obsolète (et les tests de performance avec des outils tels que JMeter sont également devenus un peu obsolètes). Un pilote d’essai typique basé sur HTTP exécute les demandes de service et exécute les réponses. Les applications web 2.0 modernes se composent de nombreux scripts côté client, qui sont totalement ignorés et non mesurés dans ce type d’exécution de test. En raison d’une pénurie d’ID de session générés côté client, les cas d’utilisation complexes ne peuvent pas être simulés au niveau du protocole.
En raison de leur demande et de leur nature basée sur la réponse, les frais généraux sur la machine d’injection de charge sont très faibles. Un serveur de test de charge typique peut simuler jusqu’à 800 sessions simultanées. Les cas complexes d’utilisation basés sur le protocole peuvent être difficiles à implémenter. Un ingénieur de performance doit traiter les cookies, les iD de session et d’autres paramètres dynamiques. Selon la technologie du système testé, certains noms de formulaires Web changent souvent une fois qu’une nouvelle version a été déployée, ce qui entraîne l’échec du script HTTP.
L’exemple de script ci-dessous met en valeur la nature très technique de ces scripts. Si un attribut technique de votre application change, vous devez réécrire l’ensemble du script, ce qui est plus facile à dire qu’à faire.
//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;
dclforme
CONTINUER001:
«nom» := «jack»,
«Nouveau nom-bouton» := «Continuer»;
SEARCH001:
«recherche» := «boot»;
Après tout, les scripts au niveau du protocole sont bons pour les tests au niveau des composants dans les environnements d’intégration continue et, en raison de leur faible encombrement sur les machines d’injection de charge, sont le cadre idéal pour les tests de contrainte.
Simulation de charge basée sur le navigateur sans tête
Avec l’essor des technologies web 2.0, l’activité de test a été confrontée à de sérieux défis. Les applications de navigateur riches ne pouvaient plus être testées ou simulées au niveau du protocole en raison de la logique manquante côté client pendant la relecture du script. Par conséquent, plusieurs navigateurs sans tête ont été introduits, tels que HtmlUnit, PhantomJS, ou SlimerJS. Ils sont souvent construits sur le webkit, le moteur derrière Chrome et Safari.
Navigateurs sans tête ont tous les avantages de navigateurs réels et ils fonctionnent plus vite sans l’interface graphique lourde. De nombreuses plateformes d’automatisation des tests et de tests de performance utilisent des navigateurs sans tête car elles permettent une simulation utilisateur réaliste.
Certains fournisseurs ont construit leurs propres moteurs de navigateur sans tête, mais ont rencontré des pièges de maintenance parce qu’ils doivent suivre les nouvelles versions du navigateur. Dans cette situation, il est fortement recommandé d’utiliser tous les kits de navigateur sans tête disponibles gratuitement car il existe une large communauté qui travaille sur les améliorations.
La simulation du rendu côté client n’est pas gratuite. Un serveur d’injection de charge typique peut simuler jusqu’à huit sessions simultanées de navigateur sans tête.
La mise en œuvre et la personnalisation du script de test ne sont pas trop difficiles. Si vous avez des compétences de base de développeur, vous serez en mesure de créer des scripts simples. Tous les navigateurs sans tête ne fournissent pas de fonctionnalités de relecture visuelle et sans relecture visuelle, débogage de script et analyse d’erreurs peuvent devenir très difficiles.
Dans l’exemple de script ci-dessous, une simple demande de publication est exécutée. Vous avez besoin de compétences en programmation Java pour personnaliser ces scripts de test.
//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';
page.open (serveur, ‘post’, données, fonction (statut) {
si (statut !== ‘succès’) {
console.log (‘Impossible de poster!’);
} autre {
console.log (page.content);
}
phantom.exit();
});
Avec cette considération à l’esprit, navigateurs sans tête sont la voie à suivre si vous avez des compétences de programmation et vous utilisez une solution qui permet la relecture de script visuel.
Simulation de charge basée sur le navigateur réel
Les applications Web 2.0 sont pleines de JavaScript, Flash, AJAX, CSS, etc. Sans navigateur complet, il n’est pas possible de mesurer les temps de réponse réels de bout en bout de l’ensemble de l’application ou de la page Web. Les tests de performance réels basés sur un navigateur vous permettent de vérifier la fonctionnalité et la vitesse du site telles que perçues par l’utilisateur final, ce qui, comme nous en avons discuté ci-dessus, est là où cela compte vraiment.
Une solution de test de performances de navigateur réel typique recueille les temps de chargement des images, JavaScript, CSS, et plus encore. Souvent, ils fournissent des cartes de chute d’eau, qui visualisent le temps de charge de ces composants.
L’empreinte d’un véritable navigateur est légèrement plus élevée. Étant donné que la simulation de navigateur sans tête ne permet pas de fournir des temps de réponse 100 pour cent réalistes, il est juste de dire que la simulation réelle basée sur le navigateur devrait être la méthode préférée pour les tests.
La mise en œuvre et la maintenance des scripts de test sont faciles parce que les actions des utilisateurs sont directement reflétées, et la relecture visuelle facilite le débogage. Dans l’exemple de script ci-dessous, le navigateur ouvre une URL, insère le mot de passe de l’utilisateur et clique sur le bouton de connexion.
//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
naviguer vers le site de connexion
BrowserNavigate («https://demo.com/TestSite/LoginForm.html»);
définir l’authentification pour le site sécurisé
BrowserSetText («//INPUT[@name=’user’]», «User1»);
BrowserSetPassword(«//INPUT[@name=’pwd’]», «Password1»);
connectez-vous
BrowserClick («//INPUT[@value=’Login’]», BUTTON_Left);
mettre fin à TMain;
Après tout, la simulation de navigateur réel est utile pour des tests de charge réalistes de bout en bout. Cependant, ne l’utilisez pas pour les tests de résistance parce que l’empreinte sur le serveur d’injection de charge est trop élevée.
Différents types de tests de charge et de performance
Tests de vitesse des composants
Ces dernières années, les méthodes de développement de logiciels ont évolué dans la direction agile. Les sprints à courte diffusion sont essentiels. Les développeurs et les ingénieurs de test automatisent leurs contrôles d’assurance de la qualité et de performance. En règle générale, ils implémentent des tests de performance basés sur les services (et parfois des tests d’API) au niveau du protocole, ou ils simulent des contrôles de performances réels basés sur un navigateur pour comparer les temps de réponse de bout en bout avec les limites de performances convenues.
Objectifs des tests de vitesse des composants :
- Vérifiez et répétez le comportement d’entrée/sortie.
- Interface automatisée et contrôles de performances de bout en bout.
- Comparer les temps de réponse avec les seuils convenus.
Tests de charge
Load teste le réglage idéal lorsqu’il s’agit de vérifier les exigences non fonctionnelles. L’une des raisons est que les temps de réponse peuvent être vérifiés dans des conditions reproductibles. Un autre étant que ces tests permettent de vérifier les seuils de temps de réponse. Une mesure réaliste du temps de réponse est essentielle dans les scénarios de test de charge. Par conséquent, les ingénieurs de test utilisent la simulation utilisateur sans tête ou réelle basée sur le navigateur pour leurs paramètres de test de charge.
Objectifs des tests de charge :
- Simulation de charge reproductible.
- Vérification des seuils de temps de réponse.
- Identification des goulots d’étranglement dans des conditions de charge similaires à la production.
- Création de scénarios de test réalistes de bout en bout.
Tests de résistance
Si vous devez prouver la fiabilité de votre application dans des conditions de charge de pointe, exécutez un test de contrainte pour déterminer le point de rupture de votre système.
Objectifs des tests de résistance :
- Prouvez l’évolutivité et la stabilité aux conditions de pointe de la circulation.
- Observez comment le système échoue et revient en ligne.
- La reproductibilité n’est pas importante.
Comparaison
Évidemment, il ya de bonnes raisons et des situations pour le protocole, sans tête, et de véritables simulations d’utilisateurs basés sur le navigateur. La matrice ci-dessous fournit quelques conseils sur le moment de choisir l’approche de test appropriée.
| critères | HTTP (en) | Navigateur sans tête | Navigateur réel |
| Simulation utilisateur | (1) Pas de rendu côté client | (2) Certains éléments côté client sont simulés | (3) Simulation réelle des utilisateurs |
| Implémentation et personnalisation de scripts | (1) Difficile lorsque les sites Web sont complexes | (2) Compétences des développeurs requises pour construire des scripts robustes | (3) Scripts simples, faciles à personnaliser |
| Rediffusion du script | (1) Analyse de bas niveau requise | (2) Selon le moteur utilisé est replay visuel possible | (3) Vous voyez ce que vous obtenez |
| Maintainability script | (1) Compétences en programmation requises | (2) Les erreurs dans les sections non rendues sont difficiles à résoudre | (3) Facile parce que vous voyez des échecs pendant la relecture |
| Prise en charge multi-navigateurs | (1) Certains outils émulent les navigateurs Web, mais ce n’est pas comparable | (2) Oui, mais certains éléments manquent souvent | (2) Certains soutiennent d’autres versions et différents navigateurs |
| Empreinte sur la machine d’injection de charge | (3) Faible, jusqu’à 800 sessions par serveur | (2) Moyen, jusqu’à 8 sessions par serveur | (1) Élevé, jusqu’à 6 sessions par serveur |
| Recommandé pour DevOps | (2) Dépend du scénario de test réel | (1) Non, des scripts souvent complexes | (3) Oui, des chiffres faciles à utiliser et réalistes |
| Recommandé pour les tests de charge | (1) Non, le traitement côté client est ignoré | (2) Oui, mieux que la simulation HTTP | (3) Oui, simulation réaliste de l’utilisateur |
| Recommandé pour les tests de résistance | (3) Oui, parce qu’il y a une faible surcharge sur la machine de générateur de charge | (2) Non, les frais généraux sur la machine de générateur de charge est trop élevé | (1) Non, frais généraux les plus élevés sur la machine de générateur de charge |
| dépens | (3) Faible | (2) Moyen | (1) Haut |
| Total Score | 17 | 19 | 24 |
Espérons que cet article sur la simulation de charge et les types de tests de performance vous a donné un aperçu supplémentaire de vos tests de performance. Si vous avez des questions sur l’exécution de tests de charge et de contrainte, ou sur la solution LoadView en général, contactez notre équipe ou inscrivez-vous pour une démonstration avec l’un de nos ingénieurs de performance.