Test

1
Test à partir de modèles pistes pour le test
unitaire de composant, le test d'intégration et
le test système

• Yves Le Traon

2
Un thème le test de logiciels

• Le test cest important !
• Objectifs du test
• examiner ou exécuter un programme dans le but
  dy trouver des fautes
• relativement à une spécification
• formalisation de critères pour guider la
  sélection des tests
• Confiance mais pas de certitude
• sûreté de fonctionnement

3
Le test dynamique processus
Génération cas de test
4
Le test des logiciels à objets

• Il était une fois, il y a 6 ans
• ou
• une certaine méfiance des testeurs

5
Mixed-feeling at the code level
Method calls flow for processing C.m1()
The Yo-yo Effect (Binder, Offut)
C.m1()
6
Plan

• Test de composants
• Assemblage de composants
• Plan dintégration
• Test  système 

7
Composants et test
8
Composant de confiance
Spécification
contrats exécutables
V V ensemble de cas de test
Confiance fondée sur la cohérence
Implantation
Composants autotestables
9
Trusting Components?

• The point of view of the user...

?
Components off-the-shelf
10
Trusting Components?

• The point of view of the user...

replay selftests
100
85
100
55
Components off-the-shelf
11
Intuition

• La confiance dépend de la manière dont le
  composant a été testé
• Comment évaluer la qualité des tests ?
• Mutation analysis
• Les tests doivent au moins être capables de
  détecter les fautes introduites intentionnellement

12
Analyse de mutationR. DeMillo, R. Lipton and F.
Sayward, "Hints on Test Data Selection Help For
The Practicing Programmer". IEEE Computer 11(4)
34 - 41 April 1978.

• Technique pour évaluer lefficacité dun ensemble
  de cas de test
• Injection derreurs dans le programme sous test
• Programme mutant
• Calcul de la proportion derreurs détectées par
  les cas de test

13
Analyse de mutation

• Différents types derreur opérateurs de
  mutation
• Opérateurs définis à partir dobservations des
  bases derreurs établies au cours du
  développement
• J. Offutt, A. Lee, G. Rothermel, R. H. Untch and
  C. Zapf, "An Experimental Determination of
  Sufficient Mutant Operators". ACM Transactions on
  Software Engineering and Methodology 5(2) 99 -
  118 April 1996.
• Travaux récents Ma02, Alexander02 proposent
  des opérateurs spécifiques pour logiciels OO
• L'indicateur clé le score de mutation

14
Quality Estimate Mutation Score

• Q(Ci) Mutation Score for Ci di/mi
• di number of mutants killed
• mi number of (non equivalent) mutants
  generated for Ci
• WARNING Q(Ci)100 notgt bug free
• Depends on mutation operators (see next slide)
• Quality of a system made of components
• Q(S) S di / S mi

15
Analyse de mutation
P
CT
Supprimé de lensemble des mutants
Ajout de contrats
16
Oracle

• Oracle par différence de comportements
• Des traces
• Des objets  programmes 
• Oracle embarqués (contrats, assertions)
• Interne au composant
• Oracle associé aux données de test
• Extérieur au composant
• Oracle spécifique à la donnée de test

17
Processus de fiabilisation
automatisé
18
Optimisation automatique de cas de test

• Score de mutation moyen facile à atteindre
• Comment optimiser ces tests
• Analogie avec lévolution

19
Optimisation des tests
Comp. A
20
Algorithme génétique

• Données
• Gène cas de test
• Individu/chromosome séquence de gènes de taille
  fixe
• Fonction dutilité évaluer lintérêt dun
  individu pour le problème
• Nouvelle population dindividus
• Croisement
• Taux de mutation des gènes
• Limitations
• Taille fixe dun ensemble de cas de test
• Opération de croisement peu utile
• Reproduction pas efficace pour garder la mémoire

21
Algorithme bactériologiqueRosenzweig , Species
diversity in space and time, CUP,1995

• Suppression de
• La notion dindividu
• Lopération de croisement
• Introduction de
• La notion de bactérie ? un cas de test
• Une mémoire des bonnes bactéries

22
Étude dun parser C
23
La boucle bactériologique

• 2 ensembles de bactéries
• Bouillon (population courante)
• Solution (contruite itérativement)
• 4 opérations
• Classer, Mémoriser, Filtrer, Muter
• Condition darrêt
• Objectif atteint
• Nb de générations

Arrêt
Mémoriser
Classer
Filtrer
Bouillon bacteriologique
Muter
24
La boucle bactériologique

• Fonction dutilité (F)
• Indique la pertinence dun ensemble de bactéries
  pour le problème considéré

Mémoriser
Définie pour un ensemble de Bactéries

• Utilité dune bactérie
• f(b) F(bUS) F(S)
• Utilité relative aux bactéries
• déjà mémorisées

Classer
Filtrer
Bouillon bacteriologique
Muter
25
La boucle bactériologique

• Fonction de mémorisation
• Fonction à valeur booléenne indiquant si la
  meilleure bactérie du bouillon doit être
  mémorisée.
• Exemples
• Seuil de mémorisation
• Plusieurs itérations sans améliorations

Mémoriser
Classer
Filtrer
Bouillon bacteriologique
Muter
26
La boucle bactériologique

• Fonction de filtrage
• Elimine les bactéries inutiles du bouillon afin
  de garantir lefficacité de lalgorithme
• Exemples
• Supprimer les bactéries dutilité nulle
• Dans le domaine du test heuristiques de
  minimisation de suites de test

Mémoriser
Classer
Filtrer
Bouillon bacteriologique
Muter
27
La boucle bactériologique

• Opérateur de mutation
• Permet, à partir dune bactérie parente, de
  construire une nouvelle bactérie
• Fortement dépendant du problème considéré

Mémoriser
Classer
Filtrer
Bouillon bacteriologique
Muter
28
Étude dun parser C
29
Résultats

• Approche composant autotestable
• Algorithme original pour la génération de cas de
  test
• Résultats expérimentaux vers des composants
  robustes
• contrats efficaces 15..85 de taux de
  détection dune erreur à lexécution
• réduction de leffort de localisation des
  fautes dun rapport 10 au moins

30
Dissémination

• Principales publis
• "From Genetic to Bacteriological Algorithms for
  Mutation-Based Testing" , B. Baudry, F. Fleurey,
  J.-M. Jézéquel and Yves Le Traon, Software
  Testing, Verification and Reliability journal
  (STVR), to be published, 2005
• An Original Approach for Automatic Test Cases
  Optimization a Bacteriologic Algorithm, B.
  Baudry, F. Fleurey, J.-M. Jézéquel and Y. Le
  Traon, IEEE Software, to be published, 2005
• Reliable Objects a Lightweight Approach Applied
  to Java, J.-M. Jézéquel, D. Deveaux, Y. Le
  Traon, IEEE Software, Vol. 18, N4, July-August
  2001, pp. 76-83.
•  Composants Objets Fiables, une approche
  pragmatique , D. Deveaux, R. Fleurquin, P.
  Frison, J-M. Jézéquel and Y. Le Traon, LObjet,
  Vol. 5, N3-4, december 1999, pp.469-494
• 7 conférences internationales ASE, TOOLS,
  ISSRE

31
Assemblage de composants
32
Test dintégration

• Objectif
• Planifier lordre dintégration
• Vérifier linteraction entre composants
  unitaires
• Difficultés principales de lintégration
• Interfaces floues (ex. ordre des paramètres de
  même type).
• Implantation non conforme à la spécification
  (ex. dépendances entre unités non spécifiées).
• Réutilisation de composants (ex. risque
  dutilisation hors domaine).

33
Intégration Approches classiques

• On obtient une architecture arborescente
• SADT, SART, SAO (Aérospatiale)
• Approches
• Big-Bang non recommandé
• De haut en bas (top-down)
• De bas en haut (bottom-up)

34
Approche classique De bas en haut
35
Systèmes à objets

• Forte connectivité
• Architecture cyclique Interdépendances

36
Objectif dun plan dintégration

• Réalisation dune  bonne  stratégie
• pour planifier lintégration des systèmes à
  objets,
• le plus tôt possible dans le cycle de vie,
• en minimisant le coût du test.

37
Test dintégration les interdépendances

• Une solution simple consiste à contraindre le
  concepteur
• pas de boucle dans larchitecture
• cest souvent possible
• mais les optimisations locales ne sont pas
  toujours optimales globalement
• mais concevoir des composants interdépendants
  est souvent naturel
• La solution que nous préconisons
• prend nimporte quel modèle UML
• Cherche à optimiser leffort et la durée de
  lintégration

38
Interdépendance

• Interdépendances
• Cycle de dépendances
• Composantes fortementconnexes (CFC)
• Intégration
• Big-Bang
• Décomposer des CFCs Utilisation de bouchons

39
Bouchon de test

• Bouchon une unité qui
• simule le comportement dune unité absente

40
Modélisation du problème

• Class-to-class

A
A
B
B
aggregation
composition
41
Stratégie dintégration minimiser les bouchons

• Une stratégie (1)

42
Stratégie dintégration minimiser les bouchons

• Une stratégie (2)

a
B
f
Tarjans algorithm
b
i
g
e
c
j
h
d
k
l
A
C
(e) or C
A or B
(a)
then
then
Complexity linear with nodes
43
Stratégie dintégration minimiser les bouchons

• Une stratégie (3)

5
f
Bourdoncles algorithm
f
i
4
i
Candidate node max(fronds)
g
j
3
j
g
h
h
2
1
B
(e) or C
A or B
(a)
then
then
Break the connected component Reapply Tarjan
g, h, j, i, f
c, b, d
l, k
44
Stratégie dintégration minimiser les bouchons

• Le résultat graphe dordre partiel

g
Optimized algorithm
d
specific stubs 4
realistic stubs 3
Random selection
k
specific stubs 9.9
Partial ordered tree
realistic stubs 5
45
Case study SMDS UML diagram
46
Case study SMDS Test Dependency Graph
47
SMDS realistic stubs
48
Results summary 30-55 stubs number reduction
49
Variantes possibles

• Mixte Big-Bang/Incrémental strict
• Parallèlisation des tâches dintégration

50
Autres travaux mesures du logiciel

•  expérimenter-comprendre-mesurer-agir 
• Design by Contracts Robustesse / Vigilance
• Capacité dun composant à détecter un état
  interne erroné
• Design by Contracts Diagnosabilité
• Facilité à localiser une faute dans un composant
  sachant quune défaillance est détectée
• Testabilité dun diagramme de classes
• identification d  anti-patterns 

51
Autres travaux conception testable

• transformations de modèles pour supprimer les
  ambiguïtés dune architecture
• Application aux design patterns courants
• refactorings

52
Dissémination

• Principales publications
• B. Baudry and Y. Le Traon, Measuring Design
  Testability of a UML Class Diagram, to be
  published in the journal, Information Software
  Technology (IST).
• Y. Le Traon, F. Ouabdesselam, C. Robach and B.
  Baudry,  From Diagnosis to Diagnosability
  Axiomatization, Measurement and Application, in
  The Journal of Systems and Software, January
  2003, Vol. 1, N65, pp. 31-50
• Y. Le Traon, T. Jéron, J-M. Jézéquel and P.
  Morel, Efficient OO Integration and Regression
  Testing , IEEE Transactions on Reliability,
  March 2000, pp. 12-25.
• 8 conférences internationales ECOOP01, UML01,
  Metrics03, Metrics02, ISSRE01 etc.
• Module de test dintégration développé par
  Softeam pour Objecteering

53
Test  système 
54
Test à partir des exigences

• Partir des exigences
• Soit textuelles
• Soit cas dutilisation étendus avec des contrats
  (dans une logique proche du B)
• Générer automatiquement des
• objectifs/cas de test
• Adaptable aux lignes de produits
• Expérimentations industrielles

55
Méthode
Langage de description des exigences LDE
Model-driven
Conception statecharts
56
if the mode of the system is dummy or real and
the user did deselect Example function then the
phase of the system is no phase and the status of
the component is released implies the presence of
the component is false.
Traçabilité MModèles indépendants
57
Etendre les cas dutilisation UML avec des
contrats  Requirements by contract 
VirtualMtg
enter
plan
consult
open
leave
manager
close
speak
user
hand over
moderator
connect
ask
58
Contrats
use case OPEN UC open(uparticipantmmtg) pre
created(m) and moderator(u,m) and not closed(m)
and not opened(m) and connected(u) post opened(m)
use case CLOSE UC close(uparticipant mmtg)
pre opened(m) and moderator(u,m) post not
opened(m) and closed(m) and forall(vparticipant)
not entered(v,m) and not asked(v,m) and not
speaker(v,m)
59
UCTS exemple
0 -gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1) 1-gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1), entered(p2, m1) 2-gtmoderator(p2,
m1), connected(p1), connected(p2), created(m1),
manager(p2, m1), opened(m1), entered(p1,
m1) 3-gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
closed(m1) 4-gtmoderator(p2, m1), connected(p1),
connected(p2),created(m1), manager(p2, m1),
opened(m1), entered(p2, m1), entered(p1,
m1) 5-gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1), entered(p2, m1), asked(p2,
m1) 6-gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1), entered(p1, m1), asked(p1, m1)
60
UCTS example
0 -gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1) 1-gtmoderator(p2, m1), connected(p1),
connected(p2), created(m1), manager(p2, m1),
opened(m1), entered(p2, m1) 3-gtmoderator(p2,
m1), connected(p1), connected(p2), created(m1),
manager(p2, m1), closed(m1)
61
Génération de test

• Un chemin de lUCTS
• séquence valide de cas dutilisation décrivant
  les acteurs et composants impliqués
• objectif de test
• Nombre de chemins élevé (ou infini)
• définir des critères de sélection dun
  sous-ensemble pertinent et efficace

62
Expérimentations

• Questions de base
• Des cas de test générés à partir des exigences
  peuvent-ils tester correctement un système ?
• Etudes de cas
• Deuxième question
• applicable au niveau industriel (ROI) ?
• des exigences couvert pour un vrai système ?

63
Couverture de code
Nominal code
64
Dissémination

• Principales publications
• 6 conférences internationales FORTE02,
  REPL02, PFE03, ISSRE03, RTAS04
• Forte implication dans des projets industriels
• Européens CAFE, Families
• Collaboration CAROLL-Mutation avec THALES
• Transfert industriel en cours

65
Perspectives
Test road
Transformation de modèles
Test guidé par les exigences
Diagnostic Et composants
Algorithmes Bactérilogiques
66
Conclusion

• Travaux pour la validation et la conception de
  composants fiables
• Algorithmes de génération de test
• Modèles pour la mesure de la qualité dun
  composant
• Outils de test
• Publications (JSS, ISSRE, Metrics, ASE)

67
?