Glossaire · Conception des tests
Test de transition d'états
En anglais : State transition testing
Également appelé : diagramme de transition d'états, table de transition d'états, test basé sur les états, state transition diagram
Définition
Technique de conception de tests qui modélise un système en états et en événements qui le font passer de l'un à l'autre, puis teste les transitions valides et invalides.
Le test de transition d’états s’applique quand la réponse du système dépend de ce qui s’est passé auparavant, et pas seulement de l’entrée courante. Vous modélisez le système comme un ensemble d’états, les événements qui provoquent les transitions entre eux, et les éventuelles actions ou conditions (gardes) associées à chaque transition. Les tests couvrent ensuite les transitions valides et, tout aussi important, vérifient que les transitions invalides sont rejetées.
Exemple : verrouillage à la connexion
Un compte se verrouille après trois mots de passe erronés consécutifs, et une connexion réussie remet le compteur à zéro.
États : Active (0 failures), 1 failure, 2 failures, Locked, Logged in.
| État courant | Événement | État suivant |
|---|---|---|
| Active (0) | Mauvais mot de passe | 1 failure |
| Active (0) | Bon mot de passe | Logged in |
| 1 failure | Mauvais mot de passe | 2 failures |
| 1 failure | Bon mot de passe | Logged in (compteur remis à zéro) |
| 2 failures | Mauvais mot de passe | Locked |
| 2 failures | Bon mot de passe | Logged in (compteur remis à zéro) |
| Locked | Bon mot de passe | Locked (rejeté) |
| Locked | Déverrouillage par un admin | Active (0) |
Les tests qui en découlent :
- Chaque transition valide au moins une fois (couverture 0-switch) : mauvais, mauvais, mauvais mène à Locked ; mauvais, bon mène à Logged in.
- Les événements invalides ou inattendus : le bon mot de passe sur un compte verrouillé doit toujours être rejeté. C’est là que se cachent les bugs de sécurité.
- Les séquences : mauvais, bon, puis déconnexion et mauvais, mauvais. Le compteur est-il vraiment remis à zéro, ou le compte se verrouille-t-il au deuxième échec ? Tester des paires de transitions consécutives s’appelle la couverture 1-switch.
Où cela s’applique
Tout ce qui a un cycle de vie : commandes (créée, payée, expédiée, livrée, annulée, remboursée), workflows de bugs, abonnements, validations de documents, états de paiement, lecteurs multimédias et assistants (wizards) d’interface. Les questions à se poser pour chaque état : quels événements sont autorisés ici, qu’advient-il de ceux qui ne le sont pas, et l’utilisateur peut-il atteindre cet état par un chemin inattendu, comme le bouton Précédent du navigateur ou un appel d’API direct ?
Erreurs fréquentes
- Ne tester que le chemin nominal. Créée, payée, expédiée n’est qu’un chemin. Une commande peut-elle être annulée après expédition ? Remboursée deux fois ?
- Ne tester que par l’interface. L’interface peut masquer le bouton Annuler, mais l’API peut toujours accepter la requête. Testez aussi les transitions au niveau de l’API.
- Oublier la table des états. Le diagramme montre ce qui doit se passer ; la table complète de chaque état croisé avec chaque événement révèle les trous où le comportement n’est pas défini.