L’évolution du cycle de vie des tests

5.2.1 Suite de tests . . . 61 5.2.2 Composition des suites de tests . . . 62 5.3 Gestion du référentiel de tests . . . 63 5.4 Synthèse . . . 64

Dans la première partie, nous venons de voir les principes du MBT et du test de non-régression. Les approches associées au test de non-régression ont pour vocation de sélectionner les tests pour vérifier le bon fonctionnement des parties inchangées dans le système sous test après modification. Cependant, il n’existe pas d’équivalent pour s’oc- cuper de valider la suppression des fonctionnalités du système devenues obsolètes lors de l’évolution, ni de tester les nouveautés apparues.

Dans cette partie, nous traitons la classification des tests et définition de leur cycle de vie durant l’évolution des exigences. Pour ce faire, le chapitre 5 défini le cycle de vie d’un test, introduit les statuts et permet de regrouper les tests en des catégories utilisables pour la validation du SUT. Pour établir le statut des tests, nous devons déterminer ce qui a évolué dans le modèle et l’impact de cette évolution sur les tests.

Le processus global de la méthode que nous proposons, nommée SeTGaM, est illustré sur la figure 5.1. Elle est basée sur deux versions de modèles, celui de référence M et son évolution M’. Tout d’abord dans l’étape ¬, elle compare les exigences, exprimées par le code OCL du diagramme d’états/transitions ou celui des opérations du diagramme de classes. Nous proposons un algorithme qui permet de déduire les impacts de l’évolution du modèle sur les tests existants. Ainsi, à l’étape _{­ les résultats de la comparaison d’une}

Figure 5.1 – Processus global de SeTGaM

part et les calculs des graphes de dépendances d’autre part, permettent d’effectuer une analyse des tests impactés. À l’étape _{®, cet impact est pris en entrée d’un calcul qui} détermine le statut du test comme décrit dans la section 5.1.

Ceci permet de le classifier dans une des suites données, comme expliqué dans la section 5.2, afin de valider le nouvel état du système. Enfin, la suite de tests pour le modèle M’ est construite à partir des tests valides pour le modèle M’.

Dans les chapitres qui suivent, nous allons détailler les différents briques nécessaires à cette méthode comme illustré sur la figure.

Les chapitres 6 et 7 présentent la méthodologie qui permet de déterminer les évolutions de modèles UML/OCL et son impact sur les exigences et sur les tests. Ils traitent respec- tivement les deux approches retenus par la définition de comportements au niveau des modèles UML/OCL, plus précisément UML4MBT. Ce sont respectivement l’utilisation de diagramme d’états/transitions et des opérations.

Le dernier chapitre de cette partie définit l’approche SeTGaM pour la prise en compte de la dimension sécurité.

Dans ce chapitre, nous allons poser les bases d’une approche qui permet de répondre à ce problème. Nous allons tout d’abord introduire le cycle de vie d’un test à travers l’évo- lution des exigences dans le système, qui sera plus précisément raffiné par chacune des méthodes axes de SeTGaM. Pour ce faire, nous proposons de compléter la nomenclature du cycle de vie d’un test, telle que proposée dans [BLH09, LW89] entre les différentes versions du système. Ensuite, nous allons regrouper les tests selon leur statut en quatre différentes suites de tests : Regression, Stagnation, Evolution et Deletion. Chacune d’elle a pour vocation de tester une spécificité lors de l’évolution i.e. les éléments inchangés, les supprimés, les nouveautés et la dernière pour sauvegarder les tests qui étaient précédem- ment dans la suite de tests Stagnation.

5.1. L’évolution du cycle de vie des tests Ce chapitre est organisé de la manière suivante. Dans le section 5.1, nous allons définir le cycle de vie des tests. Ensuite dans le section 5.2, nous allons identifier les règles pour classifier les tests dans une suite de tests en fonction de leurs statut dans le cycle. Nous verrons en section 5.3 comment le référentiel de test est géré pour aider à la validation de la nouvelle version du système, avant donner une synthèse de ce travail en section 5.4.

5.1

L’évolution du cycle de vie des tests

Dans cette section, nous introduisons la notion d’évolution pour le test. Ainsi, chaque test possède une version qui est associée à un statut, celui-ci indique l’état du test dans le cycle de vie.

Le cycle de vie d’un test est décrit dans la figure 5.2. Nous avons étendu la classifi- cation des tests par Leung et White [LW89], qui proposent les statuts obsolete, reusable, retestable, new specification et new structural. À la différence de Leung et White, nous avons défini huit statuts dans le cycle de vie du test pour raffiner leur classification. De plus, nous considérons qu’il doit exister un autre statut temporaire (non présent dans le cycle de vie) Involved. Les tests de cette catégorie Updated et Adapted sont ceux qui sont impactés par l’évolution des exigences.

Dans le cycle de vie de tests, décrit dans la figure 5.2, un test lors de sa création couvre une nouvelle exigence dans le système et possède le statut new, ce qui est donc le statut initial pour chaque test. Lors d’une évolution des exigences, un test ne peut pas revenir à cet état initial et il évolue en trois directions : impacté, supprimé ou non-impacté (ou inchangé). Dans le premier cas, son statut change en updated ou adapted parce son oracle ou ses pas sont modifiés suite à l’évolution. Dans le deuxième cas, il est obsolète et peut prendre deux statuts : outdated, si l’exigence qu’il couvre est supprimée ou failed, s’il couvre une exigence impactée ou modifiée. La version précédente d’un test adapted est mise en failed. Un test obsolète peut devenir seulement removed et il sera gardé seulement pour l’historique. Enfin, un test ni impacté ni supprimé, peut prendre deux statuts : reexe- cuted, s’il couvre une exigence impactée mais ne relève aucun changement dans l’oracle du test ou unimpacted, s’il couvre une exigence non modifiée et non impactée. Avec l’aide de ces statuts nous construisons quatre suites de tests : Evolution, Regression, Stagnation et Deletion pour tester respectivement l’évolution, la non-régression et la stagnation et garder une trace des tests obsolètes pour une stabilité du référentiel de tests.

Plus précisément, l’évolution du statut est définie en considérant deux versions de modèles, M et M0, pour lesquels il y a eu un ensemble d’évolutions du type d’ajout, de modification ou de suppression des éléments du modèle (opérations, comportements, transitions etc.). Comme déjà expliqué dans la section 2.3, chaque test a pour but la couverture d’une cible de test. Une cible peut être l’activation d’une transition dans la machine à états/transitions, ou encore la couverture des comportements issus du code

Figure 5.2 – Cycle de vie de tests OCL d’une opération.

Nous définissons un cas de test évolutif comme un cas de test pouvant changer de statut à chacune de ses versions

Définition 2 (Cas de test évolutif ) Un cas de test évolutif tc est un cas de test ca- ractérisé par son statut et la version considérée. On le note tcn _{où n est la version du}

modèle pour lequel le test tc couvre une cible de test. On note status(tcn_{) le statut associé}

à tcn_.

status(tcn) ∈ {new , adapted , updated , unimpacted , reexecuted , failed , outdated , removed } Remarque : status(tc1_{) = new}