Test de charge :
HTTP vs Headless vs Real Browser
Le chargement lent ou les pages Web non réactives ont un impact sur les revenus financiers parce que les utilisateurs frustrés ne reviendront probablement pas une fois le problème résolu. Par conséquent, les tests de performance sont devenus un élément fondamental de la chaîne de développement et la demande continue d’augmenter.
Les plates-formes de test de performances offrent un large éventail de méthodes de simulation de charge telles que HTTP, sans tête et basées sur un navigateur réel. Dans cet article, nous exposerons les principaux aspects de ceux suivis d’une matrice de comparaison, que vous pouvez utiliser pour choisir une approche de simulation appropriée.
Dans les premiers jours de l’ère numérique, les tests basés sur HTTP étaient très populaires. Avec l’essor de la riche technologie client Web, les approches de simulation basées sur HTTP sont devenues de plus en plus obsolètes. Un pilote de test http typique 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. Dans le pire des cas, les cas d’utilisation complexes ne peuvent pas être simulés au niveau du protocole en raison d’une pénurie d’ids générés côté client.
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 le type de système testé, certains noms de formulaires Web changent souvent une fois qu’une nouvelle version a été déployée, ce qui provoquera l’échec du script basé sur HTTP.
exemple de script de niveau protocole
transaction TMain
Var
hContexte: nombre;
Commencer
WebPageUrl («http://lab3/st/», «Salutations»);
WebPageStoreContext(hContext);
WebPageLink («Rejoignez l’expérience!», ” – Nouveau visiteur «);
WebPageSubmit («Continuer», CONTINUE001, «Menu principal»);
WebPageLink («Produits», «ShopIt – Produits»);
WebPageLink (NULL, «ShopIt – Produit», 3);
WebPageSubmit («Search», SEARCH001, ” – Search «, 0, NULL, hContext);
mettre fin à TMain;
dclforme
CONTINUER001:
«nom» := «jack»,
«Nouveau nom-bouton» := «Continuer»;
SEARCH001:
«recherche» := «boot»;
Après tout, les scripts de niveau protocole sont bons pour les tests de niveau des composants dans les environnements d’intégration continue et le cadre idéal pour les tests de résistance en raison de leur faible empreinte sur les machines d’injection de charge.
Avec l’essor des technologies web 2.0, l’activité 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.
Les navigateurs sans tête sont similaires aux navigateurs réels sans l’interface graphique. De nombreuses plateformes d’automatisation des tests et de tests de performance utilisent des navigateurs sans tête pour simuler le trafic.
Navigateurs sans tête ont leurs propres pièges; comme les nouveaux navigateurs entrent sur les marchés kits de navigateur sans tête doivent rattraper toutes les performances et les améliorations des fonctionnalités des navigateurs réels.
La simulation du rendu côté client n’est pas gratuite. Un serveur d’injection de charge typique peut simuler jusqu’à 10-12 sessions simultanées de navigateur sans tête, contre 500 de sessions basées sur HTTP.
La mise en œuvre et la personnalisation du script de test ne sont pas trop difficiles. Si vous avez des compétences de codage de base, vous serez en mesure de créer des scripts simples. Tous les navigateurs sans tête ne fournissent pas de fonctionnalités visuelles de relecture et sans débougeage de script de relecture visuelle ou analyse d’erreur pourrait devenir très délicat.
exemple phantomjs script
«utiliser strictement»;
var page = require (‘webpage’).create(),
serveur = ‘http://posttestserver.com/post.php?dump’,
données = ‘universe=expandinganswer=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();
});
Dans l’exemple de script vu ici, une simple demande de poste est exécutée. Vous avez besoin de compétences de programmation Java pour personnaliser ces scripts de test.
Les applications Web2.0 sont pleines de JavaScript, Flash, Ajax et CSS. Sans navigateur complet, il n’est pas possible de mesurer les temps de réponse réels de bout en bout de toute la page Web. Les tests de performances réels basés sur le navigateur vous permettent de vérifier les fonctionnalités et la vitesse du site telles qu’elles sont perçues par l’utilisateur final.
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 navigateur réel basé sur le navigateur est légèrement plus élevée. Compte tenu du fait que la simulation de navigateur sans tête ne fournit pas 100% des temps de réponse réalistes, il est juste de dire que la simulation basée sur le navigateur réel devrait être préféré. Dans les scénarios de la vie réelle, les navigateurs sans tête ne fonctionnent que 20% mieux que les navigateurs réels. Ainsi, si l’injecteur de charge unique de taille moyenne peut exécuter 10-12 sessions de navigateur sans tête, le même injecteur de charge peut exécuter 8-10 sessions de navigateur réel.
La mise en œuvre et la maintenance des scripts de test sont faciles parce que les actions des utilisateurs sont directement réfléchies et que la relecture visuelle facilite le débogage. Dans l’exemple de script ci-dessous le navigateur ouvre une URL, insère l’utilisateur et mot de passe et clique sur le bouton de connexion.
exemple de script réel basé sur le navigateur
transaction TMain
Commencer
BrowserStart (BROWSER_MODE_DEFAULT, 800 600);
naviguer vers le site de connexion
BrowserNavigate («http://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, mais il peut devenir coûteux pour les tests de résistance volumes d’utilisateurs élevés, parce que l’empreinte sur le serveur d’injection de charge est trop élevé.
Types de tests 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 performances basés sur le service au niveau du protocole ou ils simulent des vérifications réelles des performances basées sur le navigateur pour comparer les temps de réponse de bout en bout avec les limites de performances convenues.
Objectifs
+ Répétabilité
+ 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
Pour plusieurs raisons, les tests de charge sont la méthode de test idéale lorsqu’il s’agit de vérifier les exigences non fonctionnelles. La première étant 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
+ Simulation de charge reproductible
+ Vérification des seuils de temps de réponse
+ Identifier les goulots d’étranglement dans la production comme les conditions de charge
+ Scénarios de test réalistes de bout en bout
Stress Test
Si vous devez tester la fiabilité de votre application dans des conditions de charge maximale, exécutez un test de résistance. Dans ce type de test, vous spécifiez principalement le nombre maximum d’utilisateurs et le temps pendant lequel la montée en puissance et la charge d’état stable doivent être sur votre application. L’objectif est d’identifier les points de rupture de votre application à l’essai.
Objectifs
+ Preuve d’évolutivité et de stabilité
+ Simuler les conditions de charge de pointe
+ La reproductibilité exacte n’est pas importante
Comparaison
Évidemment, il ya de bonnes raisons pour le protocole, sans tête ou simulation utilisateur basé sur le navigateur réel. La matrice ci-dessous fournit quelques conseils pour choisir l’approche appropriée.
Critères
HTTP (en)
Navigateur sans tête
Navigateur réel
Simulation utilisateur
Aucun
rendu côté client
Certains éléments côté client sont simulés
Simulation réelle des utilisateurs
Implémentation
et personnalisation de scripts
Difficile lorsque les sites Web sont complexes
Compétences de développeur requises pour construire des scripts robustes
Scripts simples, faciles à personnaliser
Relecture
cript S
Analyse de bas niveau requise
Selon le moteur utilisé, la relecture visuelle est possible
Vous voyez ce que vous obtenez
Maintainability script
Compétences en programmation requises
Les erreurs dans les sections non rendues sont difficiles à résoudre
Facile parce que vous voyez des échecs lors de la relecture
Prise en charge multi-navigateurs
Certains outils émulent les navigateurs Web, mais ce n’est pas comparable
Oui, mais certains éléments manquent souvent
Certains supportent d’autres versions et différents navigateurs
F
ootprint sur la machine d’injection de charge
Faible,
jusqu’à 800 sessions par serveur
Moyen
, jusqu’à
10-12
sessions par serveur
Haut,
jusqu’à 6 sessions par serveur
Recommandé
pour
DevOps
Dépend du scénario de test réel
Non, des scripts souvent complexes
Oui, des chiffres faciles à utiliser et réalistes
Recommandé pour les tests de charge
Non,
le traitement côté client est ignoré
Oui, mieux que la simulation HTTP
Oui, simulation réaliste de l’utilisateur
Recommandé pour les tests de résistance
Oui, parce qu’il y a une faible surcharge sur la machine génératrice de charge
Non, les frais généraux sur la machine du générateur de charge sont trop élevés
Non, les frais
généraux les plus élevés sur la machine générateur de charge
Coûts
Faible
Haute
Haute
Recommandé pour les tests de résistance webserver à fort volume et à faible coût (dans la mesure du possible)
Non recommandé
Recommandé pour les simulations d’applications complexes de la vie réelle.
Stress Test
Si vous devez tester la fiabilité de votre application dans des conditions de charge maximale, exécutez un test de résistance. Dans ce type de test, vous spécifiez principalement le nombre maximum d’utilisateurs et le temps pendant lequel la montée en puissance et la charge d’état stable doivent être sur votre application. L’objectif est d’identifier les points de rupture de votre application à l’essai.
Objectifs
+ Preuve d’évolutivité et de stabilité
+ Simuler les conditions de charge de pointe
+ La reproductibilité exacte n’est pas importante
Comparaison
Évidemment, il ya de bonnes raisons pour le protocole, sans tête ou simulation utilisateur basé sur le navigateur réel. La matrice ci-dessous fournit quelques conseils pour choisir l’approche appropriée.
| Critères | HTTP (en) | Navigateur sans tête | Navigateur réel |
| Simulation utilisateur | Aucun rendu côté client | Certains éléments côté client sont simulés | Simulation réelle des utilisateurs |
| Implémentation et personnalisation de scripts | Difficile lorsque les sites Web sont complexes | Compétences de développeur requises pour construire des scripts robustes | Scripts simples, faciles à personnaliser |
| Relecture du script | Analyse de bas niveau requise | Selon le moteur utilisé est replay visuel possible | Vous voyez ce que vous obtenez |
| Maintainability script | Compétences en programmation requises | Les erreurs dans les sections non rendues sont difficiles à résoudre | Facile parce que vous voyez des échecs lors de la relecture |
| Prise en charge multi-navigateurs | Certains outils émulent navigateur Web, mais ce n’est pas comparable | Oui, mais certains éléments manquent souvent | Certains supportent d’autres versions et différents navigateurs |
| Empreinte sur la machine d’injection de charge | Faible, jusqu’à 800 sessions par serveur | Moyenne, jusqu’à 10-12 sessions par serveur | Haut, jusqu’à 6 sessions par serveur |
| Recommandé pour DevOps | Dépend du scénario de test réel | Non, des scripts souvent complexes | Oui, des chiffres faciles à utiliser et réalistes |
| Recommandé pour les tests de charge | Non, le traitement côté client est ignoré | Oui, mieux que la simulation HTTP | Oui, simulation réaliste de l’utilisateur |
| Recommandé pour les tests de résistance | Oui, parce qu’il y a une faible surcharge sur la machine de générateur de charge | Non, les frais généraux sur la machine de générateur de charge est trop élevé | Non, les frais généraux les plus élevés sur la machine générateur de charge |
| Coûts | Faible | Haute | Haute |
| Recommandé pour les tests de résistance webserver à fort volume et à faible coût (dans la mesure du possible) | Non recommandé | Recommandé pour les simulations d’applications complexes de la vie réelle.
|
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/
