HAL Id: tel-03275317
https://tel.archives-ouvertes.fr/tel-03275317
Submitted on 1 Jul 2021HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
développement logiciel
Hussein Mhanna
To cite this version:
Thè
se de
doctorat
NNT : 2020UP ASS115testing dans un processus de
développement logiciel
Thèse de doctorat de l’Université Paris-SaclayÉcole doctorale n◦ 575, Electrical, Optical, Bio: PHYSICS
AND ENGINEERING (EOBE)
Spécialité de doctorat: Sciences de l’information et de la communication
Unité de recherche: ESTACA, 53000 Laval Référent : Faculté des sciences d’Orsay
Thèse présentée et soutenue à LAVAL, le 30 Juin 2020, par
Hussein MHANNA
Composition du jury:
Amar RAMDANE-CHERIF Président
Professeur, Université Paris-Saclay (UVSQ)
Reda BENDRAOU Rapporteur
Professeur, Université Paris Ouest Nanterre la Défense
Yves LEDRU Rapporteur & Examinateur
Professeur, Université Grenoble Alpes
Laurence DUCHIEN Examinatrice
Professeure, Université de Lille
Omar HAMMAMI Examinateur
Professeur, ENSTA Paris
Chérif Larouci Directeur
Enseignant-Chercheur HDR, ESTACA
Patrick LESERF Coencadrant
Enseignant-Chercheur, ESTACA
Je remercie Amar RAMDANE-CHERIF, Professeur à l’Université Paris-Saclay, qui me fait l’honneur de présider ce jury.
Je remercie vivement Yves LEDRU, Professeur à l’Université Grenoble Alpes, et Reda BEN-DRAOU, Professeur à l’Université Paris Ouest Nanterre la Défense, d’avoir bien voulu ac-cepter la charge de rapporteur.
Je remercie Laurence DUCHIEN, Professeure à l’Université de Lille, et Omar HAMMAMI, Professeur à l’ENSTA Paris, d’avoir bien voulu juger ce travail.
J’exprime ma sincère reconnaissance à Chérif LAROUCI, qui a dirigé ma thèse et qui m’a beaucoup soutenu durant cette thèse.
Je remercie infiniment Sébastien SAUDRAIS et Patrick LESERF, pour m’avoir fait l’hon-neur d’être mes encadrants durant cette thèse, et pour m’avoir soutenu et me conseiller tout au long de cette aventure.
Je tiens également à remercier Laurent COSSON et Arnaud COSSON pour avoir accep-ter de financer cette thèse ainsi que l’ensemble des salariés d’All4tec.
J’exprime ma sincère reconnaissance à Hélène LE GUEN et à Franck HORTALA qui m’ont beaucoup soutenu au début de cette thèse.
Je remercie spécialement Laurence STEPHEN, Chloé, Delphine, Gaël, Jérémie, Nicolas, Fanch et Hassan.
Liste des figures IX 1 Introduction générale 1 1.1 Contexte . . . 2 1.2 Problématique. . . 2 1.3 Contribution . . . 3 1.4 Plan . . . 4 1.5 Publication . . . 5 1.6 Livrables . . . 5 2 État de l’art 7 2.1 Introduction . . . 9 2.2 Test . . . 9 2.2.1 Termes et définitions . . . 11 2.3 Test logiciel . . . 11 2.3.1 Techniques de tests. . . 12
2.4 Model Based Testing . . . 15
2.4.1 Processus MBT . . . 16
2.4.2 Formalismes MBT . . . 17
2.5 Les outils MBT. . . 18
2.5.1 MaTeLo : Outil de Model-based Testing . . . 18
2.6 UML : Langage de Modélisation Unifié . . . 26
2.6.1 Les diagrammes UML . . . 27
2.7 Approches de génération de tests à partir de modèles. . . 30
2.7.1 Création d’un modèle dédié pour le test . . . 31
2.7.2 Génération de tests à partir des modèles de spécifications et/ou concep-tion . . . 32
2.8 Motivation . . . 36
3 Méthodologie 39
3.1 Introduction . . . 40
3.2 Introduction de la notion du context. . . 42
3.3 Algorithme de transformation . . . 46
3.3.1 Phase d’identification . . . 48
3.3.2 Phase de transformation. . . 51
3.3.3 Phase de Factorisation de messages . . . 62
3.4 Cas d’étude. . . 64
3.5 Application d’un exemple de travaux existants sur notre cas d’étude . . . 67
3.6 Application de notre algorithme sur le cas d’étude . . . 69
3.6.1 Traitement d’un retrait d’argent avec succès . . . 70
3.6.2 Traitement d’un blocage de carte. . . 73
3.6.3 Traitement d’un retrait d’argent sans succès . . . 76
3.6.4 Traitement du dépôt d’argent . . . 79
3.6.5 Traitement de consultation du compte . . . 82
3.7 Discussion du résultat de l’application de notre algorithme sur le cas d’étude 85 3.8 Conclusion. . . 86 4 Implémentation et évaluation 87 4.1 Présentation . . . 88 4.2 Outils utilisés . . . 88 4.2.1 Eclipse et Eclipse RCP . . . 88 4.2.2 Eclipse EMF . . . 89 4.2.3 Capella . . . 89 4.2.4 Papyrus . . . 91 4.3 Implémentation MaTeLo . . . 91 4.3.1 Context . . . 92 4.4 Implémentation du MUGM . . . 100 4.4.1 Plugin : com.all4tec.matelo.mumg.model . . . 101 4.4.2 Plugin : com.all4tec.matelo.mumg.parser . . . 103 4.4.3 Plugin : com.all4tec.matelo.mumg.importer . . . 103 4.4.4 Plugin : com.all4tec.matelo.mumg.converter . . . 103 4.4.5 Plugin : com.all4tec.matelo.mumg.importer.ui . . . 103
4.5 Implémentation spécifique pour le projet Clarity . . . 104
4.5.1 Plugin : com.all4tec.matelo.mumgc.capella.parser . . . 105
4.5.2 Plugin : com.all4tec.matelo.mumgc.capella.importer. . . 105
4.5.3 Plugin : com.all4tec.matelo.mumgc.capella.importer.ui . . . 105
4.6 Évaluation . . . 107
2.1 Apport des tests à l’amélioration - ALTRAN et PAC 2013 . . . 10
2.2 Techniques de tests . . . 13
2.3 Cycle en V de développement d’un système . . . 15
2.4 Processus de Model-based Testing . . . 16
2.5 MaTeLo : Perspective Édition . . . 21
2.6 Distribution des données . . . 21
2.7 Probabilités des transitions . . . 22
2.8 Modèle d’usage MaTeLo . . . 22
2.9 MaTeLo : Perspective Génération. . . 23
2.10 MaTeLo : Perspective Report . . . 24
2.11 Algorithme de génération . . . 24
2.12 Rapport d’un cas de test . . . 25
2.13 Exécution automatique de test . . . 26
2.14 Les diagrammes UML . . . 27
2.15 Diagramme de cas d’utilisation . . . 28
2.16 Diagramme de séquences . . . 30
3.1 Étapes de génération de modèle d’usage . . . 41
3.2 Méthodologie développée . . . 42
3.3 Duplication d’états . . . 43
3.4 Transition conditionnelle . . . 45
3.5 Exemple d’une transition de conditionnelle . . . 46
3.6 Algorithme de génération d’un modèle d’usage . . . 47
3.7 Modèle d’usage initial . . . 48
3.8 Phase d’identification . . . 49
3.9 Application de la Phase d’identification . . . 51
3.10 Cas 1 : Transformation d’un message non existant. . . 53
3.11 Cas 3 : Transformation d’un message existant sans factorisation (1) . . . 53
3.12 Cas 4 : Transformation d’un message existant sans factorisation (2) . . . 54
3.14 Modèle d’usage correspondant à l’exemple. . . 55
3.15 Modèle d’usage correspondant à l’exemple (étape 2) . . . 56
3.16 Diagrammes de séquences modélisant un opérateur "ALT" (if ) . . . 57
3.17 Transformation d’un opérateur ALT (avec IF). . . 58
3.18 Diagrammes de séquences modélisant un opérateur "ALT" (IF et ELSE) . . . 59
3.19 Transformation d’un opérateur ALT (avec IF et ELSE) . . . 59
3.20 Diagrammes de séquences modélisant un opérateur Loop . . . 60
3.21 Transformation d’un opérateur LOOP . . . 60
3.22 Diagrammes de séquences modélisant un opérateur OPT . . . 61
3.23 Transformation d’un opérateur OPT . . . 61
3.24 Modèle d’usage avec factorisation du message (étape 1) . . . 63
3.25 Modèle d’usage avec factorisation du message (étape 2 : contexte) . . . 63
3.26 Modèle d’usage avec factorisation du message (étape 3 : pas de contexte). . 64
3.27 diagramme de séquences : Un retrait d’argent avec succès . . . 65
3.28 diagramme de séquences : Blocage de carte . . . 65
3.29 diagramme de séquences : Un retrait d’argent sans succès . . . 66
3.30 diagramme de séquences : Dépôt d’argent . . . 66
3.31 diagramme de séquences : Consultation du compte . . . 67
3.32 Application d’un algorithme existant sur un diagramme de séquences du cas d’étude . . . 68
3.33 Application d’un algorithme existant sur tous les diagrammes de séquences du cas d’étude . . . 69
3.34 Modèle d’usage : Transformation retrait argent (Étape 1) . . . 71
3.35 Modèle d’usage : Transformation retrait argent (Étape 2) . . . 72
3.36 Modèle d’usage : Transformation retrait argent (Étape 3) . . . 73
3.37 Modèle d’usage : Transformation blocage de carte . . . 76
3.38 Modèle d’usage : Transformation retrait argent sans succès . . . 79
3.39 Modèle d’usage : Transformation dépôt d’argent . . . 82
3.40 Modèle d’usage : Transformation consultation du compte . . . 85
4.1 Vue d’ensemble d’architectures Capella . . . 90
4.2 Scénario d’exchange . . . 91
4.3 Méta-modèle de la libraire des variables de contexte . . . 93
4.4 Libraire de variables de contexte . . . 95
4.5 Création d’une variable de contexte . . . 95
4.6 Manipulation d’une variable de contexte . . . 96
4.7 Création des relations des variables de contextes . . . 96
4.8 Manipulation d’une relation d’une variable de contexte . . . 97
4.10 Méta-modèle des chaines MaTeLo . . . 99
4.11 Transition conditionnelle . . . 100
4.12 Configuration du commutateur d’une transition conditionnelle . . . 100
4.13 Méta-modèle de l’application MUMG . . . 102
4.14 Wizarde de MUGM . . . 103
4.15 Page de Wizard de génération d’un modèle d’usage . . . 104
4.16 Erreur lors de la génération d’un modèle d’usage . . . 104
4.17 Wizard Capella . . . 105
4.18 Page de Wizard génération d’un modèle d’usage à partir de Capella . . . 106
4.19 Modèle d’usage généré via MUMGC . . . 107
4.20 Fusion des outils MaTeLo et Capella . . . 107
1.1 Contexte
Le développement de logiciels est devenu essentiel dans tous les détails de la vie, comme dans les machines à laver intelligentes, les téléviseurs haute définition, le tableau de commande de voiture, le guichet automatique ou les applications mobiles. De nom-breuses recherches ont été effectuées dans ce domaine, afin de réduire au minimum le coût du développement logiciel en temps et en argent.
Contrairement au passé, nous trouvons de nos jours une partie logicielle importante dans la plupart des systèmes (exemple téléviseurs haute définition ...). Toutefois, ces mo-difications, pour intégrer des parties logicielles dans les systèmes, ont un gros impact sur le fonctionnement des produits (Télévision, Téléphone, ...). Des dysfonctionnements peuvent devenir très graves et menacer la vie de personnes (aéronautiques, automobiles). De nombreux bugs liés au logiciel survenus dans le passé ont incité la communauté scien-tifique à concentrer leurs efforts sur l’amélioration des techniques de prévention d’er-reurs.
Le test est une activité dans laquelle les résultats d’une exécution d’un système ou d’un de ses composants sont observés et comparés par rapport aux résultats attendus[Sep90].
Le MBT (Model-Based Testing) est une technique de test qui consiste à générer au-tomatiquement des scénarios de tests à exécuter sur le SUT (System Under Test) [UL07]. Cette génération est réalisée en se basant sur un modèle construit à partir des exigences fonctionnelles et décrivant les comportements explicites du SUT, ses comportements at-tendus et/ou le comportement de son environnement. Ce modèle peut être décrit dans différents formats (diagramme machine à états, système de transitions étiquetées, dia-gramme d’activité UML). De nombreuses études [SMJU10] ont montré que le MBT était un moyen efficace et rentable de test et de nombreuses sociétés l’ont employé au sein de leurs projets.
Il existe deux approches de MBT pour générer des scénarios de tests à partir d’un mo-dèle :
— La première approche consiste à créer manuellement un nouveau modèle, dédié pour les tests et modélisant les aspects fonctionnels du SUT pour générer ces tests
— La seconde approche utilise des modèles existants, de spécifications et / ou de concep-tion, afin de générer automatiquement des cas de tests
1.2 Problématique
un nouveau modèle dédié aux tests et donc, la nécessité de changement dans le proces-sus de développement des équipes. La deuxième approche a également ses propres in-convénients. En effet, pour générer des scénarios de tests, la spécification doit être aussi complète que possible, tandis qu’en pratique et pour un système donné, souvent seuls les diagrammes de classes, certains diagrammes de cas d’utilisation et certains diagrammes de séquences sont spécifiés. De plus, il n’est pas facile pour les ingénieurs de validation de connaître les informations nécessaires et pertinentes pour la génération des scénarios de tests. En effet, lorsque le modèle est réalisé par l’équipe de développement à un niveau trop bas, il peut contenir des informations inutiles pour la génération des tests. En re-vanche, lorsque le modèle est de niveau trop élevé, il peut ne pas contenir suffisamment d’informations pour être utilisé pour générer des tests exécutables et pertinents.
Bien que le MBT est une technique rentable, elle reste très peu utilisée dans le monde industriel. Les causes majeures de ce faible succès résident d’une part dans la difficulté de gérer et de maintenir un nouveau modèle dédié aux tests et d’autre part dans la nécessité d’un changement de processus de développement.
La société ALL4TEC est une société Française qui commercialise un logiciel du MBT connu sous le nom du MaTeLo (Markov Test Logic). MaTeLo utilise un modèle d’usage basé sur un diagramme états-transitions pour ensuite générer à partir de ce modèle des scénarios de tests en utilisant différents algorithmes proposés par l’outil. Bien que la plu-part des sociétés sont convaincues par l’outil MaTeLo, elles ne l’emploient pas dans leur cycle de développement à cause des mêmes inconvénients liés à l’emploi du MBT dans les cycles de développement d’un système.
Le projet Français Clarity [CS20], est un projet National de consortium industriel d’une durée de 3 ans. L’un des défis de ce projet était de créer un pont entre l’outil MBSE, Ca-pella [Cap20], et l’outil MBT, MaTeLo, pour un MBT rentable et efficace. Ce défi soulève une question de recherche importante : Comment générer un modèle de test MaTeLo à partir d’un modèle de système Capella ?
Pour répondre aux exigences de ce projet et afin de rendre, d’une façon globale, le MBT plus accessibles aux sociétés, et plus précisément l’outil MaTeLo, nous avons décidé d’effectuer cette thèse.
1.3 Contribution
de spécifications et/ou de modèles de conception existants (réutilisation des artefacts de projet existants pour générer un modèle de test). Cela permettra de simplifier l’utilisation du MBT, et par conséquent le rendre plus accessibles par les entreprises.
Notre méthodologie a pour objectif de générer un modèle d’usage. Ce modèle d’usage pourra être modifié et être complété manuellement. Pour cela, le modèle d’usage généré doit être facile à maintenir et doit être factorisé (sans beaucoup de duplications des états et des transitions). Pour cela, nous ne devons pas dupliquer les transitions tant que c’est possible tout en gardant le modèle généré fonctionnellement valide par rapport à la spé-cification et ainsi on aura un nombre réduit d’états. Cependant, cette factorisation n’est pas évidente car cela dépend de l’état du SUT lors de l’application d’un événement. En effet, une entrée d’un SUT ne permet pas toujours de prédire son comportement et deux événements 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 test factorisé d’une manière pertinente, nous devons gérer l’historique des précédents événements 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.
Dans ce travail nous utilisons les diagrammes de séquences UML comme modèle de spécifications/conceptions à partir desquels nous générons un modèle de test. Nous uti-lisons également le modèle d’usage MaTeLo comme modèle de test.
Notre méthodologie est composée de deux contributions majeures :
— La notion du context
— Un algorithme pour générer un modèle d’usage à partir d’un ensemble de diagrammes de séquences
1.4 Plan
Le chapitre 2 de cette thèse décrit l’état de l’art dans lequel nous présentons :
— Le test logiciel
— Les techniques de tests
— Le MBT (Model Based Testing) où nous détaillons les principes de cette technique ainsi que certains travaux basés sur cette technique
— Les différents formalismes du MBT ainsi que certains outils du MBT dont l’outil MaTeLo qui est utilisé dans cette thèse
— Le langage de modélisation UML qui a été aussi utilisé pour faire du MBT
— L’introduction de notre nouvelle approche de MBT
Le chapitre 3 présente notre méthodologie permettant de générer un modèle de test à partir d’un ensemble de diagrammes de séquences. Cette méthodologie est composée de deux contributions : La notion du context qui permet de gérer l’historique des évé-nements précédents sur le SUT pour pouvoir générer un modèle de test factorisé et un algorithme pour la génération d’un modèle de test à partir d’un ensemble de diagrammes de séquences.
Le chapitre 4 présente l’implémentation de notre méthodologie, ce qui a conduit au développement des deux nouveaux outils, MUMG (MaTeLo Usage Model Generator) et MUMGC (MaTeLo Usage Model Generator For Capella), ainsi que l’évaluation de cette implémentation.
Finalement, le dernier chapitre conclut ce rapport et ouvre des perspectives.
1.5 Publication
— H. Mhanna, P. Leserf and S. Saudrais, "Generation of Context-Based Usage Scenario Test from UML Sequence Diagrams," 2018 IEEE/ACS 15th International Conference on Computer Systems and Applications (AICCSA), Aqaba, 2018, pp. 1-7.
— H. Mhanna, H. Le Guen, P. Leserf et S. Saudrais, "Réutilisation d’artefacts projets pour le Model Based Testing ". CIEL 2016 : 5ème Conférence en IngénieriE du Logi-ciel
1.6 Livrables
Participation à trois livrables dans le cadre du projet National Clarity. Chaque livrable constitue une nouvelle version de l’outil MUMGC où :
— La première version implémente notre méthodologie.
— La deuxième version intègre la génération automatique des entrées/sorties.
État de l’art
Sommaire
2.1 Introduction . . . . 9 2.2 Test . . . . 9 2.2.1 Termes et définitions . . . 11 2.3 Test logiciel. . . 11 2.3.1 Techniques de tests. . . 12 2.3.1.1 Test statique. . . 12 2.3.1.2 Test dynamique. . . 132.3.1.3 Tests boîte noire . . . 14
2.3.1.4 Tests boîte blanche. . . 14
2.4 Model Based Testing . . . 15
2.4.1 Processus MBT . . . 16
2.4.2 Formalismes MBT . . . 17
2.5 Les outils MBT . . . 18
2.5.1 MaTeLo : Outil de Model-based Testing . . . 18
2.5.1.1 Modèle d’usage de MaTeLo . . . 19
2.5.1.2 Outil MaTeLo . . . 20
2.5.1.3 Perspective Edition . . . 20
2.5.1.4 Perspective Generation . . . 22
2.5.1.5 Perspective Report . . . 23
2.5.1.6 Algorithme de génération . . . 23
2.6 UML : Langage de Modélisation Unifié. . . 26
2.6.1 Les diagrammes UML . . . 27
2.6.1.1 Le diagramme de cas d’utilisation . . . 28
2.6.1.2 Les diagrammes de séquences . . . 29
2.7.1 Création d’un modèle dédié pour le test . . . 31
2.7.2 Génération de tests à partir des modèles de spécifications et/ou conception. . . 32
2.7.2.1 Génération de tests à partir des diagrammes de séquences UML . . . 32
2.7.2.2 Génération de tests à partir des diagrammes de séquences et des diagrammes de cas d’utilisations UML . . . 34
2.8 Motivation . . . 36
2.1 Introduction
Ce chapitre est consacré à l’état de l’art concernant le test logiciel. Le MBT est une technique de test qui consiste à générer automatiquement, un ensemble des cas de tests à partir d’un modèle de test. Ces cas de tests peuvent ensuite être exécutés sur le SUT. Nous nous focalisons sur les approches MBT qui constituent les supports de nos travaux. La revue de la littérature nous permet de synthétiser les avantages et les inconvénients de ces techniques et de positionner ainsi la méthodologie développée dans le cadre de cette thèse.
2.2 Test
Le test est une activité dans laquelle les résultats d’une exécution d’un système ou d’un de ses composants sont observés et ensuite comparés par rapport aux résultats at-tendus [Sep90]. Le but principal d’un test est d’identifier la conformité d’un système ou d’un de ses composants par rapport aux spécifications et aux exigences initialement dé-finies dans son cahier des charges.
Actuellement, le monde industriel utilise principalement le test pour garantir la qua-lité et la fiabiqua-lité d’un logiciel.
Il est évident qu’il est moins cher d’éviter l’introduction de défauts plutôt que leur identification et leur correction plus tard. D’après le livre blanc proposé conjointement par ALTRAN et PAC (figure2.1), les tests ont la capacité d’améliorer fortement l’efficacité des processus et de réduire les coûts et délais de développement. Concernant l’améliora-tion de l’efficacité et la réducl’améliora-tion des coûts, 73% des sociétés estiment que le test y contri-bue de manière importante ou très importante.
FIGURE2.1 – Apport des tests à l’amélioration - ALTRAN et PAC 2013
Une étude réalisée en 2008 par IDC (International Data Corporation), a montré que les problèmes liés à la qualité logicielle coûtent à certaines sociétés, éditeurs de logiciels, jusqu’à 22 millions de dollars annuellement. Les problèmes de qualité au sein des appli-cations logicielles engendrent une perte de 59.5 milliards de dollars aux États unis chaque année selon une étude réalisée en 2002 par le NIST (National Institute of Standards and Technology). D’après [Tas02], ces problèmes sont hyper coûteux comme par exemple la fusée Ariane 5 qui a été détruite, le 4 juin 1996, seulement 36.7 secondes après son dé-collage à cause d’un bug informatique. Ce bug informatique a engendré une perte finan-cière d’environ 1,9 milliard de Francs Français [Lan96]. De nombreux bugs liés au logiciel survenus dans le passé ont incité la communauté scientifique à concentrer ses efforts sur l’amélioration des techniques de prévention d’erreurs et à développer des nouvelles tech-niques de génération de tests.
Bien que le test est indispensable pour avoir des logiciels fiables et de qualité, il n’est pas toujours la priorité pour différentes raisons telles que :
— Les tests prennent beaucoup de temps pour les écrire et pour les mettre à jour lorsque le SUT évolue ce qui peut retarder le développement d’un système
— Les équipes de développement dépensent un pourcentage croissant de leur temps à corriger les anomalies signalées ce qui perturbe le développement
— Il faut des compétences dédiées aux tests pour créer des tests pertinents
2.2.1 Termes et définitions
Pour bien appréhender la suite de ce rapport, voici quelques définitions proposées par [IST20] que nous utilisons par la suite :
Cas de test : Un ensemble de conditions préalables, de données d’entrée, d’actions (le cas échéant), de résultats attendus et de postconditions, élaboré sur la base des condi-tions de test. Chaque élément de cet ensemble est appelé "étape de test".
Suite de test : Un ensemble de cas de test ou de procédures de test à exécuter dans un cycle de test spécifique.
Script de test : Une séquence d’instructions pour l’exécution d’un test. Erreur : Une action humaine produisant un résultat incorrect.
Défaut/Bug : Une imperfection ou une déficience d’un produit d’activités lorsqu’il ne répond pas à ses exigences ou à ses spécifications.
Résultat attendu : Un comportement observable prévu d’un composant ou d’un sys-tème s’exécutant dans des conditions spécifiées, sur la base de sa spécification ou d’une autre source.
Banc de test : Un environnement contenant le matériel, les instruments, les simula-teurs, les outils logiciels et les autres éléments de support nécessaires à l’exécution d’un test.
Chemin de test : Un chemin de test est une séquence d’événements (i.e. instructions exécutables), d’un composant ou système d’un point d’entrée jusqu’à un point de sortie.
2.3 Test logiciel
Le développement de logiciels est devenu essentiel dans tous les détails de la vie, comme dans les machines à laver intelligentes, les téléviseurs haute définition, le tableau de commande de voiture, le guichet automatique ou les applications mobiles. De nom-breuses recherches ont été effectuées dans ce domaine, afin de réduire au minimum le coût du développement logiciel en temps et en argent.
Dans le cycle de développement logiciel, le test est l’une des phases les plus coûteuses [Say99]. Les phases de tests représentent entre 30% et 50% du coût total du développe-ment, et parfois même jusqu’à 70% [Roz99]. Depuis ces dernières années, on observe que beaucoup de nouvelles solutions sont mises en œuvre pour améliorer cette phase. Par exemple, il existe la séparation des équipes de développements et de tests où chaque équipe utilise des processus et des outils dédiés. L’automatisation de tests devient de plus en plus présente dans l’exécution des tests mais reste anecdotique pour la définition des tests à réaliser.
à générer automatiquement des tests de validation à partir d’un modèle décrivant cer-tains aspects fonctionnels du système sous test (System Under Test : SUT) [UL07].
La vérification du bon fonctionnement d’un système sous les différentes conditions d’utilisation est essentielle. Tester un programme, c’est l’exécuter dans l’intention d’y trouver des bugs ou des défauts [WM10].
Le principe du test logiciel consiste à générer un ensemble de cas de tests, appelé suites de tests, en utilisant une ou plusieurs stratégies de tests. Ensuite, ces cas de tests sont exécutés sur le SUT et les résultats obtenus sont comparés aux résultats attendus.
Pour garantir la qualité d’un SUT, ce SUT doit répondre aux exigences spécifiées et qui sont réparties en deux grandes catégories :
— Les exigences fonctionnelles décrivant une fonction d’un système ou d’un de ses composants
— Les exigences non fonctionnelles décrivant les propriétés que le système doit avoir tels que la performance, l’accessibilité, ...
Dans cette thèse, nous nous intéressons uniquement aux exigences fonctionnelles.
2.3.1 Techniques de tests
Dans ce paragraphe nous détaillons les différentes techniques de tests fonctionnels pouvant être effectués sur un logiciel. Les tests fonctionnels consistent à vérifier pour une exigence donnée, un comportement spécifique d’un système. Les tests fonctionnels consistent à vérifier :
— Les fonctionnalités offertes à l’utilisateur
— Si le comportement attendu d’une fonctionnalité spécifique est correct
Une vue d’ensemble des techniques de tests existantes est présentée dans la figure2.2. Nous détaillons par la suite les deux catégories de tests fonctionnels :
— Le test statique qui consiste aux revues et inspections de code
— Le test dynamique qui consiste à sélectionner un ensemble de tests, les exécuter ensuite analyser les résultats obtenus puis les évaluer afin de déterminer l’arrêt de la phase de test. Le test dynamique peut être manuel et/ou automatisé.
2.3.1.1 Test statique
FIGURE2.2 – Techniques de tests
Ce type de test a été initialement utilisé pour optimiser les compilateurs [Muc97] [RCF10]. Il a également été utilisé pour déboguer le code des programmes [Wei81]. Il cor-respond à l’ensemble des tests qui ne nécessitent pas l’utilisation ou l’exécution du logi-ciel. Les « revues » sont le principal « type » de tests statiques. Nous distinguons différents types de revues :
— Les revues des documents ex : les cahiers des charges, les exigences, ...
— Les revues de codes (pour le code et/ou les tests automatisés). Elles permettent de trouver du code mort et de détecter des accès à des variables de mémoire non ini-tialisées. Parmi les outils utilisés pour ce genre de revues, nous trouvons PACOGEN [HBG11] qui se base sur les modèles de caractéristiques et Findbugs [HP04] qui se base sur le byte-code Java.
— Les revues de tests
Il existe également d’autres types de test statiques qui peuvent être exécutés avec des ou-tils avec lesquels on peut tester la qualité du code (ex : Sonar) et la couverture des tests (avec un ALM= Application Lifecycle Management)
2.3.1.2 Test dynamique
Le test dynamique permet également de trouver des problèmes dans les programmes par exemple : détecter si le programme accède ou non à des zones mémoires interdites... Il permet aussi de déboguer un programme en temps réel, en donnant la possibilité de re-garder ce qu’il se passe dans la mémoire et dans le processeur à n’importe quel moment de son exécution.
Tester dynamiquement un système c’est :
— Provoquer l’exécution du système dans des conditions bien définies et reproduc-tibles
— Obtenir les résultats de son comportement
— Décider si les résultats obtenus sont conformes aux spécifications
Il existe plusieurs techniques de conception de test. Ces techniques sont classées en deux catégories :
— Tests de boîte noire (Tests Fonctionnels)
— Tests de boîte blanche (Tests Structurels)
2.3.1.3 Tests boîte noire
Les tests boîte noire, dits aussi tests fonctionnels, consistent à visualiser le programme comme étant une boîte noire sans s’intéresser à sa structure interne. L’objectif de ces types de tests est de vérifier le comportement du logiciel par rapport aux fonctionnalités défi-nies dans sa spécification, c’est-à-dire si il fait ce qu’il est censé faire, sans s’intéresser à comment il le fait. Dans ce type de test, le testeur ne dispose d’aucune information sur le fonctionnement interne du programme. Il construit ses données de test en se basant uniquement sur les spécifications et sans connaître la structure interne du programme [MSB11][Lew04].
2.3.1.4 Tests boîte blanche
Les tests boîte blanche, appelés aussi tests structurels, consistent à revoir le fonction-nement d’une application et sa structure interne, en d’autres termes à revoir ses processus plutôt que ses fonctionnalités. C’est une technique de test qui vérifie le fonctionnement interne du système.
Les tests boîte blanche nécessitent des compétences en programmation, afin de com-prendre le code source du programme et nécessitent également d’avoir une vision globale du fonctionnement de l’application.
2.4 Model Based Testing
Le MBT est une technique de test qui consiste à générer automatiquement des scé-narios de tests à exécuter sur le SUT [UL07]. Cette génération est réalisée en se basant sur un modèle construit à partir des exigences fonctionnelles et, décrivant les compor-tements explicites du SUT, ses comporcompor-tements attendus et/ou le comportement de son environnement. Pour décrire un modèle de test, plusieurs formalismes ont été utilisés tel que les systèmes de transitions étiquetées, les machines à états, le diagramme d’activité UML [SKR07], et les chaînes de Markov [GT03], etc. Selon [UL07], tous ces modèles sont complémentaires et offrent toutes les possibilités indispensables pour la modélisation et la génération de cas de tests automatique. Dans ce travail, nous nous intéressons aux for-malismes basés sur des états-transitions.
Dans le cycle de développement en V, le MBT se positionne entre la phase des spécifi-cations et la phase de validation (figure2.3).
FIGURE2.3 – Cycle en V de développement d’un système
2.4.1 Processus MBT
Le processus du MBT est présenté dans la (figure2.4).
FIGURE2.4 – Processus de Model-based Testing
Il est composé de 5 étapes :
— Construction d’un modèle abstrait appelé modèle de test. Ce modèle est construit à partir d’un document de spécifications logicielles ou des exigences fonctionnelles.
— Définition des critères de sélection des tests, pour orienter la génération automa-tique d’une suite de tests. Les critères de sélection de tests peuvent concerner une fonctionnalité spécifique appelée du système « requirement-based selection critera », la structure du modèle de test (comme la couverture des états, la couverture des transitions et la couverture de données) et ils peuvent aussi être de caractère aléa-toire.
— Transformation des critères de sélection de tests en des descriptions de haut niveau d’un cas de test souhaité.
— Génération automatique des cas de tests et de suites de tests à partir du modèle construit
2.4.2 Formalismes MBT
Plusieurs formalismes ou notations ont été utilisés pour décrire un modèle afin de générer des cas de tests [UPL12].
Formalismes basés sur l’état (ou pré/post) : Ces formalismes modélisent un système comme étant une collection de variables, qui représentent l’état intérieur du SUT à un instant T, ainsi que certaines opérations qui modifient ces variables. Plutôt que de défi-nir les opérations à l’aide de code comme dans les langages de programmation, chaque opération est définie par une condition préalable (précondition) et une condition posté-rieure (postcondition). Un exemple de ces formalismes est la méthode JML (Java Mode-ling Language) qui est un formalisme pour spécifier formellement le comportement et les interfaces des classes et méthodes Java [AGH00].
Formalismes basés sur la transition : Ces formalismes se concentrent sur la descrip-tion des transidescrip-tions entre les différents états du système. Généralement, ces formalismes sont présentés graphiquement sous la forme des nœuds et des arcs, comme des machines à états finis FSM (Finite-State Machine) [CK93], où les nœuds des FSM représentent les principaux états du système et les arcs représentent les actions ou les opérations du sys-tème. Des formalismes textuels ou tabulaires sont également utilisés pour spécifier les transitions. En pratique, les formalismes basés sur les transitions sont souvent enrichis par l’ajout des variables de données, des hiérarchies de machines et de parallélisme entre les machines. Parmi les exemples de formalismes basés sur les transitions, on peut ci-ter les FSM eux-mêmes, les diagrammes d’état UML, les systèmes de transition étiquetés (Labeled Transition System (LTS)) et les automates d’entrée/sortie.
Formalismes basés sur l’historique : Ces formalismes modélisent un système en dé-crivant les traces autorisées de son comportement durant le temps. Diverses notions de temps peuvent être utilisées : discret ou continu, linéaire ou ramification, points ou in-tervalles etc. Cela conduit à de nombreux types de logiques temporelles différentes. Nous incluons également des graphiques de séquences de messages , comme les diagrammes de séquences UML. Il s’agit de formalismes graphiques et textuels pour spécifier les sé-quences d’interactions entre les composants du système.
Notations fonctionnelles : Ces formalismes décrivent un système comme un ensemble de fonctions mathématiques. Les fonctions peuvent être du premier ordre seulement, comme dans le cas de spécifications algébriques.
Formalismes stochastiques : Ces formalismes décrivent un système par un modèle probabiliste des événements et des valeurs d’entrée et tendent à être utilisés pour modé-liser les environnements plutôt que les SUT. Par exemple, les chaînes de Markov sont uti-lisées pour modéliser les profils d’utilisation attendus, afin que les tests générés exercent ce profil d’usage.
Formalismes des flux de données : Ces formalismes se concentrent sur les données plutôt que sur le flux de contrôle. Les exemples les plus marquants sont Lustre [CPHP87] et les diagrammes de structure composite UML [OMG05].
2.5 Les outils MBT
Il existe plusieurs outils de MBT. Dans cette section nous présentons les outils MaTeLo, TorX, Qtronic et JUMBL.
L’outil MaTeLo est un outil commercial de MBT basé sur l’approche de l’ingénierie dirigée par les modèles. MaTeLo est développé par la société ALL4TEC, permettant de générer automatiquement des tests fonctionnels à partir d’un modèle de test dédié ap-pelé modèle d’usage. MaTeLo offre un modeleur basé sur un formalisme stochastique (chaînes de Markov) pour représenter le comportement attendu du SUT.
L’outil TorX [TB03] est un outil académique de MBT, développé au cours du projet Côte de Resyste, permettant la génération des cas de tests à partir d’un modèle compor-temental du système sous test. TorX s’appuie sur un formalisme basé sur la transition (systèmes de transitions étiquetées (LTS)) et génère des cas de test de conformité entre le système et le modèle de test. Cet outil gère le ndéterminisme par une approche on-line du test, dans laquelle la génération et l’exécution des tests sont dépendantes.
L’outil Qtronic [Hui07] est un outil commercial de génération de tests basé sur un modèle développé par Conformiq. Qtronic s’appuie sur un modèle au format Qtronic Modeling Language (QML). QML est basé sur un formalisme basé sur la transition (un diagramme d’états) enrichi avec du code écrit en Java ou C#.
L’outil JUMBL (J Usage Model Builder) [Pro03] est un outil académique de MBT, déve-loppé à l’Université du Tennessee permettant la génération des cas de tests à partir d’un modèle de tests écrit en langage TML qui est un formalisme stochastique pour décrire un modèle d’usage basé sur les chaînes de Markov.
2.5.1 MaTeLo : Outil de Model-based Testing
acces-sible aux sociétés, et plus précisément l’outil MaTeLo, nous utilisons ce dernier dans ce travail.
MaTeLo est composé de trois fonctionnalités majeures :
— Construction d’un modèle de tests, appelé modèle d’usage.
— Génération automatique des cas de tests à partir du modèle d’usage en choisissant une stratégie de génération.
— Analyse de la campagne de tests.
2.5.1.1 Modèle d’usage de MaTeLo
Le modèle de test MaTeLo, appelé modèle d’usage, est un ensemble des chaînes de Markov étendues [GM02] [Gue05] où chaque chaîne est un diagramme états-transitions probabiliste. Ce modèle d’usage décrit l’utilisation du SUT que l’on considère comme une boîte noire.
Une formalisation mathématique du modèle d’usage de MaTeLo a été proposée par Hélène Le Guen [Gue05]. Ce modèle d’usage est représenté par un graphe de test noté GM.
Le modèle d’usage MaTeLo GMest représenté par le tuple : {S, si, sf, V, F, P, T, E} où :
— S = {s0, ..., sn} : Un ensemble fini d’états
— si ∈ S : L’état initial unique de la chaîne — sf ∈ S : L’état final unique de la chaîne
— V : Un ensemble des entrées (stimulation), des sorties (résultats attendus) et des variables globales
— F : Un ensemble de fonctions de traitement pour effectuer des calculs sur des va-riables : F (V1) = V2 avec V1, V2 ∈ V. V1 : un ensemble spécifique de vava-riables glo-bales et / ou une sélection des vecteurs d’entrée, V2 : un ensemble de vecteurs de sortie
— P : Un ensemble de profils d’usage
— T : Un ensemble de transitions probabilistes. Chaque transition possède un nom et une probabilité pr par profil p ∈ P. Pour chaque état sn−1 ∈ S, la somme des pro-babilités portées par l’ensemble des transitions sortantes de sn−1doit être égale à 1
— E : Un ensemble des exigences du SUT
Afin de construire un modèle d’usage MaTeLo valide, nous devons respecter les règles suivantes :
— L’état final sf possède uniquement des transitions entrantes.
— Chaque état sn−1∈ S doit avoir au minimum une transition entrante et une transi-tion sortante.
— Chaque état dans le modèle doit être accessible (directement ou indirectement) de-puis l’état initial si et doit mener à l’état final sf, en d’autres termes, chaque état doit être au minimum sur un des chemins commençant par l’état initial si et terminant par l’état final sf.
2.5.1.2 Outil MaTeLo
L’outil MaTeLo est basé sur la plateforme Eclipse (Eclipse Rich Client Platform :https: //wiki.eclipse.org/Rich_Client_Platform). Il est composé d’un ensemble de plug-ins où chaque ensemble offre une fonctionnalité majeure visible via des perspectives Eclipse. Une perspective est composée d’un ensemble d’onglets appelés "Vues".
L’outil MaTeLo offre trois perspectives :
— Edition.
— Génération.
— Reports.
2.5.1.3 Perspective Edition
FIGURE2.5 – MaTeLo : Perspective Édition
Les transitions représentent les actions à exécuter sur un SUT. Sur chaque transition nous pouvons associer :
— Une stimulation qui est composée d’un ensemble d’entrée où chaque entrée défi-nit une distribution (probabiliste, gaussienne, ...) (cf. Figure2.6) pour produire une valeur au moment de la génération.
— Un ensemble de vérifications où chaque vérification est composée d’un ensemble de résultats attendus.
— Un ensemble des fonctions de traitements et d’exigences.
— Une valeur de probabilité d’usage par profil défini (cf. Figure2.7).
FIGURE2.6 – Distribution des données
FIGURE2.7 – Probabilités des transitions
autre chaîne (voir section 2.8). Chaque transition porte pour chaque profil Pi une pro-babilité p ss0, qui correspond à la probabilité de choisir l’état s lorsque le processus de génération se trouve dans l’état s pour le profil Pi.
FIGURE2.8 – Modèle d’usage MaTeLo
2.5.1.4 Perspective Generation
La perspective Génération (Figure2.9) sert à générer les cas de tests. Elle est composée d’un ensemble de vues permettant la création des stratégies de génération et ensuite la génération des cas de tests. Cette perspective offre également une vue affichant les cas de tests générés.
Pour générer une suite de test, en d’autres termes un ensemble de cas de tests, l’utili-sateur doit choisir une stratégie de test. Une stratégie de test est composée de :
— Un profil d’usage.
FIGURE2.9 – MaTeLo : Perspective Génération
— Un algorithme de génération parmi ceux proposés par l’outil.
Un cas de test généré par MaTeLo commence toujours par l’état initial si et fini par l’état final sf. La génération des cas de test consiste à définir un chemin selon le profil et l’algorithme de génération de tests (critères de sélection des tests). Un cas de test est composé d’un ensemble d’étapes de tests où chaque étape est composée d’une stimula-tion (entrée) et d’un ensemble de vérificastimula-tion (résultats attendus).
Les cas de test générés par MaTeLo sont compatibles avec plusieurs bancs de test ce qui offre la possibilité de les exécuter d’une façon automatisée.
2.5.1.5 Perspective Report
La perspective Report (Figure2.10) sert à analyser la campagne de test. Elle est com-posée d’un ensemble de vues permettant la création de certains rapports, tel que le rap-port de couverture d’exigences, des entrées et des sorties, etc...
2.5.1.6 Algorithme de génération
FIGURE2.10 – MaTeLo : Perspective Report
FIGURE2.11 – Algorithme de génération
Les algorithmes disponibles par défaut dans MaTeLo sont :
— Path Coverage : Cet algorithme sélectionne les transitions à partir de l’état initial jusqu’à l’état final en se basant sur le profil d’usage personnalisé.
— Most Probable : Cet algorithme choisit la transition la plus probable pendant le par-cours du modèle.
— User-oriented : Cet algorithme couvre un ensemble fini de transitions à partir de l’état initial jusqu’à l’état final du modèle d’usage. Les transitions suivies sont choi-sies au hasard, selon le dispositif probabiliste défini par le profil en cours.
— Random : Cet algorithme sélectionne les transitions à partir de l’état initial jusqu’à l’état final d’une façon aléatoire.
Une fois que les cas de test sont générés, ils peuvent être exportés soit sous différents formats textuel (ex : Excel, Word, ...) pour une exécution manuelle (cf.2.12) soit sous un format de scripts de tests pour une exécution automatique (cf.2.13).
FIGURE2.12 – Rapport d’un cas de test
FIGURE2.13 – Exécution automatique de test
2.6 UML : Langage de Modélisation Unifié
Dans cette section nous présentons le langage de Modélisation UML. Ce langage a été utilisé pour créer des modèles de tests dans l’objectif de générer des cas de tests [Hui07].
Le langage de modélisation unifiée UML est défini comme étant un langage graphique de modélisation à base de pictogrammes utilisé pour visualiser la conception d’un tème. Il est largement utilisé durant le processus de conception et spécification des sys-tèmes. C’est le résultat de la fusion de trois langages de modélisation objet, à savoir Booch [Boo93], OOSE [Jac92] et OMT [RBP+90]. L’UML est devenu maintenant un standard adopté par le groupe de gestion objet OMG. La version 2.0 de UML est adoptée par l’OMG en 2005. En 2017, l’OMG a validé la dernière version de UML qui est le UML 2.5.1. Au cours des dernières années, le UML a réussi à s’imposer dans le domaine de modélisation objet et est devenu le standard le plus utilisé dans ce domaine.
On peut utiliser l’UML pour la spécification, la modification, la visualisation et la construc-tion de tous les documents nécessaires aboutissant à de meilleurs développements d’un logiciel orienté objet. Plusieurs éléments peuvent être modélisés en utilisant UML comme :
— Les activités des objets ou les activités dans le logiciel — Les utilisateurs du logiciel (Acteurs)
— Les processus
La version actuelle, UML 2.5, propose quatorze types de diagrammes. Ces diagrammes sont répartis en six diagrammes structurels et huit diagrammes comportementaux. Ces diagrammes sont complémentaires et sont hiérarchiquement dépendants.
2.6.1 Les diagrammes UML
Comme déjà présenté, les quatorze diagrammes proposés par l’UML sont groupés en deux catégories :
— Structurels ou Statiques
— Comportementaux ou Dynamiques
FIGURE2.14 – Les diagrammes UML
La catégorie « diagrammes structurels » comporte six diagrammes : — Diagramme de classes
— Diagramme d’objets
— Diagramme de composants — Diagramme de déploiement
— Diagramme de paquetages
— Diagramme de structures composites
La catégorie « diagrammes comportementaux » comporte huit diagrammes :
— Diagramme d’activité
— Diagramme d’interaction
— Diagramme de séquences
— Diagramme global d’interaction
— Diagramme de communication
— Diagramme de temps
Dans ce travail, nous présentons uniquement le diagramme de cas d’utilisation et le diagramme de séquences.
2.6.1.1 Le diagramme de cas d’utilisation
Le diagramme de cas d’utilisation UML est utilisé pour montrer le comportement fonctionnel global d’un logiciel. Il permet de montrer les différents services offerts par le système et les interactions faites entre les utilisateurs et le système. Les utilisateurs, appe-lés les acteurs (utilisateurs humains ou machines), interagissent avec des unités discrètes dans le système qui s’appellent cas d’utilisation. Un acteur est représenté graphiquement en utilisant un pictogramme humanoïde ayant comme sous-titre le nom de l’acteur. Par contre, une simple ellipse contenant un nom est utilisée pour représenter un cas d’utili-sation. L’interaction entre un acteur et un cas d’utilisation est représentée graphiquement par une ligne. La figure2.15représente un exemple d’un diagramme de cas d’utilisation.
FIGURE2.15 – Diagramme de cas d’utilisation
On peut distinguer plusieurs rôles d’un acteur qui peut intervenir dans plusieurs si-tuations comme l’initiateur d’un cas, le rôle d’un serveur, récepteur d’information ou fa-cilitateur d’un autre acteur.
Plusieurs types de relations peuvent être définis entre deux cas d’utilisations ou entre deux acteurs. Les relations entre deux cas d’utilisation sont :
— Relation d’extension : On dit qu’un cas d’utilisation A étend un autre cas d’utilisa-tion B si A peut être appelé quand B est exécuté.
— Généralisation : Un cas d’utilisation A est une généralisation d’un cas d’utilisation B si B est un cas particulier de A.
Une seule relation peut être définies entre deux acteurs. C’est la relation de générali-sation. Un acteur A est une généralisation d’un acteur B si l’acteur B peut faire toutes les interactions que A fait en plus d’autres qui sont spécifiques à B.
2.6.1.2 Les diagrammes de séquences
Un diagramme de séquences est une représentation graphique des interactions entre les acteurs et les composants du système. Dans ce diagramme, l’ordre chronologique des interactions est montré. Le diagramme de séquences (cf.2.16) montre les interactions entre les objets dans un scénario décrit dans le diagramme de cas d’utilisation. Les acteurs principaux sont montrés à gauche du diagramme au contraire des acteurs secondaires qui prennent place à droite de la figure. Le temps est représenté dans ce diagramme par un trait (ou rectangle) vertical afin de visualiser l’enchaînement des messages, la naissance ou la disparition des objets. Les messages (ou actions) transitant entre les acteurs et les objets peuvent être de plusieurs types.
La dimension verticale du diagramme représente le temps, permettant de visualiser l’enchaînement des messages (actions) avec le temps, et de spécifier la naissance et la mort d’objets. Les périodes d’activité des objets sont symbolisées par des rectangles, et ces objets dialoguent à l’aide de messages.
Plusieurs types de messages (actions) peuvent transiter entre les acteurs et les objets.
— Message simple : Sans spécification particulière d’envoi et de réception.
— Message avec durée de vie : L’expéditeur du message attend une réponse du récep-teur. Si durant un certain délai de temps rien n’est reçu, l’expéditeur reprend ses activités.
— Message synchrone : L’expéditeur du message est bloqué jusqu’au la réception d’un signal indiquant la prise en compte du message par le destinataire.
— Message asynchrone : L’expéditeur envoie le message et continue son activité peu importe que le message soit pris en compte par le destinataire ou non.
— Message dérobant : Le message reçu par un destinataire est mis dans une file d’at-tente de traitement
FIGURE2.16 – Diagramme de séquences
— 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.
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).
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
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é.
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.
