test de logiciels

1

Test de Logiciels

Realisé par:Bilel Abed

Encadrée par:Mme Asma Sallemi

2

PLAN

Types de tests2.

Test statique3.

Test dynamique4.

Conclusion5.

Introduction1.1.

3

Pourquoi vérifier et valider?

Pour éviter les bugscoût de la correction des bugs

phase d'implantation

phase d'intégration (bug de conception)

en phase de recette (bug de spécification)

phase d'exploitation

4

Pourquoi vérifier et valider?Pour assurer la qualité

• réponse aux besoins des utilisateursCapacité fonctionnelle

• prise en main et robustesseFacilité d'utilisation

• tolérance aux pannesFiabilité • temps de réponse, débit, fluidité...Performance • facilité à corriger ou transformer le logicielMaintenabilité

• aptitude à fonctionner dans un environnement différent de celui prévuPortabilité

5

Méthodes de vérification et validation

assurer que le système fonctionne correctement

Preuve formelle de propriétés sur un modèle du système Vérifica

tion

assurer que le système fonctionne selon les attentes de l'utilisateur

Assurance d'un certain niveau de confiance dans le système Validatio

n

« Are we building the right product ? »

model-checking Preuve

Test

6

Comparaison des méthodes de V&V

Test : ✔Nécessaire : exécution du système réel, découverte d'erreurs à tous les niveaux

(spécification, conception, implantation)✗ Pas suffisant : exhaustivité impossible

Preuve :✔ Exhaustif✗ Mise en oeuvre difficile, limitation de taille

Model-checking :✔ Exhaustif, partiellement automatique✗ Mise en oeuvre moyennement difficile (modèles formels, logique)

7

Comparaison des méthodes de V&V

Méthodes complémentaires :

Test non exhaustif mais facile à mettre en oeuvre Preuve exhaustive mais très techniqueModel-checking exhaustif et moins technique que la preuve

Mais :

Preuve et model-checking limités par la taille du système et vérifient des propriétés sur un modèle du système (distance entre le modèle et le système réel ?)Test repose sur l'exécution du système réel, quelles que soient sa taille et sa complexité

8

DefinitionsTester un logiciel consiste à l’exécuter en ayant la totale maîtrise des données qui lui sont fournies en entrée (jeux de test) tout en vérifiant que son comportement est celui attendu

Le test est l’exécution ou l’évaluation 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 obtenus. (IEEE)

Tester c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts. (G. Myers, The Art of Software Testing)

Le test est une technique de contrôle consistant à s’assurer, au moyen de son exécution, que le comportement d’un programme est conforme à des données

9

Bug?Anomalie (fonctionnement) : différence entre comportement attendu et comportement observé

Défaut (interne) : élément ou absence d'élément dans le logiciel entraînant une anomalie

Erreur (programmation, conception) : comportement du programmeur ou du concepteur conduisant à un défaut

Anomalie Défaut Erreur

10

Processus de test

1.Choisir les comportements à tester (objectifs de test)

2. Choisir des données de test permettant de déclencher ces comportements & décrire le résultat attendu pour ces données

3. Exécuter les cas de test sur le système + collecter les résultats

4. Comparer les résultats obtenus aux résultats attendus pour établir un verdict

sélection

• Spécifica_tion,

génération

• Objectif de test

exécution

• Cas de test

11

Types de testsStratégie (cycle de vie)

Accessibilité

Critère d'évaluation (qualité du logiciel)

Système

Intégration

Unitaire

Boîte noire Boîte Blanche

Conformité

Robustesse

Performance

Sécurité

12

Cycle de vie du logiciel

Spécification

Conceptiongénérale

Conceptiondétaillée

Réalisation

Tests unitaires

Tests d'intégration

Tests système

Cycle en V

13

Etapes et hiérarchisation des testsTest fonctionnel - boîte noireIndépendant de l’implémentationPlanifier à partir de la spécification fonctionnelleRéutilisablesTest structurel - boîte blancheDépend de l implémentationLes données de test sont produites à partir d’une analyse du code source

Test de logiciel

Teststructurel

Tests unitaires Tests d ’intégration

Testfonctionnel

Tests système

14

Test de conformité

But : Assurer que le système présente les fonctionnalités attendues parl'utilisateur

Méthode : Sélection des tests à partir de la spécification, de façon àcontrôler que toutes les fonctionnalités spécifiées sont implantées selonleurs spécifications

Exemple: Service de paiement en ligneScénarios avec transaction acceptée/refusée, couverture desdifférents cas et cas d'erreur prévus

15

Test de robustesse

But : Assurer que le système supporte les utilisations imprévues

Méthode : Sélection des tests en dehors des comportements spécifiés(entrées hors domaine, utilisation incorrecte de l'interface,environnement dégradé...)

Exemple: Service de paiement en ligneLogin dépassant la taille du buffer Coupure réseau pendant la transaction

16

Test de sécurité

But : Assurer que le système ne possède pas de vulnérabilitéspermettant une attaque de l'extérieur

Méthode : Simulation d'attaques pour découvrir les faiblesses du système qui permettraient de porter atteinte à son intégrité

Exemple: Service de paiement en ligneEssayer d'utiliser les données d'un autre utilisateurFaire passer la transaction pour terminée sans avoir payé

17

Test de performance

But : Assurer que le système garde des temps de réponse satisfaisants à différents niveaux de charge

Méthode : Simulation à différents niveaux de charge d'utilisateurs pour mesurer les temps de réponse du système, l'utilisation des ressources...

Exemple: Service de paiement en ligne Lancer plusieurs centaines puis milliers de transactions en même temps

18

Test de non régression Un type de test transversal

But : Assurer que les corrections et les évolutions du code n'ont pasintroduit de nouveaux défauts

Méthode : À chaque ajout ou modification de fonctionnalité, rejouerles tests pour cette fonctionnalité, puis pour celles qui en dépendent,puis les tests des niveaux supérieurs

Lourd mais indispensableAutomatisable en grande partie

19

Techniques de « test statique »Définition : ne requiert pas l ’exécution du logiciel sous test sur des données réelles

Efficacité : plus de 50 % de l ’ensemble des fautes d ’un projet sont détectées lors des inspections si il y en a (en moyenne plus de 75%)

Défaut : mise en place lourde, nécessité de lien transversaux entre équipes, risques de tension…tâche plutôt fastidieuse

Règlesêtre méthodiqueun critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait(R1)un second critère : les algorithmes/l’architecture de contrôle apparaît-elle clairement ?(R2)décortiquer chaque algorithme et noter toute redondance curieuse et toute discontinuité

20

Test statiqueExemple: vérification de la clarté procédurale

R1 :Détermination des paramètres globauxet de leur impact sur les fonctions propres

Program :recherche_rec;const

max_elt = 50;choix1 = 1;choix2 = 2;fin = 3;

typeTliste = array[1..max_elt] of integer;

varliste : Tliste;taille, choix, val : integer;complex : integer;

But du programme non exprimé

Manque de commentaires

Identificateurs non explicites

21

Test statiqueExemple: vérification de la clarté

R2 : Existence d’un entête clair pour chaque fonction

{--------------------------------------------------------------------Recherche récursive d'une valeur dans une liste triée--------------------------------------------------------------------}{ paramètres d'entrée :

liste Lla valeur recherchéeindice gaucheindice droit

résultat : complexité de la recherche }

function rech_rec(L : Tliste ; val, g, d : integer) : integer ;

Interface Spécifiée

Interface implanté

22

Techniques de « test dynamique » DT : Donnée de Test = une (séquence) d’entrée(s)

JT = {DT}

D = domaine d’entrée du programme P sous test

Soient F, les fonctions spécifiées du logicielF : D -> Sorties

Le problème du test dynamique est :

D -----> Sorties

DEUX REGLES :

Conserver les tests déjà écrits

Conserver les réponses correctes correspondantes

F=P?

23

Test dynamique structurel“Testing can prove the presence of bugs, but

never their absence” (Dijkstra)

Le test structurel: abstraire pourobtenir un critère formel

C

l1 l2Si C alors l1Sinon l2

24

Test unitaire structurelGraphe de Contrôle (langages procéduraux/actionnels)

But : représenter tous les chemins d’exécution potentiels

Graphe orienté : avec un noeud d’entrée E et un noeud de sortie S (noeud fictif ajouté si plusieurs sorties)

Sommets : blocs élémentaires du programme, ou prédicats des conditionnelles /boucles, ou noeuds de jonction “vide” associé à un noeud prédicatBloc élémentaire : séquence maximale d’instructions séquentielles

Arcs :enchaînement d’exécution possibles entre deux sommets

25

Test unitaire structurelExemple : PGCD de 2 nombresPrécondition: p et q entiers naturels positifs lus au clavierEffet : result = pgcd(p, q)En pseudo-langagepgcd: integer islocal p,q : integer;do

read(p, q)while p<> q do

if p > qthen p := p-qelse q:= q-pend -- if

end -- whileresult:=p

end-- pgcd

B1

B1

E

P1

P1

P2P2

B2B2B3 B3

P=q

B4

SB4

P>q P<=q

P<>q

26

Test unitaire structurel

Chemins : suite d’arcs rencontrés dans le graphe, en partant de E et finissant en S.

en général représenté sans perte d’information par une liste de sommets

Prédicat de chemin : conjonction des prédicats (ou de leur négation) rencontrés le long du chemin.

Pas toujours calculableE B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ième valeur de p)E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ième valeur de p)E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i ∈ [0..n])

Chemins infaisables : problème en général indécidable

27


Sélection des tests fondés sur le flot de contrôle

Couverture des instructions : chaque bloc doit être exécuté au moins une fois

Couverture des arcs ou enchaînements

tous les chemins élémentaires ou 1-chemins

tous les i-chemins : de 0 à i passages dans les boucles

tous les chemins : si boucles, potentiellement infinis

28


B1

E

P1

P2

B2 B3

P=q

B4

S

P>q P<=q

P<>q

Tous les noeuds:(E, B1, P1, P2, B2, P1, B4, S)(E, B1, P1, P2, B3, P1, B4, S)Tous les arcs : idemTous 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)

Questions : qu’est-ce que ne capture pas ce modèle ?

29

Test unitaire structurelAspects données

Couverture desprédicats

if then imbriqués

Couverture desdépendances

entre variablesFlot de données

Couverture desdomainesd’entréePertinence desdonnées

30


Graphe de Flot de Données

But : représenter les dépendances entre les données du programme dans le flot d’exécution.

Graphe de contrôle décoré d’informations sur les données (variables) du programme.

Sommets :idem GCune définition (= affectation) d’une variable v est notée def(v)une utilisation d’une variable est v notée P_use(v) dans un prédicat

et C_use(v) dans un calcul.

31

Test unitaire structurelExemple : PGCD de 2 nombresPrécondition: p et q entiers naturels positifs lus au clavierEffet : result = pgcd(p, q)En pseudo-langagepgcd: integer islocal p,q : integer;do

read(p, q)while p<> q do

if p > qthen p := p-qelse q:= q-pend -- if

end -- whileresult:=p

end-- pgcd

B1

B1

E

P1

P1

P2P2

B2B2B3 B3

P=q

B4

SB4

P>q P<=q

P<>qDef(p) Def(q)

Def(p)

Puse(p) Puse(q)

Puse(p)

Puse(p) Puse(q)Puse(p)

Def(p) Cuse(q) Cuse(p)

Cuse(p)

Def(q) Cuse(p) Cuse(q)

Cuse(p)

Cuse(p)

Cuse(p)

32

Test d’intégration

But : vérifier les interactions entre composants (se base sur l’architecture de conception

Difficultés principales de l’intégration

interfaces floues

implantation non conforme au modèle architectural (dépendances entre composants non spécifiées)

réutilisation de composants (risque d’utilisation hors domaine)

33


Stratégies possibles (si architecture sans cycles)

big-bang : tout est testé ensemble. Peu recommandé !

top-down : de haut en bas. Peu courant. Ecriture uniquement de drivers de tests.

bottom-up : la plus classique. On intègre depuis les feuilles.

34


D

S

T

Driver

Stub

Composant testé

Composant sous test

Interface sous test

Interface testé

D

35


T

D D DD

T T T

D D D

Bottom-up

36

Test d’intégrationBottom-up

37

Test d’intégrationBottom-up

38

Test d’intégrationTop-down

39


40


41


42

Conclusion

Facteurs de bonne testabilité :Précision, complétude, traçabilité des documentsArchitecture simple et modulairePolitique de traitements des erreurs clairement définie

Facteurs de mauvaise testabilité :Fortes contraintes d’efficacité (espace mémoire, temps)Architecture mal définie

Difficultés du test :Indécidabilité : une propriété indécidable est une propriété qu’on ne pourra jamais prouver dans le cas généralExplosion combinatoire : Le test n’examine qu’un nombre fini (ou très petit) d’exécutionsImpossibilité d’une automatisation complète satisfaisante

test de logiciels

Education