BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Les Tests De Performance Doivent S'Appuyer Sur Les Tendances

Les Tests De Performance Doivent S'Appuyer Sur Les Tendances

Favoris

Quand on travaille sur les tests de performance, il faut d'abord mettre en place un référentiel et définir les métriques à suivre en association avec l’équipe de développement. Nikolay Avramov conseille de réaliser régulièrement des tests de performance et de les comparer avec les résultats obtenus pendant le développement pour repérer le plus vite possible les performances endommagées .

Lors du QA Challenge Accepted 2022, Avramov, responsable de l'automatisation chez Automate The Planet, s'est exprimé sur les tests de performance.

L'une des démarches communes qu'Avramov a pu observer c'est quand il faut développer un produit, effectuer des tests fonctionnels sur ce produit, obtenir la validation de l'utilisateur et vérifier que ça fonctionne "bien" en fonction de la charge d’utilisateurs simultanés attendus. Si on teste le produit à la fin du processus de développement seulement, on passe outre les chances d'obtenir des informations qu'on aurait pu utiliser, a-t-il déclaré. 

Selon Avramov, s'appuyer sur une tendance de résultats dans la durée est crucial pour les tests de performance :

Les tests de performance doivent être planifiés avant et exécutés pendant le développement. Le fait de connaître les types de tests de performance à développer, va permettre à l'équipe d'identifier les métriques qu'il faut suivre tout au long du projet et de définir un référentiel pour son système. Il est toujours possible d'évaluer le produit pendant le développement.

Au cours d'un projet, les goulots d'étranglement peuvent s'enchaîner et devenir de plus en plus difficiles à résoudre. Si tel était le cas, c'est tout le système qui serait affecté par des problèmes régression, a précisé Avramov.

Chaque application a ses limites et ses spécificités. Selon Avramov, le premier objectif des tests de performance est de définir quelles sont ses limites et quelles sont les performances "inactives", d'un point de vue client :

La question est, que pouvons-nous améliorer ?

  • S'il s'agit du temps de chargement d'une page d'accueil, il existe un ensemble de mesures et de tests que nous pouvons utiliser pour exécuter et suivre les résultats.
  • S'il s'agit de supporter un nombre simultané d'utilisateurs, il faut donc configurer un ensemble de tests de charge pour effectuer et analyser les résultats après chaque changement.
  • S'il s'agit d'un scénario métier qui prend trop de temps, la résolution du problème peut nécessiter le profilage d'une requête de base de données ou d'une série de requêtes Web.

La recherche de goulots d'étranglement de performance est toujours liée au travail d'équipe entre plusieurs rôles, départements et composants du système, a déclaré Avramov. Toutes les réponses n'émanent pas d'une seule personne dans un seul endroit, une partie du travail consiste donc à réunir toutes ces personnes et à rassembler leurs connaissances et leur énergie pour résoudre le problème.

Les tests de performance sont un processus itératif où des améliorations doivent constamment être apportées - du côté logiciel et des tests eux-mêmes, a conclu Avramov.

InfoQ a interviewé Nikolay Avramov sur les tests de performance.

InfoQ : Comment définiriez-vous les tests de performance ?

Nikolay Avramov : L'objectif des tests de performance c'est de s'assurer que le système fonctionne de façon efficace et répond aux attentes en termes de fiabilité, de rapidité, de réactivité mais aussi dans sa capacité à résister aux charges maximales.

Ce type de test peut être réalisé sur plusieurs couches du système afin de détecter les différents problèmes liés à l'installation, la configuration, le code côté client et les goulots d'étranglement lorsqu'ils sont exposés à des charges plus élevées. 

Les tests de performance ne concernent pas seulement le temps de réponse du serveur de notre système géré. Il s'agit également de l'expérience utilisateur quand il travaille avec le logiciel. Les tests de performance côté client peuvent révéler des problèmes liés aux systèmes tiers ou des intégrations qui peuvent nuire à l'apparence générale du système.

InfoQ : Quel sont les liens entre les tests de performance et les tests de charge ?

Avramov : Les tests de charge sont en fait des tests de performance sous des charges simulées. L'objectif est de capturer des métriques de performance alors que le système est proche ou au-dessus du niveau de charge attendue.

Les tests de charge ont leurs propres sous-types comme les tests Spike, Soak et Endurance. Nous pouvons reconfigurer les paramètres de la charge appliquée au système pour simuler différents scénarios réels.

Nous pouvons effectuer des tests de performance sans même appliquer de charge. Il s'agirait de capturer les mesures de performances du serveur et des requêtes Web en cours d'exécution.

InfoQ: Quel conseils donneriez-vous aux équipes qui souhaitent améliorer la manière dont elles réalisent les tests de performance 

Avramov : On peut réaliser de nombreux tests de performance et les utiliser à bon escient si on sait comment les utiliser et ce qu'on attend de ces tests. Donc, mon conseil est de connaître l'objectif de chacun d'entre-eux, puis de s'asseoir avec l'équipe et de choisir ensemble celui qui correspond à votre situation. La mise en œuvre vient ensuite - elle peut être effectuée de différentes manières mais le travail le plus important est de les réaliser avec l'équipe.

La plupart des équipes qui font des tests de performances se concentrent uniquement sur les tests de charge. Mon conseil est de penser aux utilisateurs. Chaque point de votre graphique est un client potentiel que vous pouvez perdre en raison de mauvaises performances. Il ne faut pas non plus oublier de réaliser les tests de performances côté client lors des tests de charge.

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT