Présentation
Les pages web lentes ou non réactives ont un impact sur les revenus financiers, car les utilisateurs frustrés ne reviendront probablement pas même après la résolution du problème. Par conséquent, les tests de performance sont devenus une partie essentielle de la chaîne de développement, et la demande continue de croître.
Les plateformes de tests de performance proposent une large gamme de méthodes de simulation de charge telles que HTTP, sans interface (headless) et basées sur de vrais navigateurs. Dans cet article, nous allons présenter les principaux aspects de ces méthodes, suivis d’un tableau comparatif que vous pouvez utiliser pour choisir l’approche de simulation la plus appropriée.
Simulation de charge basée sur HTTP
Aux débuts de l’ère numérique, les tests basés sur HTTP étaient très populaires. Avec l’émergence des technologies client web riches, les approches de simulation HTTP sont devenues de plus en plus obsolètes. Un pilote de test HTTP typique exécute des requêtes de service et analyse les réponses. Les applications modernes web 2.0 comportent de nombreux scripts côté client, qui sont totalement ignorés et non mesurés dans ce type d’exécution de test. Dans les pires scénarios, certains cas d’usage complexes ne peuvent pas être simulés au niveau protocolaire en raison du manque d’ID générés côté client.
En raison de leur nature basée sur des requêtes/réponses, la surcharge sur la machine d’injection de charge est très faible. Un serveur de test de charge typique peut simuler jusqu’à 800 sessions simultanées. Les cas d’usage complexes basés sur les protocoles peuvent être difficiles à implémenter. Un ingénieur performance doit gérer 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 lors du déploiement d’une nouvelle version, ce qui entraînera l’échec des scripts HTTP.
Simulation de charge basée sur un navigateur sans interface (headless)
Avec l’essor des technologies web 2.0, le domaine des tests a été confronté à de sérieux défis. Les applications riches ne pouvaient plus être testées ou simulées au niveau protocolaire en raison de l’absence de logique côté client lors de la relecture des scripts. Par conséquent, plusieurs navigateurs headless ont été introduits, comme HtmlUnit, PhantomJS ou SlimerJS. Ils sont souvent construits sur WebKit, le moteur derrière Chrome et Safari.
Les navigateurs sans interface graphique sont similaires aux navigateurs réels mais sans interface utilisateur. De nombreuses plateformes d’automatisation de tests et de performance utilisent ces navigateurs pour simuler du trafic.
Les navigateurs headless ont leurs propres inconvénients ; à mesure que de nouveaux navigateurs apparaissent sur le marché, les kits de navigateurs headless doivent suivre les améliorations de performances et de fonctionnalités des navigateurs réels.
La simulation du rendu côté client a un coût. Un serveur d’injection de charge typique peut simuler jusqu’à 10–12 sessions headless simultanées, contre 500 sessions HTTP.
La mise en œuvre et la personnalisation des scripts de test n’est pas très complexe. Si vous avez des compétences de base en codage, vous pourrez créer des scripts simples. Tous les navigateurs headless ne proposent pas de relecture visuelle, et sans celle-ci, le débogage ou l’analyse des erreurs peut devenir très complexe.
Simulation de charge basée sur un navigateur réel
Les applications web 2.0 sont remplies de JavaScript, Flash, Ajax et CSS. Sans un navigateur complet, il est impossible de mesurer les véritables temps de réponse de bout en bout d’une page. Les tests de performance basés sur de vrais navigateurs permettent de vérifier la fonctionnalité et la rapidité du site telles que perçues par l’utilisateur final.
Une solution de test de performance typique avec navigateur réel collecte les temps de chargement des images, JavaScript, CSS, etc. Ces outils proposent souvent des diagrammes en cascade qui visualisent les temps de chargement de chaque composant.
L’empreinte d’un navigateur réel est légèrement plus élevée. Étant donné que les simulations headless ne fournissent pas des temps de réponse 100 % réalistes, il est juste de dire que les simulations avec navigateur réel sont à privilégier. Dans des scénarios réels, les navigateurs headless ne sont que 20 % plus performants. Ainsi, si un injecteur de charge peut exécuter 10–12 sessions headless, il peut généralement gérer 8–10 sessions avec navigateur réel.
La mise en œuvre et la maintenance des scripts sont faciles, car les actions de l’utilisateur sont directement visibles et la relecture visuelle facilite le débogage. Dans le script d’exemple ci-dessous, le navigateur ouvre une URL, saisit un identifiant et un mot de passe, puis clique sur le bouton de connexion.
Types de tests de performance
Tests de vitesse de composants
Ces dernières années, les méthodes de développement logiciel ont évolué vers l’agilité. Les cycles de publication courts sont devenus essentiels. Les développeurs et les ingénieurs test automatisent leurs contrôles qualité et performance. En général, ils mettent en œuvre des tests de performance basés sur les services au niveau protocolaire ou simulent des vérifications de performance avec navigateurs réels afin de comparer les temps de réponse de bout en bout aux seuils fixés.
Objectifs
- + Répétabilité
- + Vérifications automatisées de l’interface et des performances globales
- + Comparaison des temps de réponse avec les seuils définis
Tests de charge
Les tests de charge sont la méthode idéale pour vérifier les exigences non fonctionnelles. Ils permettent de mesurer les temps de réponse dans des conditions reproductibles et de vérifier le respect des seuils définis. Dans ce contexte, la mesure réaliste des performances est essentielle. C’est pourquoi les ingénieurs utilisent des simulations utilisateur avec navigateurs headless ou réels pour ces scénarios.
Objectifs
- + Simulation de charge reproductible
- + Vérification des seuils de temps de réponse
- + Identification des goulets d’étranglement en conditions proches de la production
- + Scénarios de test réalistes de bout en bout
Tests de résistance (stress test)
Si vous devez tester la fiabilité de votre application sous forte charge, effectuez un test de résistance. Ce type de test consiste à définir un nombre maximal d’utilisateurs et la durée de montée en charge et de maintien. Le but est d’identifier les points de rupture de votre application.
Objectifs
- + Démonstration de la scalabilité et de la stabilité
- + Simulation de charges de pointe
- + La reproductibilité exacte n’est pas requise
Comparatif
Il existe de bonnes raisons d’utiliser la simulation utilisateur basée sur le protocole, un navigateur headless ou un navigateur réel. Le tableau ci-dessous vous aide à choisir l’approche la plus appropriée.
| Critères | HTTP | Navigateur Headless | Navigateur Réel |
|---|---|---|---|
| Simulation utilisateur | Pas de rendu côté client | Certains éléments côté client sont simulés | Simulation réelle de l’utilisateur |
| Implémentation et personnalisation des scripts | Difficile pour les sites complexes | Nécessite des compétences de développeur | Scripts simples et facilement personnalisables |
| Relecture des scripts | Nécessite une analyse bas niveau | Relecture visuelle possible selon le moteur utilisé | Ce que vous voyez est ce que vous testez |
| Maintenabilité des scripts | Compétences en programmation requises | Erreurs dans les sections non rendues difficiles à résoudre | Facile grâce à la relecture visuelle |
| Support multi-navigateurs | Certains outils émulent des navigateurs, mais sans comparaison | Oui, mais certains éléments peuvent manquer | Support de plusieurs versions et navigateurs |
| Empreinte sur la machine d’injection de charge | Faible, jusqu’à 800 sessions/serveur | Moyenne, jusqu’à 10–12 sessions/serveur | Élevée, jusqu’à 6 sessions/serveur |
| Recommandé pour DevOps | Dépend du scénario de test | Non, scripts souvent complexes | Oui, facile à utiliser et données réalistes |
| Recommandé pour les tests de charge | Non, le traitement client est ignoré | Oui, mieux que la simulation HTTP | Oui, simulation utilisateur réaliste |
| Recommandé pour les tests de résistance | Oui, faible surcharge machine | Non, surcharge trop élevée | Non, surcharge maximale |
| Coûts | Faible | Élevé | Élevé |
| Recommandé pour les tests de charge peu coûteux et à fort volume sur serveurs web (si possible) | Non recommandé | Recommandé pour les simulations complexes en conditions réelles |
Pages web utilisées pour cet article :
- 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/