Je me souviens encore du jour où les responsables de ma société de conseil ont décidé de faire passer les opérations d’un outil sous licence coûteux à des solutions moins onéreuses offrant les mêmes fonctionnalités. Nous, un groupe de trois testeurs de performance, avons alors été chargés de transférer les activités de test de performance de LoadRunner à AgileLoad.
Nous avons commencé la tâche par la collecte des besoins, dans le cadre de laquelle nous avons essayé de comprendre les attentes critiques du projet vis-à-vis de l’outil. Nous avons étudié les différentes applications sur lesquelles les tests ont été effectués, la technologie associée à ces applications, leurs architectures et le protocole qui communique entre les clients et les serveurs de ces applications. Nous avons alors commencé à étudier les différentes solutions open source et autres solutions moins coûteuses disponibles sur le marché et nous avons commencé à les étudier. Nous avons créé une matrice tabulaire reprenant toutes les caractéristiques essentielles que nous recherchions et celles fournies par ces outils.
Les caractéristiques essentielles que nous recherchions étaient les suivantes
- Disponibilité d’une fonctionnalité d’enregistrement et de relecture dans l’outil
- Exigences en matière d’infrastructure pour les différents outils
- Nombre de tests d’utilisateurs simultanés que l’outil pourrait prendre en charge
- Facilité d’écriture de scripts et d’exécution de tests pour l’outil
- Facilité de migration des scripts et autres artefacts de test élaborés pour loadrunner vers un autre outil
- Popularité de l’outil au sein de la communauté des testeurs de performance
- Précision des résultats
- Quels sont les résultats et les graphiques fournis par les différents outils après le test ?
- Compatibilité de l’outil avec les outils de surveillance des serveurs (nous voulions également dépenser pour ces outils)
- Variété de protocoles différents pris en charge par l’outil
- Disponibilité des fonctions intégrées et leur utilisation dans les scripts
- Facilité de création, de manipulation et d’utilisation des données pendant l’essai
- Compatibilité des outils avec les serveurs Windows
- Compétences de l’équipe et facilité d’apprentissage de l’outil
Le tableau nous a donné un aperçu clair des différentes fonctionnalités des différents outils et nous a aidés à établir une liste restreinte d’outils susceptibles de répondre aux exigences des projets. Parmi les outils que nous avons présélectionnés figurent Pylot, AgileLoad et Jmeter. La partie suivante du projet consistait à utiliser ces outils sur des applications et des projets en temps réel et à tester leur efficacité, leur facilité d’utilisation et leur fiabilité. Le retrait de Pylot de la liste a été facile, l’équipe a rencontré beaucoup de problèmes pour apprendre un nouveau script et nous avons remarqué que l’outil n’était pas efficace pour les applications basées sur ‘https’. La plupart de nos applications internes étaient basées sur le web (authentification SSO).
La sélection d’AgileLoad et de Jmeter a été beaucoup plus difficile que ce à quoi nous nous attendions et a pris beaucoup de temps. Tous deux ont fourni des raisons impérieuses d’être utilisés dans le projet. Avec Jmeter, nous avons réussi à effectuer un test auprès de 500 utilisateurs, mais nous avons pu effectuer un test auprès de 1200 utilisateurs simultanés avec AgileLoad (sans blocage ni problème pendant le test). En outre, les fonctions d’analyse des résultats, de manipulation des données, de surveillance du serveur et de vérification du texte d’AgileLoad ont été complétées par d’autres capacités. De plus, en comparant les résultats des tests exécutés avec AgileLoad avec ceux des scénarios de production, nous avons observé que les résultats étaient plus fiables. Au fil du temps, nous avons observé qu’AgileLoad gagnait en popularité parmi les membres de l’équipe en raison de sa simplicité et de la largeur de bande accrue de ses fonctionnalités.
C’est ainsi que nous avons planifié le passage de Loadrunner à AgileLoad et aidé la direction à réduire de 80 % le coût annuel de l’outil.
