• Arnaud Mauduit

NeoLoad comme émulateur


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é n'est pas chose aisée : l'interface d'interaction sur l'objet est assez limitée, voire inexistante ; d'autant plus si les tests sont à effectuer avant leur création.


Une solution a donc été trouvée : émuler l'objet - ou plus précisément son comportement - sur ordinateur afin de pouvoir interagir librement avec celui-ci.


Et là vous allez me dire "oui c'est un bouchon", exact, sauf qu'un bouchon ne permet pas de simuler les réponses personnalisées des IOTs, et qu'il le fait de manière unitaire.


Emuler les objets connectés


Il existe plusieurs manières d'émuler un objet connecté, ce qui compte c'est que le serveur reçoive les réponses qu'il attend, en temps, en volume et dans l'ordre attendu.


Voici 2 manières de faire : Piloter un programme d'émulation ou répondre avec NeoLoad comme le fait le programme.


Le programme émulateur


Il est possible, avec NeoLoad, d'interagir avec un programme émulateur qui reproduit à l'identique les réponses de l'objet lorsqu'il est sollicité.


En effet, NeoLoad propose une fonctionnalité "invite de commande" qui nous permet d'exécuter un programme simulant l'objet. Si NeoLoad va fonctionner comme un orchestrateur, il doit transmettre à chaque instance son ID et la liste de ses traitements à réaliser. Un véritable casse tête, car une fois lancé, il n'est plus possible de lui transmettre d'instruction. De plus celui-ci fournit aucun temps de réponse. C'est donc une solution pauvre et complexe à maintenir. Sans compter l'emprunte mémoire.


C'est pourquoi une seconde solution existe : l'émulation par requêtes.


Le Dialogue NeoLoad


Cette solution consiste à communiquer directement avec le serveur en envoyant les requêtes qui, auparavant, étaient envoyées par le programme émulateur.


Pour ce faire, nous devons commencer par obtenir lesdites requêtes (appelées "traces"). Il existe deux façons pour les obtenir : demander à l'éditeur qu'elles nous soient fournies ou les récupérer nous-même via un sniffer.


Sniffer les traces


Même s'il est préférable que les traces soient remises par le client afin d'en assurer la pertinence, il arrive parfois que cela s'avère impossible et qu'il faille les récupérer soi-même.


Il existe donc des outils - comme par exemple les logiciels Fiddler et Charles ou encore l'inspecteur du navigateur Chrome - qui permettent de capter ces traces (requêtes et réponses).


Il ne reste plus qu'à rouvrir NeoLoad et de créer un nouveau script contenant ces traces fraîchement capturées.


Utiliser les traces avec NeoLoad


Maintenant que nous avons récupéré les traces, il ne reste plus qu'à les adapter sur NeoLoad ; de façon à ce que - lorsqu'on lance le script - nous n'ayons plus besoin du programme et que l'objet soit émulé par NeoLoad : les requêtes seront envoyées directement au serveur et ce dernier renverra les mêmes réponses qu'il aurait envoyé au "véritable" objet.


Nous avons donc un outil qui maîtrise son dialogue et peut fournir les temps de réponses ainsi que les traces des erreurs (sans avoir à chercher dans une logue infinie).


Reste à lui donner une petite part d'intelligence pour qu'il réagisse comme un émulateur :

  • Mettre les bons temps de pause : OK

  • Ajouter des conditions : OK

  • Ajouter des boucles : OK

  • Avoir une émulation réseau : OK

  • Requêter des API ou du SQL pour avoir des éléments de contexte : OK

Et bien d'autres.

29 vues

Posts récents

Voir tout