La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Tests Mustapha EL FEDDI

Présentations similaires


Présentation au sujet: "Tests Mustapha EL FEDDI"— Transcription de la présentation:

1 Tests Mustapha EL FEDDI

2 Terminologie Une faute est la cause dune erreur Une erreur (IEEE 729) est Un écart entre une valeur ou condition calculée, observée ou mesurée et la valeur ou condition qui est vraie, spécifiée ou théoriquement correcte. Défaut, anomalie (fault, bug) (IEEE 729) est la manifestation d'une erreur dans un logiciel Un défaut peut causer une panne. Panne (failure) (IEEE 729) est la fin de la capacité d'un système ou d'un de ses composants d'effectuer la fonction requise, ou de l'effectuer à l'intérieur de limites spécifiées. FauteErreur Panne Défaut

3 Terminologie SPECIFICATION (ISO 8402) Document qui prescrit les exigences auxquelles le produit ou le service doit se conformer. SATISFACTION Un programme satisfait sa spécification lorsquil est en tout point conforme aux exigences de celle-ci. VALIDATION ou VERIFICATION (ISO ) Processus d'évaluation du logiciel pour s'assurer quil satisfait aux exigences spécifiées. La validation ou vérification d'un produit cherche à s'assurer qu'on a construit le bon produit (dun point de vue externe ou interne). Le test est un cas particulier de vérification.

4 Test: définition Norme IEEE 729: Le test est un processus manuel ou automatique, qui vise à établir quun système vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification.

5 Objectifs Le test vise à mettre en évidence les erreurs dun logiciel Le test na pas pour objectif de diagnostiquer la cause des erreurs Le test na pas pour objectif de corriger les fautes Le test na pas pour objectif de prouver la correction dun programme

6 Qualité du test Lefficacité du test (son aptitude à détecter des erreurs) doit être conforme à certains critères de qualité. Le niveau de qualité requis dépend du contexte dutilisation du logiciel: plus le contexte est critique, plus leffort de tests doit être important. La programmation dun logiciel aérospatial requiert des exigences de qualité supérieures à la programmation dun éditeur de dessins techniques QUALITE (QUALITY), ISO 8402: Ensemble des propriétés et caractéristiques d'un produit ou service qui lui confèrent l'aptitude à satisfaire des besoins exprimés ou implicites.

7 Coûts du test Pour un logiciel critique, le coût du test peut représenter plus de 40% du coût du développement. Conception 40% Codage 20% Tests 40%

8 Tests et Cycle de vie Spécifications Analyse Conception Implémentation Tests de réception (Recette) Testsdintégration Tests unitaires Tests de non régression

9 Phases de test TEST UNITAIRE (UNIT TEST OR MODULE TEST): Test d'un programme ou d'un module isolé dans le but de s'assurer quil ne comporte pas d'erreur d'analyse ou de programmation. TEST DINTEGRATION (INTEGRATION TEST), IEEE 729: Une progression ordonnée de tests dans laquelle des éléments logiciels et matériels sont assemblés et testés jusqu'à ce que lensemble du système soit testé. TEST DE RECEPTION (ACCEPTANCE TEST), ISO/IEC : Test, généralement effectué par l'acquéreur dans ses locaux après installation d'un système ou d'une unité fonctionnelle, avec la participation du fournisseur, pour vérifier que les dispositions contractuelles sont bien respectées. TEST DE REGRESSION (REGRESSION TEST): A la suite de la modification d'un logiciel (ou d'un de ses constituants), un test de régression a pour but de montrer que les autres parties du logiciel n'ont pas été affectées par cette modification.

10 Types de test Tests de boîte noire Le test porte sur le fonctionnement externe du système. La façon dont le système réalise les traitements n'entre pas dans le champ du test. Tests de boîte blanche Le test vérifie les détails d'implémentation, c'est à dire le comportement interne du logiciel.. Tests de conformité Le test vérifie la conformité du logiciel par rapport à ses spécifications et sa conception. Tests de non conformité Le test vérifie que les "cas non prévus" ne perturbent pas le fonctionnement du sytème. Tests beta Réalisés par des développeurs ou des utilisateurs sélectionnés, ils vérifient que le logiciel se comporte pour l'utilisateur final comme prévu par le cahier des charges. Tests alpha Le logiciel n'est pas encore entièrement fonctionnel, les testeurs alpha vérifient la pré- version. Tests unitaires Chaque module du logiciel est testé séparément, par rapport à ses spécifications, aux erreurs de logique.

11 Types de test (suite) Tests d'intégration Les modules validés par les test unitaires sont rassemblés. Le test d'intégration vérifie que l'intégration des modules n'a pas altéré leur comportement. Tests fonctionnels L'ensemble des fonctionnalités prévues est testé : fiabilité, performance, sécurité, affichages,etc Tests d'intégration système L'application doit fonctionner dans son environnement de production, avec les autres applications présentes sur la plateforme et avec le système d'exploitation. Tests de recette Les utilisateurs finaux vérifient sur site que le système répond de manière parfaitement correcte. Tests de non régression Après chaque modification, correction ou adaptation du logiciel, il faut vérifier que le comportement des fonctionnalités n'a pas été perturbé, même lorsqu'elle ne sont pas concernées directement par la modification.

12 Méthodes de tests statiques Les méthodes de tests statiques consistent en lanalyse textuelle du code du logiciel afin dy détecter des erreurs, sans exécution du programme Revue de code Analyse des types Analyse du domaine de variation des variables Analyse du graphe de contrôle …

13 Méthodes de tests statiques: Exemple: Revue du code ou INSPECTION (REVIEW OR INSPECTION), IEEE 729: Examen détaillé dune spécification, dune conception ou dune implémentation par une personne ou un groupe de personnes, afin de déceler des fautes, des violations de normes de développement ou d'autres problèmes.

14 Méthodes de tests statiques Avantages: Méthodes efficaces et peu coûteuses. 60 à 95% des erreurs sont détectées lors de contrôles statiques Les méthodes de tests statiques sont nécessaires. Inconvénients: Méthodes ne permettant pas de valider le comportement dun programme au cours de son exécution. Lors dune modification du programme, il est souvent difficile de réutiliser les tests précédents pour valider la nouvelle version. Les méthodes de tests statiques ne sont pas suffisantes.

15 Méthodes de tests dynamiques Les méthodes de tests dynamiques consistent en lexécution du programme à valider à laide dun jeu de tests. Elles visent à détecter des erreurs en confrontant les résultats obtenus par lexécution du programme à ceux attendus par la spécification de lapplication.

16 Méthodes de tests dynamiques Est-ce que P satisfait SP ? P satisfait, ou non, SP ! Sélection du jeu de tests T Exécution de P à laide de T Analyse des résultats Correction Processus de test

17 Méthodes de tests dynamiques Pour expliquer le mécanisme des méthodes de tests dynamiques, il faut encore répondre aux questions: Comment choisir le jeu de tests? Comment décider du succès ou de léchec dun jeu de tests? A partir de quel moment peut-on estimer que le programme na plus besoin dêtre testé?

18 Méthodes de tests dynamiques Il existe plusieurs méthodes de test: Aléatoires Structurelles (boîte blanche) Fonctionnelles (boîte noire) Statistiques

19 Méthodes aléatoires Le jeu de tests est sélectionné au hasard sur le domaine des entrées du programme. Le domaine des entrées du programme est déterminé à laide de linterface de la spécification ou de linterface du programme. Inconvénient Inconvénient: Ces méthodes ne garantissent pas une bonne couverture de lensemble des entrées du programme. En particulier, elles peuvent ne pas prendre en compte certains cas limites ou exceptionnels. Ces méthodes ont donc une efficacité très variable.

20 Méthodes structurelles (Boîte Blanche) Le critère de sélection du jeu de tests repose sur le code du programme. Le jeu de tests est choisi de manière à remplir certaines exigences: Couverture de toutes les instructions. Couverture de tous les chemins exécutables. Couverture de toutes les conditions. Afin daugmenter la qualité dun test de couverture, on peut sélectionner plusieurs tests par sous-domaine à laide dune loi de distribution On parle alors de méthode statistique structurelle.

21 Méthodes structurelles (Boîte Blanche) Méthodes structurelles – Limitations La sélection dun jeu de tests de taille raisonnable couvrant tous les chemins exécutables nest pas toujours possible lors de la présence de boucles (il faut limiter le nombre de passages dans ces boucles) Ces méthodes ne permettent pas de détecter des oublis par rapport à la spécification de lapplication, cette dernière nintervenant pas dans le processus de sélection des jeux de tests Lors dune modification du programme, il est souvent difficile de réutiliser les tests précédents pour valider la nouvelle version.

22 Méthodes fonctionnelles (Boîte Noire) La méthode de tests fonctionnelle vise à valider les fonctionnalités dun programme. Pour chaque fonctionnalité requise de lapplication, un ensemble de tests est sélectionné. Les jeux de tests sont dérivés de la spécification du programme Une spécification décrit complètement les comportements dun système. Elle peut être: Informelle (ex: spécification en langage naturel). Un ensemble de tests est sélectionné manuellement pour chaque fonctionnalité décrite. Formelle (ex: spécification algébrique). Une sélection automatique du jeu de tests est envisageable. Semi-formelle (ex: méthode de modélisation du type Fusion/UML). La sélection du jeu de tests est guidée par la modélisation.

23 Méthodes statistiques Le jeu de tests est sélectionné à laide dune loi de distribution sur le domaine des entrées du programme (déterminé à partir de la spécification) Avantage: Ces méthodes donnent des résultats satisfaisants. Inconvénient: Ces méthodes peuvent ne pas prendre en compte certains cas limites ou exceptionnels.

24 Méthodes expérimentales Le jeu de tests est sélectionné sur la base de lexpérience. Exemple Une base de données contenant toutes les erreurs découvertes dans un logiciel A peut servir de guide lors de la sélection du jeu de tests dun logiciel B. Cest la stratégie de tests la plus couramment utilisée dans lindustrie Avantage: Cette stratégie de tests donne des résultats satisfaisants Inconvénient: Cette stratégie de tests ne garantit pas une bonne couverture de lensemble des entrées du programme.

25 Échec ou succès du test Une fois un jeu de tests sélectionné, il est utilisé lors de lexécution du programme à valider. Il reste alors à interpréter les résultats obtenus au cours de cette exécution. Cest alors quon décide du succès ou de léchec du jeu de tests: Succès dun jeu de tests (jeu de tests positif): chaque test du jeu est positif. Échec dun jeu de tests (jeu de tests négatif): au moins un test du jeu est négatif

26 Fin des tests Un programme na plus besoin dêtre testé, lorsque lefficacité du jeu de tests sélectionné est conforme à certains critères de qualité, et lorsque ce jeu de tests est positif

27 Conclusion Le test vise à mettre en évidence les erreurs dun logiciel Le test na pas pour objectif de diagnostiquer la cause des erreurs, de corriger les fautes, ou de prouver la correction dun programme Pour un logiciel critique, le coût du test peut représenter plus de 40% du coût du développement La mise au point dune méthode optimale de vérification de programmes, passe par une combinaison judicieuse de lutilisation de différentes méthodes de tests statiques et dynamiques


Télécharger ppt "Tests Mustapha EL FEDDI"

Présentations similaires


Annonces Google