Les pages web lentes ou non r\u00e9actives ont un impact sur les revenus financiers, car les utilisateurs frustr\u00e9s ne reviendront probablement pas m\u00eame apr\u00e8s la r\u00e9solution du probl\u00e8me. Par cons\u00e9quent, les tests de performance sont devenus une partie essentielle de la cha\u00eene de d\u00e9veloppement, et la demande continue de cro\u00eetre.<\/p>\n
Les plateformes de tests de performance proposent une large gamme de m\u00e9thodes de simulation de charge telles que HTTP, sans interface (headless) et bas\u00e9es sur de vrais navigateurs. Dans cet article, nous allons pr\u00e9senter les principaux aspects de ces m\u00e9thodes, suivis d\u2019un tableau comparatif que vous pouvez utiliser pour choisir l\u2019approche de simulation la plus appropri\u00e9e.<\/p>\n
Aux d\u00e9buts de l\u2019\u00e8re num\u00e9rique, les tests bas\u00e9s sur HTTP \u00e9taient tr\u00e8s populaires. Avec l\u2019\u00e9mergence des technologies client web riches, les approches de simulation HTTP sont devenues de plus en plus obsol\u00e8tes. Un pilote de test HTTP typique ex\u00e9cute des requ\u00eates de service et analyse les r\u00e9ponses. Les applications modernes web 2.0 comportent de nombreux scripts c\u00f4t\u00e9 client, qui sont totalement ignor\u00e9s et non mesur\u00e9s dans ce type d\u2019ex\u00e9cution de test. Dans les pires sc\u00e9narios, certains cas d\u2019usage complexes ne peuvent pas \u00eatre simul\u00e9s au niveau protocolaire en raison du manque d\u2019ID g\u00e9n\u00e9r\u00e9s c\u00f4t\u00e9 client.<\/p>\n
En raison de leur nature bas\u00e9e sur des requ\u00eates\/r\u00e9ponses, la surcharge sur la machine d\u2019injection de charge est tr\u00e8s faible. Un serveur de test de charge typique peut simuler jusqu\u2019\u00e0 800 sessions simultan\u00e9es. Les cas d\u2019usage complexes bas\u00e9s sur les protocoles peuvent \u00eatre difficiles \u00e0 impl\u00e9menter. Un ing\u00e9nieur performance doit g\u00e9rer les cookies, les ID de session et d\u2019autres param\u00e8tres dynamiques. Selon le type de syst\u00e8me test\u00e9, certains noms de formulaires web changent souvent lors du d\u00e9ploiement d\u2019une nouvelle version, ce qui entra\u00eenera l\u2019\u00e9chec des scripts HTTP.<\/p>\n
Avec l\u2019essor des technologies web 2.0, le domaine des tests a \u00e9t\u00e9 confront\u00e9 \u00e0 de s\u00e9rieux d\u00e9fis. Les applications riches ne pouvaient plus \u00eatre test\u00e9es ou simul\u00e9es au niveau protocolaire en raison de l\u2019absence de logique c\u00f4t\u00e9 client lors de la relecture des scripts. Par cons\u00e9quent, plusieurs navigateurs headless ont \u00e9t\u00e9 introduits, comme HtmlUnit, PhantomJS ou SlimerJS. Ils sont souvent construits sur WebKit, le moteur derri\u00e8re Chrome et Safari.<\/p>\n
Les navigateurs sans interface graphique sont similaires aux navigateurs r\u00e9els mais sans interface utilisateur. De nombreuses plateformes d\u2019automatisation de tests et de performance utilisent ces navigateurs pour simuler du trafic.<\/p>\n
Les navigateurs headless ont leurs propres inconv\u00e9nients ; \u00e0 mesure que de nouveaux navigateurs apparaissent sur le march\u00e9, les kits de navigateurs headless doivent suivre les am\u00e9liorations de performances et de fonctionnalit\u00e9s des navigateurs r\u00e9els.<\/p>\n
La simulation du rendu c\u00f4t\u00e9 client a un co\u00fbt. Un serveur d\u2019injection de charge typique peut simuler jusqu\u2019\u00e0 10\u201312 sessions headless simultan\u00e9es, contre 500 sessions HTTP.<\/p>\n
La mise en \u0153uvre et la personnalisation des scripts de test n\u2019est pas tr\u00e8s complexe. Si vous avez des comp\u00e9tences de base en codage, vous pourrez cr\u00e9er des scripts simples. Tous les navigateurs headless ne proposent pas de relecture visuelle, et sans celle-ci, le d\u00e9bogage ou l\u2019analyse des erreurs peut devenir tr\u00e8s complexe.<\/p>\n
Les applications web 2.0 sont remplies de JavaScript, Flash, Ajax et CSS. Sans un navigateur complet, il est impossible de mesurer les v\u00e9ritables temps de r\u00e9ponse de bout en bout d\u2019une page. Les tests de performance bas\u00e9s sur de vrais navigateurs permettent de v\u00e9rifier la fonctionnalit\u00e9 et la rapidit\u00e9 du site telles que per\u00e7ues par l\u2019utilisateur final.<\/p>\n
Une solution de test de performance typique avec navigateur r\u00e9el 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.<\/p>\n
L\u2019empreinte d\u2019un navigateur r\u00e9el est l\u00e9g\u00e8rement plus \u00e9lev\u00e9e. \u00c9tant donn\u00e9 que les simulations headless ne fournissent pas des temps de r\u00e9ponse 100 % r\u00e9alistes, il est juste de dire que les simulations avec navigateur r\u00e9el sont \u00e0 privil\u00e9gier. Dans des sc\u00e9narios r\u00e9els, les navigateurs headless ne sont que 20 % plus performants. Ainsi, si un injecteur de charge peut ex\u00e9cuter 10\u201312 sessions headless, il peut g\u00e9n\u00e9ralement g\u00e9rer 8\u201310 sessions avec navigateur r\u00e9el.<\/p>\n
La mise en \u0153uvre et la maintenance des scripts sont faciles, car les actions de l\u2019utilisateur sont directement visibles et la relecture visuelle facilite le d\u00e9bogage. Dans le script d\u2019exemple ci-dessous, le navigateur ouvre une URL, saisit un identifiant et un mot de passe, puis clique sur le bouton de connexion.<\/p>\n
Ces derni\u00e8res ann\u00e9es, les m\u00e9thodes de d\u00e9veloppement logiciel ont \u00e9volu\u00e9 vers l\u2019agilit\u00e9. Les cycles de publication courts sont devenus essentiels. Les d\u00e9veloppeurs et les ing\u00e9nieurs test automatisent leurs contr\u00f4les qualit\u00e9 et performance. En g\u00e9n\u00e9ral, ils mettent en \u0153uvre des tests de performance bas\u00e9s sur les services au niveau protocolaire ou simulent des v\u00e9rifications de performance avec navigateurs r\u00e9els afin de comparer les temps de r\u00e9ponse de bout en bout aux seuils fix\u00e9s.<\/p>\n
Objectifs<\/p>\n
Les tests de charge sont la m\u00e9thode id\u00e9ale pour v\u00e9rifier les exigences non fonctionnelles. Ils permettent de mesurer les temps de r\u00e9ponse dans des conditions reproductibles et de v\u00e9rifier le respect des seuils d\u00e9finis. Dans ce contexte, la mesure r\u00e9aliste des performances est essentielle. C\u2019est pourquoi les ing\u00e9nieurs utilisent des simulations utilisateur avec navigateurs headless ou r\u00e9els pour ces sc\u00e9narios.<\/p>\n
Objectifs<\/p>\n
Si vous devez tester la fiabilit\u00e9 de votre application sous forte charge, effectuez un test de r\u00e9sistance. Ce type de test consiste \u00e0 d\u00e9finir un nombre maximal d\u2019utilisateurs et la dur\u00e9e de mont\u00e9e en charge et de maintien. Le but est d\u2019identifier les points de rupture de votre application.<\/p>\n
Objectifs<\/p>\n
Il existe de bonnes raisons d\u2019utiliser la simulation utilisateur bas\u00e9e sur le protocole, un navigateur headless ou un navigateur r\u00e9el. Le tableau ci-dessous vous aide \u00e0 choisir l\u2019approche la plus appropri\u00e9e.<\/p>\n