Leadership en Test : Test de Service

Bonjour et bienvenue à un nouveau chapitre de la série Leadership en Test. Cette semaine, nous allons nous intéresser aux tests de service pour les applications web. Nous allons couvrir :

• Qu’est-ce que le test de service ?
• Qu’est-ce que le test de performance ?
• Test de fiabilité/basculement 
• Test de gestion de service

Commençons.

Qu’est-ce que le test de service ?

La qualité de service qu’une application web fournit pourrait être définie comme englobant tous ses attributs tels que la fonctionnalité, la performance, la fiabilité, l’utilisabilité, la sécurité, etc. 

Cependant, pour nos besoins ici, nous isolons trois objectifs particuliers de service qui relèvent de ce que nous appellerons le « test de service ». Ces objectifs sont :

• Performance : le service doit répondre rapidement aux utilisateurs tout en supportant les charges imposées.
• Fiabilité : s’il est conçu pour être résistant aux pannes, le service doit être fiable et/ou continuer à fournir un service même en cas de défaillance.
• Gestion : le service doit pouvoir être géré, configuré ou modifié sans qu’une dégradation du service ne soit perceptible par les utilisateurs finaux. Le test de gestion — ou opérationnel — vise à démontrer que les procédures d’administration système, de gestion, de sauvegarde et de restauration fonctionnent efficacement.

Dans les trois cas, il est nécessaire de simuler une charge utilisateur pour réaliser les tests efficacement. Les objectifs de performance, de fiabilité et de gestion existent dans le contexte de clients réels utilisant le site pour faire des affaires.

La réactivité (dans ce cas, le temps qu’il faut à un nœud du système pour répondre à la demande d’un autre) d’un site est directement liée aux ressources disponibles dans l’architecture technique.

Lorsqu’il y a plus d’utilisateurs en ligne, moins de ressources techniques sont disponibles pour répondre à chaque demande et les temps de réponse se dégradent. 

Évidemment, un service faiblement sollicité est moins susceptible de tomber en panne. Une grande partie de la complexité logicielle et matérielle vise à répondre aux demandes de ressources dans l’architecture technique lorsqu’un site est fortement sollicité. 

Lorsque le site est chargé (ou en surcharge), les demandes conflictuelles de ressources doivent être gérées par divers composants de l’infrastructure, tels que les systèmes d’exploitation serveur et réseau, les systèmes de gestion de bases de données, les serveurs web, les courtiers de requêtes d’objet, les intergiciels, etc. 

En général, ces composants d’infrastructure sont plus fiables que le code applicatif sur mesure qui consomme la ressource, mais des défaillances peuvent survenir dans les deux cas :

• Les composants d’infrastructure tombent en panne car le code applicatif (en raison d’une mauvaise conception ou mise en œuvre) sollicite excessivement les ressources.
• Les composants applicatifs peuvent tomber en panne car les ressources dont ils dépendent ne sont pas toujours disponibles (dans les temps).

En simulant des charges de production typiques et inhabituelles sur une longue période, les testeurs peuvent mettre en évidence des défauts de conception ou d’implémentation du système. Une fois ces défauts corrigés, les mêmes tests permettront de démontrer la résilience du système. Les QAs peuvent exploiter des outils de test de charge pour exécuter nombre des processus définis ci-dessous.

Sur tous les services, il existe généralement plusieurs processus de gestion critiques à mettre en œuvre pour maintenir le service de manière optimale. Il est parfois possible d’arrêter un service pour effectuer la maintenance en dehors des heures d’ouverture, mais la plupart des services en ligne fonctionnent 24h/24.

La journée de travail du service ne s’arrête jamais. Inévitablement, les procédures de gestion doivent être réalisées pendant que le service est en ligne et que des utilisateurs sont connectés. Ces procédures doivent donc être testées sous charge pour garantir qu’elles n’impacteront pas négativement le service en production, autrement dit par le biais de tests de performance.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

LinkedIn

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Qu'est-ce que le test de performance ?

Les tests de performance sont un élément clé des tests de service. Ils permettent de vérifier comment un système se comporte en termes de réactivité et de stabilité sous une charge donnée. Voici un aperçu de leur fonctionnement :

• Les tests de performance consistent en une série de tests à différentes charges où le système atteint un état d’équilibre (charges et temps de réponse à des niveaux constants).
• Nous mesurons la charge et les temps de réponse pour chaque charge, simulés sur une période de 15 à 30 minutes, afin d'obtenir un nombre statistiquement significatif de mesures.
• Nous surveillons et enregistrons les signes vitaux pour chaque charge simulée. Il s'agit des différentes ressources de notre système, par exemple l'utilisation du processeur et de la mémoire, la bande passante réseau, les taux d’E/S, etc.

Nous traçons un graphique de ces différentes charges par rapport aux temps de réponse expérimentés par nos « utilisateurs virtuels ». Lorsqu'il est tracé, notre graphique ressemble à celui ci-dessous. 

À charge nulle, lorsqu'il n'y a qu'un seul utilisateur sur le système, il dispose de toutes les ressources et les temps de réponse sont rapides. Lorsque nous augmentons progressivement les charges et mesurons les temps de réponse, ils deviennent de plus en plus dégradés jusqu'à atteindre un point où le système fonctionne à pleine capacité. 

À ce stade, le temps de réponse pour nos transactions de test est théoriquement infini car l'une des ressources clés du système est entièrement utilisée et il n’est plus possible de traiter de nouvelles transactions.

À mesure que l'on augmente les charges de zéro à la charge maximale, on surveille également l’utilisation des différents types de ressources, par exemple l’utilisation du processeur du serveur, l’utilisation de la mémoire, la bande passante réseau, les verrous de base de données, etc. 

À la charge maximale, l’une de ces ressources est saturée à 100 %. Cette ressource est la ressource limitante car elle s’épuise en premier. Bien entendu, à ce stade, les temps de réponse sont devenus tellement mauvais qu'ils dépassent très probablement les seuils acceptables.

Le graphique ci-dessous montre l'utilisation/la disponibilité de plusieurs ressources tracée en fonction de la charge.

Pour augmenter la capacité de traitement ou réduire les temps de réponse d’un système, il faut effectuer l'une des actions suivantes :

• Réduire la demande sur la ressource, généralement en rendant le logiciel qui utilise la ressource plus efficace (cela est généralement de la responsabilité de l’équipe de développement).
• Optimiser l’utilisation de la ressource matérielle au sein de l’architecture technique, par exemple en configurant le SGBD pour mettre davantage de données en cache en mémoire ou en priorisant certains processus par rapport à d'autres sur le serveur applicatif.
• Rendre davantage de ressources disponibles. Généralement, cela consiste à ajouter des processeurs, de la mémoire, de la bande passante réseau, etc.

Comme vous commencez probablement à vous en rendre compte, le test de performance nécessite la collaboration d’une équipe pour aider les testeurs. Il s'agit des architectes techniques, administrateurs serveurs, administrateurs réseaux, développeurs et concepteurs/administrateurs de base de données. Ces experts techniques sont qualifiés pour analyser les statistiques générées par les outils de surveillance des ressources et juger de la meilleure façon d'ajuster l’application ou d’optimiser/mettre à niveau le système. 

Si vous êtes le testeur, à moins d’être vous-même un expert dans ces domaines, n'essayez pas de prétendre que vous pouvez interpréter ces statistiques ou prendre des décisions d’optimisation et de tuning. Impliquez ces experts dès le début du projet pour obtenir leurs conseils et leur adhésion et plus tard, pendant les tests, pour vous assurer que les goulets d’étranglement sont identifiés et résolus.

Rendez-vous dans le prochain article pour approfondir la gestion des tests de performance.

Tests de fiabilité/de basculement

Assurer la disponibilité continue d’un service est sans doute un objectif clé de votre projet. Les tests de fiabilité permettent de débusquer des défaillances rares à l’origine de pannes inattendues. Les tests de basculement permettent de vérifier que les mécanismes de basculement prévus pour les pannes anticipées fonctionnent réellement.

Test de basculement

Lorsque des sites doivent être résilients et/ou fiables, ils sont généralement conçus avec des composants systèmes fiables intégrant des fonctionnalités de redondance et de basculement qui s'activent en cas de défaillance. 

Ces fonctionnalités peuvent inclure une diversité des itinéraires réseau, plusieurs serveurs configurés en clusters, des middleware et la technologie de service distribué qui assurent la répartition de charge et le reroutage du trafic en cas de panne.

Le test de basculement vise à explorer le comportement du système dans des scénarios de panne spécifiques avant sa mise en production et implique généralement les points suivants :

• Identification des composants susceptibles de tomber en panne et de provoquer une perte de service (analyse des pannes de l'intérieur vers l'extérieur).
• Identification des dangers susceptibles de causer une panne et d'entraîner une perte de service (analyse des menaces de l'extérieur vers l'intérieur).
• Une analyse des modes de défaillance ou des scénarios qui pourraient se produire lorsque vous devez avoir confiance dans l'efficacité de la mesure de récupération.
• Un test automatisé pouvant être utilisé pour solliciter le système et explorer le comportement du système sur une longue période.
• Le même test automatisé peut aussi être utilisé pour solliciter le système à tester et surveiller le comportement du système dans des conditions de panne.

Une technique appelée "analyse par arbre de défaillances" (Fault Tree Analysis, FTA) peut vous aider à comprendre les dépendances d’un service vis-à-vis de ses composants sous-jacents. L’analyse par arbre de défaillances et les diagrammes associés représentent logiquement un système ou un service ainsi que les façons dont il peut échouer.

Le schéma simple ci-dessous montre la relation entre des événements de panne de composants de base, des événements de panne de sous-systèmes intermédiaires et l’événement de panne de service le plus élevé. Bien entendu, il est possible d'identifier plus de trois niveaux d’événements de panne.

Ces tests doivent être exécutés avec une charge automatisée afin d’explorer le comportement du système dans des situations de production et de renforcer la confiance dans les mesures de récupération conçues. Plus particulièrement, vous souhaitez savoir :

• Comment l’architecture se comporte-t-elle en situation de panne ?
• Les dispositifs d’équilibrage de charge fonctionnent-ils correctement ?
• Les capacités de basculement absorbent-elles la charge lorsqu’un composant tombe en panne ?
• La récupération automatique fonctionne-t-elle ? Les systèmes redémarrés "rattrapent-ils" ?

En fin de compte, les tests cherchent à déterminer si le service offert aux utilisateurs finaux est maintenu et si les utilisateurs remarquent effectivement la survenue de la panne.

Tests de fiabilité (ou de stabilité prolongée)

Les tests de fiabilité visent à vérifier qu’aucune défaillance ne se produit sous charge. 

La plupart des composants matériels sont suffisamment fiables pour que leur temps moyen entre deux pannes se mesure en années. Les tests de fiabilité nécessitent l’utilisation (ou la réutilisation) de tests automatisés de deux manières pour simuler :

• Des charges extrêmes sur des composants ou ressources spécifiques de l’architecture technique.
• Des périodes prolongées de charges normales (ou extrêmes) sur l’ensemble du système.

Lorsque l’on se concentre sur des composants particuliers, l’objectif est de mettre à l’épreuve le composant en le soumettant à un très grand nombre de requêtes pour qu’il remplisse sa fonction prévue. Il est souvent plus simple de tester la résistance des composants critiques isolément, en commençant par un grand nombre de demandes simples avant de procéder à un test beaucoup plus complexe sur l'ensemble de l'infrastructure. Il existe également des outils de tests de résistance spécifiquement conçus pour faciliter la tâche aux équipes qualité.

Les tests de stabilité prolongée (soak tests) soumettent un système à une charge prolongée pendant, par exemple, 24, 48 heures ou plus, afin de trouver (le plus souvent) des problèmes insidieux. En général, ces défaillances ne se manifestent qu’après un usage étendu.

Le test automatisé ne doit pas forcément porter la charge à des extrêmes (les tests de résistance couvrent ce cas). Mais ce qui nous intéresse particulièrement, c’est la capacité du système à supporter une exécution continue d’une grande variété de transactions de test, afin de détecter d’éventuelles fuites de mémoire, blocages, ou conditions de concurrence subtiles.

Tests de gestion des services

Pour finir, un mot sur les tests de gestion des services. 

Lorsque le service est déployé en production, il doit être géré. Garantir la disponibilité d’un service passe par sa surveillance, sa mise à jour, sa sauvegarde et une intervention rapide en cas de problème. 

Les procédures utilisées par les responsables de service pour effectuer les mises à jour, sauvegardes, déploiements et restaurations après défaillance sont essentielles pour assurer un service fiable. Elles nécessitent donc des tests, en particulier si le service doit évoluer rapidement après son déploiement.

Les problèmes spécifiques à traiter sont :

• Les procédures n’atteignent pas l’effet recherché.
• Les procédures sont inapplicables ou inutilisables.
• Les procédures perturbent le service en ligne.

Les tests devraient, dans la mesure du possible, être réalisés de la façon la plus réaliste possible.

Quelques pistes de réflexion

Certains systèmes sont sujets à des charges extrêmes lors de certains événements. Par exemple, un commerce en ligne peut s’attendre à des pics de trafic juste après la diffusion de ses offres à la télévision, ou un site d’information national peut être submergé lors d’une grande actualité.

Pensez à un système que vous connaissez bien et qui a été affecté par des incidents imprévus dans votre activité ou dans l’actualité nationale.

Quels incidents ou événements pourraient déclencher des charges excessives dans votre système ?

Pouvez-vous (ou pourriez-vous) extraire des données à partir des journaux du système qui vous donnent le nombre de transactions exécutées ? Pouvez-vous extrapoler cet événement pour prévoir un événement critique qui ne se produirait qu'une fois tous les 100 ans, voire une fois tous les 1000 ans ?

Quelles mesures pourriez-vous appliquer (ou avez-vous déjà appliqué) pour réduire la probabilité des pics, leur ampleur, ou pour les éliminer totalement ?

Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque les nouvelles parties de la série sont publiées. Ces articles sont des extraits du cours Leadership In Test de Paul que nous vous recommandons vivement pour approfondir ce sujet et bien d'autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour économiser 60 $ sur le prix total du cours !

Lecture suggérée : 10 MEILLEURS OUTILS DE GESTION DE TEST OPEN SOURCE