Panorama des techniques sélectives

est souvent utilisée dans l’industrie, les limites lors de l’analyse des régressions sont très vite atteintes. Pour cela, une grande attention est portée au techniques sélectives.

3.1.2

Classification des techniques sélectives

Dans la littérature, plusieurs auteurs ont produit des études de techniques sélectives de non-régression en les catégorisant de différentes manières [RHG+01, ESR08, YH10, BMSS11]. Cependant, la plupart d’entre elles se réfèrent aux catégories définies par Har- rold et al. [RHG+_{01] :}

1. techniques de minimisation : choisir le nombre minimal de tests depuis la suite de tests d’origine, ceux qui passent par les instructions modifiées ou affectées du programme. Par exemple, Fischer et al. [KFA81] utilisent un système d’équations linéaires pour exprimer le lien entre les tests pour que chaque élément du programme soit exercé par au moins un test.

2. techniques basées sur la couverture : choisir les tests en tenant compte d’une part de la couverture des transitions et des chemins dans le programme par les tests et d’autre part de la couverture en utilisant le graphe de dépendances.

3. techniques sûres (en anglais safe techniques) : une technique est dite sûre si elle a sélectionné tous les tests de la suite de tests initiale qui peuvent révéler des fautes dans le système. La plupart des techniques de minimisation et de flots de données ne sont pas sûres. Cependant, il existe plusieurs travaux dans ce domaine : Laski et Szermer [JW92], Rothermel et Harrold [RH97] et Vokolos and Frankl [VF98]. Cette technique est utilisée et détaillée par Rothermel et Harrold dans [RH96], et implémentée dans l’outil nommé DejaVu.

4. techniques aléatoires (en anglais ad-hoc random techniques) : sélection au hasard d’un nombre de tests prédéfinis de la suite de tests du programme. Cette technique est souvent utilisée quand il manque du temps pour les tests.

3.2

Panorama des techniques sélectives

Dans cette section, d’après la catégorisation des techniques sélectives, nous allons donner un panel des techniques sélectives basées sur les modèles dans la section 3.2.1 et nous allons présenter le cadre d’évaluation des techniques de non-régression dans la section 3.2.2.

3.2.1

À partir de modèles

Les solutions MBT pour le test de non-régression dépendent du type de modèle et de ou des techniques choisies. Dans Tahat et al. [TBVK01], nous retrouvons une étude sur les SDL9 systèmes et la notion d’exigence pour la génération des tests de non régression. Le but est de couvrir tout le système avec ces tests.

Donc, dans le but d’exprimer les exigences, nous pouvons utiliser des fragments SDL in- dividuels du système. Ensuite, nous pouvons les rassembler en un seul système SDL. À partir de là, nous pouvons le transformer en modèle EFSM10_{, qui va être l’entrée pour}

la génération des tests boîte-noire. Le langage descriptif des EFSM est donc utilisé pour repérer plus facilement l’évolution du système et mapper les exigences qu’ils utilisent. De cette manière ils ont défini des règles pour l’addition, la suppression et la modifica- tion d’une exigence, qui peut être interne ou suite à un changement d’une autre transition. Dans Korel et al. [KHV02], nous retrouvons une méthode qui est un complément de la précédente mais plus précise car elle utilise l’analyse des dépendances (Data et Control Dependencies). La sélection de tests de la suite d’origine est effectuée selon des Patterns. Les Patterns sont créés selon les différents effets : l’effet du modèle sur la modification, la modification sur le modèle et autres effets secondaires causés par la modification. Un test est inclus dans la RTS (suite de test de non régression) si au moins un des patterns d’interaction n’existe pas dans la sélection des tests.

D’autre part, Chen et al. [UPC07] décrivent une analyse des dépendances beaucoup plus approfondie définissant les règles et les dépendances pour chaque modification élémen- taire. Au total, nous retrouvons douze dépendances différentes. Ici, le mot dépendance est très proche de la signification du Pattern défini par Korel et al. La suite de test réduite contient les tests vérifiant les effets directs et indirects du modèle modifié, ayant pour but de couvrir toute les nouvelles dépendances par modification.

Récemment, nous retrouvons des études qui portent en partie sur le langage unifié de modélisation UML. Plus exactement, Briand et al.[BLH09] font une étude des tests de non régression sur les diagrammes de classes, les cas d’utilisation et les diagrammes de séquences. La méthode propose dans un premier temps de définir les différences entre les deux modèles. Ensuite, ils classifient les tests d’après la classification de Leung et White [LW89] en trois catégories : tests obsolètes, tests re-testables et tests réutilisables. Finalement, ils ont créé un outil pour des programmes en langage C qui automatisent cette méthode, nommé RTSTool. C’est ici que nous retrouvons l’un des nos objectifs prenant en compte le cycle de vie des tests, qui va nous servir par la suite dans le développement de notre méthode.

9. Specification Description Language 10. Extended Finite State Machines

3.2. Panorama des techniques sélectives La modélisation pour le test en UML, est très répandue et trouve son utilité dans l’industrie [UPL12]. Ainsi, plusieurs techniques de non-régression sont créées pour les modèles UML. Gorthi et al. [GPCL08] ont proposé une technique basée sur les diagrammes d’activités. Ils utilisent le slicing de comportements afin d’identifier les changements dans le diagramme. À chaque fois qu’une exigence est modifiée le diagramme d’activités est modifié dans le but de refléter l’évolution (le changement). Ainsi, chaque chemin dans le diagramme qui contient des noeuds modifiés est considéré comme chemin affecté par le changement. Ainsi, les tests qui exécutent ces chemins affectés sont sélectionnés pour le test de non-régression.

Naslavsky et Richardson [NR07], en se basant sur le flot de contrôle du diagramme de séquences, créent une traçabilité entre les cas de tests et le diagramme de séquences, ce qui permet d’identifier quels éléments du flot de contrôle sont exécutés par un test donné. Les flots de contrôle des deux systèmes sont analysés pour identifier les éléments affectés par le changement et la traçabilité est utilisée pour sélectionner des tests.

Farooq et al.[FIMN07, FIMR10] présentent une technique basée sur le UML 2.1, en uti- lisant des diagrammes d’états/transitions comportementales et des diagrammes de classes pour la sélection de tests. Leur technique permet de retrouver directement ou indirecte- ment l’élément affecté en UML, en utilisant l’information de la classe ou du diagramme d’états/transitions modifié i.e une transition est considérée comme modifiée si elle utilise un attribut ou une méthode modifiée dans son action, garde ou événement. Les tests qui couvrent ces transitions sont considérés comme des tests retestables.

3.2.2

Cadre d’évaluation des techniques

Rothermel et Harrold dans [RH96] définissent un cadre pour évaluer les techniques de test de non-régression :

– inclusive ou sûre : une technique est sûre si elle a sélectionné tous les tests dont les résultats (ou encore l’oracle) d’exécution sur le nouveau système sont différents. Ces tests sont aussi appelés modification-revealing.

– précise : une technique est précise lorsqu’elle ne sélectionne que des tests qui pro- duisent un oracle différent après l’exécution sur le nouveau système.

– efficace : pour ce critère il y a plusieurs facteurs à prendre en compte. Le premier facteur est la sélection de tests lors du cycle de vie de la technique elle-même. Elle peut être appliquée lors d’une phase préliminaire i.e. correction du logiciel après une livraison logiciel intermédiaire. La deuxième c’est la phase critique, qui commence après les corrections du logiciels. Ici le test de non-régression est limité en temps, souvent borné par le temps de livraison du logiciel. La minimisation du coût du test de non-régression est très important à ce moment là. Ensuite le deuxième facteur est l’automatisation de la technique. Le troisième facteur est la capacité de la technique

à calculer les modifications vis à vis de la nouvelle version. Enfin, le dernier facteur est que la technique soit applicable sur plusieurs modifications à un instant donné. – générale : une technique est dite générale quand elle est applicable dans plusieurs situations. Plusieurs facteurs doivent être pris en compte tel que le fonctionnement sur plusieurs cas pratiques, prise en compte des cas réalistes, un nombre minimal d’assomptions et indépendance d’outils d’analyse de programmes.

Les techniques [FIMN07, FIMR10, BLH09], sont des techniques sûres d’après la struc- ture d’évaluation de Rothermel et Harrold [RH96].

Enfin, beaucoup de ces techniques, ainsi que d’autres basées sur les modèles ont été détaillées dans les études [RHG+01, ESR08, YH10, BMSS11] où les auteurs montrent l’efficacité, la sûreté, la précision de telles techniques et soulignent le besoin de modéliser pour tester la non-régression.