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

Automatiser les tirs de perf, ca marche !

    Home Articles Automatiser les tirs de perf, ca marche !
    NextPrevious

    Automatiser les tirs de perf, ca marche !

    By WAPSI | Articles | Comments are Closed | 9 septembre, 2020 | 0

    Interview de Bruno Audoux, responsable de l’innovation chez WAPSI

    Bonjour Bruno, si je suis là aujourd’hui c’est parce que vous me dites que deux mondes se rejoignent, l’automatisation et les tests de performances.

    Oui en effet, Le premier sert usuellement aux déploiements et aux tests de non-régression, et le second a pour fonction la validation d’une application sous la charge.

    Alors pourquoi nous n’avons pas automatisé les tests de performance avant ?

    Déjà car cela n’était pas nécessaire, les tests de performances étaient réalisés juste avant une mise en production, il était rare qu’on ait besoin de faire des campagnes régulières pendant l’année.

    Et donc qu’est ce qui a changé ?

    L’AGILE, un mot magique qui touche tout le monde aujourd’hui dans le monde de l’IT, les développeurs ont d’abord été concernés mais ce monde agile ne peut fonctionner correctement que s’il est en synergie avec d’autres sphères agiles. Le monde des tests a donc pris un peu de temps pour proposer des méthodologies de travail adaptées à ce type de livraison rapide et régulière.

    Et quels sont les grandes nouveautés ou changements ?

    Le principal changement c’est le rythme de livraison : un sprint c’est classiquement 3 semaines, et produire une recette complète toutes les 3 semaines c’est un vrai défi ; cela demande une énorme coordination en amont sur les périmètres de test, mais aussi un partage d’information plus clair sur les résultats de test, sans parler des mises à jour des scripts de test bien sûr.

    C’est là qu’intervient l’automatisation ?

    Oui et non, si nous avons initialement mis en place des outils d’automatisation pour les tests de sprint, on s’aperçoit que se limiter à un test par sprint c’est de la perte de ressource et de temps.

    On peut faire beaucoup mieux.

    En fait à partir du moment où l’on met en place une chaine de tests automatisés, celle-ci est encore plus utile sur des tests quotidiens. Elle peut devenir un vrai outil de test de non-régression sur les indicateurs de performance. Ses résultats s’adressent directement aux développeurs qui peuvent modifier durant le sprint leur code et l’optimiser avant la livraison du sprint.

    Concrètement comment cela fonctionne ?

    Au niveau des outils, nous reprenons les outils du marché, pour lesquels les éditeurs ont dû beaucoup changer la manière de fonctionner, il fallait que ces outils puissent être pilotés par d’autres programmes et produisent des rapports automatisés. Un outil comme Gatling est issu de cette mouvance et est parfaitement adapté au pilotage externe, mais Neoload et Loadrunner ont dû ajouter des points d’entrée comme le AsCode ou les API pour être pilotable.

    De plus ces outils ont appris à utiliser du code sur des repository comme Gillab ce qui les rend plus flexible.

    Je n’ai pas encore compris.

    C’est normal je n’ai pas encore fini.

    Donc à ce moment-là on les pilote par des orchestrateurs, Jenkins étant assez fiable pour ce type de travaux, nos outils finissent dans des Pipelines qui montent les applis de test, chargent les scripts et les jeux de données, réalisent des tirs courts (5 à 30 mins) et envoient les résultats dans un repository autorisant les comparatifs. En faisant des tirs toutes les nuits sur une plateforme d’intégration, les développeurs peuvent vérifier la qualité de leur code bien avant le passage en pré-production.

    Donc les développeurs peuvent vérifier qu’il n’y a pas de dégradation sur leur livraison ?

    C’est exact, vient la problématique de comparer les résultats ; les outils de reporting sont tout juste sortie d’usine sur ce type de fonctionnalité. D’un côté, Loadrunner 2020 propose le module TrendReport, Neotys propose le NeoloadWeb qui fait des courbes de tendance. Mais dans les deux cas, ces outils ne font que présenter les résultats, ils ne sont pas conçus pour faire des alertes.

    Alors comment gérer les alertes ?

    On retourne dans Jenkins, on configure des scripts d’analyse et on pousse nos alertes vers des mails ou des Dashboards. Les éditeurs ne devraient pas tarder à proposer des fonctionnalités là-dessus en accord avec leurs fonctions de SLA. C’est une question de temps.

    Où est le problème de ce type d’outil de test automatisé ?

    Il y en a deux. Le premier est la mise à jour des scripts, même si les éditeurs proposent des fonctionnalités de mise à jour automatisées qui fonctionnent, certains framework sont trop complexe et l’intervention humaine est indispensable. L’autre, c’est les changements de périmètres de test, par principe dans l’AGILE ont peut retirer une fonction d’un site, et donc il n’est plus nécessaire de le tester, cela doit se faire manuellement aussi et les comparatifs entre deux tirs qui n’ont pas les mêmes scripts nécessitent aussi de l’intervention d’expert.

    Combien de temps pour déployer une infrastructure de test de performance automatisé ?

    C’est rapide, on s’appuie sur la technologie microservice (docker). Donc quelques jours pour la partie technique, le plus long étant de faire un cadrage de qualité et des scripts de démarrage. Pour les scripts de maintenance et d’alerte, nous avons déjà des templates. En une semaine le client peut être équipé de son moteur, il ne reste plus qu’à former ses équipes.

    Un dernier mot pour nos lecteurs ?

    Oui j’ai précisé que ce type d’outil apportait des informations aux développeurs mais c’est beaucoup plus vaste que cela. S’il est monté sur une préprod ou une production, il apporte aussi des informations de fonctionnement à l’équipe métier, et aux équipes de support. Les possibilités sont encore vastes et ne demandent qu’à être explorées.

    Merci !

    Septembre 2020, interview réalisé avec un masque FFP2.

    No tags.

    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

    • Talend for Data Integration – Les Bonnes Pratiques

      By WAPSI | Comments are Closed

      1 Préambule Dans la grande majorité des cas, les développeurs découvrent les outils Talend par la version communautaire, et bien souvent avec la brique Data Integration pour traiter leurs problématiques d’intégration. Si certains ont déjàRead more

    • Dynatrace comme outil d’audit puissant, gain de temps , gain d’expertise

      By WAPSI | Comments are Closed

      Les expertises d’architecture sont souvent demandées pour aider une équipe à remettre en état et optimiser une application qui ne semble pas optimale. Le premier principe est de faire auditer avec un œil nouveau unRead more

    • Selenium – les étapes vers l’automatisation

      By WAPSI | Comments are Closed

      Selenium est un framework dédié à l’automatisation de test disposant d’une version IDE et d’une version API nommé Selenium WebDriver qui peut être exploité avec plusieurs langages : PHP, Javascript, C#, Python, Ruby, Perl etRead more

    • Talend for Data Integration : Les Bonnes Pratiques – Part 2

      By WAPSI | Comments are Closed

      1 Préambule Dans le premier volet nous avons vu les bases sur lesquelles s’appuyer pour démarrer dans de bonnes conditions nos projet Talend. Dans ce second volet, nous allons aborder des notions plus avancées …Read 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

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

      By WAPSI | Comments are Closed

      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ôleRead more

    • Minage de crypto-monnaie

      By WAPSI | Comments are Closed

      Introduction Cet article décrit le procédé du minage des crypto-monnaies d’un point de vue fonctionnel et technique, sans rentrer dans les aspects financiers et boursiers, en l’illustrant avec l’exemple du Bitcoin. Rappel sur les crypto-monnaiesRead more

    • Boite à outil : GIT

      By WAPSI | Comments are Closed

      Il est des incontournables dans la boite à outils des dev /devOps et affiliés et git fait partis de ceux-là… Mais qu’est-ce que git ? Essayons d’imager un peu. N’avez-vous jamais eu ce fameux document WordRead 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