Cours de Génie LogicielValidation (par le test)

Lydie du BousquetNovembre 2004

2

Introduction Philippe Lalanda Cas d'étude : Ariane 5 Yves Ledru Les cycles de vie Pierre-Yves Cunin Spécifications en logiciel Philippe Lalanda Conception logicielle Philippe Lalanda Validation Lydie du Bousquet La génération de code Jean-Marie Favre UML : Principes 1 Philippe Lalanda UML : Principes 2 Philippe Lalanda UML : exemple industriel Didier Pellegrin

Liste des interventions

3

Objectifs du cours d'aujourd'hui

Comprendre ce qu’est la validation

Identifier les principales difficultés du « test » de programmes, de logiciels

Connaître quelques techniques permettant de tester des programmes

4

Rappels

Principe du test

Techniques relatives au test

Conclusion

Plan

5

Rappel Le Génie Logiciel Les processus de développement

Principe du Test

Techniques relatives au test

Conclusion

Plan

6

Le GL est une réponse à la "crise du logiciel" erreurs, budgets et échéances dépassés

Le GL est une démarche d'ingénierie définition de processus, de méthodes et d'outils s'applique à tous les aspects du logiciel

Il existe de nombreux processus, méthodes et techniques qu'il faut choisir au mieux sans trop en faire !

Génie Logiciel

7

Les processus logiciels définissent les activités liées à la production de logiciels

Tous les processus incluent les phases :

de spécification du logiciel

de conception du logiciel

d'implantation du logiciel

de vérification / validation

Processus logiciels

8

Validation établissement par des preuves objectives que

toutes les exigences ont été correctement et complètement implémentée (prises en compte)

produit répond aux besoins

Vérification confirmation que ce qui est produit pendant une

étape de développement correspond à toutes les exigences exprimée au début de cette phase

produit conforme à sa définition

Vérification et validation (1)

9

On peut se placer à différents niveaux

Spécification correspond-elle aux exigences ?

Conception correspond-elle à la spécification, aux exigences ?

Implantation correspond-elle à la conception, à la spécification,

aux exigences ?

Vérification et validation (2)

10

Analyse statique revue de code, relecture

croisée Tests Preuve

model-checking preuves déductives

Quelques techniques

11

Rappel

Principe du Test

Définition

Problématiques

Techniques relatives au test

Conclusion

Plan

12

Tester un logiciel, c'est : exécuter le logiciel en maîtrisant les données en entrée en s’assurant que le comportement est celui

attendu

Maîtrise des entrées sélectionner assez de données mais pas trop

Vérification du comportement pouvoir observer le comportement adopter une vision critique

Définition du test

13

Exécution des tests

« à la main » Programmes de test / batch Utilisation d’outils spécialisés

J-unit Cpp-unit …

14

C’est la question clé Pourquoi est-ce que vous testez ?

Pourquoi tester ?

15

On attend du logiciel certaines propriétés adéquation aux besoins absence d’erreur, robustesse, performances, ...

Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un

avion qui n’a jamais été testé en vol mais dont les fabricants vous garantissent qu’ils ont «!prouvé!» que tout allait bien se passer ?

Pourquoi tester ? (2)

16

On attend du logiciel certaines propriétés adéquation aux besoins absence d’erreur, robustesse, performances, ...

Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un

avion qui n’a jamais été testé en vol mais dont les fabricants vous garantissent qu’ils ont «!prouvé!» que tout allait bien se passer ?

Pourquoi tester ? (2)

17

Soit une propriété attendue Exemple : absence d ’erreur Le test ne peux pas garantir que la propriété est

vraie Si un contre-exemple est trouvé, on a la preuve

que la propriété est fausse

Tester : rechercher des erreurs (Myers 79)

Pourquoi tester ? (3)

18

On caractérise l’activité de test en fonction de son objectif

Test de conformité Test de performances, test de montée en charge Test de non régression

du moment ou il effectué dans le développement Test unitaire Test d’intégration Test système Test d’acceptation (ou de recette) Test de non-régression

Types de tests

19

On caractérise l’activité de test en fonction de son objectif

Test de conformité Test de performances, test de montée en charge Test de non régression

du moment ou il effectué dans le développement Test unitaire Test d’intégration Test système Test d’acceptation (ou de recette) Test de non-régression

Types de tests

20

Types de test (2)

Testsunitaires

Spécification

Conceptionglobale

Conceptiondétaillée

Codage

Analyse des besoins

Testsd’intégration

Tests système

Test d’acceptation

21

Difficultés théoriques On ne peut pas tout tester

Infinité de données et/ou pas le temps/argent

Quelles données choisir ? Comment décider que le résultat est correct ? Quand peut-on / doit-on s’arrêter ?

Difficulté psychologique Programmation : activité constructive Test : activité « destructive » Il est difficile de détruire ce que l’on a construit

Pourquoi le test est difficile (1)

22

Test exhaustif Exécuter le logiciel avec toutes les données

d’entrée possibles dans toutes les situations possibles

Impossible

Choisir des donnée pour découvrir des erreurs Quelles données pour trouver des erreurs ? Quelles données pour trouver toutes les erreurs ? Chaque programme est particulier = aucune

technique générale Démarches classiques, basées sur l’expérience

(ensemble de « trucs »)

Pourquoi le test est difficile (2)Le choix de données

23

Décider si le comportement du programme est correct

Problème de l’oracle Pouvoir observer :

quelles sont les sorties du logiciels

Savoir décider Comment décide-t-on que le comportement est OK ? Exple : Soit un programme de tri alphabétique

Pourquoi le test est difficile (3)Résultat correct ?

LagafMafalda

MafaldaLagaf

OK KO

24

Décider si le comportement du programme est correct

Problème de l’oracle Pouvoir observer :

quelles sont les sorties du logiciels

Savoir décider Comment décide-t-on que le comportement est OK ? Exple : Soit un programme de tri alphabétique

Pourquoi le test est difficile (3)Résultat correct ?

Lagaf G.La Poste

La PosteLagaf G.

25

Le test n’a pas révélé d’anomalies Absence d’erreur ? Mauvais choix de données ?

Le test a révélé des anomalies Existe-t-il d’autres erreurs ?

Pourquoi le test est difficile (4)Quand s’arrêter ?

26

Rappel

Principe du Test

Techniques relatives au test

Arrêt du test

Choix des données

Correction du résultat (oracle)

Conclusion

Plan

27

S’assurer que toutes les fonctionnalités ont été testées Base : cahier des charges; exigences et/ou

spécification « Couverture fonctionnelle »

S’assurer que tout le code a été exécuté Base : code « Couverture structurelle »

Étudier l’évolution du nombre de fautes découvertes Analyse de fiabilité

Arrêt du test

28

S’assurer que toutes les fonctionnalités ont été testées Base : cahier des charges; exigences et/ou

spécification « Couverture fonctionnelle »

S’assurer que tout le code a été exécuté Base : code « Couverture structurelle »

Étudier l’évolution du nombre de fautes découvertes Analyse de fiabilité

Arrêt du test

29

Exemple

a

edC2

C1b

c

E

S

a

si C1 alors b

sinon c

si C2 alors d

sinon e

Graphe de contrôle

30

Types de couverture

Instructions Branches Conditions et conditions multiples Chemins avec itérations LCSAJ Flux de données ...

a

edC2

C1b

c

E

S

31

Mesures de couvertureAttention!

Mesure de couverture Soit un critère On s’arrête quand le critère est atteint

L’industrie aime Manipulation de données quantitative Peut être outillé

Attention : Un critère d’arrêt signifie Tant que le critère n’est pas couvert, on n’est sûr que

l’on n’a pas fini de testé Un critère d’arrêt NE signifie PAS

Quand on a atteint le critère on a fini de tester Quand on a atteint le critère on a trouvé toutes les

erreurs

32

Couverture des instructions

Objectif : Exécuter au moins une fois toutes les

instructions du programme

But : Détecter des instructions fautives

Justification : Si on n’a pas testé toutes les instructions, on

n’a pas testé tout le programme

33

Couvertures des instructionsLimites

On peut exécuter toutes les instructions sans exécuter tous les cas

Exemple :

C = vrai satisfait le critère (S1, S2 et S3 exécutés).

C = faux potentiellement jamais testé.

S1; Si C alors S2; S3;

34

Couverture des branches

Objectif : Exécuter au moins une fois chaque branche

But : Mettre en évidence des défauts dans les

instructions conditionnelles ou itératives

Justification Si toutes les conditions n’ont pas été exécutée

au moins une fois à vraie et à faux, …

35

Couverture des branches

Limites Si C1 alors S1 sinon S2;

Si C2 alors S3 sinon S4;

(C1, C2) = (F, F) et (V, V) satisfont le critère. (F, V) et (V, F) jamais testés.

36

Couverture des conditions

Objectif : Exécuter chaque condition avec la valeur

vrai puis faux But :

Similaire couverture des branches Limites :

si A et B alors ... si A alors si B alors ...« A et B » est considéré comme une condition unique

37

Couverture des conditions multiples

Objectif : Exécution de toutes les combinaisons

possibles entre conditions élémentaires constituant une condition composée

Justification : Meilleure détection des défauts dans les

conditions

38

Couverture des chemins avec itérations

Objectif Exécution au moins une fois de chaque

chemin sélectionné suivant deux critères :

Sélection des chemins n’itérant pas plus de k fois (k fixé suite étude défauts, ...).

Sélection de tous les chemins correspondant à 1 passage dans la boucle (pas d’itération) ou 2 passages (1 itération)

39

Couverture de tous les chemins

Objectifs Exécuter tous les chemins du programme

Limites Nombre de chemins infini en général Existence de « chemins impossibles » Détection de défauts situés sur un chemin

non garantie par une seule exécution « Chemin manquant »

40

Mesures de couvertureAttention (bis) !

Un critère d’arrêt signifie Tant que le critère n’est pas couvert, on n’est

sûr que l’on n’a pas fini de testé

Un critère d’arrêt NE signifie PAS Quand on a atteint le critère on a fini de tester Quand on a atteint le critère on a trouvé toutes

les erreurs

41

Rappel

Principe du test

Techniques relatives au test

Arrêt du test

Choix des données

Correction du résultat (oracle)

Conclusion

Plan

42

Génération de données

Il existe de nombreuses méthodes de choix de données

On génère des données En utilisant la structure du code En utilisant la description des exigences,

de la spécification… De façon aléatoire ou par rapport à un

profil opérationnel En utilisant sa propre expérience /

sensibilité

43

Génération de donnéeset couverture(s) structurelle(s)

Approche « mesure a posteriori » Les jeux de test sont produits

aléatoirement ou à partir de spécifications

Le code est instrumenté A la fin de l’opération de test on obtient

une mesure de la couverture atteinte (qu’on compare au critère d’arrêt)

Approche actuellement présente dans la plupart des outils du marché

44

Génération de données (1)

Approche « génération a priori » Choix d’un chemin permettant

d’atteindre un élément visé, Calcul des entrées permettant

l’exécution du chemin A la main = coûteux Automatiquement = du domaine de la

recherche

45

Génération de donnéesbasées sur la spécification

Un exemple de démarche : à partir de la spec : Identification d’ensemble de données pour

lesquelles on suppose que le programme aura un comportement identique = hypothèse de test

Exécution du programme avec 1 données par ens. Éventuellement : identification de cas limite

Exemple : fonction de débit d’un compte Valeur positives, négatives Valeur nulle Valeur entières, relatives Valeur Maximum …

46

Génération de donnéesNotion de profil opérationnel

Idée : tester en priorité les fonctionnalités Qui seront les plus utilisées Qui sont essentielles

Principe Définition d’une description statistique Génération des données par rapport à cette

description Plus une fonctionnalité sera utilisée/critique, plus on

produit de tests

47

Rappel

Principe du test

Techniques relatives au test

Arrêt du test

Choix des données

Correction du résultat (oracle)

Conclusion

Plan

48

On exécute le programme sous test Souvent l’oracle est humain

Erreur d’interprétation Erreur d’inattention

Automatisation de l’oracle Faire un programme qui observe l’exécution et

décide Ce programme « oracle » peut contenir des erreurs Maintenance de ce programme de test

Construire une « spécification formelle exécutable » Exemple : assertion en Java Code peut être un copier-coller de l’assertion Cette spécification n’est généralement pas « complète » Elle peut contenir des erreurs

Problème de l’oracle

49

Rappel

Principe du test

Techniques relatives au test

Conclusion

Résumé

Exercice

Plan

50

Résumé

Points durs du test Choix des données et arrêt du test Problème de l’oracle

Quelques techniques de base Choix des données : pour trouver des erreurs Terminaison : analyse de couverture

de la structure du code, de la spécifications, des exigences …

Attention : indique que le test n’est pas fini

Oracle Spécifications formelles exécutables (assertions Java)

51

Exercice : longueur d’un mot est-elle paire ?

Test fonctionnel Quel ensemble de valeur choisir / spécification

Test structurel Soit le code d’un programme Construire le graphe de contrôle Trouver un ensemble de valeurs permettant de

couvrir Les instructions Les branches Les chemins

52

Exercice : longueur d’un mot est-elle paire ?

1. M <- LireMot2. L = 03. Tant que M[L] != MarqueDeFin faire4. L = L + 15. Fin

6. Ecrire(“L contient un nombre”)7. Si (L mod 2) = 08. Alors Ecrire(“pair”)9. Sinon Ecrire(“impair”)10. Ecrire(“de lettres”)

Mot : séquence de caractères + marque de finrangé dans un tableau de [0..N]

53

Exercice : longueur d’un mot est-elle paire ?

E

3

7

S

1-2

4

8 9

10

6