Port ´ees des propri ´et ´es temporelles

Exemple 4 : Expression d’une propri ´et ´e temporelle sur l’exemple fil rouge

La propri ´et ´e aucun caf ´e ne peut ˆetre servi entre le moment o `u l’utilisateur demande `a

r ´ecup ´erer sa monnaie et en ins `ere de nouveau dans la machinepeut s’exprimer par le

patron de sp ´ecification P suivant :

ETAT DE L’ART

3.1/

G ´

´

`

`

La g ´en ´eration de tests `a partir de mod `eles (en anglaisModel Based Testing souvent

abr ´eg ´e par MBT) est une m ´ethode formelle permettant la v ´erification de logiciels et

de syst `emes critiques [El-Far et al., 2002, Blackburn et al., 1996, Legeard et al., 2004]. Cette m ´ethode consiste `a confronter les impl ´ementations `a un mod `ele. Le principe est d’extraire des tests d’un mod `ele et d’ex ´ecuter ces tests sur les impl ´ementations afin de d ´etecter les non conformit ´es entre le mod `ele et ces impl ´ementations. Il y a non confor- mit ´e quand un test ex ´ecut ´e sur une impl ´ementation produit des r ´esultats non conformes `a ceux pr ´edits par le test issu du mod `ele. Cette m ´ethode est aujourd’hui tr `es utilis ´ee dans l’industrie [Blackburn et al., 2001] et son int ´er ˆet a d ´ej `a ´et ´e d ´emontr ´ee sur de gros projets du domaine ferroviaire, a ´eronautique et dans les t ´el ´ecommunications notam- ment [Lougee, 2001, Fantechi et al., 2012, Bernard et al., 2004].

3.1.1/ TEST DE SYSTEMES`

L’objectif du test de syst `emes est de d ´etecter des erreurs dans l’impl ´ementation de ce syst `eme afin de pouvoir les corriger avant la mise en service de celle-ci. Plus le syst `eme est critique, c’est- `a-dire plus les cons ´equences d’un d ´efaut du syst `eme peuvent ˆetre graves (parfois jusqu’ `a mettre des vies humaines en jeu) [Knight, 2002], plus il est crucial de le tester afin d’avoir suffisamment confiance en sa qualit ´e [Pressman, 2005] avant de l’utiliser.

Un test, ou cas de test, compos ´e d’un couple donn ´ees/r ´esultat attendu, consiste `a sou- mettre l’ensemble des donn ´ees `a l’impl ´ementation du syst `eme sous test (en anglais

system under testsouvent abr ´eg ´e parSUT) afin d’observer comment il r ´eagit et de

comparer le r ´esultat obtenu avec les r ´esultats attendus du syst `eme (on parle d’oracle). Si une diff ´erence entre le r ´esultat obtenu et celui attendu est d ´etect ´ee, le test a permis de mettre en ´evidence une erreur pouvant se situer au niveau de :

• l’impl ´ementation, auquel cas il convient de corriger l’erreur et d’appliquer `a nou-

veau l’ensemble des tests `a cette impl ´ementation modifi ´ee, et non pas seulement le test ayant mis en ´evidence l’erreur car la correction peut avoir engendr ´e de nouvelles erreurs (voir tests de r ´egression [Huizinga et al., 2007]),

• l’oracle, lorsque le r ´esultat obtenu se r ´ev `ele correct mais que le r ´esultat attendu

´etait erron ´e, auquel cas il convient de revoir ou pr ´eciser les r ´esultats attendus pour 37

ce cas de test pr ´ecis,

• l’impl ´ementation et l’oracle, lorsque ni le r ´esultat obtenu, ni l’oracle ne sont cor-

rects.

Si le test d’un syst `eme peut mettre en ´evidence la pr ´esence d’erreurs, il ne peut ce- pendant pas mettre en ´evidence leur absence. C’est- `a-dire que si les tests ne r ´ev `elent aucune erreur, rien ne prouve qu’aucune erreur n’existe : les tests ne permettent simple- ment pas de les d ´etecter.

Les oracles pour les diff ´erents cas de test d’une suite de tests (un ensemble de cas de test) sont issus de la description d’un mod `ele du syst `eme. Cette description est effectu ´ee par l’ing ´enieur de test `a partir des sp ´ecifications d ´ecrites conjointement par le client et l’ing ´enieur d’explicitation des besoins.

3.1.2/ SPECIFICATIONS DE SYST´ EMES`

Les sp ´ecifications d’un syst `eme consistent g ´en ´eralement en un document ´enonc¸ant, de mani `ere aussi compr ´ehensible que possible par le client et l’ing ´enieur d’explicita- tion des besoins, les fonctionnalit ´es (on parle d’exigences fonctionnelles) et les com- portements attendus du syst `eme. Bien qu’il existe de nombreux langages permettant de formaliser les sp ´ecifications (Z, B, Spec#, VDM, etc.) [Spivey, 1989, Abrial, 1996, Barnett et al., 2005, Fitzgerald et al., 2007, Dwyer et al., 1999], leur adoption par les non-initi ´es (souvent le client) est g ´en ´eralement compliqu ´ee. Pour cette raison, les sp ´ecifications sont g ´en ´eralement d ´ecrites de mani `ere informelle.

Ce manque de formalisme est cependant source de probl `emes car il en r ´esulte des sp ´ecifications parfois ambigu ¨es voire incompl `etes. Si le r ´esultat observ ´e sur l’impl ´ementation apr `es un test est celui attendu par l’ing ´enieur, mais pas par le client (ou l’inverse), cela met en ´evidence une ambigu¨ıt ´e dans les sp ´ecifications. Des sp ´ecifications incompl `etes correspondent par exemple au cas o `u le client souhaite que le syst `eme r ´eponde d’une certaine mani `ere dans certaines situations particuli `eres (typiquement avec un ensemble d’entr ´ees sp ´ecifiques), mais que certaines de ces situations ne sont pas sp ´ecifi ´ees. Si les tests mettent en ´evidence cet oubli, c’est- `a-dire lorsque les entr ´ees sou- mises au syst `eme correspondent `a un ensemble d’entr ´ees sp ´ecifiques pour lesquelles le client s’attend (sans le sp ´ecifier) `a une r ´eponse particuli `ere de la part du syst `eme, le probl `eme sera d ´etect ´e. Si en revanche les tests n’utilisent pas cet ensemble particulier d’entr ´ees, la situation est plus grave car les sp ´ecifications seront consid ´er ´ees comme respect ´ees alors que les exigences (les attentes) du client ne le seront pas. Dans les cas ´enonc ´es pr ´ec ´edemment, lorsque le probl `eme est d ´etect ´e, il convient ´evidemment de reformuler, pr ´eciser ou compl ´eter les points de sp ´ecification concern ´es par les tests afin de renforcer la confiance en la qualit ´e du syst `eme vis- `a-vis des exigences et en m ˆeme temps renforcer les exigences.

Si toutes les sp ´ecifications ne sont pas test ´ees, des probl `emes dans les sp ´ecifications ou l’impl ´ementation pourraient bien ne jamais ˆetre d ´etect ´ees. Id ´ealement, il serait donc souhaitable de concevoir un prototype du syst `eme reprenant chaque fonctionnalit ´e de- mand ´ee du syst `eme et s’accordant avec l’ensemble des sp ´ecifications et de s’appuyer sur ce prototype pour impl ´ementer le syst `eme. En pratique en revanche, en raison no- tamment du nombre souvent ´elev ´e des sp ´ecifications, la conception d’un tel prototype serait trop co ˆuteuse et contre-productive `a mettre en œuvre. En effet, cela s’apparen- terait fortement `a impl ´ementer directement le syst `eme et v ´erifier que l’impl ´ementation

satisfait toutes les sp ´ecifications, ce qui n’est g ´en ´eralement pas r ´ealisable. Pour pallier

ce probl `eme, on utilise g ´en ´eralement les sp ´ecifications informelles et on ´etablit unmod `ele

reprenant seulement une partie des comportements et des fonctionnalit ´es d ´ecrites dans ces sp ´ecifications.

3.1.3/ MODELES DE TEST`

Un mod `ele, dans le cadre de la g ´en ´eration de tests `a partir de mod `eles, est une abs- traction (une simplification) du syst `eme `a tester : il ne mod ´elise qu’une partie des sp ´ecifications et des fonctionnalit ´es demand ´ees par le client. Le mod `ele est ´egalement abstrait en ce sens qu’il ne mod ´elise pas toutes les donn ´ees telles qu’elles seront utilis ´ees sur l’impl ´ementation : elles sont simplifi ´ees.

Par exemple, dans [Philipps et al., 2003], un syst `eme de carte `a puce est ´etudi ´e. G ´en ´eralement, le terminal communiquant avec une carte `a puce lui transmet les op ´erations et la carte r ´epond par un code hexad ´ecimal indiquant le r ´esultat de la requ ˆete. Il peut s’agir d’un code exprimant le succ `es de l’op ´eration, d’un code d’erreur de lecture des donn ´ees, d’un code d’erreur d’ ´ecriture des donn ´ees, d’un code d’erreur signalant que la commande ´emise par le terminal est inconnue, etc. Typiquement, le mod `ele ne s’int ´eressera pas forc ´ement `a tous les codes pouvant ˆetre renvoy ´es par la carte et dis- tinguera par exemple plut ˆot le cas ou il s’agit d’un code d’erreur et le cas ou il s’agit d’un code de succ `es.

Cette abstraction des donn ´ees implique donc que les entr ´ees des tests qui seront g ´en ´er ´es `a partir d’un mod `ele devront ˆetre adapt ´ees pour pouvoir ˆetre appliqu ´ees au syst `eme. De m ˆeme, le r ´esultat attendu par un test et le r ´esultat obtenu sur l’impl ´ementation n’ont pas le m ˆeme niveau d’abstraction et une couche d’adaptation est donc ´egalement n ´ecessaire pour pouvoir comparer ces r ´esultats.

Les comportements pr ´evus du syst `eme ne seront g ´en ´eralement pas couverts par les tests si ils ne sont pas mod ´elis ´es. Aussi, il convient de mod ´eliser tous les comporte- ments jug ´es critiques du syst `eme. Il n’existe pas, `a priori, de m ´ethode syst ´ematique pour ´etablir quels comportements et fonctionnalit ´es demand ´es dans les sp ´ecifications sont cri- tiques. L’estimation du niveau de criticit ´e est donc laiss ´ee `a l’appr ´eciation du client et de l’ing ´enieur. En pratique, il arrive que plusieurs mod `eles soient conc¸us, mod ´elisant chacun une partie particuli `ere des sp ´ecifications [Utting, 2005].

Un mod `ele doit ´evidemment ˆetre conforme aux sp ´ecifications qu’il mod ´elise. Cela per- met notamment de s’assurer, d’une part, que les tests qui seront issus du mod `ele pourront effectivement ˆetre applicables sur l’impl ´ementation du syst `eme et, d’autre part, que les r ´esultats attendus par les tests soient conformes aux sp ´ecifications. Cette va- lidation du mod `ele est g ´en ´eralement r ´ealis ´ee `a l’aide d’outils formels de v ´erification de propri ´et ´es tels que CUTE [Sen et al., 2006], SPIN [Holzmann, 2003] ou encore Java Pathfinder [Visser et al., 2005] traduisant les exigences (par exemple `a l’aide de formules temporelles telles que la LTL [Pnueli, 1981] ou la CTL [Clarke et al., 1982, Emerson et al., 1985]). Afin de pouvoir mettre en œuvre ces techniques de model- checking [Clarke et al., 1999], le mod `ele doit bien s ˆur ˆetre plus simple et plus rapide `a v ´erifier que l’impl ´ementation du syst `eme elle-m ˆeme.

3.1.4/ PROCESSUS DE GEN´ ERATION DE TESTS´ A PARTIR DE MOD` ELES`

Le processus de g ´en ´eration de tests `a partir de mod `eles consiste g ´en ´eralement en 4 ´etapes principales [Utting, 2005, Utting et al., 2012]. La figure 3.1, constituant une ver- sion simplifi ´ee du processus initalement pr ´esent ´e dans [Utting et al., 2012], illustre ces diff ´erentes ´etapes.

Critères de sélection de tests Modèle Exigences Cas de test 1 2 3 3 Cas de test Script de test Système sous test Adaptateur 3 3 4

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