Test du logiciel, cours 3 Tests fonctionnels Tests
Transcription
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