UM2 - Master 2 Année 2012-2013 Sensibilisation aux Tests de Projets Informatique - Managed Testing - Le 21 février 2013 Thierry SINOT Directeur de Projet thierry.sinot@cgi.com 1 Groupe CGI inc. CONFIDENTIEL
Introduction TOAST Thème Objectif Animation Séquences & Timing 2
CGI en chiffres, cela donne... Nous sommes le 5 ème acteur mondial Nous servons plus de 10 000 clients Nous sommes présents dans 40 pays Nos 72 000 membres s engagent pour la réussite de leurs clients Nous avons 400 bureaux dans le monde Notre carnet de commandes s élève à 13G$ Notre présence couvre 86% des dépenses IT mondiales 85% de nos membres sont actionnaires de CGI Nos revenus doublent tous les 3 à 5 ans Nos revenus annuels s élèvent à 10G$ La satisfaction Client moyenne est de 9,1/10 Nous sommes propriétaires de 100 solutions exclusives 3
Métiers & Offres Finance Secteur Public Industrie Distribution Transport Consulting Télécoms Energie & Utilities B U S I N E S S Intégration de systèmes et solutions Outsourcing Training T R A N S F O R M A T I O N Offres fonctionnelles Offres sectorielles Offres technologiques 4
Introduction Tour de table Vos besoins / attentes? Vos difficultés rencontrées suite à vos projets industriels / stages? 5
Le cycle en V Intégration dans le cycle de vie du projet informatique Étude d Opportunité Déploiement Cahier des Charges MOA Recette Spécifications Fonctionnelles Spécifications Détaillées MOE Développement Tests unitaires Tests d intégration 6
Le cycle en V Intégration dans le cycle de vie du projet informatique 7
Emergence du mode Agile Intégration dans le cycle de vie du projet informatique Méthode Agile TMA CR Atelier SPEC SPEC OK Rédaction Spécification Lancement Analyse Fonctionnelle Analyse Technique CP A Tests d'intégration Validation Itération M CP D CP D Développement Test Unitaire D M CP D A A Nouvelle Itération Une itération est un mini-projet dans le projet. Elle consiste à : - analyser un besoin fonctionnel au périmètre clair avec les interlocuteurs métiers, - concevoir la solution, - réaliser les développements et tests unitaires, - réaliser les tests d intégration avec le métier, - valider le résultat avant de passer à l itération suivante. Cycle de développements courts, itératifs et incrémentaux. Pas le processus linéaire du cycle en «V», chaque cycle de développement est réalisé de façon autonome. Chaque cycle de développement porte sur la réalisation d une fonctionnalité bien délimitée, de la conception générale à l intégration de service. Points de visibilité fréquents, revue régulière des livrables avec le client. Démarche transparente et partagée. Grande flexibilité dans les prises de décision et les choix Pas d effet tunnel Meilleure convergence entre le besoin exprimé et la solution réalisée, tout en sécurisant le planning. SPEC OK SPEC OK SPEC OK D CP A Une itération dure au maximum 3 semaines. 8
Typologie des tests, concepts, def. Les différentes phases de test Tests Unitaires on élimine les erreurs de programmation L objectif est de détecter les écarts entre les spécifications détaillées d un composant, et ce qu il fait effectivement pris unitairement. Tests d intégration on élimine les erreurs d enchaînement L objectif est de détecter les écarts entre les spécifications de la demande ou du projet, et ce que fait effectivement la partie applicative concernée. On parle aussi de recette interne et parfois d homologation. Validation / recette on élimine les erreurs fonctionnelles L objectif est de détecter les défauts de l application du point de vue des utilisateurs. 9
Typologie des tests, concepts, def. Le périmètre de test Double run Exécution en parallèle sur ancien et nouveau système et comparaison des résultats 10
Typologie des tests, concepts, def. Le périmètre de test Test Unitaire base de données entrées composant résultats environnement 11
Typologie des tests, concepts, def. Le périmètre de test Tests d intégration base de données entrées Comp résultats Comp résultats 12
Typologie des tests, concepts, def. Le périmètre de test Validation / Recette base de données entrées applicatif résultats 13
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Approche globale : Tests de fonctionnement : Ils ont pour but de valider le bon fonctionnement des composants ou des parties applicatives concernées. Tests de non régression : Ils ont pour but de vérifier que les composants validés lors des tours précédents n ont pas subi de dégradation. 14
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Approche plus détaillée : Tests métiers ou fonctionnels (dits «boîtes noires»), tests structurels (dits «boîte blanche») tests d ergonomie, tests d interface, tests de performance, tests de volumétrie, tests de robustesse, tests de sécurité 15
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Approche «Boîte»: Test Boîte blanche (ou Test Structurel) Test Boîte noire (ou Test Fonctionnel) 16
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Les tests «boîte blanche» entrées résultats On cherche : Le code non testé par les tests fonctionnels. Le code mort. Les erreurs dans la gestion des conditions. Les erreurs dans la gestion des boucles. 17
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Les tests «boîte noire» On cherche les cas dans lesquels le composant produits des résultats non conformes entrées résultats Les résultats obtenus ne sont pas les résultats attendus. 18
Typologie des tests, concepts, def. Les différentes natures de tests, plusieurs approches Toutes ces natures de tests peuvent être mises en œuvre dans les différentes phases de tests unitaires, d intégration, de recette. 19
Pourquoi les TU Débat Des exemples : Coût annuel des bugs aux US ~ 60 milliards de dollars. 80% de temps de développement (mise en œuvre) serait consacré aux erreurs Fin 2004, en France 2 pannes géantes consécutives à des bugs (FT, Bouygues Telecom) Serveurs d accès moyens de paiement d un supermarché OUT un 24 décembre Des chiffres : 40% des incidents en production ont pour cause des erreurs qui auraient pu être évitées par une meilleure campagne de tests 60% des échecs sur les projets informatiques proviennent de faiblesses sur le recueil des besoins et leur analyse 90% des projets informatiques sont livrés en retard La loi du 1-10 100 Que faire pour éviter cette situation? Quels sont d après vous les impacts à ne pas faire de tests unitaires? 20
Pourquoi les TU L impact de T.U insuffisants Impacts Production Anomalies en T.I. et en recette client Perte de temps pour corriger, relivrer, retester les chaînes d intégration Impacts Finances Retard lors des T.I., risques sur la recette client Augmentation des retours, donc de la charge Génération de fiches d anomalies volume d information Dépassement des délais pouvant générer des pénalités Impacts Business Satisfaction du client. Risques pour la suite des relations client / projet. Baisse de l image «Qualité» véhiculée Impacts pour l ingénieur Image Rentabilité à titre individuel 21
Les processus de TU Synoptique global Analyste / Responsable des tests Développeur Autre développeur Responsable des normes Planifie et suit les TU Définit les conditions d'entrée en T.I. (stratégie) Valide la F.T.U Vérifie (les) et passe des TU Rédige la F.T.U Développe Passe les TU Effectue des TU croisés Effectue une revue de code Valide le développement 22
Les processus de TU Zoom sur les jeux d essai La problématique des jeux d essai est souvent passée sous silence. Mais comment tester sans jeu d essai? Existe-t-il des jeux d essai? Les jeux d essai disponibles sont-ils adaptés aux cas à tester? Qui fait les jeux d essai et qui les valide? Le client fournit-il des jeux d essai et sous quelle forme? Les jeux d essai sont-il directement exploitables ou faut-il les resaisir? Une charge a-t-elle été prévue pour constituer les jeux d essai? Les jeux d essai sont-ils partagés? Les jeux d essai sont-ils capitalisés? 23
Les processus de TU Zoom sur la non régression Vous avez oublié de tester la non régression, pourtant : Vous avez modifié plus de 10% du code! La technologie utilisée est connue comme capricieuse et des effets de bords sont à craindre! Le traitement modifié est super critique et tout dysfonctionnement peut générer un conflit sociale (ex: paie), un arrêt de la production (ex: process), un énorme manque à gagner (facturation / trésorerie)! Le programme modifié est ultra-complexe et toute modifications est susceptible d engendrer des dysfonctionnements! 24
Les stratégies de Tests Pourquoi une stratégie? La problématique d une opération de Recette fait apparaître des contraintes antagonistes qu il est nécessaire d optimiser : D une part, l objectif premier des tests fonctionnels est d obtenir une application «zéro défaut». Ceci oblige en théorie à effectuer ces tests de manière exhaustive, D autre part, pour garder une vision pragmatique des projets informatiques, la période de recette est généralement limitée dans le temps par des contraintes de délai très fortes et très souvent impératives. Il est également indispensable de minimiser les coûts de recette pour assurer un retour sur investissement acceptable. Le coût des tests doit donc toujours être mis en balance avec le coût des impacts d un dysfonctionnement éventuel (au niveau stratégique, métier et informatique). 25
Les stratégies de Tests Analyse de risques L analyse de risques permet d optimiser le nombre de cas à tester et contribue ainsi à la réduction des coûts. Dimensionner la couverture en fonction des risques et des exigences métier Elle est initialisée par classement des fonctions à tester en trois catégories, selon des critères objectifs (nombre d utilisateurs, % d utilisation des fonctions, produits, criticité,..) : Les fonctions et données stratégiques, Les fonctions et données très utilisées ou très courantes, Les fonctions et données annexes ou rares et non stratégiques. Dans la phase de réalisation des cas de test, le planning prend en compte l analyse de risques pour réaliser en priorité les cas de tests les plus stratégiques et respecter les délais impartis pour la recette. 26
Risques & Requirements (exigences Métiers) Analyser les Exigences Won t have Won t test Analyser Les risques Could have Could test Should have Should test Prioriser les Exigences En utilisant MoSCoW Must have Must test Determiner l impact des risques Spécifier les cas de test MoSCoW signifie «Must Test, Should Test, Could Test, Won t Test», «Must Test» signifiant la plus haute priorité de test et «Won t Test» la plus basse 27
Priorisation des risques produits il y a des conséquences financières pour nos clients. Tous les clients Un seul client Must test Should test Si le module contient une erreur il n y a pas de conséquence financière pour nos clients. il y a des conséquences financières en interne. Tous les clients Un seul client Pas de contournement Contournement Should test Could test Could test Won t test il n y a pas de conséquence financière en interne. Pas de contournement Contournement Could test Won t test 28
Les stratégies de Tests Multi - Campagnes de tests La méthode repose sur une stratégie de tests en campagnes, garantissant la fiabilité maximale de l application qualifiée. Une campagne de tests consiste à exécuter un ensemble de cas de tests sur un périmètre donné, en nombre décroissant au fur et à mesure des campagnes. La couverture des cas de tests exécutées lors des campagnes varie en fonction des domaines concernés. Elle dépend de l optimisation coût / qualité recherchée. La 1ère campagne de tests détecte le maximum d anomalies en exécutant 100% des cas de tests La 2nde campagne permettra d identifier les anomalies résiduelles et de valider la correction des anomalies détectées lors de la première campagne en exécutant au moins 75% des cas de tests La 3ème campagne est une phase de validation globale lors de laquelle au moins 50% des cas de tests sont exécutés 29
Les principales stratégies de tests unitaires Approche technique Objectif : Mettre en place une solution rapide et peu coûteuse pour industrialiser les tests unitaires et homogénéiser le niveau de couverture Solution : Check liste Points de contrôles systématiques Adaptation à la technologie et au contexte d exécution Prise en compte des principaux choix d implémentation : une fonctionnalité codée de manière centralisée pour tous les cas d utilisation pourrait n être testée qu une seule fois Sans oublier l état de l art et les tests aux limites Exemples de fiche de tests unitaires: @Fichtu... 30
Les principales stratégies de tests unitaires Exemple de checklist IHM 31
Les principales stratégies de tests unitaires Approche fonctionnelle Objectif : Vérifier la bonne implémentation de règles de gestion précises et éventuellement complexes Solution : Scénario de tests Liste des cas à tester sur la base des spécifications, maquettes et autres règles métier Niveau de détail variable (cas de test ou jeux d essai complet) Niveau de couverture variable Exemple de fiche de scénario de test : Fiche Scénario de Tests Exemple de journal de tests : Journal de tests 32
Les principales stratégies de tests unitaires Approche «outillage» Objectif : Sur des architectures complexes (ex: n-tiers) Réduire les coûts de développement des outils complémentaires utiles au test de couches intermédiaires Face à des applications très critiques Améliorer la qualité par une analyse objective de la couverture des tests Réduire le risque de régression sans allonger les délais, en facilitant la «rejouabilité» des tests. Identifier les parties à optimiser en priorité Etc Solution : Outillage Développements spécifiques ou produits du marché Exemples Développement des tests avec JUnit sur J2EE/NUnit sur.net Analyse de couverture avec Ncover ou CoverageEye 33
Les principales stratégies de tests unitaires Approche «performance» Objectif : S assurer du niveau de performance requis Solutions Utiliser des jeux d essai représentatifs en volume Identifier les points critiques grâce éventuellement à des outils de profiling Utiliser des outils de stress (ex: JMeter, Load Runner ) 34
Les principales stratégies de tests unitaires Ce qu il faut retenir Pas de solution idéale généralisable Chaque approche à elle seule est insuffisante La stratégie de test doit être construite spécifiquement pour chaque projet en fonction des objectifs et des moyens L utilisation de check listes complétées par quelques cas de test bien choisis offre globalement de bons résultats Pragmatisme et souplesse sont de rigueur : Dimensionner la couverture par rapport au risque Garder à l esprit que le coût d un dysfonctionnement augmente de manière exponentielle plus nous avançons dans le projet Penser aux revues de code 0 défaut comme à NASA est illusoire avec nos ratios habituels L automatisation complète des tests est coûteuse, penser à la rentabilité En optimisant 90% du code n utilisant que 10% du temps CPU on ne gagne pas grand chose. Mieux vaux axer ses efforts sur les 10% restant occupant 90% du temps CPU. 35
Les outils Aujourd hui Dans une démarche d industrialisation et de gain de productivité, la mise en œuvre d un outil quelconque est fortement recommandée, voir indispensable. 36
Les outils Aujourd hui Les NTI sont favorisées Nombreux outils gratuits et autres open source disponibles Outils avec coût de licence élevé pour les technologies classiques. 37
Les outils Automatisation des tests Permet d enchaîner des tâches très diverses (ex : copie de fichiers, compilation, appel d un exécutable quelconque..) à travers un simple fichier de paramétrage. Permet de simuler les actions d un utilisateur sur un navigateur. Permet d automatiser des scénarios très complexes dès lors que tout se passe via une interface web (cas le + simple). Gain très important en terme de temps de re-jeu des scénarios. Un scénario très complexe prend le temps d un simple clic pour le rejouer, alors qu il peut durer très longtemps via un utilisateur. Fiabilité des tests. Le facteur humain est exclus. Pas interprétation ou raccourci dans le test du fait de l habitude ou la connaissance du test à cause de re-jeux successifs. Permet de générer des rapports complets. Contrepartie : investissement non négligeable au départ afin de connaître l outil, et réaliser les premières captures. NUnit sur.net, JUnit sur J2EE (Java), Nant QuickTestPro (HP), Software Architect (IBM Rational) 38
Les outils SUIVI DES CAMPAGNES DE TESTS Définition des scénarii de tests Définition des campagnes de tests Permet de fournir des statistiques (avancement, qualité, nb itérations) Chaque développeur à un accès personnalisé TestDirector (HP), TestLink (opensource) 39
Les outils ANALYSEUR DE CODE EXECUTE Analyse l éxécution du code en runtime et enregistre les statistiques sur les lignes de code exécutées Il montre chaque séquence d exécution ainsi que le nombre de fois où la séquence a été exécutée. Mise en évidence des parties de code non éprouvées : Le programmeur peut ainsi plus facilement compléter ces tests pour en améliorer la couverture. Identification des parties de code les plus souvent exécutées : Il est plus facile de cibler les parties à optimiser en cas de problème de performance. Identification du code mort ou obsolète NCover (OpenS.Net), CoverageEye (Microsoft.Net), OptimizeIt Borland) 40
Les outils REVUE DE CODE, RESPECT DES NORMES Ces outils permettent de déterminer : le code non utilisé (code mort), le code dupliqué, Les Blocs vides, trouver Variables non utilisés. Certains outils permettent un paramétrage afin de proposer aux développeurs la vérification des règles maison. Là aussi les outils permettent d automatiser, de contrôler et de générer des rapports. Laisser les tâches fastidieuses et répétitives à la machine. Les gains en terme de qualité de code et de respect des règles est très important. Contrepartie : investissement de paramétrage de l outil et des règles maison Jtest (Java J2EE Parasoft), CheckStyle (OpenS), Software Architect (IBM Rational), PMD 41
Les outils MONTEE EN CHARGE - STRESS L objectif est de vérifier les performances d une architecture logicielle. Simulation la plus proche possible de la réalité, ainsi l'application est sollicitée par un grand nombre d'utilisateurs virtuels simultanés. Appliquer une telle charge à l'application permet de déceler d'éventuels problèmes de performances ou de stabilité et d'y remédier pour pouvoir atteindre le comportement souhaité. LoadRunner (HP), JMeter, OpenSTA (OpenS), 42
Les outils Demain Utilisation systématique d automates de tests fonctionnels de non régression Mise en place de cellules dédiées à l automatisation des tests Condition impérative pour des gains de productivités significatifs en maintenance 43
PIC : La plateforme d intégration continue La PIC est un dispositif associant une pratique de développement et une plateforme logicielle dans une démarche qualité destinée à garantir la qualité du code source d une application Objectifs de la PIC Éliminer les sessions intensives de débogage. Détecter les problèmes généralement le jour même où ils ont été introduits La qualification de la cause en est facilité L impact en est limité Obtenir un code de qualité pour une application facilement maintenable et évolutive. 44
Etudes L'étude PAC montre un marché français du test en plein boom Selon la dernière étude Pierre Audoin Consultants*, l'essor des activités de tests et d'assurance qualité informatique en France va se poursuivre. Les volumes des projets confiés à la sous-traitance devraient ainsi augmenter de 12,4 % par an en moyenne, au moins jusqu'en 2012. Pourquoi une telle lame de fond? Les entreprises ont pris conscience des gains liés à des pratiques de test optimisées, notamment pour réduire les délais de lancement de nouvelles offres. Quatre principaux secteurs sont concernés administration, industrie, finance assurance, télécoms ce dernier étant le plus dynamique. En termes de prestation, les contrats au forfait (+ 16 %) devraient prendre le pas sur l'assistance technique en régie (+ 7 %), dénotant une maturité et une capacité d'engagement plus forte des acteurs. * Décembre 2010 http://www.zdnet.fr/blogs/codes-et-modeles/les-tests-enfin-a-leur-place-dans-le-processusde-developpement-39713107.htm#xtor=rss-1 Article 01 HEBDO Métier Testeur 45
Les TMC Préambule Que sont les TMCs Ils simulent la charge induite par plusieurs utilisateurs simultanés sur une application. Ils permettent de vérifier les performances d une application dans son cadre de production avant son déploiement Il permet de suivre l évolution des performances d une application sur toute la durée de celle-ci. Projets nécessitant des TMC. Nouveau projet utilisé par de nombreux utilisateurs simultanés au sein d un système d information. Nouvelle version de projet pour vérifier la non dégradation des performances. Évolution technique importante du projet, nouvelle version de progiciel, etc pour vérifier les gains de performance annoncées par l éditeur. Déroulement des TMC Rédaction des spécifications de TMC Installation de l application sur une plate forme dédiée. Déroulement itératif des tests. Rédaction des résultats. 46
Les TMC Cycle de projet avec TMC Les TMC s insère dans le cycle normal d un projet en parallèle des tests d intégration. Développement Test Unitaire Test d intégration Test de montée en charge Livraison Les tests de montée en charge débutent après la validation de l ensemble des TU du projet. La livraison du projet est conditionnée par les tests d intégration et les test de montées en charge. 47
Les TMC Déroulement 1/2 Les TMC comme les test d intégration impliquent plusieurs équipes L équipe en charge fonctionnellement de l application doit : Rédiger les tests fonctionnel retenues pour les TMCs. Ces test doivent représenter les cas d utilisations les plus représentatif de l application ou certaines fonctions lourdes. Répartir et estimer l utilisation de ces cas d utilisation sur la population utilisatrice estimée en production de l application. Assister l équipe de TMC lors de l enregistrements des scripts. L équipe de développement de l application doit : Fournir les livrables applicatifs à l équipe tmc. Installer ou assister l équipe TMC pour l installation de l application sur la plate forme TMC. Assister l équipe de TMC si des problèmes bloquant ou des améliorations de performances sont diagnostiqués par l équipe projet. L équipe de TMC doit Vérifier l installation correcte de l application. Écrire les scripts correspondants aux cas d utilisation fourni par l équipe fonctionnelle. Réaliser les tirs de charge. Analyser les résultats et proposer des pistes d optimisations. Rédiger un rapport des performances de l application Temps de réponse individuel Charges machines Indicateurs personalisés selon le projet. Des réunions de coordinations hebdomadaires doivent être prévues pour la synchronisation. 48
Les TMC Déroulement 2/2 Estimation de la population et rédaction des cas fonctionnels Installation de l application Pré requis Test de validation de la plate-forme Écriture des scripts et scénarios de cas de test Réalisation des tirs de tests Analyse rapide et propositions d optimisations Écriture du rapport de performance T e m p s Suivie des tirs et acceptations des éventuelles propositions d optimisation pour re-test. Réalisation Rédaction des livrables Équipe TMC Équipe projet 49
Les TMC Comment ca marche? Le logiciel de test en charge simule les utilisateurs virtuels à l aides des scripts écrits afin de produire une activités réaliste pour le système. En parallèle l outils récupère des indicateurs sur l état du système et les agrège pour pouvoir réaliser facilement des études statistiques ultérieures. 50
Les TMC Outils? L enregistrement des scripts et l exécution des TMC nécessitent des outils spécifiques Les outils payant les plus connus sont : HP loadrunner Néotis Neolad Borland SkillPerformer Les outils open source les plus connus Jmeter OpenSTA Les outils payant permettent plus de libertés et une variabilisation du script. Il est aussi possible d acquérir des plugins pour étendre leur champs d activité ou de monitoring. (J2EE, oracle, etc ) Les achats sont généralement sous forme de licence incluant un nombre de Virtual user maximum simulable. 51
Conclusion 3 minutes pour déterminer 3 idées fortes retenues lors de ce cours 52