MÉTHODE DE TEST DES APPLICATIONS. Version : M21.4

Transcription

1 MÉTHODE DE TEST DES APPLICATIONS Version : M21.4

2 [PAGE INTENTIONNELLEMENT BLANCHE]

3 Introduction MÉTHODE DE TEST DES APPLICATIONS 3

4 Avertissement Ce document est un support de cours dont le seul objectif est d aider les participants en leur évitant de prendre trop de notes, et en leur permettant d être plus actifs. Ce n est qu un élément d un ensemble de matériaux pédagogiques. Il est complémentaire des exposés et développements faits par l animateur, et ne contient pas la totalité des spécificités et des discussions propres à un site ou une session. Il ne représente donc qu une partie de la formation, et ne peut être utilisé avec profit que comme document d accompagnement d une séance de formation. 4 1-Introduction

5 Objectifs du cours Sensibiliser les participants à l importance de la qualité dans le développement du logiciel Définir une méthodologie de tests des modules et des applications Permettre de construire des jeux d essai Définir les éléments d organisation liés aux tests Définir une approche de la maintenance des programmes Donner les éléments de choix des outils de test Privilégier les aspects pratiques 1-Introduction 5

6 [PAGE INTENTIONNELLEMENT BLANCHE] 6 1-Introduction

7 La qualité MÉTHODE DE TEST DES APPLICATIONS 7

8 Les objectifs du chapitre Définir le concept de Qualité Assimiler la démarche Qualité Se convaincre de son absolue nécessité Relier qualité et tests 8 2-La qualité

9 La qualité : concepts 1. Le contrôle qualité : Est un concept des années 1960 Il applique le principe du contrôle «a posteriori» ou en final Il qualifie le résultat (bon ou mauvais) Conséquences : Tout est à recommencer si le résultat est mauvais (augmentation importante des coûts) Cela renforce l idée reçue (mais fausse) : «La qualité, cela se paie» 2-La qualité 9

10 La qualité : concepts (suite) 2. L assurance qualité : Est un concept des années 1970 Il applique le principe du contrôle «tout au long du processus de développement» Il introduit la notion de «qualité du produit» et de son «processus de fabrication» Il permet la détection des anomalies le «plus tôt possible» et engendre une réduction des coûts Définition : Mise en œuvre d un ensemble de dispositions préétablies destinées à l obtention régulière de la Qualité requise Remarque : L assurance qualité introduit les notions : de responsabilisation à chaque étape d objectifs qualité 10 2-La qualité

11 La qualité : concepts (suite) 3. La gestion totale de la qualité : Est un concept des années 1980 Il s appuie sur la notion de «Totalité» : la qualité est gérée dans l entreprise toute entière elle concerne toutes les fonctions et tous les aspects (matériel, logiciel, humain) chaque intervenant est impliqué et s efforce d améliorer la qualité àson propre niveau tous les besoins des clients sont pris en compte (coûts, délais, performances,...) la qualité est présente tout au long du cycle de vie des projets 2-La qualité 11

12 Qualité : définitions La définition des systèmes qualité est régie par les normes internationales ISO 9000 reproduites par la norme européenne EN et la norme française AFNOR NF X Qualité : Aptitude d un produit ou d un service à satisfaire les besoins d un utilisateur Assurance qualité : Mise en œuvre d un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l obtention de la qualité requise Manuel qualité : Document décrivant les dispositions générales prises par l entreprise pour obtenir la qualité de ses produits ou des ses services Plan qualité : Document décrivant les dispositions spécifiques prises par une entreprise pour obtenir la qualité du produit ou du service considéré 12 2-La qualité

13 Qualité et informatique Le Manuel qualité transcrit, au niveau de l entreprise, l ensemble des méthodes, règles et procédures mises en œuvre pour développer un produit logiciel de qualité C est une base documentaire Qui s enrichit au cours du temps Le Plan qualité détermine le processus de développement propre à un projet, avec ses particularités et spécificités La Qualité est une démarche continue tout au long du développement du produit logiciel La Qualité se définit, se mesure et se concrétise 2-La qualité 13

14 Qualité et informatique (suite) Remarques : La démarche qualité ne se suffit pas à elle-même Elle demande une volonté de l encadrement (mise en place d une politique Qualité) Elle nécessite l adhésion complète de l ensemble des intervenants Elle demande la mise en place de moyens et de structures nécessaires à sa concrétisation 14 2-La qualité

15 Le manuel qualité Contenu : Les objectifs (explication de la politique de qualité) L organisation mise en place (qui contrôle quoi, où et quand?) Quels produits et services sont concernés par le manuel qualité Présentation et justification de la qualité : privilégier le professionnalisme éviter l aspect policier Le plan de développement du produit logiciel : les phases du cycle de vie les moyens nécessaires (méthodes, techniques, outils, rapports, notes,...) le plan de formation la planification et le suivi de l avancement Les documents à fournir 2-La qualité 15

16 Le manuel qualité (suite) Le contrôle de qualité : les critères de qualité les points de contrôle qualité les moyens mis en œuvre La gestion de l évolution du produit La mise à jour du manuel de qualité La qualité est présente tout au long du déroulement du projet et concerne tous les intervenants 16 2-La qualité

17 La qualité du logiciel Ce qu on demande Validité : aptitude d un produit logiciel à réaliser exactement les tâches définies par sa spécification Exploitabilité : aptitude à être utilisé par les différentes parties prenantes (opérateurs, utilisateurs, maintenance...) Efficacité : mesure de la bonne utilisation des ressources Fiabilité : aptitude d un logiciel à fonctionner sans incident Intégrité : aptitude d un composant à protéger ses différentes composantes contre des accès ou des modifications non autorisées Extensibilité (Maintenabilité) : facilité d adaptation d un logiciel aux changements de spécifications Exactitude : aptitude d un logiciel à produire des résultats corrects Robustesse : aptitude d un logiciel à fonctionner dans des conditions anormales 2-La qualité 17

18 La qualité du logiciel Ce qu on doit obtenir Portabilité : facilité avec laquelle un constituant logiciel peut être adapté àdifférents environnements matériels et logiciels Réutilisabilité : aptitude d un logiciel à être réutilisé pour de nouvelles applications Lisibilité : faculté avec laquelle un composant est lu et donc compris Vérifiabilité : facilité de préparation des procédures de test pour le constituant considéré Compréhensibilité : aptitude pour un module d être compris isolément par un lecteur humain ; au pire le lecteur ne doit avoir à consulter que quelques modules voisins. Compatibilité : aptitude des logiciels à pouvoir être combinés les uns avec les autres 18 2-La qualité

19 La qualité du logiciel Ce qu on doit obtenir (suite) Décomposabilité : aptitude à décomposer un nouveau problème en plusieurs sous-problèmes dont la solution peut être recherchée séparément Composabilité : aptitude à favoriser la production d éléments de logiciel qui peuvent être combinés librement les uns avec les autres pour produire de nouveaux systèmes, éventuellement dans un environnement très différent de celui pour lequel ils ont été éventuellement développés Continuité : une petite modification de la spécification du problème n amène à modifier qu un seul module, ou peu de modules Protection : aptitude pour une architecture de ne pas propager l effet d une condition anormale se produisant à l exécution d un module, ou tout au moins de ne propager cet effet qu à quelques modules voisins 2-La qualité 19

20 Théorie et pratique La qualité est difficile à obtenir dans les applications informatiques Les objectifs de qualité sont peu souvent définis Le seul moyen de s en assurer est souvent limité aux tests Les tests sont peu productifs Beaucoup d erreurs sont découvertes en exploitation Les tests coûtent cher La non-qualité des applications coûte encore plus cher Pourra-t-on se le permettre encore longtemps? (car de plus en plus d activités humaines dépendent directement de la qualité des applications informatiques) 20 2-La qualité

21 Le coût de la non qualité Exemple 1 Le 22 juillet 1962, une fusée Atlas-Agena lançant un satellite Mariner I fut détruite par erreur Cause : Erreur minime dans le logiciel de guidage, amenant l ordinateur à croire que la fusée se comportait mal, ce qui n était pas le cas Coût : 18,5 millions de dollars Source : Les avatars du logiciel, Addison-Wesley 2-La qualité 21

22 Le coût de la non qualité Exemple 2 En juillet 1991, des séries de coupures affectèrent les abonnés du téléphone de Los-Angeles, Washington, etc. Cause : Le programme de commutation avait été modifié. Ce programme comporte plusieurs millions de lignes de code, et un cycle de tests représente 13 semaines. La modification ne touchant que trois lignes de code, on avait estimé inutile de refaire des tests complets! 22 2-La qualité

23 Le coût de la non qualité Exemple 3 Le 25 février 1991, un missile Scud irakien tua 28 soldats américains et en blessa 98 autres. Cause : Une bogue dans le logiciel de conduite des anti-missiles Patriot n avait pas permis l interception. Une erreur de calcul dans le logiciel de poursuite entraînait un écart d un dix millionième de seconde toutes les dix secondes, qui se cumulait au fil du temps. Le système ayant fonctionné 5 jours d affilée, l erreur atteignait 36 centièmes de secondes. L erreur avait été repérée, corrigée, mais le logiciel rectifié n avait pas encore été livré. 2-La qualité 23

24 Le coût de la non qualité Exemple 4 Le 20 novembre 1985, une bogue coûta 5 millions de dollars à la Bank of New-York. Cause : Réécriture d informations par dessus des informations déjà enregistrées. La détection de l erreur dura 90 minutes, et la banque devait alors déjà 32 millions de dollars à la banque fédérale. Les efforts de tous ramenèrent la dette à 23,6 millions de dollars, ce qui coûta 5 millions de dollars en intérêts La qualité

25 Tests et cycle de vie Exemple de cycle de vie ÉTUDE DES BESOINS CONCEPTION PROGRAMMATION INTEGRATION / TESTS PRODUCTION / MAINTENANCE Les tests constituent une phase isolée, indépendante, semblant située après les autres phases. Est-ce la meilleure solution? N est-ce pas une des causes de la mauvaise qualité du logiciel? 2-La qualité 25

26 Autre exemple : SDM / S DS DEMANDE DE SERVICE EO ÉTUDE D OPPORTUNITÉ DBS DÉFINITION DES BESOINS CAS CHOIX D ARCHITECTURE SES SPÉCIFICATIONS EXTERNES SIS SPÉCIFICATIONS INTERNES PRG PROGRAMMATION TST TESTS CONV CONVERSION INST INSTALLATION BILAN BILAN Phase de tests semblant isolée 26 2-La qualité

27 Autre exemple : MCP CONCEPTION FR0 EXPRESSION DES BESOINS +-> INSCRIPTION AU D AUTOMATISATION SCHEMA DIRECTEUR FR1 ÉTUDE D OPPORTUNITÉ +-> INSCRIPTION AU PLAN INFORMATIQUE FR2 ÉTUDE DU SYSTEME D INFORMATION FR3 ÉLABORATION DU +-> DÉCISION DE CAHIER DES CHARGES RÉALISATION RÉALISATION FR4 ÉTUDE DU SYSTEME INFORMATIQUE FR5 PROGRAMMATION ET ESSAIS MISE EN OEUVRE FR6 RÉCEPTION PROVISOIRE FR7 LANCEMENT SOUS CONTROLE EXPLOITATION FR8 ÉVALUATION DE L APPLICATION+-> DÉCISION DE MAINTENANCE FR9 ÉVALUATION DU PROJET +-> DÉCISION DE MODIFICATION La qualité 27

28 Les tests dans le cycle de vie Les tests devraient être «horizontaux» 28 2-La qualité

29 Place des tests Les tests sont longs et entraînent une charge importante DISTRIBUTION PAR PHASE TAILLE EN KISL CHARGE Plan/spécifications 6% 6% 6% 6% Conception 16% 16% 16% 16% Programmation 68% 65% 62% 59% dont conception détaillée 26% 25% 24% 23% codage et tests 42% 40% 38% 36% Intégration-tests 16% 19% 22% 25% TAILLE EN KISL DÉLAI Plan/spécifications 10% 11% 12% 13% Conception 19% 19% 19% 19% Programmation 63% 59% 55% 51% Intégration-tests 18% 22% 26% 30% Source : modèle COCOMO (Barry Boehm) 2-La qualité 29

30 Comment faire Mieux connaître les tests Mieux intégrer les tests dans le cycle de développement du logiciel Mieux tester Mieux écrire Mieux concevoir 30 2-La qualité

31 Les tests et leurs problèmes MÉTHODE DE TEST DES APPLICATIONS 31

32 Les objectifs du chapitre Définir les notions d erreur et de défaut Connaîtres les difficultés inhérentes aux tests Justifier la nécessité des tests Comparer les tests aux autres méthodes de recherche d erreurs 32 3-Les tests et leurs problèmes

33 Définitions Anomalie : manifestation observée d un comportement différent du comportement attendu ou spécifié (la norme) Défaut : manque, insuffisance : l anomalie est constatée parce qu il y a un défaut Erreur : faute commise en se trompant, méprise : l erreur provoque un défaut se manifestant par une anomalie C est parce qu on peut commettre des erreurs en développant des logiciels que les tests sont nécessaires 3-Les tests et leurs problèmes 33

34 Les tests Constats : Tout programme est faux, à moins qu on ait prouvé le contraire Les tests servent à montrer la présence d erreurs, jamais à prouver leur absence (Dijkstra 1969) Le programmeur est la personne la moins bien placée pour tester son programme Faible rendement Durée importante Tâche difficile Remarques : Un programme n est jamais faux Mais il ne fait pas ce que l on attend de lui! Les tests sont estimés à 33% du coût d un projet! 34 3-Les tests et leurs problèmes

35 Test et complexité Schéma : n n A A v A A A v A >+-+ +->-+ +->-+ ++-> >-+ +->-+ ++> v v A v v A n +² 5-1 NOMBRE DE CHEMINS A TESTER : T = 5 * SI N = 4 ---> T = SI MODULE DÉCOUPÉ ---> T = SI N = > T = 9,3 * 10 SI UNE MACHINE TESTE UN MILLION DE CHEMINS A LA SECONDE ANS DE TEST!!! Remarque : Plus un programme est compliqué, plus il est difficile à tester 3-Les tests et leurs problèmes 35

36 Difficultés des tests Théoriques : Problème de combinatoire (voir ci-dessus) Possibilité des tests? Peu d intérêt théorique pour la discipline (ou intérêt très récent) Il ne peut exister aucun algorithme général (donc aucun outil) capable de démontrer l exactitude totale de n importe quel programme! 36 3-Les tests et leurs problèmes

37 Difficultés des tests Techniques : Mauvaise synchronisation entre écriture et tests Problèmes de disponibilités de ressources (modules, systèmes, fichiers non disponibles) Nécessité de création d outils spécifiques (génération de cas, interprétation des résultats) Besoin d environnement(s) particulier(s) Problèmes liés à la stabilité des environnements (quelle version de système, de SGBD, etc.) 3-Les tests et leurs problèmes 37

38 Difficultés des tests Humaines : Tâche fastidieuse Les tests débutent souvent quand on est en retard (tendance à cumuler les retards sur les tests) Blocages psychologiques (erreurs ressenties comme des fautes par le programmeur qui les a commises) C est la première fois que l on montre quelque chose : remise en cause des spécifications conflits Manque de formation à la technique des tests construction des tests analyse des résultats bibliographie? Manque d objectifs précis Manque de rigueur Obstacle culturel (on apprend à gagner, l erreur est rejetée de la formation) 38 3-Les tests et leurs problèmes

39 Les causes d erreur Il existe (malheureusement) de nombreuses causes ou possibilités d erreurs lors du développement d applications informatiques Pendant les phases de conception mauvaise expression des besoins mauvaises solutions techniques etc. Pendant la conception de la logique détaillée : mauvaise interprétation des spécifications logique incomplète cas particulier omis cas d erreurs négligés etc. 3-Les tests et leurs problèmes 39

40 Les causes d erreur Pendant le codage : erreurs de syntaxe erreurs d initialisation erreurs de paramètres erreurs de compteur de boucle prise en compte incorrecte des résultats d une décision définition multiple ou non-définition de variables déclarations de type ou de dimension incorrects erreur d écriture du nom d une variable etc Les tests et leurs problèmes

41 Les causes d erreur Pendant la translation (link) : erreur de compilation restante mauvaise résolution des références externes confusion des noms de membres ou de bibliothèques Voir la classification des erreurs en annexe 3-Les tests et leurs problèmes 41

42 Échelle de gravité des erreurs 1. légère : présentation ou orthographe 2. modérée : sorties redondantes avec peu d impact sur le système 3. ennuyeuse : fonctionnement perturbé (zones tronquées) 4. perturbante : refus de traiter des transactions 5. sérieuse : perte de transactions 6. très sérieuse : exécution de la mauvaise transaction 7. extrême : les problèmes précédents arrivent fréquemment et arbitrairement 8. intolérable : corruption de bases de données 9. catastrophique : le système tombe en panne 10. infectieuse : le système corrompt d autres systèmes, ou tue 42 3-Les tests et leurs problèmes

43 Comparaison des méthodes d essai Les tests ne sont ni la seule, ni la meilleure méthode pour assurer la qualité d une application Les tests ont un faible rendement : en effort dépensé par instruction en pourcentage d erreurs corrigées EFFORT EN INSTRUCTIONS % DE CORRECTION PAR HEURE MÉTHODE INSPECTION MOYENNE : 40 59% DU CODE EXTREMES : 10 à à 89% TEST MOYENNE : 17 51% UNITAIRE EXTREMES : 5 à à 89% Les tests et leurs problèmes 43

44 Comparaison des méthodes d essai Pourcentage de défauts détectés MÉTHODE Taux le Taux Taux le + faible médian + fort Vérification individuelle 15% 30% 70% de la conception Revue formelle en groupe 30% 40% 60% de la conception Inspections formelles 35% 55% 75% de la conception Inspections formelles 30% 60% 70% du code Modélisation/prototypage 35% 65% 80% Vérification individuelle 20% 40% 60% du code Tests unitaires (module) 10% 25% 50% Tests de programme 20% 35% 55% Tests d enchaînement 25% 45% 60% Tests de recette 35% 50% 65% Effet cumulatif 93% 99% 99% Les tests et leurs problèmes

45 Comment améliorer les tests? Meilleure connaissance du programme Meilleure connaissance de l énoncé Méthodologie de tests Objectifs de tests Formation à la technique des tests Outils de tests 3-Les tests et leurs problèmes 45

46 [PAGE INTENTIONNELLEMENT BLANCHE] 46 3-Les tests et leurs problèmes

47 Définitions et axiomes MÉTHODE DE TEST DES APPLICATIONS 47

48 Les objectifs du chapitre Définir les tests Définir le vocabulaire utilisé Donner les axiomes relatifs aux tests 48 4-Définitions et axiomes

49 Définitions des tests Quelques définitions historiques Établir qu un programme fait ce qu il est supposé faire (Hetzel 1973) Action consistant à exécuter un programme ou un système avec l intention de trouver des erreurs (Myers 1979) Détection d erreurs de spécifications ou de d écarts par rapport aux spécifications Toute activité tendant à évaluer un attribut ou une capacité d un programme ou d un système Mesure de la qualité du logiciel (Hetzel 1983) Processus d évaluation d un programme ou d un système Vérifier qu un système satisfait ses spécifications ou identifier les différences entre les résultats attendus et les résultats fournis Confirmer qu un programme effectue correctement ses fonctions 4-Définitions et axiomes 49

50 Définitions des tests Définitions officielles IEEE/ANSI 1990 (Standard ) Processus consistant à exécuter un système ou un composant dans des conditions spécifiées, en observant ou en enregistrant les résultats, et à faire une évaluation de certains des aspects du système ou du composant IEEE/ANSI 1983 (Standard 823) Processus consistant à analyser un élément logiciel pour détecter les différences entre les conditions requises et celles existantes, et permettant d évaluer les caractéristiques de l élément logiciel Notre définition préférée Test : action qui consiste à exécuter un programme (une partie de programme ou un système) avec l intention de trouver des erreurs 50 4-Définitions et axiomes

51 Autres définitions Vérification : processus d évaluation d un système ou d un composant pour déterminer si le produit satisfait, à sa phase de développement, les conditions imposées au début de la phase On vérifie qu on a bien fait un logiciel Validation : processus d évaluation d un système ou d un composant durant ou à la fin de son développement pour déterminer s il satisfait ses spécifications On valide qu on a fait le bon logiciel Test = vérification + validation 4-Définitions et axiomes 51

52 Autres définitions Débogage (debugging, déverminage) : diagnostic de la nature exacte d une erreur connue et correction de l erreur (c est une activité de réparation et non de test) Jeu d essai : ensemble (structuré) de cas à tester 52 4-Définitions et axiomes

53 Les axiomes du test Un bon jeu d essai doit avoir comme objectif de trouver des erreurs non connues, et pas de montrer que le programme fonctionne correctement Un des problèmes les plus difficiles est de savoir quand s arrêter Il est impossible de tester son propre programme Tout jeu d essai doit être accompagné de la description des sorties attendues Les tests doivent être reproductibles On doit tester, en entrée, la validité des données et les cas invalides Il faut examiner soigneusement les résultats des tests Quand le nombre d erreurs détectées dans un élément de logiciel croît, la probabilité d existence d erreurs non détectées croît également On doit affecter les meilleurs programmeurs aux tests (tests techniques et non pas fonctionnels) On doit s assurer en écrivant un programme, qu il est possible de le tester 4-Définitions et axiomes 53

54 Les axiomes du test (suite) Chaque test doit avoir un objectif (performances, exploitabilité, utilisateurs...) On doit tester les cas valides et les cas invalides Le plan de test ne doit pas être construit avec l intention tacite de ne pas trouver d erreurs Les tests peuvent être une tâche extrêmement créative 54 4-Définitions et axiomes

55 Techniques de test Boîte noire On ne connaît que les spécifications (l aspect externe) On valide le programme par rapport à ses spécifications Test fonctionnel Boîte blanche On connaît à la fois les spécifications et l implémentation (pseudo-code ou code) On valide la réalisation du programme Test structurel Boîte grise Combinaison des deux techniques Non régression Un test de non régression consiste vise à s assurer qu une évolution n a pas introduit de nouveaux défauts 4-Définitions et axiomes 55

56 [PAGE INTENTIONNELLEMENT BLANCHE] 56 4-Définitions et axiomes

57 Le plan de tests MÉTHODE DE TEST DES APPLICATIONS 57

58 Les objectifs du chapitre Définir ce qu est un plan de tests Donner une trame du contenu d un plan de test Définir les différents types de test Relier les tests à la démarche de construction du logiciel 58 5-Le plan de tests

59 Plan de tests Le plan de test décrit toutes les procédures permettant de conduite les tests jusqu à leur terme Un plan de tests doit, au minimum : établir les objectifs de chaque phase de tests, définir les responsabilités et le planning pour chacune des activités des tests, s assurer de la disponibilité des outils de tests et données de tests (bibliothèques de cas de tests?), établir les normes de conduite des tests, définir les critères de fin et d acceptabilité de chaque test. 5-Le plan de tests 59

60 Trame d un plan de tests Composants à tester faire une liste exhaustive des composants à tester préciser pour chaque composant : les objectifs des activités de test les types de test et les étapes les méthodes de test choisies pour chaque type et chaque étape les outils de test utilisés les règles à suivre pour : définir chaque type de test rédiger les procédures de test exécuter les tests définir et décider les critères d arrêt des tests enregistrer les résultats de test et rédiger les comptes-rendus exploiter les résultats des tests 60 5-Le plan de tests

61 Trame d un plan de tests Objectif de chaque test Le plan devra détailler pour chaque test l objectif à atteindre validité des fonctionnalités contrôle de l enchaînement des écrans ergonomie du produit performances etc. 5-Le plan de tests 61

62 Trame d un plan de tests Types de test Le plan devra distinguer les différents types de tests test unitaire (module) test de programme ou de transaction test d analyse test d intégration (d enchaînement) test de recette utilisateur recette exploitation tests système test inter-applications etc Le plan de tests

63 Trame d un plan de tests Procédures de tests Pour chaque type de test, on doit indiquer les moyens utilisés test boîte blanche test boîte noire test de non régression contrôle des chemins contrôle de couverture couverture de branches couverture de conditions conditions multiples etc. graphe de contrôle scénario d intégration etc. 5-Le plan de tests 63

64 Trame d un plan de tests Critères d arrêt Pour chaque type de test, on doit préciser le critère d arrêt du test : taux de couverture atteint taux ou type d erreurs détectés dépassement du temps imparti intervalle de variables performances atteintes volumes atteints etc Le plan de tests

65 Trame d un plan de tests Mise en œuvre Le plan de test doit préciser : les moyens de tests utilisés à chaque étape la configuration utilisée les responsabilités (qui définit, qui réalise, qui contrôle) les délais (planning de chaque essai) les procédures nécessaires à la réalisation des tests, à l exploitation et à l enregistrement des résultats les actions à prendre (quand passe-t-on à l étape suivante, quand refait-on un test, etc.) la forme des comptes-rendus de tests 5-Le plan de tests 65

66 Trame d un plan de tests Compte-rendu de tests date nom de la phase de test identification de composant logiciel testé version du composant type de test effectué liste détaillée des cas testés liste détaillée des erreurs constatées liste des corrections envisagées liste des répercussions sur la configuration noms des participants charge de travail procédure d acceptation éventuelle 66 5-Le plan de tests

67 Plan de tests Liste de contrôle Tous les niveaux de tests sont-ils définis? L objectif de chaque test est-il défini? Les ressources nécessaires (matériel, logiciel, personnel) nécessaires à la période de test sont-elles identifiées? Les responsabilités de chaque niveau de test sont-elles identifiées? Sont-elles clairement définies? Les testeurs sont-ils indépendants des développeurs? Des revues ou inspections sont-elles planifiées? Les responsabilités de leur conduite sont-elles clairement identifiées? Concernent-elles : la conception, la définition des plans de tests, les procédures de test, les résultats de tests? Des normes existent-elles pour ces revues? Les procédures de correction post-revues sont-elles définies? Le planning des différentes épreuves (revues, tests, etc.) est-il établi et vérifié? La documentation nécessaire est-elle définie? Un auditeur qualité est-il nécessaire? Est-il défini? 5-Le plan de tests 67

68 Les différents tests Liste minimale des différents types de tests 1. Vérification avant, pendant et après l écriture 2. Test unitaire (module) 3. Test de programme ou de transaction 4. Test d analyse (de fonctions) 5. Test d enchaînement (d intégration) 6. Test de recette 7. Recette exploitation 8. Tests système 9. Test inter-applications 68 5-Le plan de tests

69 1 Réalisation et vérification Vérification avant, pendant et après l écriture : Objectif : trouver les erreurs le plus tôt possible éviter des tests Moyens : boîte blanche «test» manuel individuel : passer par tous les chemins possibles revues, inspections 5-Le plan de tests 69

70 Revue de programme La conception est-elle claire? Le programme réalise-t-il sa fonction? Le code est-il clair? Est-il aisément compréhensible? Les commentaires aident-ils à comprendre le programme? Pourrait-on modifier facilement le programme? Serait-on fier d avoir écrit ce programme? Le code suit-il les normes de programmation? Les tests suivent-ils les normes de test établies? Les données de test sont-elles bien choisies (variété des valeurs, valeurs mini, maxi, probables)? Le test des données erronées est-il prévu? Toutes les conditions d erreur sont-elle vérifiées? Les tests montrent-ils que le programme réalise bien ce qu on attend de lui? Les tests montrent-ils que le code satisfait toutes les exigences? Les données en entrées produisent-elles les sorties attendues? 70 5-Le plan de tests

71 2 Test unitaire (module) Objectif : contrôle technique de fonctionnement Moyens : boîte blanche jeux d essai programmeur (construit logiquement) simulateur d appel, liste de contrôle, inspection 5-Le plan de tests 71

72 3 Test de programme ou de transaction Objectifs : contrôle de l enchaînement des modules, intégration des éléments, solidité, fiabilité Moyens : images de fichiers (cas normaux), jeux d essai (cas aux limites), inspection 72 5-Le plan de tests

73 4 Test d analyse Objectifs : validité par rapport à l énoncé critère de fin de programmation Moyens : boîte noire cas vraisemblables (ordre décroissant) inspection 5-Le plan de tests 73

74 5 Test d intégration (d enchaînement) Objectifs : fonctionnement correct d un ensemble par rapport à une analyse temps réel : enchaînement cohérent des éléments d une même fonction (transactions, modules) temps différé : enchaînement des programmes et validation de la procédure (JCL) Moyens : jeu d essai ou extraits de fichiers système de test 74 5-Le plan de tests

75 6 Test de recette utilisateur Objectifs : contrôle par rapport aux spécifications validation dans l environnement réel contrôle du manuel utilisateur Moyens : jeu d essai de recette travail en double 5-Le plan de tests 75

76 7 Recette exploitation Objectif : satisfaction aux normes d exploitation validation du manuel opérateur sécurités, reprises, Moyens : contrôle visuel (documents) fonctionnement à blanc manipulations spécifiques (pannes) 76 5-Le plan de tests

77 8 Test système Objectifs : charge maximum admissible volume maximum admissible performances installation (ou ré-installation) fiabilité, disponibilité réparation qualification d une ou de configurations Moyens : simulateur (moniteur) jeu d essai essai en charge 5-Le plan de tests 77

78 9 Test inter-applications Objectifs : fonctionnement des applications entre elles détection des incompatibilités Moyens : comparateur de fichiers (ou interfaces) jeu d essai spécifique 78 5-Le plan de tests

79 Tests et assemblage La stratégie d intégration des éléments du logiciel a un impact important sur les tests L intégration peut être massive («big bang») progressive («au fil de l eau») descendante («top down») ascendante («bottom up») mixte (combinaison par incréments ou agrégats, guidée éventuellement par le risque) 5-Le plan de tests 79

80 Tests et assemblage A B C D E F G H TESTS TOP-DOWN : - MODULE A ( B, C, D, E, F, G ET H VIDES) - MODULES B ET C (D, E, F, G ET H VIDES) - MODULES D, E, F, G ET H TESTS BOTTOM-UP : - MODULES D, E, F, G ET H (B ET C VIDES) - MODULES B ET C (A VIDE) - MODULE A 80 5-Le plan de tests

81 Tests top-down Caractéristiques Le moniteur est testé en premier (logique d appel) Les modules sont intégrés un à un Avantages : L intégration des programmes commence très tôt Les modules appelants sont codés avant les modules appelés : les confusions au niveau des interfaces peuvent être réduites Le besoin de fabriquer un ou plusieurs moniteurs de test est réduit dans la mesure où chaque module peut-être appelé à travers le code existant Un programme en fonctionnement est toujours disponible 5-Le plan de tests 81

82 Tests top-down Inconvénients : L utilisation de modules communs pose des problèmes Il est nécessaire d avoir des modules vides pour tester Les tests sont plus longs car ils sont dépendants des modules supérieurs La complexité des modules n est pas prise en compte 82 5-Le plan de tests

83 Tests bottom-up Caractéristiques Test individuel et indépendant de chaque module Les modules sont intégrés un à un Avantages : Meilleur parallélisme dans la réalisation du codage et des tests L intégration commence plus tôt, mais l assemblage ne se fait que très tard Un module, une fois testé, est considéré comme une simple instruction Les tests peuvent être plus complets, car les modules sont testés indépendamment des modules de niveau supérieur Pas besoin de modules vides pour tester 5-Le plan de tests 83

84 Tests bottom-up Inconvénients : Codification non harmonisée des données et des interfaces Apparition des problèmes uniquement en phase d intégration Suivi difficile de l avancement des travaux Nécessité d écriture de moniteurs de tests 84 5-Le plan de tests

85 Codage et tests Par quoi commencer : Par les modules de plus bas niveau pour bâtir par blocs successifs Par le codage du squelette à tous les niveaux, pour mieux contrôler les interfaces et la complexité Par les modules communs (utilitaires) quel que soit leur niveau Par les modules les plus compliqués (ceux qui prennent le plus de temps à réaliser) Par les modules que les programmeurs se sentent le plus à même de concevoir et de réaliser 5-Le plan de tests 85

86 Tests et construction de logiciel Intégrer les tests le plus tôt possible dans la construction du logiciel Au niveau des spécifications : Détermination de fonctions testables, caractérisées par des entrées et des sorties spécifiques Traçé de diagramme de vérification du système sous forme de couples «stimulus/réponse» Ordonnancement des fonctions à tester : Par unités de réalisation Traduction des spécifications en termes de fabrication et vérification Codage et recette : Par fonction de niveau de détail croissant 86 5-Le plan de tests

87 Tests et construction de logiciel Bénéfices : Vérification des spécifications Noyau rapidement disponible Mesure de l avancement du projet 5-Le plan de tests 87

88 [PAGE INTENTIONNELLEMENT BLANCHE] 88 5-Le plan de tests

89 Construction de jeux d essai MÉTHODE DE TEST DES APPLICATIONS 89

90 Les objectifs du chapitre Définir comment construire un jeu d essai Décrire les méthodes disponibles et leur domaine d application Donner une application concrète de ces méthodes Traiter les cas particuliers 90 6-Construction de jeux d essai

91 Les premières idées Construction logique : au moins deux fois par répétitive (boucle et fin) au moins deux fois par alternative (vrai et faux) Un seul jeu d essai n est souvent pas suffisant fichiers vides? Tester progressivement : cas général puis cas particuliers dans leur ordre décroissant d apparition Contrôler particulièrement : valeurs aux limites initialisations S inspirer des autres disciplines : on ne met pas un avion en vrille à son premier essai on s assure d abord qu il peut décoller, voler et atterrir 6-Construction de jeux d essai 91

92 Les méthodes de construction Boîte blanche couverture structurelle tests mutationnels Boîte noire analyse partitionnelle (classes d équivalence) analyse aux limites tests aléatoires anticipation des erreurs graphes causes-effet 92 6-Construction de jeux d essai

93 Couverture structurelle Couverture d instruction (SC) : chaque instruction du programme a été exécutée au moins une fois Couverture de décision (DC) : chaque point d entrée et de sortie du programme a été mise en œuvre au moins une fois, toutes les branches résultant d une décision ont été mises en œuvre au moins une fois Couverture de condition/décision (C/DC) : ajoute à DC le fait que chaque condition dans une décision a pris toutes les valeurs au moins une fois Couverture de condition/décision modifiée (MC/DC) : ajoute à C/DC le fait que chaque condition dans une décision affecte de manière indépendante (sauf conditions liées) le résultat d une décision Couverture de condition multiple (M-CC) : ajoute à C/DC le fait que toutes les combinaisons des valeurs de conditions dans chaque décision doivent avoir été prises au moins une fois Logiciel critique : couverture MC/DC dans ce cas, si n conditions booléennes indépendantes, il faut n+1 combinaisons de conditions 6-Construction de jeux d essai 93

94 Couverture structurelle Exemple instructions-1; IF (A OR B) THEN instructions-2; ELSE instructions-3; END-IF; instructions-4; Organigramme 94 6-Construction de jeux d essai

95 Couverture structurelle Table de vérité CAS A B I2 I F F X F V X V F X V V X Exemples de combinaisons à tester selon la couverture souhaitée : SC : cas 1 et 2 (ou 1 et 3, ou 1 et 4) DC : idem C/DC : cas 1 et 4 MC-DC : cas 1, 2 et 3 (ou 1, 2 et 4, ou 1, 3 et 4) M-CC : cas 1, 2, 3 et 4 6-Construction de jeux d essai 95

96 Équivalence partitionnelle Principe Processus systématique permettant de définir des classes de conditions en entrée à tester, chaque classe couvrant un ensemble important de cas de test (Myers) Deux étapes identification des classes d équivalence identification des cas de test 96 6-Construction de jeux d essai

97 Identification des classes 1. Si une entrée spécifie une tranche de valeurs admissibles, définir une classe valide dans la tranche, et deux classes invalides (une pour chaque borne) Exemple : Tranche de 1 à 999 => une classe pour une valeur entre 1 et 999, une pour < 1, une pour > Si une entrée spécifie un nombre de valeurs valides, définir une classe valide pour une valeur, et deux classes invalides (rien, et supérieur au nombre) Exemple : lister de 1 à 6 clients => une classe pour une liste entre 1 et 6, une pour une liste vide, une pour une liste > 6 3. Si une entrée spécifie un ensemble de valeurs valides, définir une classe valide pour une valeur dans l ensemble, et une classe invalide (en dehors de l ensemble) 4. S il y a une raison de penser que le programme traite chaque valeur en entrée différemment, définir une classe par entrée 6-Construction de jeux d essai 97

98 Identification des classes 5. Si l entrée spécifie une condition obligatoire, définir une classe valide et une invalide Exemple : le premier caractère doit être numérique => une classe pour une valeur initiale numérique, une classe pour une valeur initiale non numérique 6. Si on pense que les éléments d une classe ne sont pas tous traités de la même manière, subdiviser la classe en sous-classes 98 6-Construction de jeux d essai

99 Identification des cas de test 1. Donner un numéro à chaque classe 2. Tant que toutes les classes valides n ont pas été couvertes, écrire un nouveau jeu d essai couvrant autant de classes valides non couvertes que possible 3. Tant que toutes les classes non valides n ont pas été couvertes, écrire un nouveau jeu d essai couvrant une et seulement une classe non valide non couverte 4. Si de multiples conditions invalides sont testées dans le même jeu d essai, certaines peuvent être masquées par le traitement des erreurs 6-Construction de jeux d essai 99

100 Analyse aux limites Variante de la méthode des classes d équivalence sous deux aspects : 1. Au lieu de prendre n importe quel élément dans une classe, on se focalise sur les limites de la classe (elles sont souvent à l origine de défauts) 2. Au lieu de ne se centrer que sur les entrées, on explore aussi les sorties, et on génère des classes forçant les sorties désirées Construction de jeux d essai

101 Analyse aux limites Application Si une entrée spécifie une tranche de valeurs, écrire un cas de test pour chaque valeur limite, et un pour chaque valeur juste en deçà et au delà des limites Exemple : nombre de -1.0 à +1.0 => tester -1.0 et 1.0, et Si une entrée spécifie un nombre de valeurs, écrire un cas de test pour chaque valeur limite, et un pour chaque valeur juste en deçà et au delà des limites Exemple : tableau contenant de 1 à 255 éléments => tester 1, 255, 0, 25 Utiliser la même approche pour les sorties : générer les cas de test produisant, pour les sorties, les valeurs limites et les valeurs au delà et en deçà des limites Si l entrée ou la sortie comportent un tri, examiner le premier et le dernier élément Faire preuve d imagination! 6-Construction de jeux d essai 101

102 Tests aléatoires Génération probabiliste, sur les domaines de définition, des données en entrée du programme Avantages facilement automatisable objectivité Inconvénients cas particuliers, exceptions prise en compte de la sémantique Résultats à peine moins bons que des techniques plus élaborées Construction de jeux d essai

103 Anticipation des erreurs Construction de tests à partir des situations ayant provoqué des erreurs par le passé, ou provoquant le plus d erreurs (ou le plus fréquemment) Basé sur le principe que ce qui a provoqué des erreurs dans le passé risque de la faire dans le futur Importance de l expérience et de l intuition Importance d un recensement des erreurs et d un maintien de leur historique Importance d une liste de contrôle actualisée 6-Construction de jeux d essai 103

104 Conseils pratiques Valeurs numériques en entrée Dans les cas d un petit nombre de valeurs différentes en entrée, tester toutes les valeurs Dans les cas d un grand nombre de valeurs de données en entrée, tester les valeurs extrêmes et une sélection de valeurs intermédiaires Toutes les classes de données admissibles doivent être testées (blanc, zéro, valeurs négatives, etc.) Toutes les conditions invalides en entrée doivent être testées (alpha dans du numérique, négatif dans un champ positif, décimal dans un champ entier, etc.) Si deux variables (ou plus) sont liées, tester les valeurs possibles et impossibles Construction de jeux d essai

105 Conseils pratiques Valeurs numériques en sortie Dans les cas d un petit nombre de valeurs différentes en sortie, tester les combinaisons en entrée qui produisent toutes les valeurs Dans les cas d un grand nombre de valeurs différentes en sortie, tester les combinaisons en entrée qui produisent les valeurs extrêmes et une sélection de valeurs intermédiaires Essayer de tester les cas de données en entrée produisant des données en sortie invalides Si des valeurs en sortie sont liées, tester les cas extrêmes, les cas probables, les valeurs illégales 6-Construction de jeux d essai 105

106 Conseils pratiques Tableaux Le contenu de chaque donnée du poste doit être testé Les bornes du tableau doivent être testées, ainsi que leur dépassement Construction de jeux d essai

107 Conseils pratiques Et encore : Tester des valeurs erronées Tester des combinaisons erronées Tester les valeurs extrêmes Tester au delà des extrêmes Ne pas oublier les cas normaux Ne pas générer de cas superflus Tenir compte de la structure Ne pas faire qu un seul test 6-Construction de jeux d essai 107

108 Tests complémentaires : temps réel Réutilisation en série? Réentrance Blocages et interblocages Prise de points de contrôle et redémarrage Performances (moyenne, maxi, limites) etc Construction de jeux d essai

109 Tests complémentaires : interface graphique Tester les valeurs possibles et impossibles de chaque zone Tester les sauts de curseur, les listes Tester avec la souris et avec le clavier Tester les messages d erreur contextuels et les aides Tester les déplacements de fenêtre, les redimensionnements (réductions et agrandissements) Tester le menu contextuel Tester toutes les variantes possibles (les touches de fonction, les touches alt ou ctrl, les barres de menu, les boutons, les icônes) Tester les modifications d environnement (carte graphique, définition et type d écran, couleurs, polices) Tester, le cas échéant, les échanges avec l environnement (couper, coller, OLE, DDE) Tester les dépendances de fenêtres (père-file) Tester l ergonomie fonctionnelle etc. 6-Construction de jeux d essai 109

110 Tests complémentaires : réseau Caractères de contrôle Séquences de messages Messages de longueur nulle Messages trop longs Messages de structure invalide Messages à blanc ou à zéro Nature de l information transmise (binaire, packée) Traduction de code Sécurité, reprises Incidents de trafic (coupure de ligne) etc Construction de jeux d essai

111 Tests complémentaires : client/serveur Protocole(s) de communication et «middleware» Cohérence des versions (entre client et serveur) Mise à jour des programmes Accès au(x) serveurs(s) Accès aux données (disponibilité, indisponibilité, volume) Accès aux procédures stockées, aux triggers Blocages, redémarrages Identification des configurations cibles et des environnements cibles (qualification) Capacité, temps de réponse de bout en bout etc. 6-Construction de jeux d essai 111

112 Tests complémentaires : objet Héritage Surcharge de méthodes Résolution dynamique Stabilité (que se passe-t-il si la bibliothèque de classes évolue?) Réutilisabilité des objets Test d impact Allocation et libération de mémoire Persistance etc Construction de jeux d essai

113 Autres cas particuliers Achat d un progiciel Adaptation d un logiciel étranger Changement de système d exploitation, de SGBD Intégration des outils au poste de travail etc. 6-Construction de jeux d essai 113

114 Une séance de tests Une séance de test doit être structurée : 1. Test devant le terminal : 2 heures 2. Travail au bureau : 2 heures 1/2 partagées par moitiés : exploitation des résultats : mise à jour journal archivage des listes explication des cas étranges interprétation des erreurs selon la nomenclature préparation de la séance suivante : étude et réalisation des modifications test manuel mise à jour du jeu d essai Penser à la comptabilité (amélioration des prévisions futures) Penser à la gestion de la configuration Construction de jeux d essai

115 Outils de tests MÉTHODE DE TEST DES APPLICATIONS 115

116 Les objectifs du chapitre Définir les outils de test En donner une nomenclature Préparer leur sélection Outils de tests

117 Le testware Acôté du hardware et du software, on voit apparaître une catégorie particulière d outils destinés à aider le processus de tests Notion de «testware» Domaine en évolution rapide (voir annexe) Classification des outils préparation des tests exécution des tests traitement des résultats observation et mesure Ne dispensent pas d une gestion de configuration 7-Outils de tests 117

118 Outils de préparation des tests Générateur de cas de tests : limité àl aspect technique Banque de données de cas de tests Extracteurs à partir de fichiers réels Éditeurs de fichiers Analyseurs statiques (graphe de contrôle) Outils de tests

119 Outils d exécution des tests Capture d interactions et rejeu Mode test en temps réel Simulateurs : exemple : BTS sous IMS Test interactif : exemple : mode test sous TSO Lanceurs de procédures de tests Bouchons (ou muets) 7-Outils de tests 119

120 Outils de traitement des résultats Comparateurs de fichiers Gestionnaires et outils d archivage de résultats Outils de tests

121 Outils d observation et de mesure Compilateurs : trace, debugging mode «Instrumentation» du programme : prévoir les tests au moment de l écriture Calculs de compexité, de métriques Aide à la détermination et au suivi de la couverture 7-Outils de tests 121