Questionnaire sur l`outil Tobias

Questionnaire sur l’outil Tobias
Yves Ledru, Lydie du Bousquet
, rue de la Passerelle, BP. 72, 38402 Saint Martin d'Hères Cedex, France
{Yves.Ledru,Lydie.du-Bousquet}@imag.fr
1
MODELE DE SPECIFICATION
2
2
GENERATION DES TESTS
3
3
EXECUTION DES TESTS
5
4
APPLICATIONS INDUSTRIELLES
6
TOBIAS
Yves Ledru, Lydie du Bousquet
Laboratoire LSR/IMAG
, rue de la Passerelle, BP. 72, 38402 Saint Martin d'Hères Cedex, France
{Yves.Ledru,Lydie.du-Bousquet}@imag.fr
Avertissement : TOBIAS n’est pas un outil automatique de synthèse de données de tests.
C’est une aide à la génération massive de séquence de tests.
1 Modèle de spécification
1.1 Quels sont les formats de spécification en entrée ?
TOBIAS prend en entrée
- la description de la signature des classes à tester (par exemple, XMI produit à partir de
Objecteering).
- un patron pour des séquences de test à produire, appelé « schéma de test ».
L’exploitation des séquences de test produites par l’outil suppose la disponibilité d’un oracle,
sous la forme d’une spécification exécutable. A ce jour, nous avons expérimenté trois types
d’oracle :
- des spécifications JML (Java Modeling Language), qui décrivent les classes et leurs
méthodes en terme d’invariants, de pré et post-conditions
- des spécifications VDM
- des spécifications IOLTS (avec l’outil TGV)
Pour éditer des spécifications JML ou VDM, un éditeur de textes suffit. Pour les IOLTS, on
peut utiliser l’environnement CADP (http://www.inrialpes.fr/vasy/cadp/).
1.2
Les modèles nécessitent-ils des adaptations pour être acceptés par
l’outil ?
Peu d’informations du diagramme de classes UML sont utilisées par l’outil TOBIAS. Ainsi,
l’outil ne nécessite pas d’adaptation du modèle.
En revanche, les spécifications de l’oracle doivent être exécutables, ce qui peut entraîner des
restrictions dans l’utilisation de VDM, par exemple.
2
1.3
Quelles sont les propriétés de model-checking apportées par votre outil
ou par l’outil de modélisation ?
L’outil TOBIAS n’est pas directement basé sur des techniques de model-checking. Il
correspond plutôt à du test combinatoire. A ce titre, il permet à l’utilisateur de s’assurer d’une
certaine forme d’exhaustivité.
L’outil est principalement destiné à la détection d’incohérences, soit entre un programme et sa
spécification, soit à l’intérieur d’une spécification. Les principales propriétés testées sont la
conservation d’invariants, la conformité entre une post-condition et le code, et certaines
propriétés de variance (qui lient deux états consécutifs).
Notre driver de test inclut un timer qui permet de détecter l’absence de réponse d’une
application, correspondant éventuellement à un dead-lock, une famine ou une boucle infinie.
Les langages de spécification utilisés pour l’oracle sont associés à des outils de preuve ou de
model-checking qui peuvent participer au processus de validation.
1.4
Est-il possible d’animer ou de simuler le modèle ?
Les spécifications de l’oracle doivent être exécutables. Si on utilise une spécification JML ou
VDM, leur animation suppose l’existence d’une implantation prototype. Pour les
spécifications IOLTS produites dans CADP, il existe un simulateur.
1.5
Est-il possible de modéliser l’environnement ?
La prise en compte du comportement de l’environnement intervient de deux façons. Tout
d’abord, la définition des schémas de test correspond à la spécification du comportement du
testeur. Ensuite, la spécification de l’oracle peut contraindre le comportement de
l’environnement : sous la forme de pré-conditions pour JML et VDM, ou de IOLTS restreint
pour TGV.
2 Génération des tests
2.1
L’outil permet-il une génération automatique de tests à partir du modèle ?
Les tests sont produits par dépliage des patrons de tests, et éventuellement filtrage par des
contraintes. Ces deux opérations sont automatiques. L’élaboration des patrons de test est
manuelle.
Nous avons entrepris une expérience de couplage de TOBIAS avec l’outil CASTING de
AQL/IRISA, pour aider l’utilisateur avec une sélection automatique de données de tests pour
compléter les patrons de tests. Cette expérience a montré que l’outil est extensible et peut
collaborer avec des outils de synthèse de données de test.
3
2.2
Génération interactive des tests est-elle basée sur la sélection de critères
ou sur la définition d’un objectif de test ?
La construction d’une campagne de test avec TOBIAS est basée sur la définition de schémas
de test. Chaque schéma de test correspond à un ensemble de comportements du testeur que
l’on souhaite soumettre au système sous test.
Un schéma de test peut correspondre à un grand nombre de tests (plusieurs milliers). C’est le
caractère systématique des tests qui permet à l’utilisateur de se forger un certain niveau de
confiance vis à vis de l’application.
A l’origine, TOBIAS a été conçu pour générer des objectifs de tests pour TGV en grande
quantité.
2.3
Quelles sont les stratégies de maîtrise de la complexité ?
Le caractère combinatoire de TOBIAS implique forcément des stratégies de maîtrise de la
complexité.
En premier lieu, c’est une conception réfléchie des schémas de test qui permettent de s’assurer
qu’un nombre raisonnable de tests pertinents seront produits. L’écriture des schémas de test
correspond implicitement à prendre en compte des hypothèses de test sur les données ou les
comportements de l’application.
De plus, nous avons mis en œuvre dans TOBIAS et dans le driver de test, des stratégies de
filtrage à la génération et à l’exécution. Ces dernières sont basées sur des contraintes
(associées aux schémas et portant sur les valeurs des paramètres des tests) et sur les préconditions.
A terme, d’autres stratégies sont envisagées. Une technique classique de maîtrise de la
complexité est de ne prendre en compte que la combinaison d’un nombre restreint de
paramètres (par exemple, tous les paramètres deux à deux). Cette approche est à l’origine
d’outil commerciaux comme AETG.
2.4
Caractérisation des tests générés
L’objectif initial de l’outil est de s’assurer de la conformité. Mais, nous avons aussi utilisé
l’outil pour du test de robustesse.
2.5
Est-il possible de rejouer/simuler les tests sur le modèle ?
Les tests sont enregistrés et re-jouables. Par exemple, les tests d’un programme Java sont
enregistrés sous forme d’un fichier d’entrée pour J-Unit.
2.6
Est-il possible de visualiser la couverture des tests ?
TOBIAS ne comprend pas pour l’instant d’outil de couverture de tests. Pour le test de
programmes Java, il existe des outils de couverture de test structurelle (par exemple,
JCoverage). VDMTools propose une couverture structurelle du code et de la spécification.
4
Pour les IOLTS, on ne connaît pas d’outil. Une thèse est en cours pour remonter l’information
de couverture au niveau d’abstraction des schémas de test.
2.7
Maintenabilité des tests générés
Un schéma de test est une expression très concise d’un grand nombre de tests. L’évolution du
schéma de test permet de mettre à jour rapidement et automatiquement l’ensemble de ces
tests. De plus, l’utilisation d’une spécification exécutable de l’oracle, indépendante du code
des tests permet de propager une évolution de la spécification à l’ensemble des cas de tests.
Dans TOBIAS, les tests sont organisés sous formes de campagne de test.
La traçabilité des tests par rapport aux exigences n’est pas mise en place. Mais il est possible
d’associer des commentaires aux schémas.
Il possible de distinguer les tests de non-régression et les tests induits par une évolution du
modèle en les groupant dans des campagnes distinctes.
2.8
Y-a-t-il un verdict associé aux tests ?
Chaque test donne lieu à un verdict PASS, FAIL ou INCONCLUSIF.
2.9
Quel est le format des tests générés ?
TOBIAS stocke les tests dans un format propriétaire proche d’XML. Ils peuvent être traduits
en fichier d’entrée pour J-Unit, VDMTools et TGV.
3 Exécution des tests
3.1
L’outil permet-il un pilotage des bancs de tests ?
Plusieurs drivers de test sont disponibles pour exécuter les ensembles des tests produits. Pour
JML et VDM, nous avons réalisé des drivers de tests qui prennent en compte des préconditions des spécifications pour filtrer dynamiquement l’ensemble des tests.
3.2 Quelles sont les plateformes supportées ?
Principalement Java.
3.3 Sous quelle forme est généré le rapport d’exécution ?
Fichier texte.
5
4 Applications industrielles
4.1 Quels sont les applications industrielles actuelles de l’outil ?
Application bancaire en Java et JML, proposée par le service recherche de Gemplus.
4.2 Quelle est la feuille de route (roadmap) des évolutions de l’outil ?
A court terme, nous recherchons des partenaires industriels pour utiliser et évaluer l’outil.
A moyen terme, nous cherchons des moyens pour distribuer l’outil.
4.2.1 Combien de personnes travaillent au développement de l’outil ?
Deux thèses sont en cours de rédaction et deux permanents travaillent à temps partiel sur
l’outil.
6