trié sans redondance

Concrétisation : DT et résultat attendu

DT1

DT2

DT3

vec = [5,3,15]

vec = []

vec = [10,20,30,5,30,0]

res = [3,5,15]

res = []

res = [0,5,10,20,30]

S.Bardin

Test Logiciel

13/ 99

Exemple (2)

Script de test

v o i d t e s t S u i t e ( ) {

i n t [ ]

td1 = [ 5 , 3 , 1 5 ]

;

/∗ p r e p a r e d a t a

∗/

i n t [ ] o r a c l e 1 = [ 3 , 5 , 1 5 ]

;

/∗ p r e p a r e o r a c l e ∗/

i n t [ ]

r e s 1 = my−s o r t ( td1 ) ; /∗ r u n CT and

/∗ o b s e r v e

∗/

r e s u l t ∗/

( a r r a y −compare ( r e s 1 , o r a c l e 1 ) ) /∗ a s s e s s

i f

t h e n p r i n t ( ‘ ‘ t e s t 1 ok ’ ’ )

e l s e { p r i n t ( ‘ ‘ t e s t 1 e r r e u r ’ ’ ) } ;

v a l i d i t y ∗/

. . .

/∗ same f o r o t h e r

t e s t d a t a

∗/

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

S.Bardin

Test Logiciel

14/ 99

Qu’apporte le test ?

Le test ne peut pas prouver au sens formel la validité d’un programme

Testing can only reveal the presence of errors but never their absence.

• E. W. Dijkstra (Notes on Structured Programming, 1972)

Par contre, le test peut “augmenter notre confiance” dans le bon

fonctionnement d’un programme

correspond au niveau de validation des systèmes non informatiques

Un bon jeu de tests doit donc :

exercer un maximum de “comportements différents” du programme

[notion de critères de couverture]

notamment

! tests nominaux : cas de fonctionnement les plus fréquents

! tests de robustesse : cas limites / délicats

S.Bardin

Test Logiciel

16/ 99

Plan

Introduction au test logiciel

! Contexte

! Définition du test

! Éléments de classification

! Aspects pratiques

! Point de vue industriel

! Complément : critères boˆıte noire

! Complément : critères boˆıte blanche

! Complément : tests de régression

! Discussion

S.Bardin

Test Logiciel

19/ 99

Selon la propriété testée

correction fonctionnelle

robustesse

performances

sécurité

ergonomie

...

S.Bardin

Test Logiciel

20/ 99

Selon le cycle de développement (1)

aussi : phase d’évolution / maintenance : tests de (non) régression

S.Bardin

Test Logiciel

21/ 99

Selon le cycle de développement (2)

Tests unitaire : tester les différents modules en isolation

définition non stricte de “module unitaire” (procédures, classes, packages,

composants, etc.)

uniquement test de correction fonctionnelle

Tests d’intégration : tester le bon comportement lors de la composition des

modules

uniquement test de correction fonctionnelle

Tests système / de conformité : valider l’adéquation du code aux spécifications

on teste aussi toutes les caractéristiques émergentes

sécurité, performances, etc.

Tests de validation / acceptance : valider l’adéquation aux besoins du client

souvent similaire au test système, mais réaliser / vérifier par le client

Tests de régression : vérifier que les corrections / évolutions du code n’ont pas

introduits de bugs

S.Bardin

Test Logiciel

22/ 99

Selon la source de cas de tests (1)

Boˆıte Noire : à partir de spécifications

dossier de conception

interfaces des fonctions / modules

modèles formels ou semi-formels

Boˆıte Blanche : à partir du code

critères basés sur le graphe de flôt de contrôle

critères basés sur le graphe de flôt de données

mutations syntaxiques

S.Bardin

Test Logiciel

23/ 99

Selon la source de cas de tests (1)

Boˆıte Noire : à partir de spécifications

dossier de conception

interfaces des fonctions / modules

modèles formels ou semi-formels

Boˆıte Blanche : à partir du code

critères basés sur le graphe de flôt de contrôle

critères basés sur le graphe de flôt de données

mutations syntaxiques

Probabiliste : domaines des entrées + arguments statistiques

random : distribution uniforme [ou pas ...]

statistique : distribution mimant le profil opérationnel attendu

S.Bardin

Test Logiciel

23/ 99

Selon la source de cas de tests (2)

nécessite le code ?

fautes de conformance

fautes de codage

critères classiques

tests

pb spécifique

quel niveau ?

boˆıte noire

non

oui

non

partition des entrées

limites

ok

concrétisation

des CT en DT

tous

boˆıte blanche

oui

erreur fonctionnelle : oui

omission de fonctionalité : non

oui

instructions, branches

MCDC

potentiellement énorme

oracle

plutôt unitaire

(ou critères light : couv. fonctions)

S.Bardin

Test Logiciel

24/ 99

Boite Noire vs Boite Blanche (2)

Exemples de complémentarités des critères

Bug du Pentium : cause = erreurs sur quelques valeurs (parmis des millions)

dans une table de calculs

impossible à trouver en test boite noire

aurait pu être trouvé facilement en test unitaire du module concerné

Bug du “Mars Climate Orbiter” : cause = probleme de métriques (metres vs

pouces)

chaque module fonctionne correctement, test unitaire inutile

aurait pu être détecté en phase de tests d’intégration, en se basant sur

l’interface de communication (boite noire)

S.Bardin

Test Logiciel

26/ 99

Exécution du test : pas toujours simple

. Code manquant (test incrémental)

. Présence d’un environnement (réseau, Base de Données, etc.)

. Exécution d’un test très coûteuse en temps

. Hardware réel non disponible, ou peu disponible

. Possibilité de réinitialiser le système ?

si non, l’ordre des tests devient très important

. Moyens d’observation et d’action sur le système

sources dispo, compilables et instrumentables : cas facile, script = code

si non : difficile, “script de test” = succession d’opérations (manuelles ?)

sur l’interface disponible (informatique ? électronique ? mécanique ?)

S.Bardin

Test Logiciel

34/ 99

Tests de (non) régression

Tests de régression : à chaque fois que le logiciel est modifié, s’assurer que “ce

qui fonctionnait avant fonctionne toujours”

Pourquoi modifier le code déjà testé ?

correction de défaut

ajout de fonctionnalités

Quand ?

en phase de maintenance / évolution

ou durant le développement

Quels types de tests ?

tous : unitaires, intégration, système, etc.

Objectif : avoir une méthode automatique pour

rejouer automatiquement les tests nécessaires [perfs !]

détecter les tests dont les scripts ne sont plus corrects

S.Bardin

Test Logiciel

36/ 99

Dilemmes du test

Si la campagne de tests trouve peu d’erreurs

choix 1 (optimiste) : le programme est très bon

choix 2 (pessimiste) : les tests sont mauvais

Si la campagne de tests trouve beaucoup d’erreurs

choix 1 (optimiste) : la majeure partie des erreurs est découverte

choix 2 (pessimiste) : le programme est de très mauvaise qualité, encore

plus de bugs sont à trouver

solution : qualité du jeu de tests [critères de couverture]

S.Bardin

Test Logiciel

46/ 99

Sélection des tests

Problèmes de la sélection de tests :

efficacité du test dépend crucialement de la qualité des CT/DT

ne pas “râter” un comportement fautif

MAIS les CT/DT sont coûteux (design, exécution, stockage, etc.)

Deux enjeux :

DT suffisamment variées pour espérer trouver des erreurs

maˆıtriser la taille : éviter les DT redondantes ou non pertinentes

S.Bardin

Test Logiciel

48/ 99

Critères de couverture

Sujet central du test

Tente de répondre à la question : “qu’est-ce qu’un bon jeu de test ?”

Plusieurs utilisations des critères :

guide pour choisir les CT/DT les plus pertinents

évaluer la qualité d’un jeu de test

donner un critère objectif pour arrêter la phase de test

Quelques qualités atttendues d’un critère de test :

bonne corrélation au pouvoir de détection des fautes

concis

automatisable

S.Bardin

Test Logiciel

49/ 99

Récapitulatif des problèmes

Sélection des CT/DT pertinents : très difficile

expériences industrielles de synthèse automatique

Script de test : de facile a difficile, mais toujours tres ad hoc

Verdict et oracle : très difficile

certains cas particuliers s’y prêtent bien

des oracles partiels automatisés peuvent être utiles

Régression : bien automatisé (ex : JUnit pour Java)

S.Bardin

Test Logiciel

50/ 99

Rappel : deux aspects du test

1- Construire la qualité du produit

lors de la phase de conception / codage

en partie par les développeurs (tests unitaires)

but = trouver rapidement le plus de bugs possibles (avant la

commercialisation)

! test réussi = un test qui trouve un bug

2- Démontrer la qualité du produit à un tiers

une fois le produit terminé

idéalement : par une équipe dédiée

but = convaincre (organismes de certification, hiérarchie, client)

! test réussi = un test qui passe sans problème

! + tests jugés représentatifs

(systèmes critiques : audit du jeu de tests)

S.Bardin

Test Logiciel

52/ 99

Critères boite noire

. Couverture des partitions des domaines d’entrée

. Test aux limites

. Approche pair-wise pour limiter la combinatoire

Remarque : si on dispose d’un modele formel, on peut appliquer les criteres de

couverture boite blanche au niveau du modèle

S.Bardin

Test Logiciel

57/ 99

Test des domaines d’entrées

outType function-under-test(inType x, inType y);

Constat : test exhaustif souvent impratiquable

espace des entrées non borné / paramétré / infini (BD,

pointeurs, espace physique, etc.)

simplement deux entiers 32 bits : 264 possibilités

S.Bardin

Test Logiciel

58/ 99

Partition des entrées : principe

Principe :

diviser le domaine des entrées en un nombre fini de classes tel que le

programme réagisse pareil (en principe) pour toutes valeurs d’une classe

conséquence : il ne faut tester qu’une valeur par classe !

⇒ permet de se ramener à un petit nomlbre de CTs

Exemple : valeur absolue : abs : int #→ int

232 entrées

MAIS seulement 3 classes naturelles : < 0, = 0, > 0

on teste avec un DT par classe, exemple : -5, 0, 19

S.Bardin

Test Logiciel

59/ 99

Rappel : test des domaines d’entrées

outType function-under-test(inType x, inType y);

Constat : test exhaustif souvent impratiquable

espace des entrées non borné / paramétré / infini (BD,

pointeurs, espace physique, etc.)

simplement deux entiers 32 bits : 264 possibilités

S.Bardin

Test Logiciel

68/ 99

Graphe de flot de contrôle

Le graphe de flot de contrôle d’un programme est défini par :

un noeud pour chaque instruction, plus un noeud final de sortie

pour chaque instruction du programme, le CFG comporte un arc reliant le

noeud de l’instruction au noeud de l’instruction suivante (ou au noeud

final si pas de suivant), l’arc pouvant être étiquetté par l’instruction en

question

Quelques définitions sur les instructions conditionnelles :

if (a<3 && b<4) then ... else ...

un if est une instruction conditionnelle / branchante

(a<3 && b<4) est la condition

les deux décisions possibles sont (condition, true) et (condition, false)

(chaque transition)

les conditions simples sont a<3 et b<4

S.Bardin

Test Logiciel

75/ 99

Graphe de flot de contrôle (2)

1

2

3

4

5

6

7

8

9

10

11

START

i n p u t ( i )

sum := 0

i f

l o o p :

i n p u t ( j )

i f

sum := sum + j

i f

:= i +1

i

goto l o o p

end : HALT

( i > 5 ) goto end

( j < 0 ) goto end

( sum > 1 0 0 ) goto end

S.Bardin

Test Logiciel

76/ 99

Quelques critères de couverture

Quelques critères de couverture sur flot de contrôle

Tous les noeuds (I) : le plus faible.

Tous les arcs / décisions (D) : test de chaque décision

Toutes les conditions (C) : peut ne pas couvrir toutes les décisions

Toutes les conditions/décisions (DC)

Toutes les combinaisons de conditions (MC) : explosion combinatoire !

Tous les chemins : le plus fort, impossible à réaliser s’il y a des boucles

Remarque : il existe d’autres critères boite blanche

basés sur la couverture du flot de données

basés sur les mutations syntaxiques du code

S.Bardin

Test Logiciel

77/ 99

Tests de régression : problème SMP

Compromis entre tout rejouer (sûr mais trop cher) et ne pas rejouer assez.

certains tests ne passent pas par les modifications : les ignorer

Problème additionnel : temps total pour le rejeu limité

on arrête après N tests

avec cette limite, le rejeu total est risqué

faire tests pertinents d’abord

Trois phases distinctes dans la sélection :

Sélectionner les tests pertinents (aucune perte)

Minimiser les tests pertinents (perte possible)

Prioritiser les tests restants (aucune perte)

S.Bardin

Test Logiciel

91/ 99

Tests de régression : problème SMP (2)

S.Bardin

Test Logiciel

92/ 99

Philosophie du test

Testing can only reveal the presence of errors but never their absence

• E. W. Dijkstra (Notes on Structured Programming, 1972)

Oui, mais ...

Correspond au niveau de fiabilité exigé du reste du système

Correspond aux besoins réels de beaucoup d’industriels

Peut attaquer des programmes + complexes

S.Bardin

Test Logiciel

97/ 99

Test et vérification (avis personnel)

Opposition historique forte

Complémentaire au niveau fonctionnel

propriété prouvée = pas besoin de tests

propriété non prouvée = peut être fausse ? (test !)

certaines classes de propriétés sont pour le moment non modélisables

[perfs, ergonomie, etc.]

facilité de mise en oeuvre : AS unsound ≤ test ≤ AS sound

De plus en plus similaire en terme de technologie

preuve d’invariance vs preuve d’accessibilité

mêmes outils : logique, sémantique, analyse de programme, etc.

mais approximations différentes (sur- vs sous-), importance de la synthèse

de plus en plus de techniques “hybrides” (bounded model checking,

context-bounded analysis, etc.)

remarque : langage de spécification utile pour vérification et test

[next big step in industry ?]

S.Bardin

Test Logiciel

99/ 99