Dans ce nouvel article, je vous propose d’aborder une technique très efficace lorsque le logiciel à tester représente un automate fini. Autrement dit, votre logiciel peut être décrit par des états et des événements qui vont permettre de changer d’état.

PRÉSENTATION DE LA TECHNIQUE

DÉFINITION ISTQB

Le test de transition d’état permet de tester la capacité d’un système à entrer dans des états définis et à en sortir par des transitions valides et invalides. Des événements particuliers font passer le système d’un état à un autre et déclenchent certaines actions.

Les événements peuvent être associés à des conditions qui influencent le chemin de transition à prendre. Par exemple, l’événement correspondant à une connexion avec un nom d’utilisateur et un mot de passe valides donnera lieu à une transition

différente de celle déclenchée par une connexion avec un mauvais mot de passe.

Les transitions d’état sont suivies soit dans un diagramme de transition d’état montrant toutes les transitions valides entre les états, de façon graphique ; soit avec une table d’états montrant toutes les transitions possibles, valides ou invalides.

Quelques points de vocabulaire à préciser ici entre  l’ISTQB et la littérature classique:

• « diagramme de transition d’état » correspond à « diagramme états-transitions »
• « table d’états » correspond à « table de transition d’état »

APPLICATION

Cette technique peut s’appliquer à tous les niveaux de test.

Elle est particulièrement conseillée dans les situations suivantes:

• logiciels embarqués
• logiciels web (chaque page peut être vu comme un état)
• logiciels transactionnels
• logiciels de contrôle (feux de signalisation par exemple)
• globalement tout logiciel pouvant être modélisé en diagramme de transition d’état.

LIMITATIONS/DIFFICULTÉS/RISQUES

Le plus difficile dans cette technique est d’identifier la liste des états et transitions à partir de la spécification. En oublier sera forcément source d’erreur dans la génération du graphe et cela se traduira dans des oublis de cas de test pertinents pour tester le logiciel.

L’autre difficulté est de définir le niveau de couverture qu’il faut atteindre pour satisfaire le risque. En effet, plusieurs niveaux de couverture peuvent être définis et chaque niveau permettra de découvrir des défauts différents.

COUVERTURE

Comme précisé précédemment, il y a plusieurs niveaux de couverture possibles.

L’ISTQB définit que le degré minimum acceptable est d’avoir traversé au moins une fois tous les états et toutes les transitions.

Plus globalement, nous parlerons de couverture d’aiguillage-N (N-switch en anglais). Par exemple, une couverture d’aiguillage-0 signifie que toute séquence valide d’une seule transition a été testée au moins une fois. Pour une couverture d’aiguillage-1 signifie que toute séquence valide deux transitions successives a été testée au moins une fois. En conclusion, une couverture d’aiguillage-N signifie que toute séquence valide de N+1 transitions successives a été testée au moins une fois.

L’ISTQB défini aussi la « couverture Aller-Retour » qui correspond aux situations dans lesquelles les séquences de transitions forment des boucles. 100% de « couverture Aller-Retour » est obtenu lorsque toutes les boucles partant d’un état et revenant vers ce même état ont été testées. Cela doit être testé pour tous les états inclus dans des boucles.

Enfin, la couverture peut aussi être enrichie avec les transitions invalides. Une transition invalide est une transition s’exerçant sur un état alors que cela ne devrait pas arriver. Sur un diagramme états-transitions, elle n’apparaissent pas.

TYPE DE DÉFAUT

Les principaux défauts sont:

• Omission de la prise en compte d’une transition dans un état donné.
• Prise en compte d’une transition invalide.
• Mauvais traitement d’une transition selon son événement et mauvaise action déclenchée.
• Mauvais traitement dans un état courant à cause de traitements dans les états précédents.
• Contradiction entre les transitions et états

Dériver le diagramme états-transition et la table de transitions d’états depuis la spécification permet de critiquer cette dernière et s’assurer que la machine à état à développer sera la bonne.

MISE EN ŒUVRE

Un distributeur de boissons est un très bon exemple pour une telle technique.

Prenons le distributeur suivant (volontairement simple):

• le distributeur permet au client de choisir parmi plusieurs boissons en tapant un chiffre.
• le distributeur accepte uniquement des pièces de monnaies.
• le distributeur prend en compte les pièces de monnaies uniquement avant et après la sélection d’une boisson par l’utilisateur.
• lorsque le montant de la boisson est atteint ou dépassé, le distributeur procède à la préparation de la boisson puis rend la monnaie supplémentaire.

voici une proposition de diagramme d’état-transition pour cet énoncé:

Avant de poursuivre, quelques explications pour ceux dont les diagrammes ne sont pas leur quotidien:

La technique ne s’intéresse qu’aux états et transitions. Je vous ai mis quelques actions afin de rendre le diagramme plus réaliste et montré que ce dernier peut être complexe.

Nous allons chercher à obtenir  une couverture d’aiguillage-0. Rappelez-vous que cela signifie que toute séquence valide d’une seule transition a été testée au moins une fois.

Pour cela, deux possibilités:

• soit à partir du graphe en créant des cas de test permettant de couvrir chaque transition partant de chaque état en prenant soin de considérer chaque condition d’une transition conditionnelle de manière unique.
• soit en faisant la table de transition d’état et créer des cas de test pour couvrir chaque cases non vides.

La table de transition pour le graphe précédent est celle-ci:

Nous avons 8 cases que nous pouvons couvrir avec 3 cas de test:

• test 1: E1 –(T1)–> E2 –(T1)–> E2 –(T2[somme>=prix])–>E4 –(T3)–> E1
• test 2 : E1 –(T1)–> E2 –(T2[somme<prix])–> E3 –(T1[somme>=prix])–> E4 –(T3)–> E1
• test 3 : E1 –(T2)–>E3 –(T1[somme<prix])–> E3 –(T1[somme>=prix])–> E4 –(T3)–> E1

Notre distributeur et graphe étant sans état de fin, un seul test pourrait suffire pour tout couvrir. Néanmoins, cela ne serait pas forcément le plus pertinent pour assurer la maintenabilité du patrimoine de test. Ceci est vrai dans l’objectif d’avoir une couverture d’aiguillage 0.

Si l’objectif est d’avoir 100% de couverture d’aller-retour, alors il serait pertinent d’envisager les tests suivants:

• enchaîner les test 1 et test 2 précédents
• enchaîner les test 1 et test 3 précédents
• enchaîner les test 2 et test 1 précédents
• enchaîner les test 2 et test 3 précédents
• enchaîner les test 3 et test 1 précédents
• enchaîner les test 3 et test 2 précédents

De plus, nous pouvons enrichir la couverture avec les transitions invalides.

Mais c’est quoi une transition invalide? C’est une transition qui ne devrait pas arriver sur un état. Sur un graphe, elles ne sont pas représentées. Dans la table de transition d’état, elles correspondent aux cases vides.

Ces transitions invalides doivent particulièrement nous intéresser car elles peuvent révéler des besoins de conception de logiciel (voir système) particuliers. Par exemple:

• notre distributeur doit assurer de ne jamais envoyer l’événement « distribution produit » dans les états E1, E2 et E3.
• notre distributeur doit empêcher l’utilisateur de mettre des pièces pendant la préparation du produit.

Enfin, si maintenant, on souhaite atteindre une couverture de 100% d’aiguillage-1. Il faut dans ce cas poser dans un tableau la liste des séquences de 2 transitions valides successives. Dans notre exemple, cela donne:

1. E1 –> E2 –> E2
2. E1 –> E2 –> E4
3. E1 –> E2 –> E3
4. E1 –> E3 –> E3
5. E1 –> E3 –> E4
6. E2 –> E4 –> E1
7. E2 –> E3 –> E4
8. E2 –> E3 –> E3
9. E3 –> E4 –> E1
10. E3 –> E3 –> E4
11. E4 –> E1 –> E2
12. E4 –> E1 –> E3

Voici une proposition de cas de test qui permettrait d’atteindre cette couverture:

• test 1:  E1 –> E2 –> E2 –> E4 –> E1 –> E3 –> E4 –> E1 qui couvre les séquences 1, 6, 7, 9 et 12.
• test 2 : E1 –> E2 –> E4 –> E1 –> E2 –> E3 –> E3 –> E4 –> E1 qui couvre les séquences 2, 3, 8, 9 et 11
• test 3 : E1 –> E3 –> E3 –> F4 –> E1 –> E3 –> F4 –> E1 qui couvre les séquences 4, 5, 9, 10 et 12

A partir d’un graphe ou de la table, nous pouvons aussi voir des omissions dans les états et transitions pouvant rendre notre distributeur peu robuste:

• l’utilisateur ne peut annuler sa demande: cas où il n’a pas assez de monnaie pour payer. Cela soulèvera un problème à minima moral, voire juridique de conserver son argent sans lui rendre le service équivalent.
• l’utilisateur peut abandonner sa demande après avoir sélectionné le prix et s’en va. Le distributeur reste bloqué en attente de paiement jusqu’à ce qu’un autre utilisateur ait envie du même  produit de l’utilisateur précédent.

Il va de soi qu’il faudra surement améliorer notre distributeur car il y a un risque qu’aucun client ne l’utilise.

CONCLUSION

Cette technique sera d’une grande utilité pour tester des logiciels qui peuvent se modéliser sous forme de machine à états. Toutefois, la modélisation sous forme de graphe et la table de transition d’état peuvent être complexe à produire.

Il convient d’essayer de simplifier les graphes et ainsi la table pour permettre de créer des tests pertinents et maintenables.

SOURCES ET REMERCIEMENTS

Le syllabus ISTQB niveau avancé Test Analyste traduit en français par le CFTL

Le glossaire ISTQB traduit en français par le CFTL

La norme BS-7925-2  « Software component testing standard »

Merci à Marc Hage Chahine pour sa relecture.