• Bruno Audoux

Test de charge et IOT, comment faire ?


Basiquement le test de charge est le principe de simuler des utilisateurs humains qui utilisent un navigateur pour vérifier que le serveur tient la charge.


Tous les outils de tests sont conçus pour reproduire le dialogue inhérent à ce type de conversation multiplié par le nombre d’utilisateur virtuels à réaliser.


Mais les IOTs fonctionnent différemment qu’un humain derrière un navigateur, ils sont beaucoup plus prévisibles, dû au fait que ce sont eux-mêmes des programmes, mais ils ont la fâcheuse tendance à avoir des dialogues beaucoup plus complexes.


Mais là où le bencheur se retrouve un peu chahuté, c’est pour attraper le dialogue entre l’IOT et son serveur. En effet, les outils classiques montent un proxy sur le navigateur et dupliquent le dialogue HTTP, ce qui est parfois impossible sur un IOT, qui peut être une montre, un tableau de bord, une sonde de radiateur ou un capteur de présence. Bref l’IOT est un petit objet sournois qui a de multiples formes, multiples fonctions, multiples dialogues et surtout aucune envie de se faire décrypter. De plus les IOTs ne communiquent pas toujours dans le même sens, si certains sont des programmes qui interrogent les serveurs pour donner leur état de santé, d’autres attendent patiemment que le serveur viennent les interroger. Et ce mode de communication inversée est un casse-tête pour le bencheur.


Voyons comment affronter ces nouveaux habitants de la toile.


Phase 1 : Reproduire le dialogue


Comme je le disais plus haut, la plupart du temps les outils dupliquent un dialogue réel qu’ils ont attrapé avec un Proxy, mais lorsqu’il n’est pas possible de mettre un proxy dans le navi…. dans l’IOT alors comment faire ?


Méthode simple : Le simulateur


La plupart du temps le développement du code d’un IOT se fait par un simulateur, et les simulateurs son capable de pointer vers un proxy, si ce n’est pas le cas il est nécessaire de copier le flux qui en sort par des outils réseau assez fin comme Fiddler2, mais je conseillerai plutôt Charles, le super proxy.


Dans le cas ou ses IOT fonctionnent en SSL V3, c’est un vrai casse-tête car les simulateurs ainsi que les outils de capture doivent avoir et truster les bons certificats pour garantir la capture.


Méthode galère : les spécifications


Heureusement, les développeurs ont toujours dans leur manche un pavé de spécification très complexe qui présente sur des centaines de pages les dialogues par timeline et les tableaux des champs obligatoires ou optionnels pour chaque requête.


L’enfer sur terre pour tous les bencheurs qui sont incapable de créer des milliers de requêtes “from Scratch” avec leurs temps de pause et leurs cohérences de taille de champs etc…


Il y a bien le magic Swagger lors de dialogue JSON mais il n’est pas si courant sur des IOTs bien complexes. Je déconseille fortement l’idée d’inventer un dialogue complet, sans avoir le développeur sur les genoux.


Il est conseillé de faire le nécessaire pour attraper le flux par n’importe quel sniffer que de réinventer un dialogue qui sera toujours faux.


Phase 2 : Le dialogue inversé


L’apothéose de l’IOT, est la mise en place de Devices (appareils) qui n’interrogent pas le serveur qu’ils doivent renseigner mais plutôt qui attendent d’être interrogé. Cela à de multiples avantages en termes de sécurité et de répartition de charge par contre c’est une vraie utopie à bencher.


Comment simuler 1000 volets roulants dans une tour qui attendent qu’on les interroge ?


L’idée est de transformer un outil de tests de charge en Multi-simulateur, je m’explique, multi car il va simuler les réponses de nombreux IOT, et simulateur car au lieu d’interroger, il répond aux interrogations du serveur central.

Donc il faut un outil de test de charge qui puisse multiplier les IPs, les ports, répondre sur un protocole spécifique, simuler le temps de réaction, simuler des réponses différentes (sinon ce n’est pas drôle) et tenir la charge !


Dans le cas d’un dialogue HTTP ou JMS cela est assez rudimentaire, mais dans le cas d’un protocole TCP spécifique, il est nécessaire d’intégrer des librairies “clientes” servant à répondre comme l’IOT.


Conclusion


Ce type de bench se multiplie et il sera nécessaire de faire confiance à de bons experts en réseau/sécu/protocoles/outils pour sortir des tests cohérents.


La problématique de ce type de test n’est pas que la complexité, c’est surtout le temps nécessaire pour ces mises en place, ces tests de protocoles, ces jeux d’essai ultra précis.


Alors courage, Benchons.



69 vues

Posts récents

Voir tout