Test du logiciel, cours 3 Tests fonctionnels Tests

Test du logiciel, cours 3
Tests fonctionnels
Critère d’arrêt
Plan
qualitatives
Couvertures de tests fonctionnels :
– Les tests fonctionnels
.
On ne peut connaı̂tre a priori le nombre de tests nécessaires
– Les phases de tests
Se baser sur le seul élément dont on est sûr : la spécification.
DESS DLS 2002-2003 — Test du logiciel
1/33
DESS DLS 2002-2003 — Test du logiciel
Tests fonctionnels
3/33
Rappel : spécification du logiciel
Une spécification doit décrire au minimum :
– les fonctions à réaliser par le logiciel,
Aussi appelé tests boite noire
– les interfaces de ce logiciel
– les contraintes fixées au développeur.
Son but
– Vérifier le comportement d’un logiciel / spécification (fonctions non conformes ou manquantes,
erreurs d’initialisation ou de terminaison du logiciel)
– Vérifier le respect des contraintes (performances, espace m émoire, etc.) et des facteurs qualité
associés au logiciel (portabilité, maintenabilité, etc.)
Exemples de contraintes :
– performances temporelles
– performances spatiales
– contraintes matérielles
– critères de sécurité
– portabilité
DESS DLS 2002-2003 — Test du logiciel
2/33
DESS DLS 2002-2003 — Test du logiciel
4/33
Le test fonctionnel : que teste-t-on et comment le teste-t-on ?
Tests nominaux, tests aux limites
– Tests nominaux : vérifier la conformité par rapport à la spécification pour un comportement
– Que teste-t-on ? : couvertures des tests
– Comment le teste-t-on ? : analyse partitionnelle pour le test des fonctions de la sp écification
DESS DLS 2002-2003 — Test du logiciel
5/33
normal du logiciel
– Tests aux limites : vérifier le comportement aux limites fonctionnelles du logiciel
DESS DLS 2002-2003 — Test du logiciel
Que teste-t-on ? : couvertures des tests fonctionnels
7/33
Tests de robustesse
Quatre grandes catégories
Tous les tests permettant de valider la robustesse du logiciel vis- à-vis de son environnement.
– Tests nominaux
test des fonctions du logiciel
Par exemple
– Tests aux limites fonctionnels
– les tests hors limites fonctionnelles
– Tests de robustesse
– les tests en charge
autres facteurs qualité et contraintes
– les pannes des équipements externes
facteurs qualité de robustesse
– Tests de conformité
DESS DLS 2002-2003 — Test du logiciel
6/33
DESS DLS 2002-2003 — Test du logiciel
8/33
Tests de conformité
Analyse partitionnelle : la recette
Pour chaque fonction de la spécification à :
Vérifier les contraintes associées au logiciel
– déterminer les entrées de la fonction ainsi que leur domaine
– à partir de la partie contrôle de la spécification, découper le domaine des entrées en classes
d’équivalence
Par exemple
– pour chaque classe d’équivalence :
– les tests de performance
– les tests d’intrusion
– sélectionner un élément dans la classe
– les tests d’ergonomie (Interface Homme-Machine)
– à partir de la partie commande de la spécification, déterminer la valeur des sorties pour
l’élément sélectionné.
– les tests de portabilité (matériel, OS), d’interchangeabilité
DESS DLS 2002-2003 — Test du logiciel
9/33
DESS DLS 2002-2003 — Test du logiciel
11/33
Valeurs de sortie ou à défaut propriétés de ces valeurs
Comment teste-t-on ? : l’analyse partitionnelle, une solution pour les jeux d’entr ées
Première idée : force brutale (effectuer le produit cartésien des domaines des entrées du
programme)
Défaut : nombre de tests à réaliser astronomique (exemple : addition de 2 entiers de 32 bits
jeux de tests)
On se contenterait de valider chacun des comportements du logiciel pour une valeur particuli ère
Problème de l’oracle
représentative.
– algorithme trop complexe (régulation en automatisme)
– toutes les entrées nécessaires au calcul de la sortie ne sont pas accessibles au testeur
Seconde idée : partitionner ce produit cartésien en classes d’équivalence des entrées (ensemble
(positionnées par le développeur, horloge système, etc).
des entrées aboutissant au même comportement fonctionnel)
Sur notre exemple : 2 tests (1 sans débordement, 1 avec débordement)
Méthode couramment utilisée pour écrire les jeux de tests fonctionnels, appelée : analyse
partitionnelle.
DESS DLS 2002-2003 — Test du logiciel
10/33
DESS DLS 2002-2003 — Test du logiciel
12/33
Classes d’équivalence
Soit
Détermination des classes d’équivalence
un domaine.
Les ensembles
forment une partition de classes d’équivalence sur
Langage formalisé
Détermination des chemins de la spécification
Automate, Réseau de Petri,
Parcours de l’automate,
si :
Règle 1 (recouvrement)
Parcours de la matrice
Langage naturel
Remodélisation de la spécification en langage
Matrice causes/effets
DESS DLS 2002-2003 — Test du logiciel
Règle 2 (exclusion mutuelle)
13/33
Exemple
formalisé ou automate
DESS DLS 2002-2003 — Test du logiciel
15/33
Détermination des classes d’équivalence sur une spécification trop informelle
Dans ce cas, la spécification n’est pas testable en l’état. Il faut donc soit la refuser, soit :
Programme calculant :
– réaliser un modèle de cette spécification dans le formalisme le mieux adapté
sur les entiers
– faire valider ce modèle par l’équipe de développement et le client (est-ce bien cela que vous
3 classes d’équivalence :
vouliez construire ?)
– déterminer les classes d’équivalence sur le modèle.
Ce processus de remodélisation permet très souvent de trouver des anomalies dès la
spécification :
Sur les 3 classes d’équivalence, une seule est valide.
– incohérence entre différentes parties de la spécification
– incomplétude des cas traités
DESS DLS 2002-2003 — Test du logiciel
14/33
DESS DLS 2002-2003 — Test du logiciel
16/33
Choix
intelligent
Tests nominaux
des valeurs dans les classes d’équivalence
Classes d’équivalence pour toutes les entrées
E1
intelligente
Sélection d’une valeur
dans la classe d’équivalence
Varier les valeurs à l’intérieur d’un même intervalle.
DESS DLS 2002-2003 — Test du logiciel
17/33
Exemple de classes d’équivalence
E2
[Min Int,-1]
-734
[Min Int,-1]
-525
[Min Int,-1]
-7445
[0, Max Int]
3765
[0, Max Int]
7643
[Min Int,-1]
-765
[0, Max Int]
9864
[0, Max Int]
3783
DESS DLS 2002-2003 — Test du logiciel
19/33
Tests aux et hors limites fonctionnelles
Fonction : Produit_valeurs_absolues
Entrées : E1, E2
Sorties : S
Traitement :
– Tests aux limites fonctionnelles : sélection de valeurs aux bornes de chaque classe
Cette fonction calcule la valeur absolue du produit des entrées E1 et E2.
d’équivalence fonctionnelles
– Tests hors limites fonctionnelles : sélection de valeurs hors bornes de chaque classe
Classes d’équivalence pour chaque entrée
d’équivalence fonctionnelles
E1
E2
[Min Int,-1]
[Min Int,-1]
[0, Max Int]
[0, Max Int]
DESS DLS 2002-2003 — Test du logiciel
18/33
DESS DLS 2002-2003 — Test du logiciel
20/33
Tests aux et hors limites fonctionnelles pour l’exemple pr écédent
Si les entrées E1 et E2 ont un domaine fonctionnel de : [-100,
Tests aux limites fonctionnelles
E1
Tests en charge
100]
Tests hors limites fonctionnelles
E2
E1
Vérifier le comportement du logiciel en cas de stress du logiciel tel que :
E2
– avalanche d’alarmes
-57
[-100,-1]
-234
[-100,-1]
-42
[-100,-1]
-1
[0, +100]
64
[0, +100]
174
[0, +100]
39
[0, +100]
0
[-100,-1]
-5
[-100,-1]
-84
[Min Int, -1]
-115
[0, +100]
100
[0, +100]
98
[0, +100]
48
[0, +100]
120
[-100,-1]
-59
[-100,-1]
-1
[0, +100]
48
[-100,-1]
-100
[-100,-1]
-63
[0, +100]
0
[0, +100]
75
[0, +100]
100
DESS DLS 2002-2003 — Test du logiciel
– saturation des réseaux
– saturation des requêtes
–
[-100,-1]
-100
[-100,-1]
Exemple : la saturation de Yahoo fin 1999.
21/33
DESS DLS 2002-2003 — Test du logiciel
Tests de robustesse
23/33
Tests de pannes des équipements externes
Simuler des pannes sur les équipements en interface avec le logiciel afin de vérifier son
Vérifier le comportement du logiciel face à des événements non spécifiés ou dans des situations
comportement.
dégradées.
Par exemple :
– Tests en charge
– arrêt inopiné de l’équipement
– Tests des pannes des équipements externes
– débranchement brutal de l’équipement
– etc.
– changement brusque de valeurs
22/33
DESS DLS 2002-2003 — Test du logiciel
–
DESS DLS 2002-2003 — Test du logiciel
24/33
Tests de pannes des équipements externes, connaissances requises
Conclusion pour les tests fonctionnels
Ces tests nécessitent une bonne connaissance du hardware afin de spécifier les bons modes de
défaillance des équipements.
Ce ne sont que des exemples pour le test de robustesse et le tests de pannes des équipements
Par exemple, connaı̂tre les cas de défaillance d’un interrupteur :
externes, cela dépend énormément du métier pour lequel le logiciel est développé.
– collage à 1 ou à 0
– bagottements intempestifs
– parasitage à différentes fréquences.
DESS DLS 2002-2003 — Test du logiciel
25/33
DESS DLS 2002-2003 — Test du logiciel
Tests des interfaces
27/33
Les phases de tests
DÉVELOPPEMENT
TEST
Plan de Tests
de Validation
Spécification
du logiciel
Rapport de Tests
de Validation
Tests de validation
Rapport de Tests
d’Intégration
Le but des tests des interfaces est double :
Conception
du logiciel
– vérifier les interfaces logicielles entre les composants un sous-syst ème logiciel
Plan de Tests
d’Intégration
Tests d’intégration
– vérifier les interfaces physiques entre le logiciel et la machine cible (carte sur laquelle tourne le
logiciel)
Conception
détaillée
Rapport de Tests
Unitaires
Plan de Tests
Unitaires
Tests Unitaires
Codage
DESS DLS 2002-2003 — Test du logiciel
26/33
DESS DLS 2002-2003 — Test du logiciel
28/33
Durant les phases de descente du cycle
Les Tests Unitaires (TU)
Durant les phases de descente du cycle, le testeur élabore les Plans de Tests du Logiciel et
Validation de chaque composant logiciel pris unitairement par rapport à sa spécification détaillée.
fabrique les bancs de tests.
Quand
Les plans de tests décrivent essentiellement :
Dès qu’une pièce de code a été codée et compilée correctement
– la stratégie de tests mise en place
– les moyens mis en oeuvre (matériel, logiciel et humain)
Types de tests
– l’ensemble des fiches de tests.
DESS DLS 2002-2003 — Test du logiciel
Les tests structurels
29/33
Durant les phases de remontée du cycle
DESS DLS 2002-2003 — Test du logiciel
31/33
Les Tests d’Intégration (TI)
Validation des sous-systèmes logiciels entre eux
Durant les phases de remontée du cycle, le testeur exécute les fiches de tests décrites dans les
Tests d’Intégration Logiciel/Logiciel (interface entre composants logiciels)
Tests d’Intégration Logiciel/Matériel (interface entre le logiciel et le matériel)
plans et produit les rapport de tests associés. Ces rapports contiennent essentiellement :
Quand
– la synthèse des résultats de tests
Dès qu’un sous-système fonctionnel (module, objet) est entièrement testé unitairement
– les résultats de tests détaillés
– la trace d’exécution des tests.
Types de tests
Tests des interfaces
DESS DLS 2002-2003 — Test du logiciel
30/33
DESS DLS 2002-2003 — Test du logiciel
32/33
Les Tests de Validation (TV)
Vérifier la conformité du logiciel aux Spécifications du logiciel
Quand
Dès que l’ensemble des sous-systèmes fonctionnels ont été testé et intégré
Types de tests
Tests fonctionnels
Tests de robustesse
DESS DLS 2002-2003 — Test du logiciel
33/33