Illustration simplifi ´ee du processus de g ´en ´eration de tests `a partir de

´

ETAPE 1 : CONCEPTION DU MODELE DU SYST` EME SOUS TEST`

Un mod `ele abstrait du syst `eme est conc¸u `a partir des exigences, habituellement ex- prim ´ees sous la forme de sp ´ecifications informelles ou, plus rarement, de sp ´ecifications formelles (voir l’ ´etape 1 sur la figure 3.1).

Le mod `ele d ´ecrit les comportements attendus du syst `eme sous test et mod ´elise ´egalement son environnement : le contexte dans lequel le syst `eme sera utilis ´e et les contraintes qui en r ´esultent. Un ”bon” mod `ele de test ne mod ´elise cependant qu’une par- tie des comportements attendus et de son environnement : il vise `a tester une partie du syst `eme sous certaines contraintes, et non pas `a tester le syst `eme complet dans son environnement r ´eel d’utilisation. Sans cette abstraction du syst `eme et de son environne- ment, le mod `ele poss ´ederait la m ˆeme complexit ´e que le syst `eme r ´eel, ce qui annulerait l’int ´er ˆet de la mod ´elisation.

´

ETAPE 2 : D ´EFINITION DE CRITERES DE S` ELECTION DE TESTS´

La d ´efinition de crit `eres de s ´election de tests (voir l’ ´etape 2 sur la figure 3.1) permet de d ´ecrire les comportements fonctionnels ou structurels devant ˆetre couverts par les tests.

Les crit `eres de s ´election d ´efinissent donc ce qui doit ˆetre couvert par les tests, c’est- `a-dire un comportement ou une propri ´et ´e particuli `ere du syst `eme, et comment cette couverture pourra ˆetre mesur ´ee.

Dans le cadre de cette th `ese, on s’int ´eresse particuli `erement `a la g ´en ´eration de tests r ´ealisant la couverture de tous les ´etats abstraits et de toutes les transitions abstraites : il s’agit d’un crit `ere structurel de s ´election des tests. Le syst `eme abstrait ´etant calcul ´e `a partir de pr ´edicats d’abstraction constituant les gardes des ´ev ´enements apparaissant dans un objectif de test, les tests couvriront ´egalement partiellement cet objectif de test, donc un comportement fonctionnel exig ´e du syst `eme.

´

ETAPE3 : G ´ENERATION DES CAS DE TEST´

La g ´en ´eration des cas de test est ensuite r ´ealis ´ee `a l’aide du mod `ele et en fonc- tion des crit `eres de s ´election de tests (voir l’ ´etape 3 sur la figure 3.1). Typiquement, un algorithme ayant pour objectif de r ´epondre aux crit `eres de s ´election de tests est appliqu ´e au mod `ele. Il existe de nombreuses m ´ethodes de g ´en ´eration de tests dans la litt ´erature [Broy et al., 2005, Jaffuel et al., 2006], visant des crit `eres de couvertures vari ´es. G ´en ´eralement, les cas de test issus d’un mod `ele sont repr ´esent ´es par des traces d’ex ´ecution indiquant les entr ´ees `a appliquer au syst `eme, les op ´erations `a effectuer et les ´etats dans lesquels le syst `eme doit se trouver `a l’issue de ces op ´erations.

´

ETAPE4 : EXECUTION DES TESTS SUR L´ ’IMPLEMENTATION´

Une fois les cas de test g ´en ´er ´es, il convient de les ex ´ecuter sur le syst `eme afin de com- parer les r ´esultats attendus (tels que d ´ecrits par les tests) et les r ´esultats effectivement obtenus (voir l’ ´etape 4 sur la figure 3.1).

Puisque les tests sont issus d’un mod `ele abstrait du syst `eme, ils ne sont g ´en ´eralement pas directement ex ´ecutables sur ce dernier. Une phase d’adaptation des tests est donc souvent n ´ecessaire : elle consiste `a traduire les tests abstraits en tests concrets dont les entr ´ees peuvent ˆetre appliqu ´ees au syst `eme impl ´ement ´e et dont les sorties attendues sont directement comparables avec ceux obtenus sur le syst `eme.

Un test est dit passant lorsque le r ´esultat attendu dans les tests est conforme `a ce- lui obtenu sur le syst `eme et non-passant lorsqu’il ne l’est pas. Un test passant ne met aucun probl `eme en ´evidence mais permet de renforcer la confiance dans le syst `eme impl ´ement ´e, `a supposer que le test lui-m ˆeme et donc le mod `ele dont il est issu corres- pondent bien aux sp ´ecifications. Un test non-passant met en ´evidence un probl `eme au niveau de l’impl ´ementation ou de la conception du mod `ele lorsque celui-ci ne d ´ecrit pas le syst `eme de mani `ere suffisamment pr ´ecise (d’o `u l’int ´er ˆet de valider le mod `ele vis- `a-vis des sp ´ecifications).

3.2/

G ´

´

`

’

Malgr ´e la premi `ere abstraction que le mod `ele constitue par rapport au SUT, ce mod `ele peut malgr ´e tout d ´efinir un espace d’ ´etats de grande taille ou infini, rendant diffi- cile voire impossible la g ´en ´eration automatique de tests pour certains crit `eres de

couverture du mod `ele. On proc ´edera alors `a une abstraction du mod `ele lui-m ˆeme, dans le but de maˆıtriser la taille de son espace d’ ´etats. Sauf mention contraire, le

terme abstraction employ ´e dans ce m ´emoire d ´esigne cette phase d’abstraction du

mod `ele lui-m ˆeme. Afin d’ ´eviter de g ´en ´erer des tests non applicables sur un syst `eme, la m ´ethode g ´en ´eralement employ ´ee consiste `a calculer une sous-approximation de ce mod `ele. La sous-approximation prend g ´en ´eralement la forme d’un syst `eme de transitions repr ´esentant de mani `ere partielle la s ´emantique du mod `ele consid ´er ´e.

La mod ´elisation d’un syst `eme permet d’abstraire certains comportements afin de focaliser les tests sur des comportements pr ´ecis ou des situations particuli `eres. Cependant, l’espace d’ ´etats observable `a partir d’un tel mod `ele, typiquement `a l’aide d’un algorithme d’exploration, peut demeurer trop large et m ˆeme ˆetre in- fini. Pour cette raison, de nombreuses techniques de g ´en ´eration d’abstractions d’un mod `ele (qui est lui-m ˆeme une abstraction du syst `eme `a tester) ont ´et ´e mises au point [Grieskamp et al., 2002, Clarke et al., 2003, Veanes et al., 2003, Ball et al., 2005, Pasareanu et al., 2007]. G ´en ´eralement, ces techniques permettent de calculer un syst `eme de transitions de taille r ´eduite et finie, au prix d’une perte d’informations sur les situations (les ´etats) pouvant ˆetre atteints par le syst `eme sous test ainsi que sur les op ´erations (les transitions) effectivement applicables sur ce dernier.

Dans le cadre de la v ´erification de propri ´et ´es sur un mod `ele (model checking),

cette perte d’information ne repr ´esente pas forc ´ement une barri `ere car l’abstraction peut malgr ´e tout pr ´eserver ces propri ´et ´es [Henzinger et al., 2002, Clarke et al., 2003, Chaki et al., 2003, Ball et al., 2005]. En effet, en model-checking on cherche en g ´en ´eral `a prouver qu’aucune ex ´ecution du mod `ele ne viole une propri ´et ´e donn ´ee. Ainsi, si au- cune ex ´ecution may-atteignable ne viole une propri ´et ´e, alors a fortiori aucune ex ´ecution concr `etement atteignable ne le fait. Dans ce cas, l’ ´etude de l’abstraction (g ´en ´eralement de petite taille) est donc avantageuse car elle permet de v ´erifier la propri ´et ´e plus simple- ment et plus rapidement qu’en ´etudiant l’espace d’ ´etats observables `a partir du mod `ele. Si l’abstraction ne respecte pas une propri ´et ´e, un contre-exemple produit `a partir de cette abstraction exhibant une trace violant la propri ´et ´e pourrait ˆetre un faux positif, c’est- `a- dire que le contre-exemple pourrait ne pas ˆetre applicable au syst `eme `a tester. Dans ce cas, il est d’usage de raffiner l’abstraction jusqu’ `a obtenir la garantie que les propri ´et ´es soient pr ´eserv ´ees, par exemple `a l’aide de techniques de raffinement `a partir de contre-

exemples (en anglaiscounter-example guided abstraction refinement, souvent abr ´eg ´e

parCEGAR) [Clarke et al., 2003].

Dans le cadre de la g ´en ´eration de tests `a partir de mod `eles, il est ´egalement d ´esirable d’obtenir des tests effectivement applicables au syst `eme. Lorsque l’exploration compl `ete des situations et des comportements possibles `a partir du mod `ele n’est pas envisa- geable, l’abstraction du mod `ele peut malgr ´e tout ˆetre envisag ´ee. Naturellement, puisque le syst `eme de transitions obtenu par abstraction constitue une sur-approximation du mod `ele et donc du syst `eme `a tester, l’algorithme de g ´en ´eration de tests doit s’assu- rer d’en extraire la partie pouvant ˆetre instanci ´ee sur ce dernier. Un tel algorithme de g ´en ´eration de tests `a partir d’une abstraction de mod `ele calcule donc habituellement une sous-approximation de la s ´emantique d ´ecrite par ce mod `ele, `a partir d’un syst `eme de transitions abstrait constituant une sur-approximation de ce dernier.

3.2.1/ SOUS-APPROXIMATION DE PROGRAMMES UTILISANT LES MODALITES´ DES TRANSITIONS

Dans [Ball, 2005], Thomas Ball propose une m ´ethode de g ´en ´eration de tests (appel ´ee

PCTpourPredicate-Complete Testing) `a partir d’une abstraction de programmes.

Un programme est classiquement compos ´e d’un compteur de programme, d’un ensemble d’instructions d’affectation de variables, de structures conditionnelles et de boucles (voir la logique de Hoare [Hoare, 1969]).

Les conditions apparaissant dans les structures conditionnelles et les boucles constituent l’ensemble de pr ´edicats d’abstraction utilis ´e pour calculer l’abstraction du programme.

Les tests g ´en ´er ´es avec la m ´ethodePCT visent `a couvrir tous les ´etats atteignables d’un

programme (au plus m ×2n _{avec m le nombre d’instructions dans le programme et n le}

nombre de pr ´edicats d’abstraction). Un tel crit `ere de couverture permet de consid ´erer les d ´ependances entre les conditions d’un programme et les instructions dont elles contr ˆolent l’ex ´ecution.

La figure 3.2 montre un exemple de programme avec :

• une instruction skip ne modifiant pas l’ ´etat du programme au niveau du compteur

de programme L2,

• des instructions d’affectation au niveau du compteur de programme L0, L3, L4 et

L6,

• des instructions conditionnelles au niveau du compteur de programme L1 et L5.

On note que la variable x n’est pas initialis ´ee et on consid `ere qu’elle prend une valeur al ´eatoire parmi l’ensemble des entiers relatifs Z.