GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

Transcription

1 GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 6ÈME PARTIE TEST DU LOGICIEL (SOFTWARE TESTING) Faculté des Sciences et Techniques

2 Plan de cette partie de cours 2 Tests de développement Développement orienté test Tests de version Tests utilisateur

3 Test de programme 3 Tester a pour but de montrer qu un programme fait bien ce qu il doit faire et découvrir les défauts avant qu il soit mis en service Lorsqu on teste un logiciel, on exécute un programme sur des données artificielles On contrôle les résultats du test pour trouver les erreurs, anomalies ou des informations sur des attributs non fonctionnels du progamme Peut révéler la présence d erreurs, PAS leur absence Les tests constituent une partie d un processus plus général de vérification et validation qui inclue également des techniques de validation statiques.

4 Objectifs du test de programme 4 Démontrer aux développeurs et aux clients que le logiciel satisfait leurs exigences Logiciels clients au moins un test pour chaque exigence du document de spécification des exigences. Pour les logiciels génériques tests pour toutes les caractéristiques du système, plus les combinaisons de ces caractéristiques, qui seront présentent dans le produit final Découvrir des situations pour lesquelles le comportement du logiciel est incorrect, indésirable ou non conforme aux spécifications Le test de défaut consiste à trouver les effets indésirables du système comme les crashes système, les interactions non voulues avec d autres systèmes, les traitements incorrects, les données corrompues

5 Validation vs Test des défauts 5 Le premier objectif = test de validation On espère que le système va s exécuter correctement lorsqu on utilise un ensemble de cas de test reflétant l utilisation attendue du système Deuxième objectif = test des défauts Les cas de test sont conçus pour mettre en avant les défauts. Les cas de test sont délibérémment obscurs et n ont pas besoin de refléter la façon dont le logiciel est utilisé normalement

6 Objectifs du processus de test 6 Test de validation Démontrer aux développeurs et au client que le logiciel satifsait ses exigences Un test réussi montre que le système s exécute comme prévu Test des défauts Découvrir les défauts dans le logiciel lorsque le comportement est incorrect ou non conforme à sa spécification Un test réussi est un test qui fait s exécuter le logiciel incorrectement montrant ainsi les défauts du système

7 7 Modèle entrée-sortie du test de programme

8 Vérification vs Validation 8 Vérification "Are we building the product right Construit-on le produit correctement? Le logiciel devrait se conformer à sa spécification Validation "Are we building the right product Construit-on le bon produit? Le logiciel devrait faire ce que l utilisateur demande réellement

9 V & V et confiance 9 L objectif de la V & V est d établir la confiance que l on peut avoir dans le fait que le système soit bien en adéquation avec ce qu on attend de lui Cette confiance dépend de l objectif du système, des attentes de l utilisateur et de l environnement marketing Objectif du logiciel Le niveau de confiance dépend du niveau de criticité du logiciel dans l organisation Attentes de l utilisateur Les utilisateurs peuvent avoir de faibles attentes pour certaines catégories de logiciels Environment marketing Mettre un produit tôt sur le marché peut être plus important que de trouver tous les défauts dans le programme

10 Inspection et test 10 Inspection du logiciel (Software inspection) Analyse statique du système pour découvrir les problèmes Possibilité d utiliser des outils d analyse statique de code (comme PMD, Jtest, SonarJ, etc pour JAVA) Test du logiciel (Software testing) Analyse dynamique du système pour observer le comportement du système Le système est exécuté avec des données de test et son comportement est observé

11 Inspection et test 11 Spécification des exigences Architecture logicielle Modèles de conception UML Schémas de BD Programme Prototype Test

12 Inspection du logiciel 12 Implique les personnes chargées d examiner le source dans le but d y découvrir les anomalies et défauts Ne nécessite pas l exécution du système et peut donc être réalisées avant l implémentation Peut être appliquées à toute représentation du système (exigences, conception, données de test, etc) Techniques efficaces pour découvrir les erreurs dans les programmes (démontré depuis de nombreuses années)

13 Avantages des inspections 13 Durant le test, des erreurs peuvent cacher d autres erreurs. Du fait que l inspection est un processus statique il n y a pas de problème d interaction entre erreurs Des versions incomplètes d un système peuvent être inspectées sans coût additionnel. Si un programme est incomplet, il faut développer des tests spécialisés pour tester les parties disponibles Une inspection peut aussi considérer des attributs moins centraux comme le respect des standards, la portabilité, la maintenabilité

14 Inspection et test 14 Inspection et test sont des techniques complémentaires et non pas opposées Les deux devraient être utilisées durant le processus de V & V Les inspections peuvent contrôler la conformité à une spécification mais pas aux exigences réelles du client Les inspections ne peuvent pas vérifier des caractéristiques non fonctionnelles comme la performance, l utilisabilité, etc

15 Un modèle de processus de test 15 Cas de test Données de test Résultats de test Rapports de test Conception des cas de test Préparation des données de test Exec prog sur données de test Comp. résultats et cas de test

16 Etapes du test 16 Tests de développement. Le système est testé durant le développement pour découvrir les bugs et défauts Tests de version. Une équipe indépendante test une version complète du système avant qu elle soit préparée pour les utilisateurs Tests utilisateurs. Utilisateurs (potentiels) testent le système dans leur propre environnement

17 Tests de développement 17 Les tests de développement comportent toutes les activités de test menées par l équipe de développement du système. Tests unitaires Des unités de programmes, des classes sont testées. Devraient se focaliser sur le test des fonctionnalités des objets ou méthodes Tests de composants Plusieurs unités sont intégrées pour créer des composants composites Devraient se focaliser sur le test des interfaces de composants Tests système Tous les composants sont intégrés et le système est testé dans son intégralité. Devraient tester les interactions entre composants

18 Tests unitaires 18 Test unitaire = processus de test des composants pris individuellement Processus de test des défauts Les unités peuvent être Des fonctions ou méthodes d un objet Des classes avec plusieurs attributs et méthodes Des composants composites avec des interfaces définies utilisées pour accéder à leurs fonctionnalités

19 Test des classes d objets 19 Couverture complète du test d une classe Tester toutes les opérations associées à un objet Donner et récupérer des valeurs à tous les attributs des objets Utiliser l objet dans tous les états possibles L héritage rend plus difficile la conception de jeux de test du fait que l information à tester n est pas localisée

20 20 Exemple : station météo

21 Test de la station météo 21 Besoin de définir des cas de test pour reportweather Tests de calibration de la station Démarrage Arrêt En utilisant un modèle à état, identifier les séquences de transitions entre états à tester et la séquence d événements qui provoque ces transitions Exemple Arrêt-> Exécution -> Arrêt Configuration -> Exécution -> Test -> Transmission -> Exécution Exécution -> Collecte -> Exécution -> Rapport-> Transmission -> Exécution

22 Test automatique 22 Le plus souvent possible les tests unitaires devraient être automatisés tests exécutés et contrôlés sans intervention manuelle Utilisation d un environnement de test (comme Junit, cppunit, PHPUnit, DbUnit) pour écrire et exécuter les programmes de test. Les environnements de test proposent des classes de test génériques que l on peut étendre pour créer des cas spécifiques de test. Ils peuvent alors exécuter tous les tests implémentés et générer des rapports (avec l aide de GUI).

23 Composants du test automatique 23 Partie setup. Initialisation du système avec le cas de test données et sorties attendues associées Partie appel. On appelle l objet ou la méthode à tester Partie assertion. On compare le résultat de l appel avec le résultat attendu. Si l assertion est vraie le test passe sinon le test ne passe pas

24 Efficacité des tests unitaires 24 Les cas de test devraient montrer que, lorsqu utilisé de façon appropriée, le composant testé fait ce qu il est supposé faire S il y a des défauts dans le composant, ceux-ci devraient être détectés par les cas de test 2 catégories de cas de tests unitaires Exécution normale du programme celui-ci s exécute comme prévu Exécution anormale du programme entrées anormales et vérification que le composant ne crash pas

25 Stratégies de test 25 Test de partitions. On identifie des groupes de données d entrée qui ont les même caractéristiques et devraient être traitées de la même façon On réalise alors des tests pour chacun des groupes Test basé sur des scénarios. On utilise des scénarios pour choisir les cas de test Ces scénarios reflètent l expérience acquise par les programmeurs dans les types d erreurs souvent commises

26 Test de partitions 26 Les données en entrée et les résultats en sortie font souvent partie de diverses classes où tous les membres de la classe ont le même comportement Chacune de ces classes est une partition du domaine où le programme se comporte de la même façon pour tous les membres de chaque classe Les cas de test devraient être définis à partir de chaque partition

27 Partitionnement 27 Partitions de données d entrée Partitions des sorties résultats Système Entrées possibles Sorties correctes Sorties possibles

28 Partionnement (exemple) 28 Moins que 4 Entre 4 et 10 Plus que10 aaaa Moins que Entre et Plus que aaaa

29 Test de scénario (exemple des listes) 29 Tester le logiciel avec des listes d une seule valeur Utiliser des listes de différentes tailles dans différents tests Tester de telle façon que le premier élément, le dernier, celui du milieu, soient accédés Tester des listes de taille nulle

30 Conseils généraux pour le test 30 Choisir des données qui forcent le système à générer tous les messages d erreur Concevoir des données qui génèrent des débordements (de tableaux, de piles, etc) Répéter la même donnée pour la même série de données plusieurs fois Forcer des sorties invalides à être générées Forcer les résultats de calculs à être trop grands ou trop petits

31 Test de composant 31 Les composants logiciels sont souvent des composants composites fabriqués à partir de plusieurs objets en interaction On peut accéder aux fonctionnalités de ces objets au travers des interfaces définies des composants Le test de composant devraient donc se préoccuper de montrer que l interface du composant se comporte comme il est prévu dans la spécification

32 32 Tests d interface

33 Test d interface 33 Objectif : détecter les défauts dûs aux erreurs d interface ou à des hypothèses invalides à propos des interfaces Les types d interfaces Interfaces de paramètres Données passées d une méthode ou procédure à une autre Interfaces de mémoire partagée Des blocs de mémoire sont partagés entre procédures Interfaces procédurales Des sous-systèmes encapsulent un ensemble de procédures à appeler par les autres sous-systèmes Interfaces de transmission de messages des sous-systèmes requièrent des services de la part d autres sous-systèmes

34 Erreurs d interface 34 Mauvaise utilisation d interface Un composant appel un autre composant et fait une erreur dans l utilisation de son interface (exmple : paramètres dans le mauvais ordre) Mauvaise compréhension de l interface Un composant fait des hypothèses incorrectes sur le comportement d un composant appelé Erreur de synchronisation Les composants appelants et appelés s exécutent à des vitesses différentes et de l information obsolète est accédée

35 Conseils pour le test d interface 35 Concevoir des tests tels que les paramètres d une procédure appelée soient dans les limites de leurs plages de valeurs Toujours tester des paramètres pointeurs avec des pointeurs null Concevoir des tests causant l échec de l exécution du composant Faire du stress testing dans les systèmes à base de messages Dans des systèmes à mémoire partagée, varier l ordre d activation des composants

36 Tests système 36 Le test système durant le développement implique l intégration de composants pour créer une version du système et pouvoir ainsi tester le système entier L objectif est de tester les interactions entre composants Le test système contrôle que les composants sont compatibles, interagissent correctement et transfert les bonnes données au bon moment à travers leurs interfaces Le test système teste le comportement émergent du système

37 Tests système 37 Durant les tests système, des composants réutilisables et des systèmes existants peuvent être intégrés à des composants nouvellement développés. Le système complet est alors testé Des composants développés par des membres de diverses équipes peuvent être intégrés à cette étape. Le test système est donc un processus collectif plutôt qu individuel Dans certaines sociétés, le test système peut impliquer une équipe de test indépendante des concepteurs et développeurs

38 Test basé sur les use-case 38 Les cas d utilisation, développés pour identifier les interactions du système peuvent être utilisés comme base pour le test système Chaque cas d utilisation met en oeuvre en général plusieurs composants et donc tester le cas d utilisation force les interactions à s effectuer Le diagramme de séquence documente le cas d utilisation et les interactions à tester

39 39 Diagramme de séquence pour la collecte de données météos

40 Politiques de test 40 Un test exhaustif du système est impossible conception de politiques de test définissant le périmètre à tester Exemples : Toute les fonctions systèmes accessibles par des menus doivent être testées Les combinaisons de fonctions réalisées par le même menu doivent être testées Lorsque des données doivent être saisies par l utilisateur, toutes les fonctions doivent être testées avec des données correctes et incorrectes

41 Développement dirigé par le test (Test-driven development) 41 Le développement dirigé par le test est une approche de dévelopement de programme dans laquelle on alterne test et développement Les tests sont écrits avant le code et passer les tests est ensuite le fil conducteur de l activité de développement On développe le code incrémentalement, avec un test pour cet incrément. On ne passe pas à l incrément suivant tant que l incrément en cours n a pas passé le test Fait partie des méthodes agiles

42 Activités du processus de développement dirigé par les données 42 Identifier l incrément de fonctionnalité nécessaire. Normalement petit et implémentable en quelques lignes de code Ecrire un test pour cette fonctionnalité et l implémenter dans un test automatique Exécuter le test, avec les autres tests déjà implémentés. Initialement la fonctionnalité n est pas implémentée donc le test va échouer Implémenter la fonctionnalité et exécuter à nouveau le test Une fois que tous les tests sont passés, on passe à l incrément suivant de fonctionnalité

43 Développement dirigé par le test 43 Identifier nouvelle fonctionnalité Passé Écrire le test Exécuter le test Pas passé Implémenter nouvelle fonctionnalité

44 Benefices du développemnt dirigé par le test 44 Couverture du code Chaque morceau de code écrit est associé à au moins un test Test de régression Une suite de test de régression est développé incrémentalement au fur et à mesure que le programme est développé Simplification du debugging Quand un test échoue, il devrait être évident où se situe le problème. Le nouveau code doit être contrôlé et modifié Documentation système Les tests en eux mêmes constituent une forme de documentation décrivant ce que le code devrait faire

45 Tests de régression 45 Le test de régression vise à tester le système pour contrôler que les changements n ont pas endommagés du code qui fonctionnait correctement auparavant Dans un processus manuel, le test de régression est couteux, mais dans un test automatisé, il est simple. Tous les tests sont relancés à chaque changement dans le programme Les tests doivent tous être passés avant que le changement soit validé

46 Test de version 46 Le test de version est le processus qui vise à tester une version particulière du système à usage externe à l équipe de dévelopement Le but premier de ce type de test est de convaincre le client que le système est suffisamment bon pour être utilisé Le test de version est en général un processus de test de boîte noire où les tests sont dérivés des spécifications du système

47 Test de version et test système 47 Le test de version est une forme de test système Néanmoins Une équipe séparée, qui n a pas été impliquée dans le développement du système, devrait être responsable du test de version Le test système, par l équipe de développement, devrait s intéresser à découvrir les bugs dans le système. Les objectifs du test de version sont plus de contrôler que le système satisfait les exigences et est suffisamment robuste pour un usage externe

48 Test basé sur les exigences 48 Le test basé sur les exigences consiste à examiner chaque exigence et à développer un ou plusieurs test(s) associé(s) Exemple : exigence du SI-PSP Si le patient est connu pour être allergique à un médicament particulier, alors toute prescription de ce médicament devrait générer un message d alerte à l utilisateur du système Si un prescripteur choisi d ignorer l alerte il doit fournir une raison à cela au système

49 Tests associés aux exigences 49 Concevoir un enregistrement patient avec aucune allergie connue. Prescrire un médicament sensible aux allergies connues. Contrôler qu aucune alerte n est déclenchée par le système Concevoir un enregistrement patient avec une allergie connue. Prescrire un médicament sensible à cette allergie. Contrôler qu une alerte est déclenchée par le système Concevoir un enregistrement patient avec plusieurs allergies connues. Prescrire des médicaments sensibles à ces allergies séparément et contrôler que le système déclenche bien les bonnes alertes associées à chaque médicament Prescrire deux médicaments pour lesquels le patient est allergique. Contrôler que deux alertes sont générées par le système Prescrire un médicament déclenchant une alerte et outre passer cette alerte. Contrôler que le système demande à l utilisateur d expliquer pourquoi il ne tient pas compte de l alerte

50 Un scénario d usage du SI-PSP 50 Kate est une infirmière spécialisée dans les soins mentaux. Une de ses responsabilités est de visiter les patients à domicile pour s assurer qu ils suivent bien leur traitement et qu ils ne souffrent pas d effets secondaires de médicaments Un jour de visites à domicile, Kate se log sur le SI-PSP et l utilise pour imprimer l agenda des visites de ce jour ainsi qu un résumé des informations sur les patients qu elle doit visiter. Elle demande que ces enregistrements soient téléchargés sur son ordinateur portable. Le système demande alors un mot de passe pour crypter les enregistrement sur le portable...

51 Caractéristiques à tester du fait du scénario 51 Authentification par login au système Téléchargement de clients spécifiques sur un ordinateur portable Impression de l agenda de visites à domicile Cryptage et décryptage des enregistrements patient sur un terminal mobile

52 Tests de performance 52 Une part des tests de version peut consister à tester des propriétés émergentes du système telles que la performance, la fiabilité Les tests doivent refléter le profil d utilisation du système Les tests de performance doivent en général mettre en oeuvre une planification d une série de tests où la charge du système va être augmentée progressivement jusqu à ce qu elle devienne inacceptable par le système Le stress testing est une forme de test de performance où le système est délibérément surchargé pour tester son comportement en situation critique d échec

53 Tests Utilisateurs 53 Les tests utilisateurs ou clients sont une étape du processus de test au cours duquel les utilisateurs ou les clients fournissent des données ou des conseils pour le test du système Les tests utilisateurs sont essentiels même lorsque des tests système et de version ont été menés intensivement Les raisons pour cela sont que l environnement de travail de l utilisateur a une influence importante sur la fiabilité, la performance, l utilisabilité et la robustesse du système. Cela peut difficilement être simulé dans un environnement de test

54 Les divers types de tests utilisateurs 54 Alpha test Les utilisateurs du logiciel travaillent avec l équipe de développement pour tester le logiciel sur le site de développement Beta test Une version du système est mise à disposition des utilisateurs pour leur permettre de l expérimenter et de découvrir des problèmes qu ils transmettent aux développeurs Tests d acceptation Des clients testent le système pour décider si oui ou non il est prêt à être accepté et déployé dans l environnement client. Tests plutôt prévus pour les logiciels clients

55 Processus de test d acceptation 55 Critères de test Plan de test Tests Résultats des tests Rapport de test Définir les critères d acceptation Plan de Test d acceptation Génération des tests d acceptation Exécution des tests d acceptation Négociation des résultats des tests Système rejeté ou accepté

56 Méthodes agiles et tests d acceptation 56 Dans les méthodes agiles, l utilisateur/client fait partie de l équipe de développement et est responsable des décisions concernant l acceptabilité du système Les tests sont définis par l utilisateur/client et sont intégrés avec les autres tests pour être exécutés automatiquement lorsque des changements sont effectués Il n y a pas de processus de test d acceptation séparé Le problème principal est de savoir si l utilisateur membre de l équipe de développement est suffisamment représentatif de toutes les parties prenantes du système

57 A retenir 57 L activité de test peut seulement montrer la présence d erreurs dans un programme. Elle ne peut pas démontrer qu il n y a plus d erreurs résiduelles dans le programme Le test de développement relève de l équipe de développement. Une équipe indépendante devrait être responsable du test système avant d être mis à disposition des clients Le test de développement inclus le test unitaire, le test de composants (d intégration) et le test système (de recette)

58 A retenir 58 Quand on teste un logiciel, on doit essayer de le casser en utilisant son expérience pour choisir les types de cas de tests qui ont été efficaces pour détecter des erreurs dans de précédents logiciels Autant que possible il faut écrire des tests automatiques. Les tests sont alors embarqués dans le programme et sont exécutés chaque fois qu un changement est réalisé Le développement basé sur le test est une approche où les tests sont écrits avant le code Le test basé sur le scénario consiste à inventer un scénario d utilisation du système et en dériver les cas de tests Le test d acceptation est un processus de test par l utilisateur visant à décider si le logiciel est suffisamment bon pour être mis en utilisation dans son environnement opérationnel

59 59 FIN DE LA 6 ème PARTIE