Instructions: Modèle d'analyse de la charge de travail
Le modèle d'analyse de la charge de travail identifie les variables qui affectent la performance du système et la façon de mesurer leur effet. Ces instructions expliquent comment en développer un.
Relations
Description principale

Présentation

La qualité du logiciel est évaluée sous différentes dimensions, dont la fiabilité, la fonction et la performance (voir Concept : Dimensions de la qualité). Le modèle d'analyse de la charge de travail (voir Produit : Modèle d'analyse de la charge de travail) est créé pour identifier et définir les différentes variables qui affectent ou influencent la performance d'une application ou d'un système et les mesures requises pour évaluer la performance. Les profils de charge de travail qui constituent le modèle représentent des candidats aux conditions à simuler par rapport aux éléments de test cible selon une ou plusieurs configurations d'environnement de test. Le modèle d'analyse de la charge de travail est utilisé pour les rôles suivants :

  • l'analyste de test (voir Rôle : Analyste de test) utilise le modèle d'analyse de la charge de travail pour identifier des idées de test et définir des cas de test pour différents tests
  • le concepteur de test (voir Rôle : Concepteur de test) utilise le modèle d'analyse de la charge de travail pour définir une approche de test appropriée et identifier les besoins de testabilité pour les différents tests
  • le testeur (voir Rôle : Testeur) utilise le modèle d'analyse de la charge de travail pour mieux comprendre les objectifs du test afin de mettre en place, d'exécuter et d'analyser son exécution correctement
  • le représentant des utilisateurs (voir Rôle : Intervenant) utilise le modèle d'analyse de la charge de travail pour évaluer la justesse de la charge de travail et les tests requis pour évaluer de façon efficace le comportement des systèmes par rapport à ce modèle d'analyse de la charge de travail

Les informations que contient le modèle d'analyse de la charge de travail insistent sur les caractéristiques et les attributs dans les domaines principaux suivants :

  • Scénarios de cas d'utilisation (ou Instances, voir Produit : Cas d'utilisation) à exécuter et évaluer lors des tests
  • Acteurs (voir Produit : Acteur) à simuler/émuler lors des tests
  • Profil de la charge de travail - représentant le nombre et le type d'instances d'acteur simultanées, de scénarios de cas d'utilisation exécutés par ces instances d'acteurs et des réponses en ligne ou du rendement associé à chaque scénario de cas d'utilisation.
  • Configuration de l'environnement de test (réel, simulé ou émulé) à utiliser dans l'exécution et l'évaluation des tests (voir Produit : Configuration de l'environnement de test. Voir aussi Produit : Document sur l'architecture logicielle, vue du déploiement, qui doit constituer la base de la configuration de l'environnement de test)

Des tests doivent être envisagés pour mesurer et évaluer les caractéristiques et comportements de la cible de test lors de son fonctionnement selon diverses charges de travail. Une conception, une mise en place et une exécution réussies de ces tests nécessite d'identifier des données réalistes et exceptionnelles pour ces profils de charge de travail.

Cas d'utilisation et attributs de cas d'utilisation

Deux aspects des cas d'utilisation sont examinés pour la sélection de scénarios pour ce type de test :

Cas d'utilisation essentiels

Les scénarios de cas d'utilisation qui sont mis en place dans la cible de test ne sont peut-être pas tous nécessaires pour ces tests. Les cas d'utilisation essentiels contiennent les scénarios de cas d'utilisation qui feront l'objet du test - leur comportement sera mesuré et évalué.

Pour identifier les cas d'utilisation essentiels, identifiez les scénarios de cas d'utilisation qui satisfont un ou plusieurs des critères suivants :

  • nécessitent une mesure et une évaluation en fonction du profil de la charge de travail
  • sont fréquemment exécutés par un ou plusieurs utilisateurs finaux (instances d'acteurs)
  • représentent un pourcentage élevé de l'utilisation du système
  • utilisent une part significative des ressources du système

Faites la liste des scénarios de cas d'utilisation à inclure dans le test. Une fois que ceux-ci sont identifiés, le flux de cas d'événements des cas d'utilisation doit être examiné. Commencez à identifier la séquence d'événements spécifique entre l'acteur (type) et le système lorsque le scénario de cas d'utilisation est exécuté.

De plus, identifiez (ou vérifiez) les informations suivantes :

  • Les conditions préalables pour les cas d'utilisation, comme par exemple l'état des données (quelles données doivent/ne doivent pas exister) et l'état de la cible de test
  • Les données qui doivent être constantes (identiques) ou doivent différer d'un scénario de cas d'utilisation au suivant
  • La relation entre le cas d'utilisation et les autres cas d'utilisation, comme par exemple la séquence dans laquelle les cas d'utilisation doivent être effectués.
  • La fréquence d'exécution du scénario de cas d'utilisation, y compris des caractéristiques comme le nombre d'instances simultanées du cas d'utilisation et le pourcentage de la charge totale que chaque scénario place sur le système.

Cas d'utilisation significatifs

Contrairement aux scénarios des cas d'utilisation essentiels, qui sont l'objet principal du test, les scénarios des cas d'utilisation significatifs sont ceux qui peuvent influencer les comportements de performance des scénarios des cas d'utilisation essentiels. Les scénarios de cas d'utilisation significatifs comprennent ceux qui satisfont un ou plusieurs des critères suivants :

  • ils doivent être exécutés avant ou après l'exécution d'un cas d'utilisation essentiel (une condition préalable ou une postcondition dépendante)
  • ils sont fréquemment exécutés par une ou plusieurs instances d'acteurs
  • ils représentent un pourcentage élevé de l'utilisation du système
  • ils nécessitent des ressources importantes du système
  • ils seront exécutés régulièrement sur le système déployé pendant l'exécution des scénarios de cas d'utilisation essentiels, comme par exemple la messagerie électronique ou l'impression en arrière-plan

Pendant que les scénarios de cas d'utilisation significatifs sont identifiés et listés, examinez le flux d'événements de cas d'utilisation et les informations supplémentaires tel qu'effectué ci-dessus pour les scénarios de cas d'utilisation essentiels.

Acteurs et attributs d'acteur

Les tests de performance réussis nécessitent l'identification non seulement des acteurs qui exécutent les scénarios de cas d'utilisation essentiels et significatifs, mais doivent également simuler/émuler le comportement des acteurs. Ainsi, l'instance d'un acteur peut agir différemment avec la cible de test (réaction plus lente aux messages, saisie de différentes valeurs de données, etc.) tout en exécutant le même scénario de cas d'utilisation qu'une autre instance de cet acteur. Examinez les cas d'utilisation simples ci-dessous :

Diagramme décrit dans la légende.

Acteurs et cas d'utilisation d'un système de guichet automatique.

La première instance de l'acteur "Client" qui exécute un scénario de cas d'utilisation peut être un utilisateur expérimenté de guichet automatique, alors qu'une autre instance de l'acteur "Client" peut être inexpérimentée. Le Client expérimenté navigue rapidement dans l'interface utilisateur du guichet automatique et passe moins de temps à lire chaque message et appuie sur les boutons par automatisme. Cependant, le Client inexpérimenté lit chaque message et prend plus de temps à interpréter les informations avant de réagir. Des profils de charge de travail réalistes reflètent cette différence afin d'assurer une évaluation précise des comportements de la cible de test.

Commencez par identifier les acteurs pour chaque scénario de cas d'utilisation identifié ci-dessus. Puis identifiez les différents profils d'acteurs qui peuvent exécuter chaque scénario de cas d'utilisation. Dans l'exemple du guichet automatique ci-dessus, nous pouvons avoir les stéréotypes d'acteurs suivants :

  • Utilisateur de guichet automatique expérimenté
  • Utilisateur de guichet automatique inexpérimenté
  • Le compte de l'utilisateur du guichet automatique est "à l'intérieur" du réseau bancaire du guichet automatique (le compte de l'utilisateur se trouve dans la banque à laquelle appartient le guichet automatique)
  • Le compte de l'utilisateur du guichet automatique est à l'extérieur du réseau bancaire du guichet automatique (banque concurrente)

Pour chaque profil d'acteur, identifiez les différents attributs et leurs valeurs comme par exemple :

  • Temps de réflexion - le temps que met un acteur à réagir aux messages individuels d'une cible de test
  • Vitesse de frappe - la vitesse à laquelle l'acteur agit avec l'interface
  • Vitesse de demande - la vitesse à laquelle l'acteur effectue des demandes de la cible de test
  • Facteur de répétition - le nombre de fois qu'un cas d'utilisation ou une demande est répété dans une séquence
  • Méthode d'interaction - la méthode d'interaction utilisée par l'acteur, comme par exemple l'utilisation du clavier pour saisir des valeurs, des tabulations pour passer à un autre champ, des raccourcis-clavier, etc., ou l'utilisation de la souris pour "pointer et cliquer", "couper et coller", etc.

De plus, pour chaque profil d'acteur, identifiez le profil de la charge de travail, en indiquant tous les scénarios de cas d'utilisation qu'il exécute et le pourcentage de temps ou la proportion d'effort donné par l'acteur pour l'exécution de ces scénarios. L'identification de ces informations est utilisée dans l'identification et la création d'une charge réaliste (voir Charge et attributs de charge ci-dessous).

Attributs et variables du système Haut de la page

Les attributs et variables spécifiques de la configuration de l'environnement de test qui identifient uniquement l'environnement doivent également être identifiés, car ces attributs influencent aussi la mesure et l'évaluation du comportement. Ces attributs comprennent :

  • Le matériel physique (vitesse de l'UC, mémoire, mémoire cache du disque dur, etc.)
  • L'architecture de déploiement (nombre de serveurs, distribution de traitement, etc.)
  • Les attributs du réseau
  • D'autres logiciels (et cas d'utilisation) qui peuvent être installés et exécutés simultanément sur la cible de test

Identifiez et listez les attributs et variables du système dont l'inclusion doit être envisagée dans les tests. Ces informations peuvent venir de plusieurs sources, dont :

Profils de charge de travail Haut de la page

Tel qu'indiqué précédemment, la charge de travail est un facteur important qui influence le comportement d'une cible de test. L'identification précise du profil de charge de travail qui sera utilisé pour évaluer le comportement des cibles est essentielle. En général, les tests qui concernent la charge de travail sont exécutés plusieurs fois en utilisant différents profils de charge de travail, chacun d'eux représentant une variante des attributs décrits ci-dessous :

  • Le nombre d'instances d'acteur simultanées qui agissent avec la cible de test
  • Le profil des acteurs qui agissent avec la cible de test
  • Les scénarios de cas d'utilisation exécutés par chaque instance d'acteur
  • La fréquence de chaque scénario de cas d'utilisation essentiel exécuté et la fréquence de répétition

Pour chaque profil de charge de travail utilisé pour évaluer la performance de la cible de test, identifiez les valeurs de chacune des variables ci-dessus. Les valeurs utilisées pour chaque variable dans les différentes charges peuvent être dérivées en observant ou en interrogeant les acteurs ou à partir du modèle de cas d'utilisation métier s'il y en a de disponible. Il est courant qu'un ou plusieurs des profils de charge de travail suivants soient définis comme étant :

  • Optimal - un profil de charge de travail qui reflète les meilleures conditions de déploiement, telles qu'un nombre minimal d'instances d'acteur qui agissent avec le système, exécutent uniquement les scénarios de cas d'utilisation essentiels, avec un minimum de logiciel et de charge de travail supplémentaire en cours d'exécution lors du test.
  • Moyen (également appelé Normal) - un profil de charge de travail qui reflète les conditions d'utilisation moyennes réelles ou anticipées.
  • Périodes de pointe instantanées - un profil de charge de travail qui reflète des conditions d'utilisation élevée instantanée réelles ou anticipées, qui se produisent pendant de courtes périodes lors du fonctionnement normal.
  • Période de pointe - un profil de charge de travail qui reflète des conditions d'utilisation élevée réelles ou anticipées, telles qu'un nombre maximal d'instances d'acteurs, qui exécutent des volumes importants de scénarios de cas d'utilisation, avec de nombreux logiciels et charges de travail supplémentaires en cours d'exécution lors du test.

Lorsque le test de la charge de travail comprend le test sous contraintes (voir Concept : Test de la performance et Technique : Types de test), plusieurs charges supplémentaires doivent être identifiées, chacune ciblant des aspects spécifiques du système dans des états anormaux ou imprévus au-delà de la capacité normale prévue du système déployé.

Mesures et critères de performance Haut de la page

Un test réussi de la charge de travail peut uniquement être effectué si les tests sont mesurés et les comportements de la charge de travail évalués. Afin d'identifier les mesures et les critères de la charge de travail, les facteurs suivants doivent être examinés :

  • Quelles mesures vont être effectuées ?
  • Où / quels sont les points de mesure essentiels dans l'exécution de la cible de test / du cas d'utilisation.
  • Quels sont les critères à utiliser pour déterminer un comportement de performance acceptable ?

Mesures de la performance

Différentes mesures peuvent être effectuées lors de l'exécution du test. Identifiez les mesures significatives à effectuer et justifiez leur importance.

Les comportements de performance les plus communément surveillés ou capturés sont énumérés ci-dessous :

  • Etat ou statut du script de test - une description graphique de l'état, du statut ou de l'évolution actuels de l'exécution du test
  • Temps de réponse / Rendement - mesure (ou calcul) des temps de réponse ou du rendement (en général indiqué en transactions par seconde).
  • Traçabilité - capture des messages / conversations entre l'acteur (script de test) et la cible de test, ou le flux de données et/ou le flux de processus lors de l'exécution.

Voir Technique : mesures de test clés pour en savoir plus

Points de mesure essentiels de la performance

Dans la section Cas d'utilisation et attributs de cas d'utilisation ci-dessous, il a été noté que tous les cas d'utilisation et leurs scénarios sont exécutés pour le test des performances. De même, les mesures de performance ne sont pas toutes effectuées pour chaque scénario de cas d'utilisation exécuté. En général, seuls des scénarios de cas d'utilisation spécifiques sont ciblés pour la mesure, ou il peut y avoir une séquence d'événements spécifique au sein d'un scénario de cas d'utilisation spécifique qui sera mesuré pour évaluer le comportement des performances. Veillez à bien sélectionner les "points" de début et de fin les plus significatifs pour la mesure des comportements des performances. Les plus significatifs sont en général ceux qui contiennent les séquences d'événements les plus visibles ou ceux que nous pouvons affecter directement par des modifications de logiciel ou de matériel.

Par exemple, dans le cas d'utilisation Guichet automatique - Retrait d'espèces identifié ci-dessus, nous pouvons mesurer les caractéristiques de performance de la totalité de l'instance du cas d'utilisation, du point où l'Acteur initie le retrait au point auquel le cas d'utilisation est arrêté - autrement dit, l'Acteur récupère sa carte bancaire et le guichet automatique est désormais prêt à accepter une autre carte, tel qu'illustré par la ligne en noir "Temps total écoulé" dans le diagramme ci-dessous :

Le diagramme est détaillé dans le contenu.

Notez cependant, qu'il y a de nombreuses séquences d'événements qui contribuent au temps total écoulé, certaines que nous pouvons contrôler (comme par exemple lire les informations de la carte, vérifier le type de carte, initier la communication avec le système bancaire, etc., les éléments B, D et E ci-dessus), mais d'autres séquences que nous ne contrôlons pas (comme par exemple la saisie du code PIN par l'acteur ou la lecture des messages avant la saisie du montant du retrait, les éléments A, C et F). Dans l'exemple ci-dessus, en plus de mesurer le temps total écoulé, nous mesurerions les temps de réponse pour les séquences B, D et E, puisque ces événements sont les temps de réponse les plus visibles pour l'acteur (et nous pouvons les affecter via le logiciel / matériel de déploiement).

Critères de mesure des performances

Une fois que les mesures de performance et les points de mesure essentiels ont été identifiés, examinez les critères de performance. Les critères de performance sont indiqués dans les Spécifications supplémentaires (voir Produit : Spécifications supplémentaires). Si nécessaire, relisez les critères.

Voici quelques critères qui sont souvent utilisés pour mesurer la performance :

  • temps de réponse (également appelé réponse en ligne)
  • débit
  • centiles de réponse

Le temps de réponse en ligne, mesuré en secondes, ou le débit des transactions, mesuré par le nombre de transactions (ou messages) traités, est le critère principal.

Par exemple, si l'on prend le cas d'utilisation Retrait d'espèces, les critères indiqués sont : "les événements B, D et E (voir le diagramme ci-dessus) doivent se produire chacun en moins de 3 secondes (pour un total combiné de 9 secondes)". Si lors du test, on note qu'un des événements identifiés par B, D ou E met plus longtemps que les 3 secondes établies par les critères, on notera un échec.

Les mesures de centiles sont combinées aux temps de réponse et/ou taux de rendement et sont utilisées afin d'"ignorer statistiquement" les mesures qui ne satisfont pas les critères indiqués. Par exemple, les critères de performance du cas d'utilisation indique désormais "pour le 90e centile, les événements B, D et E doivent se produire en moins de 3 secondes chacun ...". Lors de l'exécution du test, si l'on mesure que 90 pour cent de toutes les mesures de performance se produisent dans les critères indiqués, aucun échec ne sera noté.