Par David BUCH, Directeur innovation de Radview
Si vous êtes dans le même cas que le client dont j’ai parlé hier, et qu’il vous faut à chaque fois entre 24 et 48 heures pour mettre en place votre environnement de test de charge, il y a de fortes chances que vous vous vous y preniez mal.
Contrairement au test fonctionnel, où un ordinateur et un bureau suffisent à se lancer, bâtir un environnement de test de charge s’avère un petit peu plus difficile – et ce, quels que soient les outils de test utilisés. Voilà donc quelques astuces qui pourraient bien vous dépanner.
1 – Utiliser votre environnement de production
Oui, au premier abord cela peut sembler bizarre et même rarement faisable. Et pourtant, votre environnement de production est l’environnement idéal pour mener à bien les tests. Rien à répliquer, et tous les processus en tâche de fond et variables d’environnement, qui tendent à passer inaperçus mais affectent la performance, sont déjà présents et ne peuvent pas être manqués, comme c’est sinon bien souvent le cas.
Quelques-uns de nos clients (dont une banque et un marché financier), utilisent leur environnement de production réel pour exécuter des tests de charge pendant la nuit et/ou les weekends. C’est donc tout à fait envisageable et j’aurais tendance à opter en priorité pour cette option, si tant est qu’elle est disponible.
Lorsque vous utilisez un environnement de production pour les tests, assurez-vous de:
-Sauvegarder les données de production, afin de pouvoir rapidement réactiver l’environnement réel une fois le test terminé
-Régler le problème de soit isoler/désactiver les applications tierces (comme les systèmes de paiement). Par exemple, si vous testez un site de commerce en ligne, incluez les activités de paiement Visa ou PayPal. Concernant celles-ci, vous devrez collaborer avec des entreprises tierces et supprimer toutes les données de test. Sinon, vous pouvez utiliser des souches pour simuler cette activité. Si cela s’avère une fois de plus impossible, alors exécutez les transactions tout en excluant l’activité tierce que vous souhaitez éviter, comme un virement vers un compte.
-Utiliser des entités fictives (comme des comptes utilisateur) pour simuler l’activité que vous désirez tester.
2 – Effectuer une réplique exacte de votre environnement de production
Extrapoler les résultats de test de charge est une mission à haut risque. Si vous exécutez le test sur une machine de 1 Go bi-cœur, à quoi ressembleront les résultats pour une machine de 2 Go quadri-cœur ? C’est presque impossible à deviner.
Ainsi, assurez-vous de créer une réplique dans le moindre détail de votre environnement de production – profils machines, configuration, base de données, architecture réseau, équilibreurs de charge, pare-feu, etc. Une méthode pour ce faire serait de créer des images complètes des machines de production, puis de les dupliquer dans votre environnement de test.
3 – Répliquer l’environnement d’un client
Partons du principe que votre produit est un logiciel sur site – par exemple, un système d’informations pour des universités, qui gère les étudiants, les inscriptions, l’administration, etc. Il serait assez compliqué pour vos équipes de R&D et de contrôle qualité de simuler un environnement réaliste à des fins de test. La manière la plus efficace serait de dupliquer l’environnement de production d’un client. Essayez de collaborer avec certains clients sélectionnés, en offrant la garantie de protéger ou d’omettre les données sensibles, et en les compensant avec des réductions ou une assistance gratuite. Au final, vous offrez de tester l’environnement réel de votre client et leur évitez d’avoir à le faire de leur côté, c’est bien ça?
4 – Bâtir un environnement réel en partant de zéro
Dans certains cas, vous n’aurez aucun environnement de production à copier, et vous devrez bâtir un environnement de test de charge en partant de zéro. Vous en êtes possiblement aux premières phases de développement de votre logiciel, et vous n’avez aucun environnement de production ou une base de clients encore insuffisante. Ou vous pouvez aussi être soumis à des restrictions de sécurité et n’avez aucun accès à un environnement de production réel.
Dans une telle situation, assurez-vous de:
-Prendre en compte les différents types de déploiements potentiels que vous souhaitez tester – petit, moyen, grand, etc. Pour chacun, définissez le nombre d’utilisateurs configurés, le nombre d’enregistrements dans la base de données, etc.
– Créer des configurations les plus proches possible de la production standard – sécurité, matériel, logiciel, réseau, autres applis déployées, équilibreurs de charge, etc.
-Utiliser des scripts automatisés pour remplir la base de données représentant l’environnement réel.
-Incorporer les procédures continues moins remarquables. Assez souvent, la performance se dégrade lors de tâches périodiques comme une sauvegarde de la base de données ou la génération d’un rapport BI hebdomadaire pour la gestion. Ces problèmes ne sont pas détectés si ces tâches périodiques ne sont pas incorporées à l’environnement de test.
-Ajouter les intégrations tierces utilisées dans le système de production réel, comme les systèmes de paiement, de rapport ou d’assistance, etc. Prenez acte du commentaire précédent sur la manière de gérer ceux-ci pendant le test.
5 – Établir une procédure pour rapidement configurer votre environnement de test
Vous devez configurer votre environnement de test de charge aussi vite que possible, afin de pouvoir le réutiliser pour de nouveaux tests. Une fois l’environnement en service et configuré, créez-en un instantané ou une image afin de pouvoir le recréer en quelques minutes. De même, il existe de nombreux outils de gestion de configuration et d’automatisation informatique à votre disposition pour configurer rapidement un environnement de serveur, tels que Puppet, Chef, Saltstack, Ansible, Docker, ou Vagrant.
6 – Isoler l’environnement de test
Les ressources informatiques restent rares, et les machines de test sont souvent la solution par défaut. Lorsque le CFO ou la nouvelle équipe produit cherche une machine pour exécuter un processus ou un essai, ils se rabattent souvent sur une machine de test – et vous en serez toujours le dernier informé ! Vous devez vous assurer que seuls vos clients virtuels peuvent atteindre votre application testée. Tout aussi important, votre réseau de test doit être isolé afin de ne pas être affecté par d’autres activités de l’entreprise dont vous ne seriez pas forcément informé.
