Instructions: Idées de test pour des diagrammes d'état-transition et des diagrammes de flux
Les idées de test se fondent sur des fautes plausibles d'un logiciel et sur la meilleure façon de les découvrir. Ces instructions montrent comment identifier des idées de test à partir de diagrammes d'état-transition ou d'autres structures de conception de type graphique.
Relations
Eléments connexes
Description principale

Introduction

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 ?

Test de l'implémentation

Prenez ce diagramme d'état-transition :

Diagramme décrit dans la légende.

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 :

Diagramme décrit dans la légende.

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.

Test de la conception

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.

Diagramme décrit dans la légende.

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.

Test d'interactions

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.