transp. - Imagine

Transcription

transp. - Imagine

Génie logiciel – Test © 2005-2007 Renaud Marlet
1
Cours de génie logiciel
(d'après A.-M. Hugues, ...)
Test
Renaud Marlet
LaBRI / INRIA
http://www.labri.fr/~marlet
màj 23/04/2007
2
Le Test
●
Vérifie que le produit est conforme aux intentions
–
●
Un des moyens de l'assurance qualité
–
●
aspects surtout fonctionnels
le plus utilisé, aussi « vieux » que le développement
Méthode dynamique (en exécutant le logiciel)
–
vient après les méthodes statiques (analyses auto.)
–
dernier rempart contre les erreurs résiduelles
–
encore trop souvent empirique
Aspects psychologiques (1)
●
●
Importance de l'intention
–
les tests sont élaborés en fonction de l'intention
–
vouloir démontrer que le programme marche =
mauvaise approche car les tests sont choisis en
conséquence (ne trouvent rien de neuf)
Activité de test
–
processus « destructif »
–
objectif : mettre en évidence des erreurs
–
si on n'y aboutit pas, c'est un échec (!)
3
Aspects psychologiques (2)
●
Plus facile de trouver les erreurs des autres que
les siennes
–
on ne détruit pas bien ce qu'on a construit soi-même
–
à force de regarder, on ne voit plus rien
–
regard neuf : nouvelle interprétation des spécifications
→ Séparation des tâches
–
équipes de développement ≠ équipes d'intégration et
de qualification
–
budget de qualification et de développement séparés
4
5
Testabilité
●
●
Facilité avec laquelle des tests peuvent être
développés à partir des documents de conception
–
faisabilité
–
coût
–
critères de décision de succès ou d'échec d'un test
–
couverture
Se prépare tout au long du cycle de vie
–
spécifications, conception globale et détaillée
(compréhensibles, précises, pertinentes, quantifiées...)
6
Facteurs de testabilité
●
●
Facteurs de bonne testabilité
–
précision, complétude, traçabilité des documents
–
architecture simple et modulaire
–
abstractions à travers des interfaces
–
politique claire des traitements d'erreur
Facteurs de mauvaise testabilité
–
forte contraintes d'espace mémoire et d'efficacité
–
intégration forte des traitements
–
longues chaînes de traitements
7
Limites théoriques (1)
●
Notion d'indécidabilité
–
●
propriété indécidable = qu'on ne pourra jamais prouver
dans le cas général (pas de procédé systématique)
Exemples de propriétés indécidables
–
l'exécution d'un programme termine
–
deux programmes calculent la même chose
–
un programme n'a pas d'erreur
–
un paramètre du programme fait passer l'exécution
●
sur une instruction, une branche, un chemin donné
●
sur toutes les instruction, branches ou chemins
Limites théoriques (2)
Une bataille perdue d'avance :
–
un programme a un nombre infini (ou gigantesque)
d'exécutions possibles
–
un jeu de tests n'examine qu'un nombre fini (petit)
d'exécutions possibles
Trouver des heuristiques :
–
approcher l'infini (ou le gigantesque) avec le fini (petit)
→ tester les exécutions les plus « représentatives »
8
Terminologie : alpha- et bêta-test
●
Alpha-test (alpha testing)
–
●
test effectué en phase de développement, avant la
distribution du produit (→ alpha-versions du produit)
Bêta-test (beta testing)
–
test effectué après l'alpha-test, en distribuant le
produit (→ des bêta-versions) à un groupe limité
d'utilisateurs avertis
☛ dans la suite de ce cours : uniquement -test
9
Organisation de l'activité de test
●
●
Activité coûteuse → optimiser l'investissement
–
effort minimum / probabilité max. de détection d'erreur
–
incrémentalité
Construction des tests
–
aussi organisée que celle d'un produit (!)
(☛ il y a des sociétés qui vendent des suites de test)
●
Gestion projet
–
planification suffisamment tôt (difficile d'accroître les
ressources en fin de développement)
10
11
Tâches
●
Définition des tests
●
Implémentation des jeux de tests
●
Soumission des jeux de tests
●
Dépouillement des résultats
●
Évaluation de la qualité des tests
●
Décision d'arrêter l'écriture de tests
●
Rejeu (maintenance, non régression)
Environnements (outils) de test
●
Mise en œuvre des jeux de test
–
●
●
construction de données et de contextes d'exécution
Diagnostic
–
définition de critères de réussite / échec
–
automatisable ou non (ex. test d'interface)
Synthèse des résultats
–
car les sorties des tests sont souvent très grosses
→ ne pas rater une erreur dans une masse de succès
●
Diffusion des résultats
12
Types de test
(éléments testés et phases)
●
Tests unitaires
–
●
Tests d'intégration
–
●
test de l'assemblage des modules
(pendant le développement)
Tests de validation
–
●
test d'une fonction, une classe, un module
(pendant le développement)
chez le fournisseur, par l'équipe de qualification,
puis chez le client
Tests de suivi d'exploitation
13
Types de test
(nature des propriétés testées)
●
Tests fonctionnels
–
●
Tests de performance
–
●
vitesse, charge, ...
Tests de fiabilité
–
●
réaction à certaines entrées (sorties produites)
résistance aux pannes
Tests de sécurité, ...
☛ Tous types et étapes de test pas nécessairement
présents : dépend de la criticité du logiciel
14
Types de test
(selon les informations accédées)
●
●
Test boîte noire [black box testing]
–
évaluation de l'extérieur (sans regarder le code),
uniquement en fonction des entrées et des sorties
–
sur le logiciel ou un de ses composants
Test boîte blanche [white/glass box testing]
–
exploite le code (→ besoin du source/de l'architecture)
–
tests de portions de code : bloc, branche, etc.
15
Contenu d'un plan de test (1)
●
●
Définition des cas de test
–
configuration matérielle et logicielle
–
pré-conditions
–
étapes du test
–
critères de réussite / échec
Chronologie et durée des étapes de test
–
pour chaque étape, chronologie et moyens de mise
en œuvre des différents jeux de test
–
modes d'intégration
16
●
Équipes concernées et responsabilités
●
Procédures de suivi
●
–
évaluation du degré de réalisation des tests
–
procédures de collecte de données statistiques
Actions à prendre en cas de découverte d'erreur
–
signalement aux développeurs
–
contrôle après corrections (suivi)
17
●
Délais et temps de calcul
●
Politique de passage des tests
(y compris les tests de non régression)
●
Normes
●
Outils et méthodes recommandés
●
Bibliothèques de tests
18
Critères d'arrêt des
développements de tests
●
Taux de couverture atteint (☛ critère a priori)
–
●
●
suffisamment d'aspects testés
Nombre ou taux d'erreurs découvertes
(☛ critère a posteriori)
–
courbe du nb d'erreurs en fonction de la durée
–
arrêt sous un certain seuil (→)
–
séparation des erreurs par catégorie
Épuisement des ressources dédiées au test (☹)
–
effort humain et/ou durée
19
Taux de découverte de bogues
et arrêt des tests
nb d'erreurs découvertes
par unité de temps
supplémentaire
Surface sous la courbe =
nb d'erreurs découvertes
ou encore à découvrir
seuil de
rentabilité
arrêt des tests
temps
20
21
Rapport qualité prix
Nombre de cas de test arbitrairement grand
→ Nécessité d'un compromis
–
précision, bon degré de couverture, bonnes
informations pour les développeurs-testeurs
(reproductibilité, debug)
–
coût (définition, réalisation, passage, dépouillement)
–
temps d'exécution de tests
–
nb de ressources de calcul (machines) mobilisées
Test fonctionnel :
Partition en classes d'équivalence (1)
●
Partition du domaine d'entrées (souvent infini) en
un nombre fini de classes d'équivalence
→ limite le nombre de tests
●
Définition d'une entrée représentative pour
chaque classe
–
●
idée : chaque représentant d'une classe a une même
« probabilité » que les autres de mettre en évidence
une erreur
Prendre en compte les données invalides comme
les données valides : toutes sont des entrées...
22
Test fonctionnel :
Ex. fonction qui attend un numéro de département
(de métropole) entre 1 et 95 :
Validité des entrées
Classes d'équivalence
Représentant
[1, 95]
33
entrées invalides
<1
-12
entrées invalides
> 95
401
entrées valides
Ex. fonction qui attend une réponse oui/non :
Validité des entrées
Représentant
entrées valides
{oui}
“oui”
entrées valides
{non}
“non”
autre (ni oui ni non)
“casimir”
entrées invalides
23
Test fonctionnel :
●
●
Découpage en classes
–
déduit de la spécification (→ travail d'interprétation)
–
en fonction d'un degré de finesse donné
Quantité de classes
–
compromis précision / coût / temps d'exécution
●
●
précision, bon degré de couverture, bonnes informations
pour les développeurs (debug)
coût (définition, réalisation, passage, dépouillement)
24
Test fonctionnel :
Analyse aux bornes (1)
L'expérience prouve que
☛ Les erreurs se situent très souvent à frontières
de comportements différents
Par ex. :
●
indice de tableau tout juste trop grand ou trop petit
●
boucles avec une itération en trop ou en moins
●
comparaisons stricte au lieu de avec égalité, ou l'inverse
●
etc.
25
Test fonctionnel :
●
Sensibilité à la frontières de comportements
→ analyse précise aux bornes des classes
●
Plusieurs représentants par classe d'équivalence
une valeur « médiane » ordinaire
+ une ou plusieurs valeurs aux bornes
Aussi appelé « test aux limites »
26
Test fonctionnel :
Ex. fonction qui attend un numéro de département
(de métropole) entre 1 et 95 :
Validité
entrées valides
Classes d'équiv. Représentants +large couverture
[1, 95]
1, 48, 95
1, 2, 48, 94, 95
entrées invalides
<1
-12 ,0
-12, -1, 0
entrées invalides
> 95
96, 401
96, 97, 401
Ex. fonction qui attend une réponse oui/non :
Validité
Représentants
entrées valides
{oui}
“oui”
entrées valides
{non}
“non”
autre (ni oui ni non)
“ouii”, “mon”, “oui ”, “casimir”
entrées invalides
27
Test fonctionnel :
Combinaison de valeurs d'entrée
●
●
Combinaison des classes d'équivalences
–
combinatoire exponentielle
–
précis mais coûteux et long (parfois trop)
Exemple
–
–
hypothèses pour une fonction f(x,y,z) :
●
2 classes d'équivalence pour chacun des x, y et z
●
représentants respectifs : x1,x2, y1,y2, z1,z2
combinaisons de cas à tester : (23 = 8)
●
(x1,y1,z1), (x1,y1,z2), (x1,y2,z1), (x1,y2,z2),
(x2,y1,z1), (x2,y1,z2), (x2,y2,z1), (x2,y2,z2)
28
Test fonctionnel :
Combinaisons de valeurs d'entrée
●
Exploiter ce que doit faire la fonction
–
●
regrouper les combinaisons indépendantes
Ex. si f(x,y,z) = (g(x,y),h(y,z))
–
pour g(x,y) : (x1,y1), (x1,y2), (x2,y1), (x2,y2)
–
pour h(y,z) : (y1,z1), (y1,z2), (y2,z1), (y2,z2)
–
pour f(x,y,z) : (x1,y1,z1), (x1,y2,z1), (x2,y1,z2), (x2,y2,z2)
→ 4 combinaisons au lieu de 8
29
Test fonctionnel :
●
Ex. conjonction : « si (x > 0 et y > 0 et z > 0) »
–
2 classes d'équivalence pour x, y, z : ]-∞,0] , ]0,+∞[
–
représentants aux limites (variables entières) : 0, 1
–
nombre de combinaisons = 23 = 8
●
●
(0,0,0), (0,0,1), (0,1,0), (0,1,1), (1,0,0), (1,0,1), (1,1,0), (1,1,1)
Test aux limites sur l'expression « U et V et W » ?
→ examiner les différents cas de triplets de booléens
30
31
Treillis des triplets de booléens
(vrai, vrai, vrai)
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
(faux, faux, faux)
Treillis des triplets de booléens et
conjonction
(vrai, vrai, vrai)
U et V et W = vrai
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
(faux, faux, faux)
U et V et W = faux
32
Treillis des triplets de booléens,
conjonction et valeurs aux limites
(vrai, vrai, vrai)
U et V et W = vrai
valeurs limites
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
(faux, faux, faux)
U et V et W = faux
33
Test fonctionnel :
●
●
Ex. conjonction : « si (x > 0 et y > 0 et z > 0) »
–
classes pour x, y, z : ]-∞,0] , ]0,+∞[
–
représentants aux limites : 0, 1 (soit 23 combinaisons)
Test aux limites sur la condition C = U et V et W
–
valeurs limites tq C = vrai
●
–
valeurs limites tq C = faux
●
–
(vrai, vrai, vrai)
(faux, vrai, vrai), (vrai, faux, vrai), (vrai, vrai, faux)
au final : 4 combinaisons pour (x,y,z) au lieu de 8
●
(1,1,1), (0,1,1), (1,0,1), (1,1,0)
34
Test fonctionnel :
●
Ex. disjonction : « si (x > 0 ou y > 0 ou z > 0) »
–
2 classes d'équivalence pour x, y, z : ]-∞,0] , ]0,+∞[
–
représentants aux limites (variables entières) : 0, 1
–
nombre de combinaisons = 23 = 8
●
●
35
(0,0,0), (0,0,1), (0,1,0), (0,1,1), (1,0,0), (1,0,1), (1,1,0), (1,1,1)
Test aux limites sur l'expression « U ou V ou W » ?
→ examiner les différents cas de triplets de booléens
36
Treillis des triplets de booléens
(vrai, vrai, vrai)
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
(faux, faux, faux)
disjonction
(vrai, vrai, vrai)
U ou V ou W = vrai
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
(faux, faux, faux)
U ou V ou W = faux
37
disjonction et valeurs au limites
(vrai, vrai, vrai)
U ou V ou W = vrai
(faux, vrai, vrai)
(vrai, faux, vrai)
(vrai, vrai, faux)
(faux, faux, vrai)
(faux, vrai, faux)
(vrai, faux, faux)
valeurs limites
(faux, faux, faux)
U ou V ou W = faux
38
Test fonctionnel :
●
●
Ex. disjonction : « si (x > 0 ou y > 0 ou z > 0) »
–
classes pour x, y, z : ]-∞,0] , ]0,+∞[
–
représentants aux limites : 0, 1 (soit 23 combinaisons)
Test aux limites sur la condition C = U ou V ou W
–
valeurs limites tq C = vrai
●
–
valeurs limites tq C = faux
●
–
(vrai, faux, faux), (faux, vrai, faux), (faux, faux, vrai)
(faux, faux, faux)
au final : 4 combinaisons pour (x,y,z) au lieu de 8
●
(1,0,0), (0,1,0), (0,0,1), (0,0,0)
39
40
Test boîte blanche
●
exploite le code
→ nécessite le source
+ graphe de flot de contrôle, graphe de flot de données, ...
–
●
tests de portions de code (bloc, branche, etc.)
éventuellement, marquage des portions de code
–
testées
–
effectivement parcourues
→ taux de couverture
Test fonctionnel :
Analyse de chemins
●
●
Basé sur le chemin d'exécution
–
boîte noire : d'après l'algorithme de la spécification
–
boîte blanche : d'après le graphe de flot de contrôle
Couverture
–
des branches (ou des instructions)
–
de séquences de branches
–
des chemins
–
...
41
42
Couverture des branches
[branch coverage ou decision coverage]
vrai
C1
faux
X1
●
Toute branche est exécutée
au moins une fois
Y1
●
vrai
C2
X2
faux
Y2
Ex. valeurs tq (C1,C2) =
–
ou
T1=(vrai, vrai), T2=(faux, faux)
–
T1=(vrai, faux), T2=(faux, vrai)
→ 2 groupes de tests au choix
Z
43
Couverture des instructions
[instruction coverage]
●
vrai
C1
faux
●
X1
Y1
Toute instruction est
exécutée au moins une fois
Idem couverture de branche
–
vrai
C2
X2
faux
●
Y2
–
ou
–
Z
parcourir tous les noeuds
~ parcourir tous les arcs
T1=(vrai, vrai), T2=(faux, faux)
T1=(vrai, faux), T2=(faux, vrai)
→ 2 groupes de tests au choix
44
Couverture des chemins (1)
[path coverage]
●
vrai
C1
faux
X1
Y1
vrai
C2
X2
–
faux
Y2
Z
●
Toute chemin est exécuté
au moins une fois
T1=(vrai, vrai), T2=(vrai, faux),
T3=(faux,vrai), T4=(faux, faux)
→ 1 seul groupe de tests
(comportant 4 cas de tests)
45
Couverture des chemins (2)
[path coverage]
●
vrai
X
→ chemins les plus représentatifs
→ limiter le nombre de boucles
Y
●
faux
C
vrai
Z
Couverture des chemins
impossible : nb chemins infini
Ex. (limite = 1) : valeurs tq
–
T1 : Citération1 = vrai
T2 : Citération1 = faux, Citération2 = vrai
→ 2 cas de tests
(pour la couverture de branches, 1 test suffit : T2)
46
Analyse de chemins
Et aussi :
–
couverture des i-chemins
●
–
couverture des branches essentielles
●
–
réunion de chemins ne différant que par le nb d'itérations
boundary interior path testing
●
–
inutile d'ajouter des tests pour les passages obligés
structured path testing
●
–
portions linéaires de code suivies d'un saut
...
pour les chemins ayant au moins une itération : exécuter au
moins une fois les chemins différents pour une 1ère itération
Analyse de flot de données (1)
●
●
Toute variable a des
–
points de définition, c.-à-d. affectations (x = 0;)
–
points d'utilisation dans des conditions logiques (x > 0)
–
points d'utilisation dans des instructions de calcul (x+3)
Couverture
–
de toutes les définitions
–
de toutes les utilisations dans des conditions logiques
–
de toutes les utilisations dans des calculs
–
définitions exécutées au moins une fois pour toutes les
utilisations qu'elle atteint, ...
47
48
Analyse de flot de données (2)
Ex. définitions exécutées au moins une fois pour
toutes les utilisations qu'elle atteint → 4 cas
if (cond1)
x = exp1;
else
x = exp2;
if (cond2)
y = ... x ...;
else
y = ... x ...;
// définition 1 de x
// définition 2 de x
// utilisation 1 de x
// utilisation 2 de x
49
Test intrusif
●
Instrumentation du code
–
identification des branches effectivement parcourues
(pour le test boîte blanche)
–
interrogation possible, en cours de test (c.-à-d.
d'exécution), de la valeur de certaines variables
→ fourniture de résultats de calcul intermédiaires
●
En général, pas le code final
–
#ifdef, ...
–
mais risque de différences de comportement
50
Auto-test (1)
●
Assertion
–
●
vérification dynamique d'un invariant (propriété qui
doit toujours être vraie en un point d'exécution)
Ex. (dans une implémentation de String) :
assert(len >= 1);
lastChar = chars[len-1];
→ si len n'est pas plus grand que 1 au moment de
l'exécution, une erreur se produit
51
Auto-test (2)
●
Suppression des assert dans le produit final
–
●
Certains langages disposent d'assertions
–
●
sinon ralentit l'exécution
Eiffel, Java (v1.5) → flag du compilateur
Sinon, implémentable avec des macros
#ifdef DEBUG
#define assert(cond) { if (!cond) error(); }
#else
#define assert(cond) /* assert ignoré */
#endif
52
Questions
Mais
–
qui teste les tests ?
–
qui teste les tests de tests ?
–
...
–
et qui débogue les test ?
53
Oracle de test
●
Prédire les valeurs de sorties correctes (attendues)
–
●
diagnostiquer la réussite ou l'échec
Implémentation
–
cas simples : valeurs codées en dur
–
cas complexes : valeurs calculées par simulateur/proto
●
maintenance plus facile en cas d'évolution de la spécification
☛ Ne pas tester les tests avec l'implémentation
–
vote à la majorité de 3 :
●
valeur simple, valeur simulée, valeur produite par le programme
54
À retenir
●
Test = processus « destructif »
–
●
pas d'erreur trouvée (chez un autre) = échec
Notion de plan de test
–
poser le problème du compromis couverture/effort
●
Tests boîte noire / boîte blanche (code visible)
●
Tests fonctionnels :
●
–
partition des entrées, test aux limites, combinatoire
–
couverture des branches et chemins
Instrumentation, auto-test (assertion) et oracle

transp. - Imagine

Transcription

Documents pareils

Soirée Comm Animale

Définition des Besoins

Monsieur Claude RENAUD

Antoine Chance « Fou » Lana Del Rey « Ultraviolence » Sia « 1000

CONCERT : RENAUD - le 2 décembre 2016

Annuaire entreprise Elsa Renaud

Institut Supérieur Aquitain du Bâtiment et des Travaux Publics

toupie-tenonneuse sicm-chambon

degauchisseuse raboteuse lurem 510