Leadership dans le test : Gérer les tests de performance
Note de la rédaction : Bienvenue dans la série Leadership In Test du gourou et consultant en tests logiciels Paul Gerrard. Cette série est conçue pour aider les testeurs ayant quelques années d'expérience—en particulier ceux travaillant en équipes agiles—à exceller dans leurs rôles de responsable et de gestion des tests.
Dans l’article précédent, nous avons exploré le test de services et ses principaux composants : les tests de performance, les tests de tolérance aux pannes/de charge prolongée et la gestion. Comme promis, nous allons ici approfondir un peu plus les tests de performance.
Inscrivez-vous à la newsletter The QA Lead pour être averti dès que de nouveaux volets de la série seront publiés. Ces articles sont des extraits du cours Leadership In Test de Paul que nous vous recommandons vivement pour approfondir ce sujet et d'autres thématiques. Si vous décidez de vous inscrire, utilisez notre code coupon exclusif QALEADOFFER pour bénéficier de 60$ de réduction sur le prix total du cours !
Bienvenue dans la série Leadership In Test. Dans le dernier article, nous avons abordé le test de services pour les applications web.
L'objectif de ce chapitre est de donner quelques conseils et bonnes pratiques pour la gestion d'un élément clé du test de services mentionné dans cet article, qui est, roulement de tambours... le test de performance !
Nous allons aborder :
- Objectifs des tests de performance
- Quatre prérequis pour un test de performance
- Kit d’outils pour les tests de performance
- Processus de test de performance
C’est parti.
Objectifs des tests de performance
Pour rappel, nous pouvons définir l’objectif principal des tests de performance comme :
« Démontrer que le système fonctionne selon les spécifications, avec des temps de réponse acceptables, tout en traitant les volumes de transactions exigés sur une base de données de taille production. »
Votre environnement de test de performance est un banc d’essai qui peut être utilisé pour d’autres tests, avec des objectifs plus larges, que l’on peut résumer ainsi :
- Évaluer la capacité d’évolution du système (Si vous ne savez pas quel logiciel peut couvrir vos besoins, notre liste des meilleures solutions de gestion de base de données peut vous guider.)
- Identifier les points faibles de l’architecture
- Procéder à des réglages du système
- Détecter des bogues obscurs dans le logiciel
- Vérifier la résilience et la fiabilité.
Votre stratégie de test doit définir les besoins pour une infrastructure de test permettant d’atteindre tous ces objectifs.
Quatre prérequis pour un test de performance
« Si l’un de ces prérequis est manquant, soyez très prudent avant de procéder à l’exécution des tests et à la publication des résultats. L’utilisation d’outils d’automatisation de l’assurance qualité peut vous aider à garantir que ces prérequis sont satisfaits. Les tests pourraient être difficiles, voire impossibles à réaliser, ou bien la crédibilité des résultats publiés pourrait être sérieusement compromise et facilement remise en cause. »
1. Exigences quantitatives, pertinentes, mesurables, réalistes et atteignables
Comme base pour tous les tests, les exigences de performance (objectifs) doivent être convenues avant le test afin qu’il soit possible de déterminer si le système répond à ces exigences.
Les exigences en matière de débit ou de temps de réponse du système, pour servir de référence à la comparaison des résultats de performance, doivent présenter les caractéristiques suivantes. Elles doivent être :
- Énoncées en termes quantifiables.
- Pertinentes pour la tâche que l’utilisateur souhaite accomplir.
- Mesurables à l'aide d'un outil (ou d'un chronomètre), et à un coût raisonnable.
- Réalistes eu égard à la durée des tâches utilisateur.
- Atteignables à un coût raisonnable.
Souvent, les exigences de performance sont vagues ou inexistantes. Cherchez toute exigence documentée si possible. S’il existe des lacunes, vous devrez peut-être les formaliser a posteriori.
Avant qu’un test de performance ne puisse être spécifié et conçu, les exigences suivantes doivent être acceptées :
- Temps de réponse des transactions.
- Profils de charge (le nombre d’utilisateurs et les volumes de transactions à simuler).
- Volumes de base de données (le nombre d’enregistrements dans les tables de la base de données attendus en production).
Il est courant que les exigences en matière de performance soient définies en des termes vagues. Souvent, ces exigences sont basées sur des volumes d’activité prévus et approximatifs ; il peut être nécessaire d’amener les utilisateurs métier à réfléchir de façon réaliste aux exigences de performance.
Vous devrez peut-être également effectuer vous-même une analyse des exigences et documenter celles-ci comme étant les objectifs de performance à atteindre.
2. Un système stable
Si le système est bogué et peu fiable, vous n’irez pas loin avec un test de performance. Les tests de performance sollicitent tous les composants architecturaux dans une certaine mesure. Pour que les tests de performance produisent des résultats utiles, le système et l’infrastructure technique doivent cependant être suffisamment fiables et résilients dès le départ.
3. Un environnement de test réaliste
L’environnement de test doit être configuré pour que le test ait du sens. Il est probable que vous ne puissiez pas répliquer le système cible ou de production, mais l’environnement de test devrait être comparable, en tout ou en partie, à l’environnement de production final. Vous devrez vous mettre d’accord avec l’architecte du système sur les compromis acceptables et ceux qui ne le sont pas, ou au minimum, sur les interprétations utiles qui pourraient être faites des résultats de test.
Créer un environnement de test réaliste est essentiel pour réaliser des tests de performance significatifs. Pour découvrir des outils qui vous aident à simuler des conditions réelles, consultez notre sélection de plateformes de tests logiciels recommandées
4. Un environnement de test maîtrisé
Les testeurs de performance ont besoin de stabilité. Non seulement en termes de fiabilité et de résilience du matériel et des logiciels, mais aussi par la minimisation des changements au sein de l’environnement ou du logiciel testé. Par exemple, si l’interface évolue même très légèrement, les scripts de test conçus pour piloter l’interface utilisateur risquent d’échouer immédiatement.
Toute modification de l’environnement doit être strictement contrôlée. Si les modifications corrigent des bogues qui n’ont probablement pas d’impact sur la performance, vous pouvez envisager de ne pas accepter la version. Seuls les changements visant à améliorer la performance ou la fiabilité pourraient être acceptés.
Boîte à outils de test de performance
Votre boîte à outils de test de performance comprend cinq principaux outils :
- Création/Maintenance de données de test – pour créer les gros volumes de données dans la base de données nécessaires pour le test. On s’attendrait à ce qu’il s’agisse d’un utilitaire basé sur SQL, ou peut-être d’un produit PC comme Microsoft Access connecté à votre base de données de test.
- Génération de charge – les outils courants utilisent des pilotes de test qui simulent des clients virtuels en envoyant des messages HTTP aux serveurs web.
- Outil d’exécution d’application – celui-ci pilote une ou plusieurs instances de l’application via l’interface du navigateur et enregistre les mesures des temps de réponse. (C’est généralement le même outil utilisé pour la génération de charge, mais ce n’est pas obligatoire).
- Supervision des ressources – des utilitaires qui surveillent et journalisent les ressources système côté client et serveur, le trafic réseau, l’activité des bases de données, etc.
- Analyse et reporting des résultats – les outils d’exécution de test et de surveillance génèrent de gros volumes de données de résultats à analyser.
À lire aussi : LES 10 MEILLEURS SERVICES D’ANALYTIQUE SQL POUR LES ÉQUIPES QA
Le processus de test de performance
Ci-dessous, une figure présente un processus générique pour tester et optimiser (tuner) la performance. L’optimisation ne fait pas vraiment partie du processus de test, mais il s’agit d’une étape indissociable de l’amélioration de la performance et de la fiabilité. L’optimisation peut impliquer des changements dans l’infrastructure architecturale, mais ne devrait pas impacter les fonctionnalités du système testé.
Voyons maintenant comment élaborer, exécuter, analyser et restituer les résultats d’un test de performance.
Développement progressif des tests
Le développement des tests est généralement réalisé de manière progressive en quatre étapes :
- Chaque script de test est préparé et testé isolément afin de le déboguer.
- Les scripts sont intégrés dans la version de développement de la charge de travail et la charge de travail est exécutée pour vérifier que le nouveau script est compatible.
- Au fur et à mesure que la charge de travail s’accroît, le cadre de test en développement est continuellement perfectionné, débogué et rendu plus fiable. L’expérience et la maîtrise des outils augmentent également.
- Lorsque le dernier script est intégré à la charge de travail, le test est exécuté en tant que « test à blanc » pour garantir qu’il soit complètement répétable et fiable, et prêt pour les tests formels.
Des tests intermédiaires peuvent fournir des résultats utiles
Les exécutions d’une charge de travail partielle et des transactions de test peuvent révéler des problèmes de performance. Les tests effectués avec de faibles volumes offrent aussi des indications précoces sur le trafic réseau et les goulets d’étranglement potentiels lorsque la charge de travail sera augmentée.
Des temps de réponse médiocres peuvent être dus à une mauvaise conception applicative, pouvant être étudiée et résolue plus tôt par les développeurs. Des tests précoces peuvent également être menés sur de longues périodes comme tests d’endurance.
Exécution des tests
L’exécution des tests nécessite de la gestion de projet ou une certaine coordination. Vous devrez collaborer avec les participants qui surveilleront le système lors de l’exécution des tests. L’« équipe de supervision des tests » peut être répartie, il est donc nécessaire de la tenir informée pour assurer le bon déroulement du test et la bonne collecte des résultats.
Au-delà de la coordination des différents membres de l’équipe, l’exécution d’un test de performance suit en général une routine standard.
- Préparation de la base de données (restauration depuis une sauvegarde sur bande, si nécessaire).
- Préparer l’environnement de test comme requis et vérifier son état.
- Lancer les processus de surveillance (réseau, clients et serveurs, base de données).
- Démarrer la simulation de charge et observer les outils de surveillance du système.
- Si un outil distinct est utilisé, lorsque la charge est stable, démarrer l’outil de test d’application et la mesure des temps de réponse.
- Surveiller attentivement le test pendant toute sa durée.
- Si les outils d’exécution de tests ne s’arrêtent pas automatiquement, terminer le test à la fin de la période d’essai.
- Arrêter les outils de surveillance et sauvegarder les résultats.
- Archiver tous les résultats collectés et s’assurer que les données des résultats sont sauvegardées de façon sécurisée.
- Produire des rapports intermédiaires ; échanger avec les autres membres de l’équipe à propos d’éventuelles anomalies.
- Préparer les analyses et les rapports.
La coordination des différents membres de l’équipe pendant l’exécution des tests peut s’avérer complexe. Simplifiez ce processus en intégrant des outils avancés de gestion des tests conçus pour Jira, qui proposent des fonctionnalités telles que la collaboration en temps réel et le reporting
Le réglage (tuning) intervient généralement après les tests lorsqu’il existe des problèmes ou lorsque des optimisations sont connues. Si un test est répété, il est essentiel d’enregistrer toute modification de l’environnement, afin que l’on puisse relier les différences de comportement système, et donc de performance, aux changements de configuration opérés.
En matière de gestion des cas de test pour les tests de performance, un logiciel de gestion des tests peut faire la différence. Il permet une meilleure organisation, un meilleur suivi, et même l’automatisation des cas de test.
En règle générale, il est prudent de ne changer qu’un seul paramètre à la fois afin que, lorsque des écarts de comportement sont détectés, on puisse les remonter précisément aux modifications effectuées.
Analyse et rapport des résultats
Le rapport type d’une exécution de test résume ces mesures et pour chaque mesure prise, il sera indiqué :
- Le nombre de mesures réalisées.
- Le temps de réponse minimum.
- Le temps de réponse maximum.
- Le temps de réponse moyen.
- Le temps de réponse du Ne percentile (généralement 95e).
L’outil de génération de charge de votre boîte à outils doit enregistrer le nombre de chaque type de transaction pendant la période de test. En divisant ces nombres par la durée du test, on obtient le taux de transaction ou le débit réellement atteint.
Le nombre de transactions correspond à la charge appliquée au système. Cela suppose que les proportions de transactions exécutées correspondent au profil de charge que vous souhaitez simuler.
La charge appliquée devrait correspondre au profil de charge simulé – mais ce n’est pas forcément le cas si le système répond lentement et que les transactions s’exécutent à des vitesses variables.
Habituellement, vous effectuerez une série de tests à différentes charges. En utilisant les résultats de ces tests, tracez un graphique du temps de réponse pour une transaction en fonction de la charge appliquée.
Les outils de surveillance des ressources disposent généralement de fonctionnalités de rapport statistique ou graphique qui permettent de visualiser l'utilisation des ressources au fil du temps. Des rapports détaillés montrant l'utilisation des ressources par rapport à la charge appliquée sont très utiles et peuvent aider à identifier les goulets d'étranglement dans l'architecture d'un système.
Bonne chance !
Inscrivez-vous à la newsletter The QA Lead pour être informé de la publication des nouveaux articles de la série. Ces publications sont des extraits du cours Leadership In Test de Paul que nous recommandons vivement pour approfondir ce sujet et d’autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix du cours !
Lecture connexe : MÉTRIQUES DE SURVEILLANCE SERVEUR À SUIVRE POUR LA SANTÉ ET LES PERFORMANCES DU SYSTÈME
