• Accueil
  • Automatisation
  • Performance
  • Sécurité
  • Intelligence
  • Recrutement
  • Contact
  • Blog
WAPSIWAPSIWAPSIWAPSI
  • W
  • A
  • P
  • S
  • I

La complexité des tests de performance sur une Single Page Application

    Home Articles La complexité des tests de performance sur une Single Page Application
    NextPrevious

    La complexité des tests de performance sur une Single Page Application

    By WAPSI | Articles, Performance, Tests | Comments are Closed | 25 avril, 2019 | 0

    Les technologies de développement Web ont beaucoup évolué durant les 30 dernières années. Les pages Web des sites des années 90 étaient surchargées d’images et le contenu était très condensé. Les navigateurs n’avaient pour rôle que d’afficher les pages qui étaient envoyées par le serveur Web.

    Voici comment la structure simple d’une application Web des 90’

    Ici, le navigateur affiche la page html demandée. Lorsqu’une action utilisateur effectue une action et déclenche une requête, il est simple de mesurer le temps de réponse entre le navigateur et le serveur, le navigateur lui-même est capable de le faire.

    Aujourd’hui, les choses sont différentes. D’après les calculs d’Amazon, 1s de temps de réponse de plus sur leurs applications ferait perdre 1.6 milliards de dollars à l’entreprise. L’expérience utilisateur est donc dans le cœur des débats, notamment pour les sites e-commerce (182 000 en France en 2018). Les entreprises font donc face à des clients toujours plus exigeants, et les technologies ont évolué dans ce sens.

    Malgré cette attente des utilisateurs, il faut de plus en plus de requêtes pour afficher une page Web, et la taille des pages chargées est de plus en plus conséquente. Pour afficher une page d’un site, il faut en moyenne 75 requêtes.

    Evolution du nombre de requêtes par page depuis 2011

    Depuis les années 2010, de nouveaux Frameworks Javascript comme Angular, React,et VueJS (pour ne citer que les 3 plus connus) permettent le développement d’applications très riches et ergonomiques pour les utilisateurs. Ceci implique également que les navigateurs soient capables de suivre la cadence, car l’émergence de ces outils a aussi impacté la structure des nouvelles applications.

    Ces frameworks permettent d’architecturer les applications dites Single Page Application, en créant des components et en respectant le modèle MVC (Modèle, Vue, Contrôleur). Le principe est d’avoir une application qui ne charge qu’une fois la page, et qui charge ses données d’entrée pour les manipuler ensuite.  Ce ne sont alors plus des serveurs d’application, mais des APIs et microservices qui sont contactés par le navigateur. Contrairement aux premières applications, les pages HTML ne sont plus envoyées par le serveur Web. L’application est découpée en plusieurs petites briques qui sont chargées de récupérer du contenu spécifique, qui transite au format json/XML à la demande de l’utilisateur. Tout le reste est géré par le framework et le javascript est dominant sur le front.

    Qu’est ce qui a changé ?

    Il est autant simple de tester et mesurer les performances d’une application classique qu’il est difficile de mesurer celles d’une Single Page Application (SPA). La logique serveur a été déportée côté client :

    Avec l’explosion du javascript sur les navigateurs ces dernières années, et des structures d’applications très différentes, fournir un temps de réponse sur une page n’est plus assez représentatif. Pour les architectures en microservices/API (très souvent ce qui se cache derrière une SPA), c’est la capacité transactionnelle du serveur qui va être importante à mesurer. Effectivement il ne reste que des services capables de fournir des données rapidement, et une base de données. Plus de serveur Web, ou d’application déployée sur un serveur d’application car tout est géré par le framework sur le front.

    En principe, les SPA chargent le contenu le plus important au début de la navigation. Le reste du contenu peut être téléchargé au fil de l’eau selon les actions de l’utilisateur. Les échanges client-serveur sont plus nombreux et il est difficile de mesurer leur temps de réponse.

    Ici, les zones 1, 2 et 3 peuvent être chargées à différents moments. Soit l’application permet d’afficher des données dans ces zones en cliquant sur un bouton, soit les développeurs feront en sorte de ne charger le contenu qu’une fois que l’utilisateur ait scrollé jusqu’ici (lazy loading). Dans les deux cas, la page est déjà chargée, et le reste des données arrive au fil de l’eau.

    Du point de vue du testeur, il devient difficile de mesurer le temps de réponse d’une page étant donné que son contenu est modifié dynamiquement en permanence.

    Mesure du temps de réponse sur un site normal

    Nous pouvons facilement mesurer le temps de chargement de la page (qui comprends le temps de chargement des ressources)

    Mesure du temps de réponse sur une SPA

    Les données sont chargée s en fonction de la navigation de l’utilisateur. Les requêtes asynchrones sont lancées en parallèle.

    Comment tester ces applications ?

    Si on tient à avoir des indicateurs sur l’expérience utilisateur, il faut utiliser des outils de tests fonctionnels comme Selenium ou Ranorex, qui sont capables de mesurer le temps d’affichage des éléments sur le navigateur. Couplés aux outils de tests de performance, ils pourront ainsi fournir des métriques issues du DOM alors que l’application est soumise à une forte charge. (Il faut prendre en compte la difficulté de réaliser des tests fonctionnels sur une SPA… mais ceci est un autre sujet)

    Pour tester le backend, nous parlerons de tests de composants. Evidemment une application Web classique sera testée depuis le navigateur, mais ici, il est important de connaitre la capacité transactionnelle. Son but est de fournir rapidement de la donnée, un point c’est tout (Si l’application est développée dans un contexte de CI/CD, il est alors préférable de tester les composants dès leur développement).

    Il faut donc tester l’application sous deux angles différents : les tests de composant pour connaitre la capacité des services backend et les tests bout en bout pour mesurer les performances de l’application et l’expérience utilisateur.

    Sources

    https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales

    https://www.alsacreations.com/actu/lire/1778-frameworks-javascript-angular-react-vue.html

    https://www.httparchive.org

    Appli web, Application, Performances, Serveur, SPA, tests, web, Web testing

    WAPSI

    More posts by WAPSI

    Related Post

    • Les principes des tests logiciels

      By WAPSI | Comments are Closed

      Cet article a pour finalité de définir les tests logiciels et de mettre en avant les principes des tests logiciels.  Tout d’abord, Qu’est-ce qu’un Test logiciel ?  Contrairement aux idées reçues, le test logiciel ne se limite pas àRead more

    • Comment allier les tests automatisés aux tests de performance ?

      By WAPSI | Comments are Closed

      Qu’est-ce que les tests automatisés ?  Aujourd’hui l’automatisation se trouve au centre de tout, elle s’installe dans notre quotidien sans même le savoir. Lorsqu’on retire de l’argent au distributeur automatique, ou lorsqu’on paye avec la carteRead more

    • Appium, le Selenium de vos applications mobiles

      By WAPSI | Comments are Closed

      Nous avions vu dans un précédent article toutes les possibilités qu’offrait Selenium pour ce qui est de l’automatisation des tests fonctionnels d’une application web https://www.wapsi.fr/selenium-les-etapes-vers-lautomatisation/. Et bien cette fois-ci, nous nous placerons dans une optique de portage deRead more

    • Neoload et les Custom Actions

      By WAPSI | Comments are Closed

      Neoload est un outil de tests de performance qui s’utilise de manière classique, mais il s’intègre également dans des environnements agiles et DevOps. Il propose par exemple une fonctionnalité permettant de maintenir et de faire évoluer unRead more

    • NeoLoad comme émulateur

      By WAPSI | Comments are Closed

      Introduction  Avec la diversification et la complexification des objets connectés, de plus en plus de structures informatiques (serveurs, programmes, etc.) voient le jour dans le but de les gérer et d’interagir avec.   Cependant, réaliser des tests de performances sur les services d’une montre ou d’une voiture connectée n’est pas chose aisée : l’interface d’interaction surRead more

    • L’Optimisation des performances de SAP Business Objects Data Services

      By WAPSI | Comments are Closed

      SAP Data Services propose une solution d’entreprise unique pour l’intégration, le profilage et le traitement des données de texte qui vous permet d’intégrer, de transformer, d’améliorer et de fournir des données sécurisées aux processus de gestion critiques.Read more

    NextPrevious
    WAPSI logo blanc

    NAVIGATION

    • WAPSI
    • Automatisation
    • Performance
    • Sécurité
    • Intelligence
    • Contact
    • Blog

    NOUS CONTACTER

    contact@wapsi.fr

    +33 6 72 35 13 26

    16 rue Washington 75008 Paris

    Tous droits réservés © 2019 WAPSI

    Mentions légales | Politique de Confidentialité
    • Accueil
    • Automatisation
    • Performance
    • Sécurité
    • Intelligence
    • Recrutement
    • Contact
    • Blog
    WAPSI