•Rappels – Définitions – Pourquoi tester ? – Quand tester ? – Niveaux de test – Types de test – Les limites du test – Les techniques du test • Procédural vs Objet • Le test en Orienté Objet – Niveaux de tests – Tests de validation / use cases – Tests d’intégration –Tests unitaires
45
Embed
Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test
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 - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
•Rappels– Définitions – Pourquoi tester ? – Quand tester ?– Niveaux de test– Types de test– Les limites du test– Les techniques du test
• Procédural vs Objet• Le test en Orienté Objet
– Niveaux de tests– Tests de validation / use cases– Tests d’intégration –Tests unitaires
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)
• 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?
• Fonctionnalités manquantes
• Fonctionnalités incorrectes
• Effets de bord, interactions indésirables
• Mauvaises performances, pbs temps réel, deadlock…
• 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
VV
E1
E2
E3
E4
S2
S3
S1
Table de décision
E1 1 0 0 0 X
E2 0 1 0 0 X
E3 0 0 1 0 X
E4 1 1 1 X 0
S1 0 0 0 0 1
S2 0 0 0 1 0
S3 1 1 1 0 0
Diagramme d’activité
ECRIRE BD
MESSAGE M2
X
X
[1er CARACTERE == A]
ECRIRE BD
MESSAGE M2
X
X
[1er CARACTERE == B]
ECRIRE BD
MESSAGE M2
X
X
[1er CARACTERE == C]
MESSAGE M1[1er CARACTERE ! = ….]
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)
• 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)
• 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)
FIGURE
OUVERTE FERMEE
SEGMENT MULTI-SEG ELLIPSE
CERCLE
POLYGONE
TRIANGLE QUADRILATERE …..…..
TRIANGLE
SEGMENT
POINT
Le test en orienté objet
OO vs Non OO
– System tests - use cases– Integration tests - class, sequence, interaction– Unit tests - class/methods
– 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;
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é 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é 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é 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.