Chapitre 6 SeTGaM pour les diagrammes d’états-transitions
6.3 Analyse des exigences impactées par l’évolution
Dans cette section, nous décrivons l’analyse de dépendances de données et de contrôle dans le but d’identifier et classifier les tests existants de la version précédente du modèle. Nous détaillons la façon dont les exigences impactées sont calculées et ensuite les règles de classification des tests vis-à-vis de la nouvelle version du modèle.
6.3.1
Calcul des impacts
Afin de calculer les transitions impactées dans une version évoluée d’un diagramme d’états/transitions, nous nous basons sur le calcul de la différence entre les deux versions de modèles et les dépendances obtenues pour les deux versions (version évoluée et cou- rante). L’algorithme 6 de calcul d’impacts prend ainsi en compte les dépendances des deux versions et les différences entre les versions. Nous allons considérer la fonction merge qui prend en compte deux diagrammes de dépendances D et D0 en entrée et elle renvoie un diagramme dependenceDiff composée des deux diagrammes en résultat. La composition est faite en utilisant le principe de marquage des graphes de façon à ce que :
6.3. Analyse des exigences impactées par l’évolution l’ensemble dependenceDiff et marquées par le signe distinctif deleted .
– les dépendances qui sont ajoutées dans D0 par rapport au D sont ajoutées à l’en- semble dependenceDiff et marquées par le signe distinctif added .
– toutes les autres sont ajoutés à dependenceDiff et par le signe distinctif none. Pour le calcul des impacts, nous considérons qu’une arrête dans le graphe de dépendances est représentée par le quadruple (t , t0, v , m) où t0 est la transition dépendante de t , et v est soit la variable (dans le cas d’une dépendance de données), soit vide si dépendance de contrôle, m est la marque mise à jour lors de l’appel de la fonction merge. Nous dénotons l’ensemble de transitions impactées Impactee. Les transitions qui ne sont ni impactées, ni modifiées, ni ajoutées, ni supprimées du diagramme d’états/transitions sont appelées des transitions non-impactées. Leurs ensemble est dénoté Nonimpactee.
Données : diff : ensemble de différences entre les modèles;
D, D’ : dépendances pour les deux modèles d’états/transitions M et M’ respectivement; Sorties : impacts : ensemble de transitions impactées par le changement;
dependeceDiff = merge(D,D’);
pour chaque Dépendance Q(t,t’,v,m) ∈ dependenceDiff faire si t,t’ /∈ diff & m 6= none alors
impacts.add(t); impacts.add(t’); sinon
si t ∈ diff & t’ /∈ diff alors impacts.add(t’); fin
fin fin
Algorithme 6: Calcul des transitions impactées lors d’évolution de la spécification Lors du calcul des impacts dans le diagramme d’états/transitions, chaque transition est associée à une exigence. De cette manière, nous pouvons remonter les exigences impactées à l’utilisateur.
Transition Dépendances de données Dépendances de contrôle Impactée Variable login-success register-success * goToRegister
buy-success * current user x x
login-success x x x
all registered users x
register-success * x x
goToHome-fromReg x
Table 6.4 – Calcul des impacts sur un fragment d’eCinema
Pour illustrer le calcul de transitions/exigences impactés, dans le tableau 6.4 nous présentons un récapitulatif des dépendances entre les transitions et le résultat du calcul des impacts. Sur le tableau nous marquons par ∗ les transitions changées suite à l’évolution. Pour rappel, buyTicket − success est supprimée et cinq nouvelles transitions sont ajoutées et la transition register − success est modifiée. Nous pouvons constater que la transition login −success est impactée suite aux modifications dans les dépendances avec buyTicket − success et register − success. Ces dernières sont aussi impactées par l’évolution, mais elles
font partie de l’évolution, pour cela nous ne les considérons pas dans l’ensemble des impactées.
6.3.2
Règles de catégorisation des tests
Les règles de classification des tests dans les suites de tests ont été définies dans le chapitre précédent. Dans cette section, nous donnerons les règles de catégorisation d’un test ou encore d’attribution de statut d’un test, identifié à partir des diagrammes d’états/transitions.
Nous pouvons dire que le principe de la catégorisation des tests se base sur deux versions de modèles et se déroule en trois étapes :
1. calculer les exigences impactées, 2. définir les statuts des tests existants,
3. générer des tests new pour maintenir la couverture des exigences.
La première étape a été détaillée en section 6.3.1. Par la suite, nous prendrons en compte les changements et les éléments impactés et nous allons les utiliser pour déterminer le statut des tests. De manière informelle, le processus va pour chaque exigence supprimée classifier les tests correspondants en tant qu’outdated, pour chaque exigence modifiée ou impactée, classifie les tests correspondants dans la catégorie intermédiaire retestables. Les tests de cette catégorie seront animés sur le nouveau modèle afin de déterminer leur statut définitif et les classifier en tant que : updated, adapted, failed, reexecuted. Pour les nouvelles exigences, nous allons utiliser l’outil de génération pour créer de nouveaux tests. Enfin pour toutes les autres exigences, l’algorithme classifie les tests correspondants (s’ils n’ont pas été déjà sélectionnées précédemment) en tant qu’unimpacted. Nous rappelons qu’un test peut couvrir plusieurs exigences. Afin d’avoir un classement déterministe et non- ambigüe de chaque test, nous donnons des critères de supériorité dans la détermination de statut d’un test existant du plus fort vers le moins fort :
outdated → retestable → unimpacted
En tenant compte de la priorité de cet ordonnancement, nous formalisons la classification par les règles définies ci-dessous. Afin de maintenir la couverture sur les nouvelles cibles ainsi que les existantes, nous définissons les règles suivantes. Pour construire nos règles, nous utilisons la définition du test donnée dans la section 2.3, les définitions de transition ajoutée, supprimée, modifiée données en section 6.1, ainsi que les notations de transition impactée et non-impactée, section 6.3.1.
Règle 6 (RT-New) Le test correspondant à une nouvelle transition qui n’a été couverte par aucun test existant.
6.3. Analyse des exigences impactées par l’évolution Règle 7 (RT-Unimpacted) Le test correspondant à une transition non impactée et non modifiée i.e non impactée est classifié en tant qu’Unimpacted.
∀ T ∈ Nonimpactee and T .TAGS ∈ tags(tcn+1); status(tcn+1) = unimpacted
Règle 8 (RT-Outdated) Le test correspondant à une transition supprimée est classifié en tant qu’Obsolete.
∀ T ∈ Supprimee and T .TAGS ∈ tags(tcn+1); status(tcn+1) = outdated
Règle 9 (RT-Retestable) Le test correspondant à une transition modifiée ou à une exigence impactée est classifié en tant que Retestable.
∀ T ∈ {Modifiee ∪ Impactee} and T .TAGS ∈ tags(tcn+1)
; status(tcn+1) = retestable
Les tests sont ensuite animés sur le modèle afin d’obtenir leur statut définitif : reexe- cuted, updated, failed.
Toujours pour maintenir la couverture des cibles, il faut prendre en compte les tests qui n’ont pas pu être animés sur le nouveau modèle ou les tests outdated qui couvrent des exigences qui peuvent toujours exister dans la nouvelle version. Pour ce faire, nous devons générer des tests pour les couvrir. Ces tests ne peuvent pas être désignés en tant que nouveaux, puisqu’ils ne couvrent pas de nouvelles exigences, nous les appelons adapted. Règle 10 (RT-Adapted) Le test correspond à une exigence existante et non couverte par les tests actuels. Elle devient une cible de tests pour laquelle un test adapted est créé. ∀ T ∈ uncovered ; status(tcn+1) = adapted
Nous considérons l’évolution de buyTicket et register présentés dans la Section 6.1, le détail sur le calcul de dépendances et d’impacts est respectivement donné en Section 6.2 et Section 6.3.1. Afin d’illustrer la classification des tests, nous considérons les trois tests suivants :
(1) ECinema::sut.login(REGISTERED USER, REGISTERED PWD); ECinema::sut.buyTicket(TITLE1);
(2) ECinema::sut.goToRegister();
ECinema::sut.register(UNREGISTERED USER, UNREGISTERED PWD); ECinema::sut.buyTicket(TITLE1);
(3) ECinema::sut.login(REGISTERED USER, REGISTERED PWD); ECinema::sut.logout();
Les tests (1) et (2) sont classifiés en tant que outdated, suite aux calculs de différences et la suppression de l’exigence :
TAGS : BUY TICKET , Buy Success
Cependant, le test (2) couvre une exigence qui est toujours présente, même si elle est modifiée. Le générateur de tests est appelé et crée un test adapted afin de la couvrir :
ECinema::sut.register(UNREGISTERED USER, UNREGISTERED PWD, SUB NORMAL); ECinema::sut.buyTicket(TITLE1);
Enfin, le dernier test (3) est classifié d’abord en tant que retestable, suite à l’impact sur la transition login-succes. Après exécution sur le modèle, il est classifié en tant que updated , parce que son oracle a changé i.e. l’instance de l’utilisateur est modifié et il contient un abonnement. Il est à noter que l’exécution du test sur le système se comporte comme prévu précédemment.
(3) Updated ECinema::sut.login(REGISTERED USER, REGISTERED PWD); ECinema::sut.logout();
Finalement cinq nouveaux tests sont créés par le générateur pour couvrir les nouvelles exigences.
(1) ECinema::sut.login(YOUNG USER, YOUNG PWD); ECinema::sut.buyTicket(TITLE1);
(2) ECinema::sut.login(STUDENT USER, STUDENT PWD); ECinema::sut.buyTicket(TITLE1);
(3) ECinema::sut.login(SENIOR USER, SENIOR PWD); ECinema::sut.buyTicket(TITLE1);
(4) ECinema::sut.login(ONEFREE USER, ONEFREE PWD); ECinema::sut.buyTicket(TITLE1);
(5) ECinema::sut.login(NORMAL USER, NORMAL PWD); ECinema::sut.buyTicket(TITLE1);
6.4
Synthèse
Nous avons proposé une technique basée sur les modèles UML/OCL, et plus particu- lièrement les diagrammes à états/transitions, pour prendre en compte le test des systèmes évolutifs. Notre but est d’éviter la re-génération complète de la suite de tests pour chaque évolution du système. Nous avons proposé d’analyser les dépendances extraites du mo- dèle en fonction de l’évolution faite, et ainsi d’identifier automatiquement les tests qui ont été impactés par l’évolution, et ceux qui ne l’ont pas été. Nous avons introduit dans le chapitre 5 la notion de cycle de vie du test.
Dans ce chapitre, nous avons défini les règles qui permettent l’identification de chaque statut de test, s’il est toujours valide pour la nouvelle version ou s’il est obsolète ou s’il doit être recalculé. L’exemple fil rouge illustre bien l’utilité de la méthode, qui permet d’avoir une génération et une gestion de tests sophistiquée, ce qui est une des préoccupations principales dans l’industrie. Une gestion de la traçabilité des exigences est garantie par les tags. Finalement, l’historique est gardé et assuré d’une version à une autre, ce qui facilite le travail de l’utilisateur. Dans le chapitre suivant, nous présentons la méthode appliquée aux modèles n’utilisant pas le diagramme d’états/transitions.