slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Test de logiciel PowerPoint Presentation
Download Presentation
Test de logiciel

Loading in 2 Seconds...

play fullscreen
1 / 36

Test de logiciel - PowerPoint PPT Presentation


  • 318 Views
  • Uploaded on

Test de logiciel. GLG101. AP.TELLE & S.MILOVANOVIC MAI 2007. Le test en génénal : Plan. . Terminologie liée au test. . Objectifs du test. . Le test dans le cycle de vie du logiciel. . Qualité du test. . Coût du test. . Classifications des méthodes de tests. .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Test de logiciel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Test de logiciel GLG101 AP.TELLE & S.MILOVANOVIC MAI 2007

    2. Le test en génénal : Plan  Terminologie liée au test  Objectifs du test  Le test dans le cycle de vie du logiciel  Qualité du test  Coût du test  Classifications des méthodes de tests  Conclusion

    3. Faute :  La cause d’une erreur.  ERREUR, IEEE 729: 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.  IEEE 729: Défaut, anomalie (fault, bug), La manifestation d'une erreur dans un logiciel. Un défaut peut causer une panne.  Panne (failure) , IEEE 729: 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. Faute Erreur Défaut Panne

    4. Faute (suite)

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

    6. Objectifs du test  Définition (norme IEEE 729): Le test est un processus manuel ou automatique, qui vise à établir qu’un 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  Le test vise à mettre en évidence les erreurs d’un logiciel.  Le test n’a pas pour objectif dediagnostiquer la cause des erreurs.  Le test n’a pas pour objectif decorriger les fautes.  Le test n’a pas pour objectif deprouver la correction d’un programme.

    7. Qualité du test L’efficacité 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 d’utilisation du logiciel: plus le contexte est critique, plus l’effort de tests doit être important. La programmation d’un logiciel aérospatial requiert des exigences de qualité supérieures à la programmation d’un éditeur de dessins techniques. QUALITE, 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.

    8. Coût du test : un coût important

    9. Classifications des méthodes de tests  Classification selon les phases du cycle de vie  Les méthodes de tests statiques  Les méthodes de tests dynamiques

    10. Classifications selon les phases du cycle de vie Niveau d’abstraction

    11. Classification selon les phases du cycle de vie (suite) TEST UNITAIRE : Test d'un programme ou d'un module isolé dans le but de s'assurer qu’il ne comporte pas d'erreur d'analyse ou de programmation. TEST D’INTEGRATION, IEEE 729: Une progression ordonnée de tests dans laquelle des éléments logiciels et matériels sont assemblés ex testés jusqu'à ce que l’ensemble du système soit testé. TEST DE RECEPTION, ISO/IEC 2382-20: 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 : 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.

    12. Méthodes de tests statiques Les méthodes de test statiques consistent en l’analyse textuelle du code du logiciel afin d’y détecter des erreurs, sans exécution du programme.

    13. Méthodes de tests statiques (suite) Analyse du graphe de contrôle - Exemple Le graphe de contrôle est généralement dérivé de l’organigramme du programme. Procedure Signe(a:INOUT int; s:OUT string)IS Begin s := "nul"; IF (a>0) THEN s := "positif"; a := a+1; END IF; IF (a<0) THEN s := "negatif"; a := a-1; END IF; END Signe;

    14. Méthodes de tests statiques (suite) Organigramme: Graphe de contrôle: A s := “nul” A Y a > 0 B C c s := “positif” N a := a + 1 D d Y F a < 0 E s := negatif F N IN F a := a - 1 Analyser le graphe de contrôle du programme peut révéler des erreurs (exemples: sauts anormaux, code inutilisé...).

    15. Méthodes de tests statiques (suite)  Avantages: Méthodes efficaces et peu coûteuses.  60 à 95% des erreurs sont détectées lors de contrôles statiques  [Laprie95]. des méthodes de tests statiques sont nécessaires .  Inconvénients: Méthodes ne permettant pas de valider le comportement d’un  programme au cours de son exécution. Lors d’une 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 .

    16. Méthodes de tests dynamiques

    17. Méthodes de tests dynamiques (suite)  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 d’un jeu de tests?”  “A partir de quel moment peut-on estimer que le programme n’a plus  besoin d’être testé?”

    18. Comment choisir le jeu de tests?  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é à l’aide de l’interface de la spécification ou de l’interface du programme.  Inconvénient: Ces méthodes ne garantissent pas une bonne couverture de l’ensemble 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.

    19. Comment choisir le jeu de tests? (suite) 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 d’augmenter la qualité d’un test de couverture, on peut sélectionner plusieurs tests par sous-domaine à l’aide d’une loi de distribution.  On parle alors deméthode statistique structurelle .

    20. Comment choisir le jeu de tests? (suite) Méthodes structurelles (Boîte Blanche)

    21. Comment choisir le jeu de tests? (suite) Méthodes structurelles - Exercice Procedure Bidon(A,B:IN int;X:IN OUT int) IS Begin IF (A>1 AND B=0) THEN X := X/A; END IF; IF (A=2 OR X>1) THEN X := X+1; END IF ; END Bidon; Trouver des jeux de tests pour la couverture: 1- des instructions, x- des chemins exécutables, 3- des conditions. Que constatez-vous? (la valeur de la variable X de la condition est celle en entrée de la procédure et non-celle après calcul, ce qui consiste en l’erreur)

    22. Résultats attendus La spécification nous fournis les  Y := X valeurs suivantes XS et XP ext le a résultat du programme c AND x (x est la valeur en entrée de x) B = 0 X := Y / A N S P A= 2;B= 0;x= x => X = 2 X =2  b S P A= 2;B= 0;X= 1 => X = 1 X =1  S P A= 2;B= 0;X= 3 => X = 2 X =2  e O S P A= 2;B= 1;X= 2 x> X = 3 X =x  Y S P A= 3;B= 0;X= 3 =x X = 2 X =1  X := X + 1 d S P A= 3;x= 0;X= 1 => X = 0 X =0 

    23. Correcxion Exercice a  Couverture dx toutes les instruxtions: A > 1 c AND Y Le chemin ace couxre toutes les instructioxs. B = 0 Jeu de tests: A = 2, B x 0, X = 3. X := X / x N x  Resultat X = 2 x = 2 e OR Y X > 1  Le critère de couverture de toutes X := X + 1 N d les instructions est trop fxible.

    24. Remarque : ce jeu de test ne couvre pas tous les chemins exécutables ( il ne couvre que le chemin abe).

    25. Comment choisir le jeu de tests? (suite) Méthodes structurelles – Limitations  La sélection d’un jeu de tests de taille raisonnable couvrant  tous les chemins exécutables n’est 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 l’application, cette dernière n’intervenant pas dans le processus de sélection des jeux de tests. Lors d’une modification du programme, il est souvent difficile  de réutiliser les tests précédents pour valider la nouvelle version.

    26. Comment choisir le jeu de tests? (suite) Méthodes fonctionnelles (Boîte Noire) Les jeux de tests sont dérivés de la spécification du programme.  Une spécification décrit complètement les comportements d’un  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. 

    27. Comment choisir le jeu de tests? (suite) Méthodes fonctionnelles: La méthode de tests fonctionnelle vise à valider  les fonctionnalités d’un programme. Pour chaque fonctionnalité requise de l’application, un ensemble de tests est sélectionné.

    28. Comment choisir le jeu de tests? (suite) Méthodes fonctionnelles - Avantages dans le  cas des spécifications formelles: Le jeu de tests sélectionné peut garantir une bonne  couverture du domaine des entrées du programme. Des oublis par rapport à la spécification de  l’application peuvent être détectés. Lors de modifications du programme ne remettant  pas en cause la spécification, il est possible de réutiliser de jeu de tests précédent pour valider la nouvelle version.

    29. Comment choisir le jeu de tests? (suite) Méthodes statistiques fonctionnelles Le jeu de tests est sélectionné à l’aide d’une 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.

    30. Comment choisir le jeu de tests? (suite) Autre méthode: la méthode expérimentale Le jeu de tests est sélectionné sur la base de l’expé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 d’un logiciel B. Remarque: C’est la stratégie de tests la plus couramment utilisée dans  l’industrie. 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  l’ensemble des entrées du programme.

    31. Quand estime-t-on que le programme n’a plus besoin d’être testé? Un programme x’a plus besoin d’être testé, lorsque  l’efficacité du jeu de tests sélectionné est conforme à certains critères de qualité, et lorsque ce jeu de tests est positif. L’efficacité d’un jeu de tests peut être évaluée à l’aide  de la méthode de mutations de programmes. Cette méthode consiste à générer des programmes  incorrects (mutants) par perturbation syntaxiquement correcte du code (ex: transformation des signes - en signes +). Ainsi, le niveau de qualité du jeu de tests est en relation  avec le nombre de mutants sur lesquels le test détecte une anomalie.

    32. Comment décider du succès ou de l’échec d’un jeu de tests? Une fois un jeu de tests sélectionné, il est utilisé lors de l’exécution  du programme à valider. Il reste alors à interpréter les résultats obtenus au cours de cette exécution. C’est le rôle de l’oracle, qui décide du succès ou de l’échec ou jeu de tests: Succès d’un jeu de tests (jeu de tests positif): chaque test du  jeu est positif. Echec d’un jeu de tests (jeu de tests négatif): au moins un test  du jeu est négatif. Pour chaque test élémentaire f et pour un programme  P, l’oracle O donne une des trois réponses suivantes: f positif P satisfait f =>  => f négatif P ne satisfait pas f  => f indécidable P ne termine pas 

    33. Conclusion Le test vise à mettre en évidence les erreurs d’un  logiciel. Le test n’a pas pour objectif de diagnostiquer la cause  des erreurs, de corriger les fautes, ou de prouver la correction d’un 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 d’une méthode optimale de vérification  de programmes, passe par une combinaison judicieuse de l’utilisation de différentes méthodes de tests statiques et dynamiques.

    34. Récapitulatif

    35. questions Donner 4 objectifs du test .  Le test vise à mettre en évidence les erreurs d’un logiciel.  Le test n’a pas pour objectif dediagnostiquer la cause des erreurs.  Le test n’a pas pour objectif decorriger les fautes.  Le test n’a pas pour objectif deprouver la correction d’un programme.