Le test de logiciel

1
Le test de logiciel

• Yves Le Traon
• Yves.letraon_at_francetelecom.com
• Benoit Baudry
• bbaudry_at_irisa.fr

2
Objectifs du cours

• Test de composants  unitaires 
• classes ou classes
• Assemblage de composants
• Le problème du test dintégration
• Test dun composant depuis ses exigences ou ses
  cas dutilisation test  système 

3
Objectifs du cours

• À chaque étape, une technologie (outillée) est
  choisie
• Un ou plusieurs exemples sont traités en TD et en
  TP
• La notion de  contrat  est importante
• Pré/post conditions
• Langage prédominant Java

4
Plan

1. Problématique du test
2. Rappels test de logiciel
3. Test de composants unitaires OO
4. Test d'intégration
5. Test système
6. Diagnostic

5
Problématique du test

• On ne peut pas tester tout le temps ni tous les
  cas possibles
• Il faut des critères pour choisir les cas
  intéressants et la bonne échelle pour le test
• Prouver labsence derreurs dans un programme est
  un problème indécidable
• il faut des heuristiques réalistes

6
Problématique du test
Le coût du test dans le développement
analyse des
besoins
Implém.
spécification
Spécif.
Test
An. b
Implémentation
test
maintenance 80 du coût global de
développement !!!
7
Problématique une définition !
conformité du produit par rapport à sa
spécification
La validation
Vérification/preuve
tests
8
Problématique du test
Pourquoi ?
Coût
Effort
Confiance
9
Vocabulaire
Testabilité
faute
bogue
Fiabilité (Reliability)
erreur
défaillance
Test de Robustesse
Test statique
Test de non-régression
Tolérance aux fautes
Séquence de test
Données de test
Sûreté de fonctionnement (Dependability)
Jeu de test
Test statistique
Cas de test
10
Défaillances

• Catastrophe humaine ou financière
• Automobile (2004) régulateur de vitesse
• Therac-25 (1985-1987) radiologie et contrôle
  d'injection de substances radioactives
• London Ambulance System (1992) central et
  dispatch ambulances
• Iran Air Flight 655 (1988) guerre d'Irak et
  missile américain système radar
• Ariane 5 (1996)
• SI du FBI (2005) SI qui n'a pas pu être déployé
• Mars Climate Orbiter (1999) kilos pounds
• Bourse de Londres (Taurus, 1993) SI qui n'a pas
  pu être déployé
• Image de marque
• FT et Bouygues en 2004 crash des serveurs
  indisponibilité 48h
• Succès financier Windows
• Sans conséquence mais énervant bogue Irisa

11
Dues à des bugs

• USS Yorktown (1998)
• Une division par zéro coupe les moteurs
• Ariane 5 (1996)
• Mauvaise réutilisation
• Mars orbiter (1999)
• Plusieurs unités de mesure
• Système de guidage (2002)
• Initialisation erronée
• The Patriot and the Scud
• mauvais arrondi dans une soustraction

12
Dues au processus

• Therac-25 (official report)
• The software code was not independently reviewed.
  
• The software design was not documented with
  enough detail to support reliability modelling.
• The system documentation did not adequately
  explain error codes.
• AECL personnel were at first dismissive of
  complaints.
• The design did not have any hardware interlocks
  to prevent the electron-beam from operating in
  its high-energy mode without the target in place.
  
• Software from older models had been reused
  without properly considering the hardware
  differences.
• The software assumed that sensors always worked
  correctly, since there was no way to verify them.
  (see open loop)
• Arithmetic overflows could cause the software to
  bypass safety checks.
• The software was written in assembly language.
  While this was more common at the time than it is
  today, assembly language is harder to debug than
  high-level languages.
• .

13
Processus (cf. IEEE Spectrum 09/2005)

• Système dinformation du FBI
• abandonné en avril 2005 coût 170 M
• mauvaise spécification, exigences mal exprimées
• réutilisation dans un contexte inadapté
• trop dacteurs concurrents (hommes politiques,
  agents secrets, informaticiens)

14
Problématique du test

• Un jeune diplômé sur trois commence par faire du
  test
• 50 des start-up échouent à cause du trop grand
  nombre de bugs
• mauvaise campagne de test
• maintenance difficile
• pas de non régression

15
2- Rappels test de logiciel

• 2.1. Le test quoi et comment
• 2.2. Etapes et processus de test
• 2.3. Génération de test

16
2- Rappels test de logiciel

• 2.1. Le test quoi et comment
• 2.2. Etapes et processus de test
• 2.3. Génération de test

17
Le test
Essayer pour voir si ça marche.
18
Quest-ce quon teste?(quelles propriétés?)

• fonctionnalité
• sécurité / intégrité
• utilisabilité
• cohérence
• maintenabilité
• efficacité
• robustesse
• sûreté de fonctionnement

19
Comment on teste?

• Test statique
• relecture / revue de code
• analyse automatique (vérification de propriétés,
  règles de codage...
• Test dynamique
• on exécute le programme avec des valeurs en
  entrée et on observe le comportement

20
Avec quoi on teste?

• Une spécification exprime ce quon attend du
  système
• un cahier des charges (en langue naturelle)
• commentaires dans le code
• contrats sur les opérations (à la Eiffel)
• un modèle UML
• une spécification formelle (automate, modèle B...)

21
Exemple
Comment tester la classe StringList?

• tester lajout dans une liste vide
• tester lajout dans une liste avec un élément
• tester le retrait dans une liste avec deux
  éléments
• ....

Comment écrire ces tests? Comment les
exécuter? Les tests sont-ils bons? Est-ce que
cest assez testé? ...
22
Test de logiciel
décrit
Programme
Spécification
implante
23
2- Rappels test de logiciel

• 2.1. Le test quoi et comment
• 2.2. Etapes et processus de test
• 2.3. Génération de test

24
Test de logiciel

• Plusieurs échelles
• Unitaire, intégration, système
• Plusieurs techniques
• Dynamique / statique
• Génération de test
• Fonctionnel / structurel

25
Cycle de vie en V (normalisé AFNOR)
Analyse
Validation


 Expression du besoin
 Validation
 Analyse détaillée
 Mise en œuvre
Conception
Intégration

 Etude technique préalable
 Intégration
 Conception préliminaire
 Tests d'Intégration
 Conception détaillée
Réalisation
 Codage
 Mise au point
 Tests unitaires
26
Hiérarchisation des tests
Maintenance
Programme livrable
analyse des besoins
Test de recette (avec client)
Plan de test système (fonctionnel)
Système
Tests systèmes
Cahier des charges
Tests d intégration
Plan de test dintégration
?
Tests unitaires
Conception détaillée
implémentation
le cycle en  V 
27
Cycle de vie en  spirale 
Synergie avec approche par objets
28
Test unitaire

• Validation dun module indépendamment des autres
• Valider intensivement les fonctions unitaires
• Les unités sont-elles suffisamment spécifiées?
• le code est-il lisible, maintenable...?

29
Test unitaire

• Pour un langage procédural
• unité de test procédure
• Dans un contexte orienté objet
• unité de test classe

void Ouvrir (char nom, Compte C, float S, float
D ) C-gttitulaire AlloueEtCopieNomTitulaire(no
m) (C).montant S (C).seuil D
(C).etat DEJA_OUVERT (C).histoire.nbop
0 EnregistrerOperation(C) EcrireTexte("Ouver
ture du compte numero ") EcrireEntier(NumeroCour
ant1) EcrireTexte(", titulaire
\"") EcrireTexte(C-gttitulaire)
EcrireCar('"') ALaLigne()
30
Test dintégration

• Choisir un ordre pour intégrer et tester les
  différents modules du système

31
Test dintégration
Cas simple il ny a pas de cycle dans les
dépendances entre modules Les dépendances
forment un arbre et on peut intégrer simplement
de bas en haut
32
Test dintégration
Cas plus complexe il y a des cycles dans les
dépendances entre modules Cas très fréquent dans
les systèmes à objets Il faut des heuristiques
pour trouver un ordre dintégration
33
Test système

• Valider la globalité du système
• Les fonctions offertes
• A partir de linterface

34
Test de non régression

• Consiste à vérifier que des modifications
  apportées au logiciel nont pas introduit de
  nouvelle erreur
• vérifier que ce qui marchait marche encore
• Dans la phase de maintenance du logiciel
• Après refactoring, ajout/suppression de
  fonctionnalités
• Après la correction dune faute

35
Etapes et hiérarchisation des tests
Test structurel
Tests unitaires Tests d intégration Tests
système
Test fonctionnel
36
2- Rappels test de logiciel

• 2.1. Le test quoi et comment
• 2.2. Etapes et processus de test
• 2.3. Génération de test

37
Le test dynamique processus
Donnée de test
Programme P
Exécution
Résultat
Spécification S
Oracle
Localisation / Mise au point
faux
Verdict
Problèmes
vrai
non vérifié
Critère darrêt
38
Le test dynamique de logiciel

• Soit D le domaine dentrée dun programme P
  spécifié par S, on voudrait pouvoir dire
• Soit D le domaine de P ? x?D P(x) S(x)
• Test exhaustif impossible dans la plupart des cas
• Domaine D trop grand, voire infini
• Trop long et coûteux

39
Le test dynamique

• On cherche alors un ensemble de données de test T
  tel que
• T ? D
• si ? x?T P(x) S(x) alors ? x?D P(x) S(x)
• Critère darrêt pour la génération de données de
  test
• données de test T

40
La génération de test

• Test fonctionnel (test boîte noire)
• Utilise la description des fonctionnalités du
  programme
• Test structurel (test boîte blanche)
• Utilise la structure interne du programme

41
Test fonctionnel

• Spécification formelle
• Modèle B, Z
• Automate, système de transitions
• Description en langage naturel
• UML
• Use cases
• Diagramme de classes ( contrats)
• Machines à états / diagramme de séquence

42
Test structurel

• A partir dun modèle du code
• modèle de contrôle (conditionnelles, boucles...)
• modèle de données
• modèle de flot de données (définition,
  utilisation...)
• Utilisation importante des parcours de graphes
• critères basés sur la couverture du code

43
Génération de test

• Génération déterministe
• à la main
• Génération automatique aléatoire
• Génération automatique aléatoire contrainte
• mutation
• test statistique
• Génération automatique guidée par les contraintes

44
Génération de test

• Reste à savoir quand on a suffisamment testé
• critères de test structurels, fonctionnels
• analyse de mutation
• Choisir le bon niveau pour le test

45
Exemple de test unitaire structurel
PGCD de 2 nombres Précondition p et q entiers
naturels positifs pgcd integer is local p,q
integer do read(p, q) B1 while pltgt q
do P1 if p gt q P2 then p
p-q B2 else q
q-p B3 end -- if end -- while resultp B4
end-- pgcd
46
Exemple de test unitaire structurel
Tous les noeuds (E, B1, P1, P2, B2, P1, B4,
S) (E, B1, P1, P2, B3, P1, B4, S) Tous les arcs
idem Tous les chemins élémentaires (1-chemin)
idem (E, B1, P1, B4, S) Tous les 2-chemins
idem (E, B1, P1, P2, B2, P1, P2, B2, P1,
B4, S) (E, B1, P1, P2, B2, P1, P2, B3, P1, B4,
S) (E, B1, P1, P2, B3, P1, P2, B2, P1, B4,
S) (E, B1, P1, P2, B3, P1, P2, B3, P1, B4, S)
47
Techniques de test fonctionnel

• Test boite noire
• Nutilise que la description fonctionnelle du
  programme
• cest la spécification
• Plusieurs informations
• domaine dentrée
• scénarios
• use cases
• ...

48
Domaine dentrée

• Plusieurs niveaux
• type des paramètres dune méthode
• pré-condition sur une méthode
• ensemble de commandes sur un système
• grammaire dun langage
• ...
• On ne peut pas tout explorer, il faut délimiter
• Génération aléatoire
• Analyse partitionnelle
• Test aux limites
• Graphe causes - effets

49
Technique 1 Analyse partitionnelle

• A partir de la spécification
• déterminer le domaine dentrée du programme
• Partitionner le domaine dentrée en classes
  déquivalences
• identifier des classes déquivalence pour chaque
  donnée
• les classes déquivalence forment une partition
  du domaine de chaque donnée en entrée
• choisir une donnée dans chacune

50
Technique 2 Test aux limites

• Intuition
• de nombreuses erreurs se produisent dans les cas
  limites
• Pour chaque donnée en entrée
• déterminer les bornes du domaine
• prendre des valeurs sur les bornes et juste un
  peu autour
• Exemple
• pour un intervalle 1, 100
• 1, 100, 2, 99, 0, 101

51
Technique 2 Test aux limites

• Le programme lit trois nombres réels qui
  correspondent à la longueur des côtés dun
  triangle. Si ces trois nombres ne correspondent
  pas à un triangle, imprimer un message derreur.
  Sil sagit dun triangle, le programme détermine
  sil est isocèle, équilatéral ou scalène et si
  son plus grand angle est aigue, droit ou obtus.

52

• Analyse partitionnelle

aigu obtus droit
scalène 6,5,3 5,6,10 3,4,5
isocèle 6,1,6 7,4,4 ?2,2,?2
équilatéral 4,4,4 impossible impossible
53
1, 1, 2 non triangle
0, 0, 0 un seul point
4, 0, 3 unes des longueurs est nulle
1, 2, 3.00001 presque triangle
0.001, 0.001, 0.001 très petit triangle
88888, 88888, 88888 très grand
3.00001, 3, 3 presque équilatéral
2.99999, 3, 4 presque isocèle
3, 4, 5.00001 presque droit
3, 4, 5, 6 quatre données
3 une seule donnée
5, 5, A une lettre
pas de donnée
-3, -3, 5 données négatives
...
54
Structurel/fonctionnel conclusion

• Les critères structurels et fonctionnels sont
  complémentaires
• une erreur domission ne peut pas être détectée
  par le test structurel
• du code mort ne peut pas être détecté par le test
  fonctionnel
• Au niveau unitaire
• on commence par le test fonctionnel
• on complète par du test structurel

55
Oracle

• Fonction qui évalue le résultat dun cas de test
• Plus formellement
• soit un programme P Dom(P) ? Ran(P)
• une spécification S Dom(P) ? Ran(P)
• une donnée de test X ? Dom(P)
• oracle O Dom(P) Ran(P) ? bool
• O(X, P(X)) true iff P(X) S(X)
• Problème comment comparer P(X) et S(X)
• plus S est formalisé plus on peut automatiser

56
Oracle

• Oracle manuel on regarde le résultat et un
  humain évalue sil est bon
• Construire le résultat attendu
• Assertions
• dans le code (programmation défensive)
• aux interfaces (design by contract)
• set_current_node (cnode Node)
• pre cnode ! null
• post currentNode cnode
• dans les cas de test (par ex. JUnit)
• ...

57
Quelques notions importantes pour conclure

• La relecture gtgt au test dynamique
• La non-régression est fondamentale et implique la
  capacité à mémoriser les tests
• On verra aussi que les contrats/assertions
  peuvent servir doracle embarqués

58
Plan

1. Problématique du test
2. Rappels test de logiciel
3. Test de composants unitaires OO
4. Test d'intégration
5. Test système
6. Diagnostic

59
3- Test unitaire de composants 00

• 3.1. Introduction au test unitaire de composants
  00
• - composant 00 "de confiance"
• - l'unité la classe
• - sentiment mitigé des testeurs
• 3.2. JUnit
• le cas particulier du test unitaire en Java
• 3.3. Test-driven development (TDD)
• 3.4. Fiabilisation de composants par analyse de
  mutation

60
Composant 00 de confiance

• Composant
• Unité de réutilisation
• Unité de déploiement
• Pour le testeur quelles sont les
  caractéristiques dont doit être doté un composant
  pour être fiable/testable ?
• Quelle est la complexité d'un composant ?

61
Unité vs. système

• Juste une question de granularité
• En OO et pour les composants, un système est un
  composant au même titre quun composant unitaire
• La distinction unité/système est maintenue en
  raison du processus industriel

62
Intérêts des composants

• Encapsulation
• Pas besoin de savoir comment est fabriqué un
  composant pour lutiliser
• Ça marche (i.e. il y a un marché)

63
Faiblesses des composants

• Encapsulation
• Il faut savoir très précisément ce quil fait
  pour lutiliser
• Sentiment mitigé pour les systèmes critiques
• Elaine J. Weyuker Testing Component-Based
  Software A Cautionary Tale, IEEE Software
  Sep-Oct 1998
• Ariane 501

64
Composant fiable
Spécification
contrats exécutables
V V ensemble de cas de test
Confiance fondée sur la cohérence
Implantation
65
Conclusion composant

• Sont de granularité variable
• Pour nous composant unitaire classe
• Les contrats ? oracles embarqués

66
Le test des logiciels à objets

• Au départ, une certaine méfiance des testeurs

67
Mixed-feeling at the code level
Flôt dappels de méthodes pour exécuter C.m1()
Leffet Yo-Yo (Binder, Offut)
C.m1()
68
Test unitaire OO

• Tester une unité isolée du reste du système
• Lunité est la classe
• Test unitaire test dune classe
• Test du point de vue client
• les cas de tests appellent les méthodes depuis
  lextérieur
• on ne peut tester que ce qui est public
• Le test dune classe se fait à partir dune
  classe extérieure
• Au moins un cas de test par méthode publique
• Il faut choisir un ordre pour le test
• quelles méthodes sont interdépendantes?

69
Test unitaire OO

• Problème pour loracle
• Encapsulation les attributs sont souvent privés
• Difficile de récupérer létat dun objet
• Penser au test au moment du développement (
  testabilité )
• prévoir des accesseurs en lecture sur les
  attributs privés
• des méthodes pour accéder à létat de lobjet

70
Cas de test unitaire

• Cas de test une méthode
• Corps de la méthode
• Configuration initiale
• Une donnée de test
• un ou plusieurs paramètres pour appeler la
  méthode testée
• Un oracle
• il faut construire le résultat attendu
• ou vérifier des propriétés sur le résultat obtenu
• Une classe de test pour une classe testée
• Regroupe les cas de test
• Il peut y avoir plusieurs classes de test pour
  une classe testée

71
Exemple
Comment tester la classe StringList?

• tester lajout dans une liste vide
• tester lajout dans une liste avec un élément
• tester le retrait dans une liste avec deux
  éléments
• ....

Comment écrire ces tests? Comment les
exécuter? Les tests sont-ils bons? Est-ce que
cest assez testé? ...
72
Exemple test de StringList

• Créer une classe de test qui manipule des
  instances de la classe StringList
• Au moins 9 cas de test (1 par méthode publique)
• Pas accès aux attributs privés count, LastNode,
  CurrentNode, FirstNode

73
Exemple insertion dans une liste
//first test for insert call insert and see if
//current element is the one that's been
inserted public void testInsert1() StringList
list new StringList() list.add("first")
list.add("second") list.insert("third")
assertTrue(list.size()3) assertTrue(list.item
()"third")
Intention
74
3- Test unitaire de composants 00

• 3.1. Introduction au test unitaire 00
• 3.2. JUnit
• le cas particulier du test unitaire en Java
• 3.3. Test-driven development (TDD)
• 3.4. Fiabilisation de composants par analyse de
  mutation

75
JUnit

• Origine
• Xtreme programming (test-first development)
• framework de test écrit en Java par E. Gamma et
  K. Beck
• open source www.junit.org
• Objectifs
• test dapplications en Java
• faciliter la création des tests
• tests de non régression

76
JunitFramework
Un framework est un ensemble de classes et de
collaborations entre les instances de ces
classes. http//st-www.cs.uiuc.edu/users/johnso
n/frameworks.html
77
JunitFramework

• Le source dun framework est disponible
• Ne sutilise pas directement il se spécialise
• Ex pour créer un cas de test on hérite de la
  classe TestCase
• Un framework peut être vu comme un programme à
   trous  qui offre la partie commune des
  traitements et chaque utilisateur le spécialise
  pour son cas particulier.

78
3- Test unitaire de composants 00

• 3.1. Introduction au test unitaire 00
• 3.2. JUnit
• le cas particulier du test unitaire en Java
• 3.3. Test-driven development (TDD)
• 3.4. Fiabilisation de composants par analyse de
  mutation

79
Test-first development

• Xtreme programming
• Écrire les cas de test avant le programme
• les cas de test décrivent ce que le programme
  doit faire
• avant décrire le code, les cas de test échouent
• quand on développe, les cas de test doivent
  passer
• Ensuite on développe la partie du programme qui
  fait passer le cas de test

80
Test-first development
Écrire un cas de test
Exemple ajout dans une liste chainée public
void testAdd() list.add("first") assertTrue(li
st.size()1)
Exécuter les cas de test
succès
échec
public void add (String it) Node node new
Node() node.setItem(it) node.setNext(null) i
f (firstNode null) node.setPrevious(null)
this.setFirstNode(node) lastNode
node this.setCurrentNode(node)
public void add (String it)
développement continue
Faire un petit changement
Exécuter les cas de test
échec
développement sarrête
81
3- Test unitaire de composants 00

• 3.1. Introduction au test unitaire 00
• 3.2. JUnit
• le cas particulier du test unitaire en Java
• 3.3. Test-driven development (TDD)
• 3.4. Fiabilisation de composants par analyse de
  mutation

82
Trusting Components?

• The point of view of the user...

?
Components off-the-shelf
83
Trusting Components?

• The point of view of the user...

replay selftests
100
85
100
55
Components off-the-shelf
84
Trusting Components?

• Plug-in the component in the system

Continuity Strategy Test dependencies between a
component and its environment
85
Summary

• The problem trustable components
• Component qualification with mutation analysis
• Genetic algorithms for test enhancement
• A new model bacteriological algorithms for test
  enhancement
• A mixed-approach and tuning of the parameters
• Conclusion

86
Testing for trust
Object-oriented paradigm
Reuse
the better you test, the more trustable your
component is
87
Testing for trust
Specification
Derived as executable contracts
V V checking Implementation against Specificat
ion
Trust based on Consistency
Implementation
88
Trusting Components?

• The Design of a Trustable Component

89
Intuition

• The better a program is tested the more trust we
  can have
• How can we evaluate the quality of testing?
• Mutation analysis
• If test can detect faults that are seeded
  intentionally, they can detect real faults in the
  program

90
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
• Calcul de la proportion derreurs détectées par
  les cas de test

91
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

92
Analyse de mutation

• Programme erroné mutant
• Cas de test qui détectent les mutants
• Cas de test tuent les mutants
• Score de mutation
• Proportions de mutants tués ? efficacité des cas
  de test
• Deux fonctions doracle
• Différence de traces
• Contrats exécutables

93
Limited Mutation Analysis
Remove-inst
94
Overall Process
95
About Living Mutants

• What if a mutant is not killed?
• Tests inadequate gt add more tests
• Equivalent mutant gt remove mutant (or original!)
• e.g., xlty ? xy ltgt xlty ? xy

96
Quality Estimate Mutation Score

• Q(Ci) Mutation Score for Ci di/mi
• di number of mutants killed
• mi number of 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

97
Outline of a Testing Process

• Select either
• Quality Driven select wanted quality level
  Q(Ci)
• Effort Driven Maximum test cases MaxTC
• Mutation Analysis and Test Cases Enhancement
• while Q(Ci) lt Q(Ci) and nTC lt MaxTC
• enhance the test cases (nTC)
• apply test cases to each mutant
• Eliminates equivalent mutants
• computes new Q(Ci)

98
Component qualification
Mutation operators
99
Mutation operators (1)

• Exception Handling Fault
• causes an exception
• Arithmetic Operator Replacement
• replaces e.g., by - and vice-versa.
• Logical Operator Replacement
• logical operators (and, or, nand, nor, xor) are
  replaced by each of the other operators
• expression is replaced by TRUE and FALSE.

100
Mutation operators (2)

• Relational Operator Replacement
• relational operators (lt, gt, lt, gt, , /) are
  replaced by each one of the other operators.
• No Operation Replacement
• Replaces each statement by the Null statement.
• Variable and Constant Perturbation
• Each arithmetic constant/variable / --
• Each boolean is replaced by its complement.

101
Mutation operators (3)

• Referencing Fault Insertion (Alias/Copy)
• Nullify an object reference after its creation.
  
• Suppress a clone or copy instruction.
• Insert a clone instruction for each reference
  assignment.

102
A test report
119 mutants, 99 dead, 15 equivalents MS
99/10495
103
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

104
Global Process
Automated process
5
6
105
Partial conclusion

• An effective method to build (some level of)
  trust
• estimate the quality a component based on the
  consistency of its 3 aspects
• specification (contract)
• tests
• implementation
• be a good basis for integration and
  non-regression testing
• A tool is currently being implemented
• for languages supporting DbC
• Eiffel, Java (with iContract), UML (with OCLMSC)
  ...