Ces instructions montrent comment identifier des idées de
test à partir de diagrammes d'état-transition et d'autres structures de conception principalement composées de
noeuds connectés entre eux par des arcs et illustrant une partie des flux de contrôle possibles d'un programme.
L'objectif principal de ce test est de traverser chaque arc d'une certaine manière. Si vous-même n'êtes jamais
intervenu sur un arc, comment envisager que l'opération fonctionnera quand agit un client ?
Prenez ce diagramme d'état-transition :
Fig.1 : diagramme d'état-transition chauffage, ventilation et climatisation
Voici une première liste d'idées de test :
-
L'état Inactif reçoit l'événement Trop chaud
-
L'état Inactif reçoit l'événement Trop froid
-
L'état Refroidissement/Marche reçoit l'événement Compresseur en fonctionnement
-
L'état Refroidissement/Marche reçoit l'événement Ventilateur en fonctionnement
-
L'état Refroidissement/Marche reçoit l'événement OK
-
L'état Refroidissement/Marche reçoit l'événement Echec
-
L'état Echec reçoit l'événement Erreur supprimée
-
L'état Chauffage reçoit l'événement OK
-
L'état Chauffage reçoit l'événement Echec
Toutes ces idées de test peuvent être appliquées dans un même test ; vous pouvez aussi créer plusieurs tests
rassemblant chacun quelques idées. Comme pour toute conception de test, tentez de trouver l'équilibre entre la facilité
d'implémentation de plusieurs tests simples et le pouvoir d'identification d'incidents de tests complexes. (Voir "Conception de tests à l'aide de la liste" à la page Concept : Liste d'idées de test.) Si vous disposez de scénarios de cas d'utilisation
décrivant certaines procédures à l'intérieur du diagramme d'état-transition, vous devez accorder la priorité à ces
tests.
Dans tous les cas, les tests doivent vérifier que toutes les actions requises par le diagramme d'état-transition ont
lieu. Par exemple, l'alarme est-elle déclenchée dès que l'état Echec est atteint, puis s'arrête quand cet état n'est
plus actif ?
Le test doit aussi vérifier que la transition mène à l'état correct suivant. Il peut s'agir d'un problème délicat
lorsque les états sont invisibles de l'extérieur. La seule façon de détecter un état incorrect est d'insérer une
séquence d'événements conduisant à la sortie incorrecte. Plus précisément, vous devez établir une séquence d'événements
dont les résultats visibles de l'extérieur pour l'état correct sont différents de ceux que la même séquence
donnerait à partir de chaque état incorrect possible.
Dans l'exemple ci-dessus, comment savoir que l'événement Erreur supprimée dans l'état Echec a correctement mené à
l'état Inactif, au lieu de rester à l'état Echec ? Vous devez croire que l'arrêt de l'alarme indique que la transition
a été réalisée ; toutefois, il peut être préférable de vous en assurer en abaissant suffisamment la température de
façon à déclencher le chauffage ou en l'augmentant assez pour activer le refroidissement. Si quelque chose se produit,
vous avez plus la garantie que la transition était correcte. Si rien ne se passe en revanche, il est probable que
l'appareil est resté dans l'état Echec.
Le simple fait de déterminer si l'état obtenu est correct complique la conception du test. Il est souvent préférable de
rendre la machine d'état explicite et ses états visibles pour les tests.
Autres constructions de diagrammes d'état-transition
Les diagrammes d'état-transition se composent de plusieurs arcs et flèches. Ci-après la liste des constructions de
diagrammes d'état-transition et de leur incidence sur la liste d'idées.
Actions d'événement, actions d'entrée et sorties
Elles ne génèrent pas en soi des idées de test. Les tests doivent plutôt vérifier que les actions se déroulent comme
indiqué. Si ces actions correspondent à des programmes importants, ces derniers doivent faire l'objet de tests. Les
idées de test pour ces programmes doivent être associées à celles issues du diagramme d'état-transition, mais il sera
probablement plus simple de les gérer séparément. Prenez votre décision en fonction de l'effort supposé et de votre
crainte d'interactions entre des événements. Si une action déterminée sur un arc ne peut pas partager des données avec
une action sur un autre arc, il n'y a aucune raison d'exécuter ces deux actions dans le même test (contrairement à ce
que vous feriez si ces actions appartenaient au même chemin dans un test du diagramme d'état-transition).
Conditions de garde
Les conditions de garde sont des expressions booléennes. Les idées de test pour les conditions de garde sont créées
comme décrit dans Instructions pour le produit : Idées de test pour des expressions booléennes et des
conditions frontière.
Dans l'exemple ci-dessus, la transition Trop froid de l'état Inactif est conservée avec [délai de redémarrage >= 5
min]. Ceci conduit à deux idées de test distinctes :
-
L'état Inactif reçoit l'événement Trop froid lorsque le délai de redémarrage est de cinq minutes (transition
effectuée).
-
L'état Inactif reçoit l'événement Trop froid lorsque le délai de redémarrage est inférieur à cinq minutes
(transition bloquée).
Dans les deux cas, tout test utilisant l'idée de test doit vérifier que l'état correct est atteint.
Transitions internes
Une transition interne ajoute le même genre d'idées à une liste d'idées de test comme le fait une transition externe.
L'état suivant est simplement le même que celui d'origine. Il serait prudent de configurer les tests de façon à ce que
les actions d'entrée et les sorties de l'état entraînent un effet observable si elles sont lancées de façon incorrecte.
Etats imbriqués
Lors de l'élaboration de tests, définissez-les de façon à ce que les événements entrants et sortants de l'état
composite aient des effets observables. Vous voulez en effet constater s'ils sont ignorés.
Sous-états simultanés
Test de simultanéité hors de la portée du test de développement
Evénements différés
Si vous pensez qu'un événement peut être géré différemment selon qu'il ait été différé ou mis en file d'attente au lieu
d'être généré lorsque le programme passait à l'état de réception, vous devez tester ces deux cas.
Si l'événement dans l'état de réception possède une condition de garde, pensez aux degrés de changement des variables
de la condition entre le moment où l'événement est généré et celui où il est reçu.
Si plusieurs états peuvent gérer un événement différé, envisagez de tester le report pour chaque état de réception
possible. L'implémentation suppose éventuellement que l'état "logique" gérera l'événement.
Etats historiques
Voici un exemple d'état historique :
Fig. 2 : exemple d'état historique
La transition à un état historique correspond à trois transitions réelles et donc trois idées de test :
-
L'événement BackupUp dans l'état Command mène à l'état Collecting.
-
L'événement BackupUp dans l'état Command mène à l'état Copying.
-
L'événement BackupUp dans l'état Command mène à l'état CleaningUp.
Etats de chaîne
Les états de chaîne ne semblent avoir aucune implication pour la conception de test, sauf qu'ils demandent la
vérification d'actions supplémentaires.
La discussion antérieure a pour but de vérifier si l'implémentation correspond à la conception. Cependant, la
conception peut être elle aussi incorrecte. Lorsque vous l'observez à la recherche d'idées de test, recherchez
également deux types de problèmes :
Evénements manquants. Le diagramme d'état-transition montre la réponse d'un état à des événements que le
concepteur a anticipé dans cet état. Il arrive aux concepteurs d'ignorer ces événements. Par exemple, dans ce
diagramme d'état-transition (répété depuis le haut de cette page), le concepteur a peut-être oublié qu'un échec peut se
produire dans le sous-état Prêt de Refroidissement et pas uniquement quand le ventilateur est en fonctionnement.
Fig.3 : diagramme d'état-transition chauffage, ventilation et climatisation
C'est pourquoi il est conseillé de se demander pour chaque état si un ou plusieurs des événements s'appliquant à
d'autres états peuvent aussi s'appliquer à celui-ci. Si vous découvrez que tel est le cas pour l'un d'eux, modifiez
votre conception.
Conditions de garde incomplètes ou manquantes. De la même façon, il est possible que des conditions de garde
pour une transition suggèrent des conditions de garde sur d'autres transitions. Par exemple, le diagramme
d'état-transition prend soin de ne pas redémarrer trop souvent le système de chauffage, mais il n'existe pas de
restriction de la sorte pour le système de refroidissement. En faudrait-il une ?
Il est également possible que des variables employées pour une condition de garde suggèrent que d'autres conditions de
garde sont trop simples.
Le test de chaque arc dans un graphique ne représente en rien un test complet. Imaginez par exemple que l'état de
départ initialise une variable à 0, que l'état Setter la définit à 5 et l'état Divider la divise par 100
(100/variable). S'il existe un chemin de l'état de départ à Divider ne passant pas par Setter, vous obtenez une
exception de division par zéro. Si le diagramme d'état-transition possède beaucoup d'autres états, le fait d'appliquer
chaque arc peut suffire à manquer ce chemin.
Sauf dans le cas de diagrammes d'état-transition simples, le test de chaque chemin est infaisable. Dans la pratique,
les tests complexes et correspondant à des scénarios de cas d'utilisation sont souvent suffisants. Si vous souhaitez
des tests plus poussés, envisagez un chemin partant de chaque état et dans lequel les données reçoivent une valeur pour
chaque état les utilisant.
|