— alt : Fragment multiple alternatifs qui est l’analogue du « si alors sinon »
— opt : Fragment optionnel l’analogue du « si »
— par : Fragment parallèle pour afficher les traitements concurrents
— loop : Fragment qui s’exécute plusieurs fois
— region : Section critique (un seul processus à la fois)
— neg : Une interaction non valable
— break : Représente des scénarios d’exception
— ref : Référence une interaction dans un autre diagramme
— sd : Fragment du diagramme de séquences en entier
2.7 Approches de génération de tests à partir de modèles
Il existe deux approches pour appliquer le Model Based Testing et générer des tests à partir d’un modèle.— Création d’un modèle dédié pour le test.
— Génération de tests à partir des modèles de spécifications et/ou conception, tels que les diagrammes UML.
2.7.1 Création d’un modèle dédié pour le test
La première approche du MBT consiste à construire manuellement un nouveau mo-dèle dédié pour le test. Ce nouveau momo-dèle est construit souvent manuellement à partir des exigences fonctionnelles ou d’un document de spécifications logiciel. La validation du modèle est réalisée par l’examen minutieux des exigences du SUT afin d’en vérifier la consistance et la complétude.
Cette approche est utilisée par plusieurs travaux. Nous présentons dans la suite les travaux de [Las12], [TB03] et [Pro03].
[Las12] utilise cette approche pour générer automatiquement des tests à partir de mo-dèles SysML pour la validation de systèmes embarqués. Le modèle utilisé dans cette ap-proche est un modèle propriétaire appelé SysML4MBT, qui est un sous-ensemble du lan-gage SysML. SysML4MBT permet une représentation suffisante des comportements du système et de son environnement pour permettre une génération de tests pertinente de manière automatique.
TorX [TB03] utilise cette approche en se basant sur un modèle académique, dédié pour le test, développé à la fin des années 90. Le but était de mettre en œuvre la théorie des tests de relations de conformité entre modèles et implémentations [Tre96]. Ce principe a été implémenté dans l’outil TorX qui permet la génération de cas de test à partir de ce mo-dèle décrivant le comportement du SUT. Cet outil est représentatif de la famille d’outils de génération de tests basés sur un modèle de formalisme basés sur la transition (sys-tèmes de transitions étiquetées (LTS)) du système testé. Ce genre de système gère le non-déterminisme via la génération et l’exécution de tests en ligne. TorX fournit également un mode hors ligne et certains critères de couverture du modèle comme des critères de sélection des tests.
JUMBL [Pro03] (J Usage Model Builder) utilise cette approche en se basant sur un mo-dèle académique développé à l’Université du Tennessee. Ce momo-dèle dédié JUMBL est écrit en langage TML qui est un formalisme stochastique pour décrire un modèle d’usage basé sur les chaînes de Markov. Ce principe a été implémenté dans un outil JUMBL permettant la génération des cas de tests en utilisant des algorithmes de recherche statistiques.
L’avantage de cette approche est d’avoir un modèle dédié aux tests bien conçu, mo-délisant les exigences fonctionnelles du système et contenant uniquement les données utiles et nécessaires pour pouvoir générer des cas de tests pertinents et permettant de va-lider les exigences modélisées. D’autre part avec cette approche, il y a une indépendance entre le processus de développement et celui de test.
Cependant, un inconvénient majeur de cette approche est la nécessité de créer et de maintenir manuellement un nouveau modèle, dédié pour les tests, et donc d’effectuer un travail de modélisation parfois redondant avec celui réalisé en phase de spécification.
laquelle la plupart des sociétés n’emploient pas le MBT dans leur cycle de développement logiciel, malgré leur conscience du gain apporté, est la nécessité de la création de ce nou-veau modèle dédié aux tests et à le maintenir à chaque modification du système.
2.7.2 Génération de tests à partir des modèles de spécifications et/ou
conception
La génération de tests à partir des modèles de spécifications et/ou conception est une alternative à la création d’un modèle dédié aux tests. Cette approche consiste à utiliser des modèles existants en les enrichissant afin de générer des cas de tests. Différentes tech-niques de génération des cas de tests à partir de modèles existent telles que la génération à partir de modèle de spécification/conception comme UML ou des automates. Ces tra-vaux peuvent être groupés en plusieurs catégories. Nous présentons les tratra-vaux liés à la génération des cas de tests à partir des diagrammes de séquences seuls puis avec des dia-grammes de cas d’utilisation.
2.7.2.1 Génération de tests à partir des diagrammes de séquences UML
Sarma et al. [SKR07] ont proposé une méthode consistant à générer des scénarios de test directement à partir du diagramme de séquences UML. Leur méthode se compose de deux étapes :
— Tout d’abord, le diagramme de séquences (SD) est converti en un format inter-médiaire appelé graphe de diagramme de séquences (Sequence Diagram Graph) (SDG).
— Ensuite, le SDG est parcouru pour générer les cas de tests.
Dans la méthode proposée, le SD est d’abord converti en SDG. Cependant, pour les au-teurs, le SD n’est pas suffisant pour décider des différentes composantes pour la généra-tion de cas de test. Par conséquence, les auteurs proposent d’enrichir chaque nœud du SDG par des contraintes OCL (Object Constraint Language).
Pour la construction du SDG à partir du SD, la série de scénarios de fonctionnement est d’abord dérivée du SD puis, en fonction des scénarios d’opération, le SDG est construit. Un scénario d’opération représente un ensemble de messages transmis entre les objets lors de chaque opération. Un simple scénario d’opération peut être défini comme un qua-druple, aOpnScn : <ScnId ; StartState ; MessageSet ; NextState> où ScnID est un numéro unique qui identifie chaque scénario d’opération . Le StartState est un point de départ du ScnId, c’est-à-dire, où un scénario commence. L’ensemble de tous les événements qui se produisent dans un scénario d’opération est désigné par MessageSet. L’état dans le-quel le système se trouve à la fin du scénario d’opération est représenté par NextState. Il
s’agit de l’état final d’une activité ou d’un cas d’utilisation. Un SDG possède un seul état de démarrage et un ou plusieurs états finaux en fonction des différents scénarios de fonc-tionnement. Un événement dans un MessageSet est désigné par un tuple, aEvent : <mes-sageName ; fromObject ; toObject [/ guard]> où, mes<mes-sageName est le nom du message avec sa signature, fromObject est l’expéditeur du message, toObject est le destinataire du message et le paramètre optionnel garde est la condition de garde pour laquelle l’événe-ment aura lieu. Le SDG est ensuite traversé à l’aide d’un algorithme pour générer des cas de tests.
Nayak et al. [NS10] ont proposé une méthode semblable pour générer des cas de tests à partir des diagrammes de séquences UML (SD). Leur méthode consiste à enrichir le SD avec des attributs et des contraintes dérivées de l’OCL (Object Constraint Langue).
Le SD est transformé en un graph appelé Structured Composite Graph (SCG). Il existe deux types de nœuds dans le SCG, l’un est le Block node et l’autre est le Control node. Un Block node est un nœud correspondant à un ensemble de messages du diagramme de séquences. Un Control node est utilisé pour marquer l’entrée et la sortie d’un fragment dans un diagramme de séquences. Il existe quatre types de Control node.
— Un nœud de décision est utilisé pour afficher le comportement de sélection
— Un nœud de fusion est utilisé pour afficher la sortie du comportement de sélection
— Un ensemble de nœuds de fourche et de jointure est utilisé comme entrée et sortie d’un fragment "par"
— Tous les états à l’exception de l’état initial si doivent avoir au minimum une transi-tion entrante.
Le SCG est ensuite traversé à l’aide de l’algorithme de recherche en profondeur pour gé-nérer des cas de tests.
Samuel et al. [SJ08] ont proposé une méthode pour générer des cas de tests à partir des diagrammes de séquences UML (SD). Leur méthode utilise des nouvelles fonctionnalités des diagrammes de séquences UML 2.0 telles que les fragments alt, loop. Elle consiste en deux étapes principales :
— Le SD est transformé en un format intermédiaire appelé Sequence Dependecy Graph (SDG). Chaque nœud du SDG représente soit un message soit une séquence de message et il existe une transition entre chaque deux paire de nœuds
— Le SDG est traversé pour générer des cas de tests
Lin et al. [LSQH07] ont proposé une méthode pour générer des cas de tests à par-tir des diagrammes de séquences UML (SD) et le langage OCL. Leur méthode consiste à construire un arbre de scénario appelé Scenario Tree (ST) à partir d’un diagramme de sé-quences. Lors de la création du ST à partir du SD, les messages sont représentés par des
nœuds et la séquence, dans laquelle les messages sont échangés entre les objets, repré-sente les liens entre les nœuds. Ensuite, le ST est traversé en utilisant les critères de tests tous les chemins de message pour générer les cas de tests.
Misra et al. [MM14] ont proposé de tester le logiciel dans les premières phases (phase de conception) du cycle de vie du développement logiciel, afin qu’il puisse aider les tes-teurs de logiciel dans les phases suivantes. Leur approche consiste à générer automati-quement des cas de tests à partir d’un diagramme de séquences. La première étape de leur approche consiste à lire le diagramme de séquences à partir d’un fichier XMI pour ensuite le transformer en un graphe appelé Sequence Control Flow Graph (SCFG), en sé-lectionnant uniquement les messages entre les objets internes d’un système sont ignorés comme ils sont uniquement intéressés par les tests fonctionnels. Ensuite, les cas de tests sont générés automatiquement grâce à leur algorithme Test Scenario Generation Algo-rithm (STSGA).
Cartaxo et al. [EGCM07] ont proposé une méthode pour générer des chemins de test pour une application mobile à partir d’un diagramme de séquences. Leur méthode consiste à construire un modèle intermédiaire appelé système de transition étiqueté (LTS : Labeled Transition System) à partir du diagramme de séquences, où les transitions sont utilisées pour représenter le flux de contrôle, la sortie attendue et les étapes de tests. Ensuite, ils appliquent un algorithme de recherche en profondeur (ou parcours en profondeur, ou DFS, pour Depth-First Search) pour parcourir le modèle LTS afin de générer des chemins de tests.
Khandai et al. [KAM11] ont également proposé une méthode pour générer des cas de tests à partir d’un diagramme de séquences, mais en utilisant un graphe intermédiaire appelé CCG (Concurrent Composite Graph). Ils traversent ensuite la CCG en appliquant l’algorithme de recherche en profondeur (DFS) et l’algorithme de parcours en largeur (ou BFS, pour Breadth First Search en anglais) pour générer des cas de tests.
2.7.2.2 Génération de tests à partir des diagrammes de séquences et des diagrammes de cas d’utilisations UML
Sarma et al. [SR07] ont proposé une méthode pour générer des cas de tests à partir des diagrammes de séquences (SD) et des diagrammes de cas d’utilisations (UCD). Leur méthode est composée de trois étapes :
— Le UCD est converti en un graph appelé Usecase Diagram Graph (UDG)
— Le SD est converti en un graph appelé Sequence Diagram Graph (SDG)
— Le UDG et le SDG sont intégrés afin de générer un graph appelé System Testing Graph (STG)
Swain et al. [SMM10] ont également proposé une méthode pour générer des cas de tests à partir des diagrammes de séquences (SD) et des diagrammes de cas d’utilisations (UCD). Leur méthode consiste à construire deux graphes :
— Use case Dependency Graph (UDG) à partir du UCD
— Concurrency Control Flow Graph (CCFG) à partir du SD
Ensuite ces deux graphes sont traversés dans l’objectif de couvrir les différents défauts d’interaction, les défauts de séquences de messages et les défauts de synchronisation. L’approche a utilisé XML et un outil semi-automatisé a également été développé.
D’un autre côté, il existe des travaux sur l’exploration de spécifications qui consistent à transformer un ensemble de traces d’exécution en entrée et une machine à états finis en sortie [BABE11], [MPS17] et [WH16]. Ces travaux peuvent être appliqués aux diagrammes de séquences en considérant chaque diagramme comme un ensemble de messages li-néaires.
Conclusion sur la génération des tests à partir des modèles de spécifications et/ou conception : Comme nous pouvons le remarquer, tous les travaux connexes mentionnés ci-dessus tentent de générer directement des scénarios de test à partir de diagrammes de séquences UML.
Cependant, une préoccupation commune liée à ces travaux est qu’ils considèrent tous que les modèles de spécifications/conception existants, tel que les diagrammes de sé-quences, sont exhaustifs et complets pour obtenir des cas de tests pertinents. Cependant, ce type de diagrammes n’est pas toujours disponible, en particulier dans les premières phases de la conception d’un système.
D’autre part, la plupart des sociétés ne modélisent pas complètement leurs systèmes. En effet pour un système donné, la majorité des sociétés se contente uniquement de grammes de classes, de quelques diagrammes de cas d’utilisation et de quelques dia-grammes de séquences et donc ne crée pas tous les diadia-grammes de séquences de dif-férents scénarios du système. Cela rend impossible le test de plusieurs fonctionnalités et plusieurs enchaînements de fonctionnalités du système.
Un inconvénient supplémentaire de ces travaux est qu’ils limitent tous leur applica-bilité à la spécification et à la transformation d’un seul diagramme de séquences pour générer des cas de tests et ne gèrent pas la combinaison de scénarios, alors que ce que nous proposons dans notre méthodologie est de bénéficier des différents diagrammes de séquences existants pour un problème donné.
De plus, ces travaux sont entièrement automatiques, donc l’utilisateur ne peut pas intéragir avec les générations des cas de tests et ces travaux ne gèrent pas l’historique des événements, ce qui est très important pour obtenir un modèle de test valide et factorisé. Par exemple, lors de la transformation d’un diagramme de séquences, nous ne pouvons
pas fusionner automatiquement deux mêmes messages sans tenir compte de l’historique des précédents messages.
2.8 Motivation
Motivé par les avantages et les inconvénients de chacune des deux approches de MBT, nous sommes arrivés à l’objectif de notre travail, qui consiste à combiner les deux ap-proches de MBT pour générer un modèle de test, qui est un modèle basé sur l’utilisation du SUT, à partir de spécifications et/ou modèles de conception (réutiliser les artefacts du projet existant pour générer un modèle de test). Dans notre travail, nous ne générons pas directement des cas de tests, mais nous générons un modèle de tests à partir d’un mo-dèle de spécification ou de conception quel que soit le niveau de détail de ce momo-dèle. Le modèle de tests généré peut être modifié et enrichi par le testeur avant de générer des cas de tests. Dans le cadre de nos travaux, nous utiliserons un ensemble de diagrammes de séquences comme modèle de spécifications pour générer un modèle de tests. Notre travail est plus lié aux approches qui utilisent le diagramme comportemental UML, en particulier les diagrammes de séquences, sans nécessiter de formalisme ou d’effort sup-plémentaire dans le diagramme de conception pour faciliter la génération de modèle de tests ou de cas de tests.
Le modèle généré est un modèle réalisable pour toute modification manuelle. Cela aidera à simplifier l’utilisation du MBT et, par conséquent, le rendra plus utilisable par les industriels.
Cependant, une préoccupation majeure lors de la génération d’un modèle de test est qu’une entrée d’un SUT ne permet pas toujours la prédiction de son comportement. En revanche, cela dépend de l’état du SUT lors de l’application d’un événement : deux événe-ments sont gérés différemment par le SUT selon les ensembles des entrées précédentes du SUT. Pour construire un modèle de tests factorisé (avec fusion de messages équiva-lents) d’une manière pertinente, nous devons gérer l’historique des précédents événe-ments sur le SUT. Par conséquent, notre processus de génération de modèle de test sera basé sur ce que nous appellerons le context, notion qui se fonde sur l’historique de l’État du SUT (l’historique des entrées précédentes du SUT).
Dans le cadre de nos travaux, nous utilisons un ensemble de diagrammes de séquences UML comme modèles de spécifications pour générer un modèle d’usage MaTeLo qui sera considéré comme modèle de tests.
En résumé, le tableau2.1présente une comparaison des approches existantes du MBT et le positionnement de notre approche.
Création d’un modèle dédié pour le test
Génération automatique des tests
à partir des modèles UML Notre approche
Critères de coût Effort de modélisation
et maintenance
- Coûteux
- Un travail de modélisation parfois redondant - Très facile à maintenir car le modèle contient uniquement les données nécessaires pour les tests
- Coût faible car pas de nouveau modèle.
- Pas de maintenance d’un modèle de tests mais on maintient directement les modèles UML. Cependant, si le modèle contient peu d’informations nécessaire ou trop d’informations inutiles pour la génération de tests, nous serons obligés de dupliquer ces modèles afin d’adapter une copie pour les tests et ainsi l’effort de travail sera multiplié par 2 lorsque les spécifications évoluent.
- Coût faible car le modèle de tests est généré automatiquement. - La maintenance est facile car le modèle pourra être modifié manuellement avant de générer des cas de test et donc l’utilisateur pourra modifier ce modèle pour le rendre utile pour le test.
Critères d’efficacité Efficacité du Modèle
- Un modèle de tests très bien conçu, factorisé et sans redondance
- Un modèle de tests linéaire et avec beaucoup de redondance (beaucoup de duplications des états/transitions) - Les informations contenues dans ces modèles ne sont pas toujours pertinentes pour la génération des cas de tests. En effet, lorsque le modèle est à un niveau trop bas, il peut contenir des informations inutiles pour la génération des tests. Lorsque le modèle est de niveau trop élevé, il peut ne pas contenir suffisamment d’informations pour être utilisé afin de générer des tests exécutables et pertinents.
- Un modèle de tests bien conçu, factorisé et sans redondance
Efficacité des cas de tests
- Très efficace car ils sont générés à partir d’un modèle qui modélise les exigences fonctionnelles du SUT
- Les tests ne sont pas très efficaces si les modèles de spécifications/conceptions ne sont pas exhaustifs
- Efficace car ils seront générés à partir d’un modèle bien conçu et valide
TABLEAU2.1 – Comparatifs des approches de MBT et de notre approche
2.9 Conclusion
Le logiciel a connu et continue de connaître une croissance considérable. Il existe deux types d’approches de tests : Statique et Dynamique. Dans le cycle de développement logiciel, le test est l’une des phases les plus coûteuses [Say99].
Le MBT peut amener à réduire ce coût. C’est une technique rentable [SMJU10]. Le MBT facilite le test d’un système car lorsque les exigences de ce dernier évoluent, nous aurons besoin uniquement de modifier le modèle de test correspondant et de régénérer les cas de tests, plutôt que de maintenir les cas de tests en soi.