slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test PowerPoint Presentation
Download Presentation
Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test

Loading in 2 Seconds...

play fullscreen
1 / 45

Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test - PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on

Les tests en orienté objet. Procédural vs Objet Le test en Orienté Objet Niveaux de tests Tests de validation / use cases Tests d’intégration Tests unitaires. Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test Les limites du test

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test' - ravi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Les tests en orienté objet

  • Procédural vs Objet
  • Le test en Orienté Objet
    • Niveaux de tests
    • Tests de validation / use cases
    • Tests d’intégration
    • Tests unitaires

Rappels

Définitions

Pourquoi tester ?

Quand tester ?

Niveaux de test

Types de test

Les limites du test

Les techniques du test

d finition
Définition

IEEE-STD 610.12-1990

  • "Le test est l'exécution d'un système ou d'un composant par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats observés"
cas de test jeu
Cas de test (jeu)
  • Un cas de test spécifie
    • L’état de l’implantation sous test (IUT) et de son environnement avant le test
    • Le vecteur des entrées et/ou les conditions
    • Le résultat attendu
      • messages, exceptions
      • valeurs retournées
      • état résultant de l’IUT et de son environnement
pourquoi tester
Pourquoi tester?
  • Fonctionnalités manquantes
  • Fonctionnalités incorrectes
  • Effets de bord, interactions indésirables
  • Mauvaises performances, pbs temps réel, deadlock…
  • Sorties incorrectes
quand tester
Quand tester ?

100

50

20

10

5

1

Spécification

Conception

Codage

Tests

Validation

Maintenance

niveaux de test
Niveaux de test
  • Tests de validation
  • Tests d’intégration
  • Tests unitaires

préparation

exécution

types de tests
Types de tests
  • Tests fonctionnels
  • Tests structurels
  • Tests de non régression
  • Tests de robustesse
  • Tests de performance
les limites du test
Les limites du test
  • L’espace des entrées
  • Les séquences d’exécution
  • Sensibilité aux fautes
explosion combinatoire ex dessiner 1 triangle
Explosion combinatoireEX : dessiner 1 triangle
  • Hypothèse : Coordonnées [1..10]
    • 104 possibilités de dessiner 1 ligne
    • 1012 possibilités de dessiner 3 lignes
  • Hypothèse : écran 1024x768
    • 2,37 1035 possibilités
les s quences d ex cution
Les séquences d’exécution

for (int i=0; i<n; ++i) {

if (a.get(i) ==b.get(i))

x[i] = x[i] + 100;

else

x[i] = x[i] /2;

}

sensibilit aux fautes
Sensibilité aux fautes

short scale(short j) {

j = j -1; // devrait être j = j+1

j = j/30000;

return j;

}

sensibilit aux fautes1
Sensibilité aux fautes
  • 65536 valeurs possibles
  • 6 rendent une valeur incorrecte :

-32768

-30000

-29999

29999

30000

32767

  • 99,9908 % de risque de ne pas trouver l’erreur si test aléatoire.
autres limitations
Autres limitations
  • Tester un programme permet de montrer la présence de fautes mais en aucun cas leur absence
  • Les tests basés sur une implémentation ne peut révéler des omissions car le code manquant ne peut pas être testé
  • On ne peut jamais être sûr qu’un système de test est correct
techniques de test
Techniques de test
  • Classes d’équivalence (éviter l’explosion combinatoire)
  • Graphe de cause à effet (identifier et analyser les relations devant être modélisées dans une table de décision)
  • Tables de décision (concevoir des cas de test)
classes d quivalence
8 Classes valides

triangle scalèle

triangle isocèle (4)

équilatéral (2)

25 Classes invalides

1 valeur = 0

3 valeurs = 0

1 valeur négative

triangle isocèle plat

3 valeurs telles que la somme de 2 d’entre elles < à la 3ème (6)

1 valeur non numérique (3)

1 valeur manquante (3)

triangle scalène plat

1 valeur max

Classes d’équivalence
graphe de cause effet
Principe : représenter la spécification sous forme d’un graphe

On définit les états d’entrées et les états de sorties

On construit le graphe à l’aide de “connecteurs” logiques (et, ou, négation)

Exemple : soit la spécification suivante:

Tout identificateur de voiture doit commencer par les lettres A, B ou C et avoir comme 2ème caractère la lettre X. Les messages M1 et M2 sont émis respectivement en cas d’erreur sur le premier ou le second caractère. Si l’identificateur est correct, il est inséré dans la base de données.

Graphe de cause à effet
graphe de cause effet1
Graphe de cause à effet

E1

S2

E2

V

V

S3

E3

S1

E4

diagramme d activit

X

X

X

ECRIRE BD

ECRIRE BD

ECRIRE BD

[1er CARACTERE == B]

[1er CARACTERE == C]

[1er CARACTERE == A]

X

X

X

MESSAGE M2

MESSAGE M2

MESSAGE M2

MESSAGE M1

Diagramme d’activité

[1er CARACTERE ! = ….]

orient objet uml
Orienté Objet – (UML)
  • Niveau Application (spécification)
    • Diagramme des cas d’utilisation (Use cases)
  • Niveau Sous-Système (conception)
    • Diagramme des classes (ébauche)
    • Diagrammes de séquence
    • Diagrammes de transitions d’états
  • Niveau Classes (conception détaillée)
    • Classes détaillées
comparaison effort de test 1
Comparaison – effort de test (1)
  • Lire 3 valeurs entières.
  • Ces trois valeurs sont interprétées comme représentant les longueurs des côtés d’un triangle.
  • Le programme imprime un message qui établit que le triangle est isocèle, équilatéral ou scalène.
comparaison effort de test 2
Comparaison – effort de test (2)
  • Programmation procédurale
    • 33 cas de tests
  • Programmation objet
    • 58 cas de tests (26 sont les mêmes que ci-dessus, 32 sont dûs à la programmation objet)
slide24

SEGMENT

TRIANGLE

FIGURE

FERMEE

OUVERTE

POLYGONE

ELLIPSE

MULTI-SEG

CERCLE

QUADRILATERE

…..

…..

slide25

TRIANGLE

SEGMENT

POINT

le test en orient objet
Le test en orienté objet

OO vs Non OO

  • System tests - use cases
  • Integration tests - class, sequence, interaction
  • Unit tests - class/methods
  • Regression tests - inheritance?
  • Automated testing - re-use?
  • UML - comment utiliser pour tester?
tests de validation
Tests de validation
  • Trouver les emprunts en retard
    • Tester le délai autorisé (fonction du type de client et du type de document) - 9 cas de test
    • Tester qu’un client peut avoir plusieurs documents en retard
    • Tester que la fiche d’emprunt est supprimée lorsque le document est rendu
le test en orient objet1
Le test en orienté objet
  • Au niveau sous-système
    • test des associations, des agrégations (diagramme de classes)
      • multiplicité
      • création, destruction
    • test de séquences (diagramme de séquence)
      • construction d’un graphe de flot
    • test des exceptions controlées
niveau sous syst me

Triangle

Segment

Mediatheque

Document

LettreRappel

FicheEmprunt

Niveau Sous-Système

0..1

classe ficheemprunt
Classe FicheEmprunt
  • Multiplicité
    • tester qu’une fiche d’emprunt ne concerne qu’un et un seul client et qu’un et un seul document
    • tester qu’une fiche d’emprunt ne peut référencer qu’au plus une lettre de rappel.
    • tester que plusieurs fiches d’emprunts peuvent concerner un même client
classe ficheemprunt1
Classe FicheEmprunt
  • Création
  • Test de validation (raffinement)
    • tester que dateLimite -DateEmprunt = délai autorisé
  • (Test unitaire)
    • tester que si dateLimite dépassée

alors depasse = true.

le test en orient objet2
Le test en orienté objet
  • Tests d’intégration (diagramme de classes => arbre des dépendances)
  • Techniques
    • big-bang
    • bottom-up
    • top-down
ficheemprunt
FicheEmprunt
  • Test de validation (traçage)
    • Tester que la fiche d’emprunt est supprimée lorsque le document est rendu
  • Création
    • Tester que depasse = false
  • Tests de transition d’états
    • Tester que dateJour>dateLimite alors depasse = true (raffinement du test unitaire correspondant)
ficheemprunt1
FicheEmprunt
  • Tester les actions liées aux états et aux transitions d ’états.
ficheemprunt3
FicheEmprunt
  • Tester la chronologie des actions
    • dn = document.dureeEmprunt()
    • dateLimite = client.dateRetour(dateEmprunt, dn)
    • document.emprunter ()
    • Client.emprunter ()
    • tn =document.tarifEmprunt()
    • Tarif = client.sommeDue(tn)
le test en orient objet3
Le test en orienté objet
  • Au niveau de la classe
    • test des méthodes
      • “concevoir pour tester”
      • graphe de contrôle
    • test des séquences d’activation des méthodes
      • diagramme de transition d’états
    • test des méthodes héritées
      • diagramme de classes
concevoir pour tester
lire I,J;

débutCas

cas I = 5 et J < 4

alors M = 23;

cas I = 5 et J >= 4

alors M = J + 16;

cas (J + 1) < I et I<0

alors M = 4I +J;

cas (J + 1) < I et I >= 0 et I /= 5

alors M = 5I + 2

cas (J + 1) >= I et J < 2

alors M = 2I + 3J - 4;

cas (J + 1) >= I et J>= 2 et I /= 5

alors M = 3I +2J –2;

finCas

écrire M;

lire I,J;

si I <= J + 1

alors K = I + J -1

sinon K = 2I + 1

finsi

si K >= I+1

alors L = I + 1

sinon L = J - 1

finsi

si I = 5

alors M = 2L + K

sinon M = L + 2K - 1

finsi

écrire M;

Concevoir pour Tester
le test en orient objet4
Le test en orienté objet
  • L’interaction de méthodes (individuellement correctes) de classes et sous-classes peut générer des erreurs.

=> Ces interactions doivent être systématiquement exercées.

le test en orient objet5
Le test en orienté objet
  • Omettre de tester les interactions d’une méthode redéfinie dans la hierarchie de classe est facile.

=> Les suites de tests conçues pour les superclasses doivent être réexécutées sur les sous-classes et conçues de façon à pouvoir être réutilisés pour tester n’importe quelle sous-classe

le test en orient objet6
Le test en orienté objet
  • La difficulté et la complexité d’implémentation des contraintes de multiplicité peut facilement conduire à des erreurs quand un élément est ajouté, mis à jour, supprimé.

=> L’implémentation de la multiplicité doit être systématiquement exercée.

le test en orient objet7
Le test en orienté objet
  • Des classes avec des contraintes séquencielles sur l’activation des méthodes et leurs clients peuvent avoir des erreurs de séquencement.

=> Le comportement requis doit être testé en utilisant un modèle de machine à états.