Livrable L1.1: Guide méthodologique de l'industrialisation et référentiel de bonnes pratiques. Version 1

Emetteur : SDE Date de révision : 07/02/09 Livrable L1.1: Guide méthodologique de l'industrialisation et référentiel de bonnes pratiques APPROBATION DU DOCUMENT Version 1 Nom Date Signature Rédacteur S. Debricon 05/01/09 Vérificateur B. Legeard 07/02/09 Approbateur P.Y. Muhlebach DIFFUSION DU DOCUMENT Liste de diffusion Nom Organisation Pour action Pour information M. Pawlak CTI / DTD P.Y. Muehlbach CLIO B. Legeard Smartesting F. Bouquet UFC / LIFC S. Debricon UFC / LIFC HISTORIQUE DES MODIFICATIONS Référence Date Modifications V 1.0 05/01/09 Création du document 1

Table des matières Table des matières... 2 Figures... 4 Tableaux... 3 Introduction... 5 1 Les exigences... 10 1.1 Des exigences métiers aux exigences de test... 10 1.1.1 Définir le concept d exigence... 10 1.1.2 Différents types d exigence... 10 1.2 Traçabilité entre les exigences et les cas de tests... 11 1.2.1 Génération des tests et traçabilité des exigences... 13 1.2.2 Bonnes pratiques et préconisations... 14 2 Définition de la stratégie de test fonctionnel... 17 2.1 Positionnement de la stratégie de test... 17 2.1.1 Stratégie de test et politique qualité... 17 2.1.2 Niveaux stratégiques, tactiques et opérationnels de la stratégie de test... 17 2.1.3 Structuration du plan de test... 18 2.2 Stratégie de test dirigée par les risques... 20 3 Les outils de test logiciel... 23 3.1 Notion de Processus outillé... 23 3.1.1 Pourquoi un processus outillé... 23 3.2 Un outil pivot : le gestionnaire du référentiel de tests... 25 3.2.1 Intégration ou coopération d outils... 28 3.2.2 L outillage de test doit s inscrire dans une politique globale de l entreprise... 29 3.3 Le générateur de tests... 29 3.3.1 Principes de la génération de tests... 30 3.3.2 Les fonctions d un outil de génération de tests... 32 3.3.3 Les générateurs de tests sur le marché... 33 3.3.4 Apports de la génération de tests... 34 3.4 L automate de test... 35 3.4.1 L'automatisation des tests sur IHM... 35 3.4.2 Les outils d automatisation des tests sur IHM... 36 4 Production du référentiel de tests... 38 4.1 Techniques de conception de tests... 38 4.1.1 Principes du test boîte-noire... 38 4.1.2 Test logique / Test physique... 38 4.1.3 Techniques basées sur le partitionnement par classe d équivalence... 40 4.1.4 Combinaison de valeurs... 42 4.1.5 Un cas de test est en général constitué d une séquence d actions et de vérifications sur l application... 43 4.2 Génération automatique de tests à partir de modèle... 44 4.2.1 Principes de la génération de tests... 44 4.2.2 Modélisation pour la génération de tests... 46 4.2.3 Données de test... 50 4.2.4 Génération automatique des tests... 52 4.2.5 Publication des tests dans le référentiel... 54 4.2.6 Génération des scripts de test... 56 2

En conclusion : Mutation du test fonctionnel - De la planche à dessin à la CAO tridimensionnelle... 57 Tableaux Tableau 1-1: Eléments principaux participants à la définition des exigences applicatives... 11 Tableau 1-2: Situation vis-à-vis de l expression des exigences et préconisation... 16 Tableau 2-1: Tableau croisé des niveaux de risque (d après TMap Next)... 22 Tableau 2-2: Croisement des fonctionnalités / objectifs de test avec le niveau risque associé.... 22 Tableau 4-1: Table de décision... 43 3

Figures Figure 0-1: Le cycle de la qualification fonctionnelle en lien avec les besoins métiers... 7 Figure 0-2: Les outils de l industrialisation de la qualification fonctionnelle... 8 Figure 1-1: Lien entre le référentiel des exigences et le référentiel des tests... 11 Figure 1-2: Construction du référentiel des exigences par l expert métier ou à partir de documents de spécifications en Word... 13 Figure 1-3: Traçabilité à partir d un référentiel des exigences (source Smartesting)... 14 Figure 2-1: Niveaux de la stratégie de test... 18 Figure 2-2: Etapes du pilotage du test par les risques... 21 Figure 3-1: Schéma du processus outillé de test fonctionnel... 24 Figure 3-2: Rôles utilisateur du référentiel de tests... 26 Figure 3-3: Interface de HP Quality Center 9.2... 28 Figure 3-4: Relation entre les artefacts... 29 Figure 3-5: Continuité de la chaîne outillée du test fonctionnel... 30 Figure 3-6: Exemple de diagramme de classes d un modèle de test d une application de gestion de vols... 31 Figure 3-7: Exemple de diagramme d états d un modèle de test d une application de gestion de vols... 31 Figure 3-8: Exemple de diagramme d états d un modèle de test d une application de gestion de vols... 32 Figure 3-9: Exemple de diagramme d objets d un modèle de test d une application de gestion de vols... 32 Figure 4-1: L approche du test boite-noire... 38 Figure 4-2: Méta-modèle des cas de tests logique / physique... 40 Figure 4-3: Classes d équivalence pour la règle métier «Tarification des ordres de bourse» 41 Figure 4-4: Valeurs aux bornes pour la règle métier «Tarification des ordres de bourse»... 42 Figure 4-5: Structure d un cas de test... 44 Figure 4-6: Positionnement de la génération de tests... 45 Figure 4-7: Intervenants dans la production et l exploitation du référentiel de tests... 46 Figure 4-8: Types de diagrammes UML utilisés pour la génération de tests... 47 Figure 4-9: ecinema Modèle de test Diagramme de classes... 48 Figure 4-10: ecinema Modèle de test Diagramme d énumérations... 48 Figure 4-11: ecinema Modèle de test Diagramme d états... 49 Figure 4-12: ecinema Modèle de test Définition OCL de l opération «login»... 50 Figure 4-13: ecinema Modèle de test Définition des données «utilisateurs»... 51 Figure 4-14: ecinema Modèle de test Définition des données «séances disponibles»... 51 Figure 4-15: ecinema Modèle de test Définition des données «tickets disponibles»... 51 Figure 4-16: ecinema Gestion des données Association entre données logique et données concrètes... 52 Figure 4-17: ecinema Génération de tests Interface de Smartesting Test Designer 3.3... 53 Figure 4-18: ecinema Génération de tests Détail d un test... 54 Figure 4-19: ecinema Publication des tests Vue Test Plan de HP Quality Center... 55 Figure 4-20: ecinema Modèle de tests Description de l opération «login» au niveau du modèle de test... 56 Figure 4-21: ecinema Modèle de tests Script du test «deletealltickets»... 57 Les figures utilisées dans ce document sont issues du livre "Industrialiser le test logiciel" 4

Introduction Ce document constitue le livrable 1.1 du projet TEST_INDUS. Il s'agit d'un guide méthodologique de l'industrialisation des tests et un référentiel des bonnes pratiques de mise en œuvre. L'objectif de ce document est de fournir un point de départ pour la mise en place d'une stratégie outillée de tests fonctionnels efficace. Certaines parties de ce document sont extraites du livre intitulé "Industrialiser le test fonctionnel", à paraitre chez Dunod. et rédigé par des membres du projet TEST_INDUS (Fabrice Bouquet Université de Franche-Comté, Bruno Legeard Smartesting). L'ensemble des participants du projet TEST_INDUS ont également contribué à la rédaction de ce document. L industrialisation de la qualification fonctionnelle constitue un enjeu essentiel pour la maîtrise de la qualité et des coûts des développements logiciels que ce soit dans le domaine des progiciels de gestion intégrés (customisation, migration) ou pour les applications spécifiques. Les principaux points d appui (les piliers) de cette industrialisation sont maintenant connus et permettent de définir les clés du succès en la matière : 1. Définir un budget pour la qualification fonctionnelle applicative. La qualification fonctionnelle applicative doit être budgétée en tant que telle et faire l objet d un suivi en phase avec la gestion du projet. Ce budget va garantir la réalisation des activités de qualification fonctionnelle indépendamment des aléas du développement de l application. L estimation d un projet de test est toujours une activité difficile. Mais, elle peut s appuyer aujourd hui sur des méthodes analytiques qui permettent, en lien avec un suivi des projets et des métriques, une fiabilité de ces estimations. 2. S appuyer sur une équipe spécialisée dans le test. Le test est une activité dont l efficacité passe par la mise en place de processus outillés permettant de garantir à la fois la qualité des tests (en termes de détection d anomalies) et d assurer une bonne productivité de la production des tests. L industrialisation des tâches de qualification conduit ainsi à préciser les différentes fonctions et rôles qui doivent être réunis dans le cadre d un projet, depuis les analystes jusqu aux administrateurs, en passant par les chefs de projet, les consultants et, dans le domaine du support, les responsables méthodes et outils. Les compétences seront structurées au sein d une équipe de test, dont la transversalité dépendra de l organisation de l entreprise. Un tel centre de test peut être constitué en interne, s appuyer sur un dispositif de sous-traitance, par exemple une Tierce Recette applicative. L important est que la recette s appuie sur une équipe spécialisée, formée aux outils et maîtrisant les savoir-faire spécifiques des activités de test. 3. Démarrer les activités de recette dès le début du projet. Une erreur courante consiste à positionner l ensemble des activités de recette fonctionnelle applicative en fin de projet : lorsque le projet est en retard et qu il est urgent de livrer. La bonne solution consiste à commencer la production des tests dès les phases de spécification terminées, voire encore en amont avec les aspects stratégie de test et identification des exigences. Pour cela, l approche par génération automatique des tests est un outil puissant car la génération automatique s appuie sur un modèle de test qui est élaboré en parallèle des développements, permettant une production du référentiel de tests en 5

phase avec les livraisons prévues. Ce modèle de test permet aussi de détecter au plus tôt les ambiguïtés ou les contradictions au sein de spécifications, permettant un bénéfice immédiat pour le projet grâce à leur consolidation. 4. Piloter la production des tests à partir des exigences métiers et prenant en compte le niveau de risque applicatif. Définir les exigences fonctionnelles et qualifier sur la base de ces exigences permet d assurer l alignement entre l application informatique et les besoins métiers. Ainsi, les tests de qualification fonctionnelle doivent être élaborés à partir des exigences métiers et montrer la couverture (matrice de traçabilité bidirectionnelle des exigences vers les tests). Il s agit d assurer le pilotage des activités de test par les enjeux métiers. Ces exigences doivent être qualifiées en termes de niveau de criticité pour permettre un pilotage du test par les risques. 5. Automatiser l exécution des tests dans un objectif de test de non-régression et maîtriser cette automatisation. L exécution uniquement manuelle des tests ne peut permettre d assurer ni la qualité de la recette (trop incertain dans sa mise en œuvre), ni le time-to-market (trop long dans sa mise en œuvre lors des tests de non régression), ni la maîtrise des coûts (trop cher du fait de la répétition). A partir de 3 ou 4 livraisons prévues de l application, et donc de mises à jour fonctionnelles ou techniques, il est pertinent de passer à l automatisation des tests pour permettre de tester suffisamment et de traiter les problèmes potentiels de régression. Mais l automatisation doit être maitrisée, en particulier en utilisant des techniques de génération automatique des tests automatisés qui structurent la production des scripts en s appuyant sur des mots clés et facilitent la maintenance. L automatisation peut aussi être freinée par des problèmes de testabilité de l application : ainsi les automates de tests peuvent être difficiles à mettre en œuvre sur des parties graphiques ou sur des outils de développement peu ou mal supportés. L automatisation devra donc être maîtrisée pour trouver son efficacité (rapport effort/bénéfice) maximum. 6. Mettre en place des métriques et un tableau de bord de suivi des résultats des activités de qualification logicielle. Il s agit de mettre en place les indicateurs et leur suivi qui permettent d évaluer la qualité des applications lors de leur réalisation, de leur utilisation et à l occasion de leurs évolutions. Pour partie, ces indicateurs sont directement issus des activités de qualification fonctionnelle (en termes de couverture et de suivi d anomalies en particulier). Ces indicateurs permettent de suivre l évolution dans le temps des indicateurs de qualité mais aussi participent à la maitrise des schémas de sous-traitance. La qualification fonctionnelle peut ainsi être vue comme partie intégrante du système d information de la gouvernance des applications informatiques. 7. Appuyer la transition vers la mise en exploitation par la qualification fonctionnelle et mettre en place un processus continu de qualification. La transition des phases de développement vers la mise en exploitation constitue une étape cruciale du projet, où se produisent de nombreux échecs. Une bonne pratique consiste à faire courir la phase de qualification logicielle sur les premières étapes de la mise en exploitation de façon à assurer une continuité des phases de tests et des premières exploitations terrain. Il s agit de procéder à la mise en place d un processus continu de qualification. Les équipes qui ont pris en charge la qualification fonctionnelle seront ainsi à même d apporter leur expertise aux premières phases de mise en exploitation, et d assurer une continuité de service dans la prise de maturité de l applicatif. C est aussi un moyen d engager profondément la responsabilité de l équipe de test qui doit garantir, non seulement la phase de recette et la couverture des 6

exigences fonctionnelles, mais aussi faire le lien entre le référentiel de test et les retours du terrain. Ces sept piliers de la sagesse pour les activités de recette fonctionnelle sont au cœur des démarches réussies en matière d assurance de la qualité du logiciel. Ils correspondent aux enjeux clés des organisations IT amenées à gérer l aversion des bugs des utilisateurs, la complexité croissante des applicatifs et la globalisation des démarches de développement. Nous proposons de capturer ces éléments clés dans le processus outillé présenté dans cette partie : depuis l expression des exigences fonctionnelles jusqu'à la mise en œuvre des tests automatisés et le suivi des indicateurs de qualité. La Figure 0-1 fournis un schéma de la qualification fonctionnelle et de sa relation avec les besoins métiers. Figure 0-1: Le cycle de la qualification fonctionnelle en lien avec les besoins métiers Ce schéma montre plusieurs aspects importants du processus de la qualification fonctionnelle tel que proposé dans ce livre : Les besoins métiers constituent le point d entrée de la qualification. Leur qualité est cruciale pour tout le processus ; nous présentons en chapitre 1 les bonnes pratiques pour développer des spécifications et exigences fonctionnelles exploitables pour la phase de qualification. Le cycle de qualification est en lui-même un processus itératif et incrémental. Les étapes de production des tests, d exécution des tests et d analyse/suivi des anomalies s enchainent au fil 7

des différentes phases de tests successives et jusqu'à l obtention de la couverture et du niveau de qualité requis. La gestion de la production des tests dirigée par les exigences fonctionnelles garantit un bon suivi et une terminaison claire du processus. Ce processus s appuie sur une chaine d outils, tel que montré par la Figure 0-2. Figure 0-2: Les outils de l industrialisation de la qualification fonctionnelle Les outils standards du cycle de qualification fonctionnelle sont de cinq ordres : La gestion des exigences fonctionnelles une bonne définition des exigences est essentielle pour la qualification; La génération des tests la génération automatique de tests permet de réduire les coûts de production et de maintenance du référentiel de tests ; La gestion du référentiel de tests, des campagnes de test et des anomalies il s agit d un outil clé de l industrialisation des tests qui permet une bonne gestion du référentiel de tests et des résultats associés à l exécution; L automatisation de l exécution des tests permet de gérer correctement les risques liés aux régressions fonctionnelles lors des corrections d anomalies et des évolutions. La gestion des données de test et la production des bases de recette constituent un élément important de la phase de qualification. Ces outils s appuient aussi sur une infrastructure qui permet l accès à l application et les services de base du poste de travail. Ce processus outillé doit être au service d une stratégie de test qui constitue le schéma directeur du processus de test. La suite de ce livrable s'organise de la façon suivante: Le chapitre 1 traite de la liaison entre les référentiels d exigences fonctionnelles associés à un projet applicatif, et le référentiel de tests qui vise à assurer la conformité de l application à ses spécifications. Il s agit aussi de préciser les concepts principaux de la gestion des exigences, de leur structuration, de leur traçabilité vers les tests, ainsi que de lister des bonnes pratiques de formalisation des exigences dans une perspective de test. 8

Le chapitre 2 aborde la définition de la stratégie de test pour un projet donné. La stratégie de test s inscrit dans la politique qualité globale définie pour l application et s incarne au travers d un Plan de test. Nous proposons un sommaire type pour le plan de test, puis développons une approche dirigée par les risques, c'est-à-dire permettant de gérer les efforts de test fonctionnel en fonction des risques identifiés au sein de l application sous test. Le chapitre 3 présente une vision globale du processus outillé, puis détaille chaque catégorie d outil utilisée dans cette chaîne. Il fait également référence au livrable 4.2 du projet. Le chapitre 4 introduit les méthodes et techniques de construction du référentiel de tests fonctionnels. Nous présentons d'abord les concepts principaux de la conception de tests fonctionnels. Nous décrivons ensuite la démarche de génération de tests à partir d un modèle de tests. 9

1 Les exigences 1.1 Des exigences métiers aux exigences de test 1.1.1 Définir le concept d exigence La notion d exigence provient en fait d une traduction du mot «Requirements» issu du vocabulaire anglo-saxon dans le domaine. Ce mot «Requirements» est définit par Sommerville et Sawyer [Somm1997] «comme l expression de ce qui doit être implémenté dans l application considérée. Il s agit d une description du comportement attendu de l application, de ses propriétés et attributs, ou des contraintes qu elle doit respecter. Cela peut aussi recouvrir le processus de développement applicatif.». La terminologie française dans le domaine utilise le mot «spécifications» pour traduire ce même concept. Dans le vocabulaire utilisé dans ce document, «exigences» et «spécifications» seront donc considérés comme identique. L intérêt d utiliser le mot «exigence» est de mettre l accent sur le caractère atomique de l élément de spécification considéré, et donc permettant une traçabilité au sein du processus de développement, en particulier vis-à-vis des tests. 1.1.2 Différents types d exigence Comme le montre la définition de Sommerville et Sawyer, la notion d exigence recouvre un ensemble varié d informations décrivant ce que nous devrons obtenir à l issue du développement applicatif. Par exemple la «description du comportement attendu de l application» correspond aux exigences fonctionnelles, alors que «les contraintes que doit respecter l application» correspond à des exigences non-fonctionnelles (par exemple de qualité, de performance, ). D autres types d exigences peuvent recouvrir des propriétés nécessaires de l application, par exemple des propriétés de sécurité (contrôle d accès, authentification, confidentialité, intégrité). Enfin, les choix technologiques de la plate-forme de développement, d interopérabilité ou de support de certains systèmes d exploitation ou de l explorateur Internet, constituent un autre type d exigence. Cet ensemble d informations est listé dans le Tableau 1-1. Nature Type Description Fonctionnel Cas d utilisation Les cas d'utilisation sont utilisés pour représenter les différentes interactions entre un utilisateur (humain ou machine) et un système au travers de différents scénarios. Ils peuvent être représentés sous la forme de Diagramme de Cas d Utilisation en UML. Fonctionnel et non-fonctionnel Règles métiers (ou règles de gestion) Les règles métiers définissent des exigences comportementales, des standards métiers ou des règles internes à l entreprise que doit respecter l application. Ces règles constituent des éléments clés de la traçabilité du référentiel de test vers le référentiel des exigences. Non-Fonctionnel Critères qualité Les critères qualité expriment des contraintes sur l application en termes d utilisabilité, de performances, de disponibilité, de maturité et 10

Non-fonctionnel Exigences d interface de portabilité en particulier. Ces critères sont en général hors du champ du test fonctionnel. Ce type d exigences recouvrent d une part les exigences de type Interface Homme /Machine, et l ensemble des interfaces avec les systèmes tiers. Tableau 1-1: Eléments principaux participants à la définition des exigences applicatives Dans ce document, nous nous intéressons plus particulièrement aux exigences fonctionnelles, c'est-à-dire aux cas d utilisation et aux règles de gestion, pour lesquels le test fonctionnel devra assurer que l application à tester est conforme. Le référentiel de tests devra donc assurer la couverture de ces exigences, et montrer que chaque exigence est testée suivant une stratégie de test définie au préalable. 1.2 Traçabilité entre les exigences et les cas de tests Les exigences fonctionnelles, les cas d utilisation, les règles métiers, et d une manière générale l ensemble des éléments de description fonctionnelle de l application sous test, constituent le point de départ du processus de production du référentiel de tests. Figure 1-1: Lien entre le référentiel des exigences et le référentiel des tests Comme le montre la Figure 1-1, les relations entre les référentiels des exigences et le référentiel des tests sont d une part la production des tests, et d autre part la traçabilité bidirectionnelle 1 des exigences. Dans cette vision, le référentiel des exigences fonctionnelles est considéré comme préexistant au démarrage du projet de test. Ce référentiel des exigences fonctionnelles (appelé aussi référentiel métier) est sous la responsabilité des experts métiers (business analyst par exemple), de la même façon que le référentiel des tests est sous la responsabilité des architectes de test. Autant le référentiel des tests possède une structure bien définie, gérée en général par des outils de gestion des tests tels que HP Quality Center ou IBM Rational Quality Manager, autant le référentiel des exigences fonctionnelles prend dans la pratique des applications IT de formes très variées. Les quatre situations différentes de formalisation du référentiel des exigences qui peuvent être rencontrées sont les suivantes: 1 On appelle «Traçabilité bidirectionnelle» la capacité à suivre le lien entre deux artefacts du processus de développement logiciel en relation l un avec l autre. Dans notre cas, cela concerne la gestion du double lien : exigences vers tests et tests vers exigences. 11

Situation 1 - L absence totale de référentiel des exigences fonctionnelles sans aucune spécification, le référentiel métier est incarné dans ce cas directement et uniquement par l expert métier. C est évidement une situation qui rend difficile la traçabilité bidirectionnelle, et qui conduit à introduire des éléments de formalisation d exigences (voir cas suivants) si l on souhaite réaliser cette traçabilité. Situation 2 - Le référentiel fonctionnel est constitué de documents et matériels disparates c est une situation très courante en pratique sur les projets IT actuels, où coexistent différents matériels tels que des spécifications fonctionnelles générales et détaillées, des cas d utilisation, des exigences fonctionnelles non formalisées et éventuellement la description de processus métiers. Ce matériel constitue le point de départ du processus de production du référentiel des tests, et la traçabilité des exigences vers les cas de test est réalisée à partir d éléments référençables extraits de cet ensemble. Dans ce cas, nous préconisons un travail préliminaire à la production des tests, qui consiste à extraire de manière atomique les exigences à tester puis les faire valider par le métier. Les outils de gestion des référentiels de tests (voir chapitre 3) permettent pour la plupart cette étape. Les ambiguïtés de spécifications alors découvertes sont levées par l expert métier qui précise et actualise le référentiel fonctionnel. Situation 3 - Les exigences fonctionnelles sont explicitées, sans être gérées par un outil spécialisé - dans cette situation, un effort de formalisation des exigences fonctionnelles applicatives a été réalisé, permettant leur traçabilité bidirectionnelle avec les cas de tests, et en particulier leur référencement au sein du référentiel des tests. Le support de ce référentiel est typiquement sous forme de tableaux (type Excel) accompagné de documents textuels. L inconvénient principal de ce niveau de gestion provient du caractère manuel du suivi du changement pour ces exigences. Situation 4 Les exigences fonctionnelles sont explicitées et gérées dans un outil de gestion d exigences spécialisé dans cette situation, l effort de formalisation des exigences est supporté par des outils spécialisés, tels que Borland CaliberRM, IBM RequisitePro, Serena Dimension RM, Compuware Optimal Trace,. Ces outils facilitent le référencement des exigences et la gestion de leur évolution dans le temps et ils comportent en général des passerelles natives permettant d exporter un extrait des exigences métiers (les exigences à tester) vers les référentiels de tests. En termes de traçabilité des exigences, les situations 1 et 2 ne permettent pas la traçabilité, du fait de l absence du référentiel des exigences (situation 1), ou parce que son niveau de formalisation empêche un référencement explicite (absence d identifiants d exigences ou de garantie d unicité situation 2). Dans ce cas, pour permettre la traçabilité entre les exigences et les tests, il faudra se mettre en situation 3 ou 4, c'est-à-dire avec des exigences explicitées. Cela peut être réalisé par exemple en produisant un référentiel des exigences pour le test. C est ce que montre la Figure 1-2 avec une production du référentiel dans un tableau Excel. 12

Figure 1-2: Construction du référentiel des exigences par l expert métier ou à partir de documents de spécifications en Word Dans le cas des situations 3 et 4, c'est-à-dire à partir du moment où les exigences sont explicitement formalisées, la traçabilité est possible. Cependant, chaque évolution d exigences impose une mise à jour manuelle du référentiel. C est là un travail lourd et fastidieux et, en pratique, on constate souvent une désynchronisation de la matrice de traçabilité avec le référentiel des tests. Le support apporté par le processus outillé décrit dans cet ouvrage, et par la génération automatique des cas de test à partir d un modèle de test, permet d automatiser la gestion de la traçabilité bidirectionnelle entre les exigences et les tests. Cette automatisation garantit que la couverture des exigences par les tests soit à jour en permanence, et devient un outil de suivi de production et de certification applicative. 1.2.1 Génération des tests et traçabilité des exigences La génération de tests permet d automatiser la gestion de la traçabilité entre les exigences et les tests. Comme le présente la Figure 1-3, ce processus est réalisé en trois étapes : L expert métier en charge du référentiel des exigences publie, dans le gestionnaire des tests, les exigences fonctionnelles à tester dans le cadre du projet action ; L architecte de test développe le modèle de test en fonction des exigences à tester et produit avec le générateur des tests couvrant ces exigences action ; La fonction de publication du générateur de tests permet la publication automatique des tests générés (action a) et du lien de traçabilité (action b) dans le gestionnaire de test. 13

Figure 1-3: Traçabilité à partir d un référentiel des exigences (source Smartesting) Ce processus est itératif. C'est-à-dire que chaque évolution des besoins conduit à mettre à jour le référentiel des exigences et à le republier (action de l expert métier) et à mettre à jour le modèle de test, à générer et republier avec le générateur de tests (action de l architecte de test). La génération automatique des tests et leur publication dans le gestionnaire de test permet une prise en charge complète de la gestion de la traçabilité bidirectionnelle des exigences avec les tests au sein du gestionnaire de test. À tout moment, cela garantit la fiabilité du suivi de la couverture des exigences par les tests. Un autre intérêt de cette approche concerne la gestion du changement et la réduction du coût de maintenance. En effet, lorsqu une exigence est modifiée, l architecte de test répercute unitairement ce changement dans le modèle et utilise le générateur de tests pour propager tous les impacts dans tous les tests. 1.2.2 Bonnes pratiques et préconisations Les bonnes pratiques de développement et de gestion des exigences font parties des pratiques à plus forte valeur ajoutée du modèle CMMI [Chris2003], qui recommandent les éléments suivants en termes de gestion des exigences : 1. Comprendre ces exigences 2. Obtenir un engagement sur ces exigences (client, équipe projet, autre intervenant,..) 3. Gérer les changements d exigences 4. Maintenir une traçabilité bidirectionnelle entre les exigences et les changements associés et les produits d activité (tests entre autres) 5. Identifier les incohérences entre les exigences et les plans et produits d activité La pratique 4 se révèle souvent une des plus difficiles à mettre en œuvre si on ne peut s appuyer sur un processus outillé de bout-en-bout qui va alors faciliter cette tâche. 14

Rentrons plus dans le détail dans la recherche d amélioration de la gestion des exigences, par l approche inspirée de CMMI, mais plus appliquée, proposée dans le RMM (Requirement Management Maturity) 2. Celle-ci décrit en cinq niveaux de maturité un modèle relatif à la gestion des exigences qui sont : (1) écrit, (2) organisé, (3) structuré, (4) tracé, et (5) intégré (L atteinte du niveau 5 de RMM assure normalement l organisation IT d être au minima au niveau 3 du modèle CMMI). On peut y noter les différents points suivant : Niveau 1 (Exigences «Ecrites») : L un des bénéfices est la possibilité pour le testeur de commencer très tôt l écriture de ses cas de tests sur lesquels il peut ensuite baser ses procédures et scripts de tests. Niveau 2 (Exigences «Organisés») : Les exigences doivent être non seulement lisibles mais aussi non-ambigües et testables. Niveau 4 (Exigences «Tracées») : La traçabilité fournit la capacité de comprendre comment les exigences interagissent (Analyse d impact) et détermine leur complétude (Matrice de couverture). L effort et par conséquent le coût pour la mise en œuvre et la maintenance en est tout sauf trivial. Niveau 5 (Exigences «Intégrées») : Les tests basés sur les exigences (Requirement Based Testing) est l un des principes à respecter pour vérifier que le logiciel atteint ses objectifs. De plus, la capacité pour le chef de projets d accéder au statut du projet en lien avec les exigences est prépondérante avec bien évidement les métriques tests rattachées à chacune d elles. Nous avons mentionné précédemment et détaillé les différentes situations rencontrées au sein des organisations IT concernant leur maturité sur les exigences. Le Tableau 1-2 propose des préconisations pour mettre en œuvre la traçabilité des exigences avec en fonction de ces situations le reflet du niveau effectif atteint en termes de gestion des exigences. 2 Voir l article de Jim Heumann IBM/Rational 2003.http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/Management Maturity_TheRationalEdge_Feb2003.pdf 15

Situation 1 - Absence totale de référentiel des exigences fonctionnelles 2 - Le référentiel fonctionnel est constitué de documents et matériels disparates 3 - Les exigences fonctionnelles sont explicitées, sans être gérées par un outil spécialisé 4 Les exigences fonctionnelles sont explicitées et gérées dans un outil de gestion d exigences spécialisé Bonnes pratiques Pour assurer la mesure de couverture fonctionnelle, une première étape consiste à définir, fonction par fonction, des exigences de test. L idée est d arriver au minimum au niveau de la situation n 3, c'est-à-dire d identifier et de stocker ces exigences dans un référentiel sous un tableau au format Excel par exemple. Ce tableau sera ensuite publié dans l outil de gestion des tests. De nouveau, l idée est de se mettre au minimum au niveau de la situation n 3. Les documents de spécifications doivent permettre de définir des exigences de tests qui seront saisies dans un référentiel sous la forme d un tableau Excel par exemple. Ce tableau sera ensuite publié dans l outil de gestion des tests. Les exigences formalisées, par exemple dans Excel, peuvent être importées dans l outil de gestion de test pour permettre la traçabilité. Ce cycle de publication doit être assuré à chaque mise à jour des exigences. Un extrait des exigences (les exigences à couvrir par les tests fonctionnels) sera publié dans le gestionnaire des tests (les outils de gestion des exigences possèdent en général cette fonction). La mise à jour sera assurée par re-publication à chaque évolution des exigences fonctionnelles. Tableau 1-2: Situation vis-à-vis de l expression des exigences et préconisation En conclusion, quelque soit votre niveau de maturité de gestion des exigences, la première démarche, si vous souhaitez démarrer votre industrialisation, est de structurer vos exigences dans un même référentiel. Ce référentiel peut être celui associé au référentiel de tests, ou à un référentiel spécialisé. Cela vous permettra non seulement de centraliser l information (B.A.- BA de l amélioration) mais aussi de mettre en œuvre une relation de traçabilité entre votre référentiel d exigence et votre référentiel de test. 16

2 Définition de la stratégie de test fonctionnel 2.1 Positionnement de la stratégie de test 2.1.1 Stratégie de test et politique qualité La stratégie de test doit s inscrire dans la politique qualité de l entreprise et du projet considéré. Le test n est pas le seul moyen de l assurance qualité, mais participe d un ensemble de méthodes et processus qui concourent à la qualité de l application, tant au niveau de l expression de besoins que du développement et de la mise en exploitation. La norme IEEE 730 - Standard for Software Quality Assurance Plans [IEEE 730-2002] propose un contenu type pour le plan qualité logiciel. Ce document décrit les dispositions spécifiques pour un projet prises pour obtenir la qualité du logiciel considéré, et s inscrivant dans la politique globale du maitre d ouvrage en matière qualité. Le plan d assurance qualité définit les priorités en termes de facteurs, de caractéristiques et sous-caractéristiques et de métriques de la qualité applicables pour le projet de test concerné. Ces caractéristiques sont normalisées au sein du standard ISO 9126 [ISO-9126]. Les caractéristiques de qualité correspondent aux catégories suivantes : Capacité fonctionnelle : Est-ce que le logiciel répond aux besoins fonctionnels exprimés? Fiabilité : Est-ce que le logiciel maintient son niveau de service dans des conditions précises et pendant une période déterminée? Facilité d utilisation : Est-ce que le logiciel requiert peu d effort à l utilisation? Rendement : Est-ce que le logiciel requiert un dimensionnement rentable et proportionné à la plate-forme d hébergement en regard des autres exigences? Maintenabilité : Est-ce que le logiciel requiert peu d effort à son évolution par rapport aux nouveaux besoins? Portabilité : Est-ce que le logiciel peut être transféré d une plate-forme ou d un environnement à un autre? Le test fonctionnel visera en premier lieu la capacité fonctionnelle, en particulier au travers du respect des exigences de type cas d utilisation et règles métiers, mais la fiabilité sera aussi couverte. Le plan qualité logiciel couvre aussi les moyens de la qualité tant en termes de processus de développement, de méthodologies mises en œuvre que d outil d ingénierie logiciel utilisé. C est donc ce plan qualité qui donne le cadre au sein duquel s instancie la stratégie de test de l application. Enfin, le plan qualité définit le suivi de la mise en œuvre de l assurance qualité et la gestion des risques devant être appliquée tout au long du projet. De ce point de vue, les résultats des campagnes de test permettront d alimenter ce suivi, et de mettre en évidence les dérives éventuelles par rapport aux objectifs de qualité. En cela, le test tient un rôle central dans la politique d assurance qualité. 2.1.2 Niveaux stratégiques, tactiques et opérationnels de la stratégie de test La stratégie de test peut être vue de façon hiérarchique comme le montre la Figure 2-1 : Le plan de test définit le niveau stratégique : il caractérise la politique de test applicative et définit les aspects méthodologiques ; Le référentiel de tests implémente cette stratégie et constitue le niveau tactique de définition des tests à exécuter ; 17

L infrastructure et l outillage de test constitue le niveau opérationnel, permettant de supporter la stratégie et de mettre en œuvre de façon opérationnelle le référentiel de tests. Figure 2-1: Niveaux de la stratégie de test Les éléments clés de la définition de la stratégie de test sont les suivants : Sa définition doit impliquer tous les acteurs de la chaîne de validation La stratégie de test concerne les différents acteurs de la chaîne de validation : les analystes qui participent à la définition des exigences fonctionnelles de l application, les gestionnaires du produit logiciel qui sont concernés de façon directe par la qualité du logiciel produit, les chefs de projets et bien sur l équipe de test et validation qui mettra en œuvre cette stratégie. La stratégie de test n est pas statique Il faut voir la stratégie de test comme un élément dynamique de la construction et de la maintenance du logiciel. En fonction des retours terrains et des évolutions prévues dans la vie de l application, il faut faire évoluer la stratégie de test. La stratégie de test doit être réaliste et réalisable avec le budget Il est clair que définir des objectifs ambitieux en termes de couverture de test par exemple ou d automatisation, sans en avoir les moyens rend la stratégie de test inopérante en pratique. La stratégie de test doit intégrer les éléments de mesure et de contrôle des objectifs Les indicateurs d atteignabilité des objectifs doivent être explicitement définis de façon à permettre un suivi des résultats de la stratégie de test mise en œuvre. 2.1.3 Structuration du plan de test La documentation du test fait l objet de la norme IEEE 829 [IEEE829-2008]. Cette norme recouvre le plan de test et les documents complémentaires tels que la spécification des cas de test, la structuration des rapports d exécution des tests et d anomalies, ainsi que la synthèse des activités de test. Cette documentation est conçue pour les différents niveaux de test mais est particulièrement adaptée pour les tests fonctionnels de niveau test système. La structure du plan de test proposée par la norme IEEE 829 est la suivante : Sommaire du Plan de test 1. Introduction a. Objet : Courte description des objectifs du plan de test. 18

b. Définition : Définition des termes et des acronymes utilisés dans le document. 2. Références Énumérer les références à d'autres documents appropriés. Normes & Standards Plan de projet et plan d assurance qualité Cahier des charges Documents d'analyse Documents de conception 3. Périmètre couvert par le plan de test Énumérer les éléments à tester (composants, produits, classe, module,...). Ainsi que la version du composant et autres informations techniques. 4. Propriétés testées Énumérer les propriétés testées par ce plan, d un point de vue Utilisateur. Mentionner le risque sur le produit en cas d échec. (élevé, médium, faible) Mentionner le risque potentiel de découvrir des défectuosités (élevé, aucun). 5. Exigences non couvertes par le plan de test Énumérer les propriétés qui ne sont pas testées par ce plan d un point de vue Utilisateur et expliquer les raisons. 6. Processus et stratégie de test Décrire les activités, techniques et outils qui seront utilisés pour les tests avec suffisamment de détail pour permettre l'estimation des ressources et du temps nécessaires. Cette section définit aussi la stratégie globale en termes de priorité de test. 7. Critères d'acceptation des tests Définir les critères de passage et d'échec des éléments testés. 8. Critères d arrêt des tests Décrire les circonstances où l exécution des essais est interrompue et les conditions pour continuer. 9. Identification des documents livrables Énumérer et définir les livrables qui doivent être élaborés durant les tests. Référentiel de tests Rapport d'exécution: verdict de chacun des cas de test lors de l'exécution Rapports des anomalies: Description et suivi des anomalies découvertes lors de l'exécution des tests. Rapport sommaire: Sommaire des activités et résultats des tests. 10. Gestion des anomalies Décrire comment rapporter, suivre et résoudre les anomalies détectées. 11. Définition des activités de test Description des différentes activités réalisées lors des phases de test 12. Outillage et infrastructure de test Définition des outils et de l infrastructure de test (environnement de test, base de recette, moyens matériels et réseau) 13. Responsabilité Niveaux de responsabilité lors de phases de test (répartition en Client, Développement et Equipe de test) 14. Equipe de test Définition de l équipe de test, et des compétences et du plan de formation nécessaire 15. Planning prévisionnel Planning prévisionnel global des phases de test incluant les principaux jalons. 19

16. Gestion des risques Risques identifiés et gestion prévisionnelle Dans le cas de projets complexes, la formalisation du plan de test est réalisée à plusieurs niveaux : définition d une politique globale pour le projet (par exemple en suivant le standard IEEE 1012 Verification and validation plan [IEEE1012-2004], accompagné de plan de test spécifiques par niveau de test. A noter que dans certaines méthodologies structurées de test, telle que TMap Next [TMap2006] de la société Sogeti, ce document de politique globale de vérification et validation est appelé «Test Master Plan» et vise à expliciter de façon globale la politique de test, l organisation de test, les environnements de test, les outils de test et les équipes de test. Ce plan de test maître est dérivé ensuite en plans de test par niveau de test. Couramment la stratégie de test peut faire l objet d un document à part du plan de test, qui sera validé en amont du plan de test. De la même manière les projets complexes comporteront une stratégie de tests globale et des stratégies de tests par phase de tests. 2.2 Stratégie de test dirigée par les risques L aphorisme célèbre du Professeur Edsger W. Dijkstra, en 1970: «Program testing can be used to show the presence of bugs, but never to show their absence!», est bien sur toujours valide 40 ans après. Le test de logiciel ne permet qu une vérification partielle de l application testée, et l explosion combinatoire inhérente à l activité même du test nécessite d appliquer des stratégies de sélection des cas de test et de la couverture fonctionnelle pour maîtriser le triptyque Qualité/Délai/Coût. Cette stratégie de sélection gagne à être dirigée par les risques pour maitriser au mieux l impact des anomalies et/ou défaillances applicatives en termes de coûts induits sur l activité associée à l application. En effet, quel serait l intérêt d une activité de test sur une application pour laquelle l impact d une quelconque défaillance serait nul. A l inverse, les systèmes critiques, qui mettent en jeu la vie humaine, s appuie sur des techniques de test qui garantissent un niveau élevé de couverture de code dépendant du niveau de criticité (cf. la norme DO-178B [DO178B-1992]). Le risque peut être analysé comme une fonction à deux composantes : la probabilité d occurrence d un événement indésirable et l impact de la défaillance en termes de coûts induits. La probabilité d occurrence d un événement sur une application logiciel dépend en général de la fréquence d utilisation de la fonction concernée par l événement, plus cette fonction est utilisée plus il est probable que l événement redouté se produise. Ce sont donc ces deux aspects, à la fois la probabilité d occurrence et les dommages induits, qui seront analysés dans l objectif de définir des niveaux de priorités et de sensibilité permettant de piloter la construction du référentiel de tests. La méthode TMAP Next, déjà mentionnée précédemment, fournit une approche structurée dite Analyse de Risque Produit pour l identification des risques à prendre en compte lors de l élaboration du plan de test et de la construction du référentiel de tests. La Figure 2-2: Etapes du pilotage du test par les risques s inspire du processus TMap et permet d illustrer la démarche de pilotage du test par les risques. L identification des risques sera réalisée à partir des différents éléments analytique de l application sous test : cas d utilisation, processus métiers, exigences, règles de gestion, 20

caractéristiques qualité, mais aussi à partir de sa décomposition en sous-systèmes et composants, qui peuvent porter chacun un niveau de risque, et impliquer un niveau de test. Figure 2-2: Etapes du pilotage du test par les risques La Figure 2-2 montre que le Client (la maîtrise d ouvrage) de l applicatif doit être au centre du pilotage de la politique de test par les risques. Les défaillances de l application peuvent être différentes suivant les types d utilisateur. Il s agit donc, lors de l analyse de risque, d identifier les services de l application utilisée par chaque type d utilisateur de façon à en tenir compte lors de la détermination des classes de risques par objectifs de test. La définition des classes de risques dépend de la nature de l application testée. Dans le cas des systèmes critiques aéronautiques, la norme DO-178B, déjà citée, en prévoit cinq : Niveau A : Problème catastrophique - Sécurité du vol ou atterrissage compromis - Crash de l'avion Niveau B : Problème majeur entraînant des dégâts sérieux, mettant en jeu la vie humaine Niveau C : Problème sérieux entraînant un dysfonctionnement des équipements vitaux de l'appareil Niveau D : Problème pouvant perturber la sécurité du vol Niveau E : Problème sans effet sur la sécurité du vol. 21

Dans le cas des systèmes d information, que cela soit des applications de type Progiciel métiers ou des applications spécifiques, trois niveaux de risques sont en général utilisés pour l analyse : A- Risque élevé, B Risque Moyen et C Risque Faible. Ces classes de risques sont associées à une matrice de risque absolue [Broek2002] qui croise la probabilité d occurrence d un événement avec l impact en cas de défaillance (cf. Tableau 2-1). Dommage en cas de défaillance Probabilité de défaillance Elevée Moyenne Faible Elevé A B B Moyen B B C Faible C C C Tableau 2-1: Tableau croisé des niveaux de risque (d après TMap Next) La détermination des classes de risques pour les différents objectifs de test peut être synthétisée dans un tableau qui croise les sous-systèmes (ou fonctionnalités) et les cas d utilisation ou exigences fonctionnelles avec un niveau de criticité, comme le montre le Tableau 2-2. Fonctionnalité Objet de test Niveau de risque Argumentaire Fonction # 1 Exigence 1 A.. Fonction # 2 Exigence 2 C.. Cas d utilisation 1. A Tableau 2-2: Croisement des fonctionnalités / objectifs de test avec le niveau risque associé. La synthèse de l analyse de risque est exploitée de façon directe lors du processus de production du référentiel de test, pour appliquer différentes stratégies de tests et de couvertures en fonction du classement associé à l objectif de test. 22

3 Les outils de test logiciel 3.1 Notion de Processus outillé 3.1.1 Pourquoi un processus outillé Le test de logiciel a été historiquement une activité peu structurée, s appuyant sur des processus manuels peu reproductibles et donnant des résultats mitigés, tant en termes de détections d anomalies, que de maîtrise des coûts et des délais. Cette situation évolue rapidement depuis une dizaine d année sous la contrainte des impératifs budgétaires (une anomalie découverte en phase de production coûte souvent cher à corriger), de délais (tester le plus tôt possible) et de qualité. Le test fonctionnel joue ainsi un rôle central par rapport aux problématiques réglementaires (type loi Sarbanes-Oxley ou Normes Bale II) et dans la maitrise des risques liés à la globalisation des développements. La mise en place d un processus outillé, depuis l expression des exigences jusqu'à la mise en œuvre d un référentiel de tests automatisés permet d assurer à la fois la reproductibilité des activités de test, de mesurer leur qualité et de mieux maîtriser leurs coûts. Une activité centrale, telle que la traçabilité bidirectionnelle entre les exigences métiers et les cas de tests, est très difficile à réaliser et surtout à maintenir manuellement lorsque les exigences et l application à tester évoluent (ce qui constitue le cas usuel d une application informatique). Le processus outillé va donc permettre de structurer les activités de test et d automatiser nombres de tâches fastidieuses, garantissant une meilleure pérennité dans le temps du patrimoine de test. Il faut cependant noter que les outils en eux-mêmes ne constituent pas une méthodologie, et qu il faudra systématiquement les mettre en œuvre dans le cadre d une démarche structurée telle que proposée par les guides de bonnes pratiques de l ISTQB International Software Testing Qualification Board représenté en France par le Centre Français du Test Logiciel www.cftl.fr [Spill2007], ou la méthode TMap Next déjà citée. Il faut aussi prendre conscience que la mise en œuvre d un processus outillé va requérir des compétences spécialisées, correspondant à la professionnalisation des métiers du test logiciel. 23

Figure 3-1: Schéma du processus outillé de test fonctionnel La Figure 3-1 fournit le schéma d un processus outillé qui fait apparaitre trois étapes principales : L expression des exigences métiers cette activité se situe en amont du test fonctionnel, n en faisant pas à proprement partie mais en constituant un pré-requis ; cette activité peut être outillée par un outil de gestion des exigences. La construction du référentiel de tests Cette activité est outillée par un générateur de tests qui permet d alimenter le référentiel de tests, à la fois en cas de test et en scripts automatisés. La gestion et l exploitation du référentiel de tests Cette activité recouvre les différentes tâches liées au cycle de vie des tests, à leur traçabilité avec les exigences métiers, à la planification des tests et au suivi des résultats d exécution sur l application. Ce processus outillé fait apparaitre 3 types d outils (les outils de gestion des exigences sont considérés hors du périmètre des outils du test fonctionnel) : Le gestionnaire du référentiel de test c est l outil pivot au cœur du processus outillé du test fonctionnel Le générateur de tests qui permet d alimenter le référentiel de tests à partir des exigences métiers Le robot d exécution qui permet d automatiser l exécution des tests sur l application cible. Nous présentons de façon détaillée cette gamme d outils dans la suite de ce chapitre. D autres outils qui n apparaissent pas dans ce schéma font aussi partie intégrante du processus outillé : Les outils de «versionning» pour gérer les versions des artefacts de test et de construction automatique d applications pour préparer l application à tester (nous n en parlerons pas car il 24

s agit d outils classiques du développement logiciel, pas spécifiques au test, mais ils sont indispensables dans un tel processus outillé). Les outils de construction de base de test et de simulation d application pour réaliser l infrastructure de test. 3.2 Un outil pivot : le gestionnaire du référentiel de tests Les activités du test fonctionnel conduisent à développer et à maintenir un ensemble important d artefacts de tests. Cela recouvre en particulier : Les cas de test et la documentation associée ; Les scripts de test pour l exécution automatique ; Les données de test pour la valorisation des tests sur des données concrètes ; La définition des campagnes de test ; Les résultats de test et la documentation associée ; Les anomalies détectées et leur état selon le cycle de vie défini ; Les liens de traçabilité vers le référentiel des exigences ; C est le rôle du gestionnaire du référentiel de test que de permettre la gestion de l ensemble de ces artefacts et la rendre accessible de façon distribuée à l ensemble des personnes impliquées dans le cycle de validation de l application. La Figure 3-2 illustre les différents rôles utilisateurs du référentiel des tests dans le cadre du test fonctionnel. 25

Figure 3-2: Rôles utilisateur du référentiel de tests Le gestionnaire du référentiel de test constitue donc une application de type client-serveur, permettant un accès réparti aux informations du référentiel, et permettant de gérer les rôles, les processus et les propriétaires des éléments livrables, pour automatiser le flux des travaux et activités de test. Les fonctions principales supportées par le gestionnaire du référentiel de tests sont les suivantes : La gestion des projets de test, des rôles et des accès au référentiel Un gestionnaire de test multi-projets en accès distribué permet d administrer les différents utilisateurs tout au long du cycle de vie des tests. La traçabilité entre exigences et les cas de test Les exigences caractérisant le produit doivent être reliées par un lien de traçabilité avec les cas de test, de façon à pouvoir mesurer en permanence la couverture réalisée. Les outils de gestion des exigences étant spécifiques, et indépendant du test, en pratique le manager de tests doit permettre de les importer dans un référentiel central, ou de créer une passerelle entre les deux types d outils. Les exigences peuvent ainsi être reliées aux cas de test pour assurer la gestion de la traçabilité 26

bidirectionnelle (voir chapitre 1). La capture de l historique des exigences et de leurs modifications permet de déterminer l'impact des changements sur le référentiel de tests. La gestion et la structuration de la base de tests Le gestionnaire du référentiel de tests permet la définition des cas de test, leur regroupement en sous-ensemble cohérent (relatifs à une fonction, sous-fonction ou cas d utilisation par exemple) et le paramétrage des attributs de données que l on souhaite gérer. La gestion partagée de la base de tests permet la réutilisabilité des cas de tests lors de l évolution de l application. Ainsi, la référentiel de tests pour un projet pourra être structuré par exigences métiers de haut niveau dans sa définition, pour en faciliter l accès et la gestion des évolutions. La gestion et le suivi de l exécution des tests L exécution des tests doit pouvoir être organisée (quels tests exécutés sur telles ou telles versions de l application), et suivie lors de l exécution. Cela concerne à la fois les tests manuels et les tests automatisés. Le suivi des anomalies Les anomalies détectées lors de l exécution des tests doivent pouvoir être enregistrées dans un gestionnaire d anomalies. Le cycle de vie des anomalies (depuis leur détection jusqu'à leur correction) est géré, ainsi que le lien avec le ou les cas de test ayant permis de les détecter ; comme pour la gestion des exigences, la gestion des anomalies constitue un outil à part entière, qui peut donc être soit intégré soit interfacé au manageur du référentiels de test. La visualisation graphique des résultats de test Le suivi et la visualisation graphique des résultats de test et de l état d élaboration du référentiel de tests (par exemple en termes de couvertures des exigences) constitue une fonction importante pour permettre au gestionnaire du projet d accéder à une information synthétique et à jour sur le processus de test. Ces fonctions sont supportées par les principaux outils du marché, souvent au travers d une architecture client-serveur avec une interface Web pour faciliter le déploiement de l accès au référentiel de tests. Les principaux produits commerciaux actuellement sur le marché sont les suivants : Borland SilkCentral Test Manager Compuware QADirector HP Quality Center IBM Rational Quality Manager On trouve aussi des outils open-source (cf. le site http://www.opensourcetesting.org/ qui tient à jour une liste des différents outils open-source dans le domaine du test), tels que TestLink ou Salome-TMF par exemple. Une grille de critères permettant l'évaluation de ce type d'outils est disponible comme livrable de ce projet (Livrable L4.2). Cette grille a également été utilisée pour évaluer les outils suivant: HP Quality Center, TestLink et Salomé-TMF. Les études des analystes montrent, au niveau des outils commerciaux, une forte diffusion de l environnement HP Quality Center (cf. par exemple l étude Gartner Q1/08 MarketScope for Application Quality Management Solutions, ou l étude Forrester Q3/08 Functional Testing Solutions). 27

La Figure 3-3 montre l interface de HP Quality Center avec l accès aux différents panels : Requirements Gestion de la traçabilité des exigences, Test Plan Gestion du plan de test, Test Lab Gestion des campagnes de tests et de leur exécution, Defects Gestion des anomalies. Figure 3-3: Interface de HP Quality Center 9.2 3.2.1 Intégration ou coopération d outils La Figure 3-4 montre les liens entre les différents niveaux d artefacts et des gestionnaires associés dans la chaîne outillée du test fonctionnel. Il y a bien sûr des avantages et inconvénients à une solution intégrant tous les outils vers une solution de coopération entre outils. L intégration facilite la mutualisation des informations, mais impose d utiliser tous les outils d un même éditeur. La coopération permet l'exploitation de différents outils, éventuellement venant de différents éditeurs, mais induit une communication moins directe entre les différents niveaux d information. La solution HP Quality Center intègre dans un référentiel central les exigences, les cas et scripts de tests et les anomalies. La solution IBM Rational Quality Manager s appuie sur le framework commun Eclipse pour favoriser l intégration avec la gestion des exigences et la gestion des anomalies. L ouvrage de Pierre Henry, «The Testing Network» [Henry2008] met bien en évidence l intérêt des gestionnaires intégrés du référentiel de tests dans le cas de larges projets, impliquant des équipes distribuées géographiquement. 28

Figure 3-4: Relation entre les artefacts 3.2.2 L outillage de test doit s inscrire dans une politique globale de l entreprise Les relations que le référentiel de test entretient nécessairement avec la gestion des exigences et la gestion des anomalies induisent que le choix du gestionnaire de test est structurant et doit être pensé de façon stratégique et globale. Le gestionnaire du référentiel de test doit être commun à l ensemble des entités de l entreprise dans le cadre d un politique de test global. Ce besoin d inscrire le choix du gestionnaire de test dans la politique globale de l entreprise en matière de gestion de la qualité logicielle, est aussi lié aux problématiques de retour sur investissements. De tels outils sont couteux, tant en termes d acquisition de licence qu en termes d exploitation. La formation des équipes et la mise en place des méthodes adaptées s amortissent sur le temps d utilisation. Les choix doivent donc être réalisés avec attention et supportés par le management de l entreprise utilisatrice. 3.3 Le générateur de tests La génération des tests constitue l aspect le plus innovant du processus outillé présenté dans ce document. Il s agit d un élément clé qui permet d obtenir une continuité entre les exigences métiers et le référentiel de tests, d assurer le suivi des évolutions fonctionnelles de l application et d accélérer la production du référentiel de tests automatisés en prenant en charge des tâches répétitives et laborieuses. C est ainsi l'un des composants central de la démarche d industrialisation du test fonctionnel comme illustré par la Figure 3-5. 29

Figure 3-5: Continuité de la chaîne outillée du test fonctionnel 3.3.1 Principes de la génération de tests Un générateur de test génère automatiquement les cas et scripts de test à partir d un modèle comportemental de l application testée. Le modèle, appelé modèle de test, est en général développé spécifiquement pour produire les tests : il définit les comportements attendus. Le générateur de tests est alors en charge de produire automatiquement les cas couvrant pertinents pour tester les comportements modélisés. De ce point de vue, et au travers d heuristiques de test, le générateur de test prend en charge une partie des tâches initialement réalisée par le concepteur de test dans la production des cas de test. L effort de conception des tests portent donc sur le développement du modèle de test qui permet à l architecte de test de se concentrer sur l essentiel : les comportements applicatifs à tester pour couvrir les exigences fonctionnels et les objectifs de test. Le modèle de test exprime une vision externe, boîte-noire, de l application testée. Le point de vue est bien celui d un testeur qui décrit les actions réalisables et les comportements attendus associés. La modélisation pour la génération de test, dans le contexte des systèmes d information et de communication 3, est principalement proposée avec le standard UML Unified Modeling Language standardisé par l Object Management Group cf. www.omg.org. L intérêt de s appuyer sur une notation standard et fortement diffusée pour la génération de tests est de pouvoir réutiliser des éléments de modèles issus de l analyse (par exemple la description des entités métiers). Le modèle de test met en œuvre trois types de diagrammes UML : Le diagramme de classes - Les classes, attributs et opérations associées représentent les entités métiers et les actions d un point vue externe à l application, Le diagramme d états, accompagné du langage OCL Object Constraint Language pour décrire les actions, représente le comportement dynamique attendu de l application testée. Le diagramme objets, qui permet de définir les instances des entités métiers, fournit un état initial de l application pour la génération des tests et des instances de données abstraites. Ces points, ainsi que le processus de génération de tests, sont détaillés dans la section 3.3, qui décrit les techniques de génération de tests. Les images des Figure 3-6, Figure 3-7, Figure 3-8 et Figure 3-9 fournissent des exemples d un modèle de test au travers d un diagramme de classes, d un diagramme d états et d un diagramme d objets correspondant à une petite application de gestion de réservation de vols. 3 Dans le domaine des systèmes embarqués temps réels, pour l aéronautique, l énergie ou l automobile par exemple, les modèles de test sont plutôt développés en Simulink, une notation développée par la société The Mathworks (cf www.mathworks.com ). 30

Figure 3-6: Exemple de diagramme de classes d un modèle de test d une application de gestion de vols Figure 3-7: Exemple de diagramme d états d un modèle de test d une application de gestion de vols 31

Figure 3-8: Exemple de diagramme d états d un modèle de test d une application de gestion de vols Figure 3-9: Exemple de diagramme d objets d un modèle de test d une application de gestion de vols Ces éléments de modèle de test illustrent la nature de la modélisation pour le test : la modélisation pour la génération de tests consiste à définir les actions (dans le diagramme de classes) et les comportements attendus de ces actions (dans le diagramme d états). 3.3.2 Les fonctions d un outil de génération de tests Les fonctions principales d un outil de génération de tests sont de quatre ordres : 32

Le support à la modélisation pour le test Cette fonction peut être assurée à partir d outils de modélisation indépendants (par exemple d outil de modélisation UML tels que IBM Rational Software Modeler, ou Borland Together), en incluant des fonctions de support pour les aspects spécifiques de la modélisation pour le test (vérification de modèles, simulation de modèles, export des modèles). Cette fonction peut aussi être intégrée dans l outil de génération de test. La génération des cas de test C est bien sûr la fonction centrale du générateur de test qui applique sur le modèle des stratégies de génération permettant de couvrir les fonctionnalités modélisées suivant différentes stratégies qui sont détaillées au chapitre 4. Les tests produits sont de nature logique, c'est-à-dire qu il s agit d enchaînement d actions sur l application testée, à partir des actions décrites dans le modèle, en associant des données abstraites d entrées et les résultats attendus pour chaque action. Pour être pertinent, ces cas de test doivent pouvoir être exploités manuellement par un testeur n ayant pas participé à la modélisation pour le test (Ils doivent donc être documentés). La publication des tests et la production de scripts exécutables Les tests générés doivent pouvoir être publiés dans le référentiel de tests, de façon compatible avec un gestionnaire de référentiel (voir section précédente). Typiquement, les tests générés vont être publiés dans un outil tel que HP Quality Center, les données de test automatiquement ajoutées, et les scripts associés générés, par exemple avec un automate tel que HP QuickTest Professional. A l'aide du générateur de tests, l alimentation du référentiel est automatique par la publication des tests générés à partir du générateur de tests. La gestion de la traçabilité des exigences fonctionnelles Cette gestion est assurée à deux niveaux : le premier niveau est celui de l architecte de test qui établit le lien, au sein du modèle de test, entre les comportements modélisés et les exigences fonctionnelles. Le second niveau est celui du générateur de tests qui produit et maintient à chaque re-génération les liens de traçabilité bidirectionnels entre les cas de tests produits et les exigences fonctionnelles de référence. Ces fonctionnalités constituent le corps des outils de génération de tests, elles peuvent être complétées par une fonction de spécification de scénarios métiers permettant de produire des tests ad hoc, une fonction de gestion de la couverture de données (production de tables de données sur les classes d équivalence de tests par exemple), et une fonction de gestion de la génération de tests par les risques (la stratégie de génération dépend des risques associés aux exigences plus le risque est élevé et plus la stratégie couvrira la combinatoire de tests associée). 3.3.3 Les générateurs de tests sur le marché Le marché des outils de génération de tests est nettement segmenté entre les générateurs qui traitent les applications de type systèmes embarqués temps réels, et ceux qui adressent en priorité les systèmes d information et de communication. Cela est dû aux caractères spécifiques de chacun de ces systèmes : la gestion du temps et de la concurrence est un élément spécifique des systèmes embarqués aéronautique, automobile ou spatial, alors que la gestion d une forte composante orientée données est une caractéristique des systèmes d information. 33

Dans le domaine des systèmes d information et de communication, qui constitue le focus de ce document, les principaux générateurs de tests commercialisés actuellement et visant ce domaine sont les suivants 4 : ConformiQ Qtronic www.conformiq.com, qui possède un outil de modélisation propriétaire basé sur UML, et offre une version en-ligne de la génération de tests (les tests sont générés et exécutés de façon synchronisée). Smartesting Test Designer - www.smartesting.com, qui s intègre avec des outils de modélisation UML du marché (en particulier IBM Rational Software Modeler et Borland Together) et permet la publication dans les référentiels du marché (HP Quality Center et IBM Rational Quality Manager par exemple). Test Designer est l outil utilisé dans ce document pour illustrer le processus outillé. Automated Test Designer de la société @yourside Consulting - www.atyoursideconsulting.com, qui utilise une notation spécifique de modélisation orientée Causes / Effets, pour représenter le modèle de test. BenderRBT de la société Bender - www.benderrbt.com, utilise aussi une notation spécifique de modélisation orientée Causes / Effets, pour représenter le modèle de test. Comme l ensemble des outils du test fonctionnel, le domaine de la génération automatique de tests constitue un champ actif et en diffusion rapide sur le marché. 3.3.4 Apports de la génération de tests Dans cette section, nous présentons donc les aspects qualitatifs spécifiques à la génération des tests. Ces apports peuvent être synthétisés en 4 points : La qualité des exigences et l implication du test dans le processus de développement - Le développement du modèle de test, tôt dans le processus de développement, implique l équipe de test dans la conception du produit ; cela a un impact très fort, à la fois sur la qualité des exigences produites (rappelons-le nécessaires aux activités de test) et sur la qualité globale applicative ; La complétude du référentiel de tests - La génération des tests à partir du modèle de test permet de soulager l ingénieur validation des tâches fastidieuses de rédaction et maintenance des cas de test individuels en se focalisant sur les aspects métiers, c'est-à-dire l expression de comportements à tester. La gestion automatique de la traçabilité des exigences permet de contrôler à tout moment les fonctionnalités couvertes et comment elles le sont. Le référentiel de test est ainsi plus complet, couvrant mieux les exigences fonctionnelles. L accélération du cycle de test et de prise en compte des évolutions fonctionnelles Le modèle de test synthétise les comportements à tester. Chaque cycle d évolution de l application est pris en compte directement au niveau du modèle (dans le cas d évolutions fonctionnelles) et permet une mise à jour du référentiel de tests par re-génération : les tests devant être modifiés sont corrigés dans la base, des tests nouveaux peuvent être crées et 4 Il existe un ensemble de générateurs de tests dédiés aux systèmes embarqués tels que : Reactis - www.reactive-systems.com - de la société Reactive Systems, basé sur des modèles Simulink- Stateflow, et T-Vec Tester - www.t-vec.com de la société T-Vec aussi basé sur des modèles Simulink-Stateflow. A noter, le module Automatic Test Generation (ATG) de IBM Telelogic Rhapsody à partir de modèles UML pour l embarqué. 34

d autres rendus obsolètes, les autres restent inchangés. Le référentiel de tests est mis à jour en fonction de ces évolutions et les choix d exécution (en particulier pour le test de nonrégression) peuvent être réalisés par l équipe de test avec un référentiel à jour. La mise à jour du référentiel de tests porte à la fois sur les tests manuels et sur les tests automatisés (mise à jour des scripts). L industrialisation et la continuité du processus de test La génération des tests à partir d un modèle qui représente et trace de façon systématique les exigences métiers crée une chaine continue des besoins au référentiel des tests. Cette continuité constitue un des vecteurs de l industrialisation du test fonctionnel. 3.4 L automate de test L automatisation de l exécution des tests, sur l IHM de l application ou au niveau des API de ses composants, nécessite des formes de codage (appelé scripting dans le vocabulaire du test) permettant l expression des pas d exécution du cas de test automatisé, la vérification des résultats attendus et différentes procédures de mise en contexte de l application. L objectif d un automate de test est d une part de prendre en charge l exécution automatique des tests et d autre part de faciliter le développement de ces cas de test automatisés. Dans le cas de systèmes techniques, par exemple des applications embarquées tels que des calculateurs de contrôles automobiles, ou des terminaux bancaires, les environnements d automatisation de tests intégreront des capacités de simulation de l environnement du système sous test. On trouve donc sur le marché une segmentation forte entre d une part des outils généralistes, facilitant l automatisation de l exécution des tests sur l IHM (par exemple des IHM web au travers des navigateurs, ou des IHM client-serveur, adressant des environnements de développements spécifiques tels que Delphi ou Powerbuilder par exemple. Cela inclut typiquement des outils tels que HP QuickTest Professionnal, IBM Rational Functional Tester, Borland Silk Test, Compuware TestPartner ou AutomatedQA TestComplete, que nous étudions plus spécifiquement dans la suite de cette section. Mais, cette catégorie concerne aussi des environnements facilitant l automatisation des tests sur API, et disponible sous un forme open-source pour la plupart des langages de programmation autour de la famille xunit. Cela inclut bien sur JUnit www.junit.org pour le langage Java, et les environnements similaires pour les autres langages. Ces outils sont au départ dédiés aux tests unitaires, mais sont aussi couramment utilisés pour automatiser des tests fonctionnels applicatifs à partir de l interface API du système sous test. D autre part, il existe une grande variété d outils spécialisés d automatisation pour un domaine particulier. Par exemple, dans le domaine des transactions électroniques sécurisées (monétique, billetterie électronique, ), il existe plusieurs outils commerciaux facilitant le développement de scripts automatisés et la simulation de l environnement du système testé (simulation de protocoles, de terminaux, de serveurs,.). L outil KaNest de la société Galitt www.galitt.com - constitue un exemple d un tel outil. 3.4.1 L'automatisation des tests sur IHM Comme nous l avons déjà mentionné pour les deux gammes précédentes d outils (automates de test sur IHM ou sur API), et pour le processus complet, l installation des outils ne suffit pas pour réussir : il s agit bien d appliquer une méthodologie adaptée par une équipe formée et maîtrisant les concepts et techniques sous-jacentes. Ces éléments sont particulièrement 35

vrais pour l automatisation des tests, qui a connu beaucoup d échec ces dernières années (on parle d échec lorsque les bases de scripts sont construites puis abandonnées ou lorsque des délais ou coûts de projet de tests sont grevés par la difficulté de la maîtrise de l automatisation). Les fonctions principales d un outil d automatisation des tests sur IHM sont les suivantes : L extraction et la gestion de la carte des objets graphiques L automatisation d un cas de test sur une IHM fait nécessairement référence aux objets graphiques de l IHM. Par objets graphiques, nous entendons les champs de saisies et d affichage, les boutons de diverses formes, les liens dynamiques, les menus, les tableaux, et tous les objets qui font partie de la stimulation de l application et de l affichage des résultats des actions réalisées. L extraction de ces objets graphiques, leur référencement unique et leur maintenance au travers d une carte des objets graphiques constitue donc une fonction centrale des automates de test. L analyse de la carte des objets graphiques nécessite que l automate de test supporte la technologie de développement IHM utilisée (web, Java,.Net,.). La gestion de technologies multiples est souvent réalisée avec des modules complémentaires (add-in). Enregistrement de séquence d actions Il s agit de la fonction dénommé «capture & replay» qui permet d enregistrer une séquence d actions réalisées manuellement sur l IHM de l application testée, de façon à la paramétrer, et à la réutiliser dans les tests automatisés. Scripting de tests automatisés A coté du mécanisme de «capture & replay», ces outils offrent la possibilité de développer les tests automatisés dans un langage de programmation dédié, souvent vu comme une extension d un langage généraliste tels que Visual Basic, Java, ou des langages de scripts tels que TCL ou Ruby. Exécution des tests automatisés et gestion des résultats Les cas de tests automatisés doivent pouvoir être lancés (avec une planification du lancement) et les résultats enregistrés et rendus disponibles pour l utilisateur. L intégration avec le référentiel de tests Les tests automatisés doivent pouvoir être lancés depuis le gestionnaire du référentiel de tests, sous forme de campagne de tests, et les résultats d exécution enregistrés dans le gestionnaire d anomalie. 3.4.2 Les outils d automatisation des tests sur IHM Il existe une offre importante en matière d automates de test sur IHM, tant au niveau des offres des éditeurs qu au niveau des solutions open-source (cf. www.opensourcetesting.org ). Certains outils sont restreints à une technologie (web par exemple), d autres présentent un grand nombre de modules complémentaires pour supporter les principales technologies de développement d IHM. Parmi les outils commerciaux les plus diffusés, on peut citer : Borland Silk Test IBM Rational Functional Tester HP QuickTest Professional Compuware TestPartner AutomatedQA TestComplete Ces outils sont intégrés avec les gestionnaires de référentiel de tests des mêmes éditeurs. 36

Parmi les outils open-source disponibles, on peut citer : Watir, restreint aux applications web - http://wtr.rubyforge.org/ Selenium, aussi focalisé sur les applications web, et intégrant un puissant environnement des développements de scripts - http://seleniumhq.org/ 37

4 Production du référentiel de tests 4.1 Techniques de conception de tests 4.1.1 Principes du test boîte-noire Le test fonctionnel est essentiellement de nature «boîte-noire», c'est-à-dire que l application testée est vue au travers de ses interfaces : les actions et contrôles réalisables d un point de vue externe. C est l approche utilisée en qualification fonctionnelle, car elle vise à réaliser des tests correspondants à l utilisation prévisible d un utilisateur. En test unitaire par contre, l approche de conception des tests sera plutôt «boîte-blanche» (ou «boîte de verre»), c'està-dire que les tests seront conçus dans un objectif de couverture du code du module testé. Comme le montre la Figure 4-1, en mode boîte-noire, l application est stimulée au travers de ces points de contrôle et les résultats des actions de test sont vérifiés au travers des points d observation. Figure 4-1: L approche du test boite-noire Les points de contrôle et d observation sont donc principalement à l extérieur de l application testée. L infrastructure de test est par contre prévue pour permettre de maîtriser l environnement de l application testée. Les tests exécutables pourront aussi faire appel à des procédures spécifiquement développées pour le test. Par exemple, une procédure pourrait permettre de remettre le contexte de la base de données dans un certain état pertinent pour la campagne de test. Ces procédures appelleront du code pour le test pouvant modifier les données en base et ce sans passer par les points de contrôle de l application testée. La notion de test boîte-noire a donné lieu à un ensemble de techniques de conception de tests (différentes des techniques boite-blanche) que nous présentons dans la section suivante. 4.1.2 Test logique / Test physique La conception des cas de test vise à implémenter la stratégie de tests, les objectifs de test et l analyse des risques définis au sein du plan de test (cf. chapitre 2). Une approche en deux temps est utilisée : tout d abord la conception des cas de tests logiques (aussi appelé test abstrait) puis leur concrétisation sous forme de cas de tests exécutables, on parle de cas de tests physiques (ou concrets). Les tests logiques définissent la séquence des actions et des observations (permettant de consolider le résultat attendu) constituant le cas de test, mais la valeur concrète des paramètres d entrées et de sortie n est pas établie. Ainsi, un cas de test logique constitue une spécification détaillée d un cas de test qui devra être valorisée sur des données concrètes pour l exécution du test. Le cas de test physique constitue une implémentation d un cas de test logique. Il est utile de bien voir qu il ne s agit en général que d une des implémentations possibles du cas de test logique correspondant car différentes données de test peuvent 38

permettre d implanter des séquences équivalentes au niveau des actions réalisées et des résultats attendus. Par exemple le test logique suivant : Pas de test Login : Utilisateur enregistré Réservation : Séance soirée / 2 places Paiement : Carte EMV Fin session Résultats attendus Message : Login_OK Message : Réservation_OK Paiement OK pourra être concrétisé par différents tests physiques, dont les deux suivants : Pas de test Login : «Jules Asting» Réservation : Séance «Schreck 4» - 20h / 2 places Paiement : Carte VISA Jules Asting Fin session Résultats attendus Message : Login_OK Message : Réservation_OK Paiement OK Pas de test Login : «Nora Midi» Réservation : «Eleven 17» - 22 h / 2 places Paiement : Carte Mastercard Nora Midi Fin session Résultats attendus Message : Login_OK Message : Réservation_OK Paiement OK où «Jules Asting» et «Nora Midi» sont deux utilisateurs référencés, et «Eleven 17» et «Schreck 4» deux films référencés avec des séances en soirée comme spécifié dans le cas de test logique. La séparation test logique / test physique recouvre un double objectif. Il s agit tout d abord de focaliser la conception des tests (au niveau logique) sur la couverture fonctionnelle recherchée, sans s embarrasser de détails d implémentation, qui créeraient un parasitage inutile dans cette phase. Mais il s agit aussi de faciliter la plus grande robustesse des tests par rapport à des évolutions de données en permettant une «valorisation» des tests logiques par les données concrètes au moment de leur exécution. Si l exécution de test est manuelle, elle va être, en tout ou partie réalisée manuellement par le testeur à partir des données de test référencées. La Figure 4-2 montre la double relation existante : du test logique avec un objectif de test et du test physique avec le script de test exécutable. 39

Figure 4-2: Méta-modèle des cas de tests logique / physique Ce méta-modèle simplifié des cas de test logique et physique montre que les bonnes pratiques tendent à produire un test logique par objectif de test, et que plusieurs tests physiques peuvent implémenter un test logique. Un script de test peut regrouper plusieurs tests physiques au sein d un même code, qui peut être paramétré par une table de données pour traiter différentes instances de paramètres d entrée (et éventuellement de sortie). La séparation logique /physique fait apparaitre de façon implicite une notion de classe d équivalence : en effet, lorsque nous établissons que «Utilisateur enregistré» peut être instancié par «Jules Asting» ou «Nora Midi», nous indiquons simplement que Jules et Nora font partie de la même classe d équivalence correspondant aux utilisateurs enregistrés, et que l ingénieur validation aura à décider si un représentant de la classe d équivalence lui suffit pour le test, ou s il veut itérer son test sur plusieurs représentants de ladite classe. 4.1.3 Techniques basées sur le partitionnement par classe d équivalence Le partitionnement du domaine métier en classes d équivalence constitue le pivot des techniques de conception de tests fonctionnels. Le domaine des entités métiers, des paramètres d entrées des actions et des résultats attendus est divisé en classes d équivalence comportementales : un ensemble de valeurs de la même classe déclencheront le même comportement observable. Par exemple, le «login» sur notre application ecinema permet de définir deux classes d équivalence sur les utilisateurs : les utilisateurs enregistrés et les utilisateurs qui ne sont pas enregistrés. Les premiers pourront s identifier (car ils sont enregistrés et possèdent un identifiant et un mot de passe) alors que les seconds ne pourront pas s identifier, et devront s enregistrer au préalable. L objectif de l analyse par classe d équivalence est bien de réduire un espace de données illimité ou de très grande taille (la combinaison des valeurs possibles des attributs de données 40

de l application) en un nombre limité de combinaisons «intéressantes» correspondant aux classes d équivalence retenues. C est une technique fondamentale de la conception de tests fonctionnels. Elle permet de produire une base de test réduite car le choix des paramètres des actions va être guidé par l utilisation d un représentant de la classe d équivalence et la couverture des comportements à tester. L analyse par classe d équivalence s appuie sur différents principes et permet d agréger différentes techniques complémentaires (test aux limites, test par pair) : La détermination des classes d équivalence peut être pilotée par les règles métiers Les règles de gestion applicative fournissent un guide pour l élaboration des classes d équivalence. Par exemple une règle de gestion indiquant le taux de TVA sur différentes classes de produit. Ainsi, une application de gestion d ordres de bourses en ligne prévoyant la tarification des ordres de bourse suivante : ordres de bourse 1500 tarif 7,00, 1500 < ordres de bourse 7500 13,00, ordres de bourse > 7500 13,00 + 0,12 %. Comme le montre la Figure 4-3, l analyse par classe d équivalence conduira à produire trois classes d équivalence correspondant à un partitionnement explicites sur la base des intervalles définis par les règles de gestion. Figure 4-3: Classes d équivalence pour la règle métier «Tarification des ordres de bourse» Les données invalides doivent aussi entrer dans l analyse par classe d équivalence Il est nécessaire d introduire les données «invalides» dans l analyse par classe d équivalence. Ainsi, les classes de données «invalides» conduisent à un comportement d erreur (dit comportement non passant). Elles permettront de concevoir les tests de robustesse, c'est-à-dire les tests intégrant des actions et/ou de paramètres hors du périmètre nominal de fonctionnement et que l application doit traiter sans défaillance (par un message d erreur en général). Pour la règle métier de tarification des ordres de bourse, il sera bien sûr utile de tester une valeur négative et une valeur dépassant le plafond admissible. Les classes d équivalence portent sur les différents types de domaine : numérique, énuméré, mais aussi complexe et structuré L exemple précédent de la tarification des ordres de bourse porte sur une règle de gestion de nature numérique, sur des intervalles d entiers : c est évidemment un cas simple. Mais l analyse par classe d équivalence s applique aussi de façon pertinente sur d autre type de domaines : Sur des types énumérés, par exemple si les conditions d'un état d'entrée d action correspondent à un ensemble de valeurs (série) ou si un sous-ensemble des éléments du type énuméré (série) correspond à un cas qui sera traité de la même façon alors on identifie un représentant valide pour les valeurs de la série et un représentant non valide en dehors de la série. 41

Sur des types structurés par exemple des textes, images, structure graphique, on détermine des caractéristiques communes auxquelles associer des comportements type, chaque caractéristique constituant une classe d équivalence. La détection des valeurs aux limites constitue une extension de l analyse par classe d équivalence Une fois les classes d équivalence établies, il s agit de trouver un (ou plusieurs) représentant type. Une heuristique efficace consiste à choisir des valeurs aux bornes des intervalles considérés (lorsque les domaines sont de nature numérique). Cette technique s appuie sur l hypothèse que de nombreuses erreurs de programmation sont commises sur les conditions des décisions, par exemple une condition inférieure stricte (<) remplacée par une condition inférieure ou égale ( ). Un choix de valeur aux bornes sollicitera la décision erronée et mettra en évidence l anomalie lors de l exécution du test. Les valeurs aux limites sont donc calculées aux bornes, et très proches des bornes : borne + 1 et borne -1 dans le cas de domaine entier, borne + ε (valeur très petite) et borne ε dans le cas de domaine réel. La Figure 4-4 montre les 9 valeurs susceptibles d être exploitées pour le test aux bornes de la règle métier tarification des ordres de bourse. Figure 4-4: Valeurs aux bornes pour la règle métier «Tarification des ordres de bourse» 4.1.4 Combinaison de valeurs Les approches précédentes permettent d identifier et de choisir des valeurs dans des domaines où les données sont analysées une par une. En pratique, lors de la construction du cas de test, à chaque pas du test, il s agit de tester des actions possédant un ensemble de paramètres d entrée et de sortie, et interagissant entre eux. Le test par paire 5 (ou triplet) permet de maîtriser la combinatoire entre valeurs de classes d équivalence dans la construction des données de test. En effet, la combinaison des valeurs des classes d équivalence pour calculer un vecteur de données de test pour une fonction contenant plusieurs paramètres peut rapidement produire un nombre très important de données de tests. Par exemple, le choix d une configuration logicielle où intervient 3 types de systèmes d exploitation (Vista, MacOSX, Linux), 3 types de connexion réseau (câble, wifi, bluetooth), 3 types d explorateur internet (ie, firefox, chrome) et 3 types de base de données (MySQL, SQLserver, Oracle), donnera 3x3x3x3=81 combinaisons (vecteurs de test). L approche par pair consiste à garantir que chaque combinaison de 2 valeurs sera testée. Cela donne sur l exemple précédent 9 vecteurs de test (au lieu de 81). L approche par triplet considère chaque combinaison de 3 valeurs. Ces approches permettent de maîtriser la combinatoire de test dans la gestion de combinaison de données. 5 Le test par pair est appelé «pair-wise» en anglais, a fait l objet de différentes études, à la fois en termes d implémentation algorithmique, et en termes de capacité de détection d anomalies cf www.pairwise.org. 42

Une des limites de l approche par pair, tient au fait que les valeurs ne sont pas, en général, indépendantes, par exemple telle valeur de paramètre est contradictoire avec telle autre. Plusieurs méthodes sont exploitables pour traiter cette interaction entre domaines de valeurs. La méthode par table de décision permet de déterminer l applicabilité des règles en fonction de conditions spécifiques, et donc traiter certaines interactions entre valeurs de paramètres. Par exemple, pour la règle de gestion de la tarification des ordres de bourse vue précédemment, elle peut interagir avec une autre règle qui indique que les clients de catégorie «Business First» bénéficient d une réduction de 10% sur le tarif. La catégorie «Business First» correspond à des clients qui ne passent que des ordres de plus de 7500 et au moins 50 ordres par an. Le Tableau 4-1 fournit la table de décision pour gérer l interaction entre ces règles. Les cas «Business First» et ordre de bourse inférieur à 7500 ne sont pas autorisés, et seront donc testés en cas non passants. Cette table est très simple, mais en tant que telle, les tables de décision sont un bon outil d analyse des interactions entre classes d équivalence. Valeur de l ordre 1 à 1500 1501 à 7499 7500 à valeur plafond Statut «Business Non Non Oui First» Statut Non Oui Oui Oui «Business First» Tableau 4-1: Table de décision La méthode par graphe causes/effets vise à représenter les liens de dépendance entre les valeurs des paramètres. Il s agit d une représentation graphique des entrées ou des stimuli (causes), avec leurs résultats (effets), qui peut être utilisée pour la conception de cas de test pour déterminer la relation des paramètres entre eux. Enfin, et nous le détaillons dans la section 3.3, c est l objectif même de la génération automatique de tests à partir de modèle que de prendre en compte les interactions entre classes d équivalence issues des règles métiers dans le calcul des tests. Les algorithmes des moteurs de calcul de tests permettent d automatiser le calcul des interactions entre règles métiers et l extraction des données logiques pertinentes pour chaque cas de test. Pour aller plus loin dans les différentes techniques de conception de tests fonctionnels, nous vous conseillons l ouvrage de Lee Copeland «A Practitioner s Guide to Software Test Design» [Cope2004]. 4.1.5 Un cas de test est en général constitué d une séquence d actions et de vérifications sur l application En général, un cas de test ne se résume pas à une action simple effectuée sur l application où l on peut vérifier directement les résultats attendus. Il est plutôt constitué d une séquence d actions, chacune pouvant faire l objet de points de vérification du résultat attendu, dans l objectif de couvrir les exigences du cahier des charges. Ainsi, on cherchera à activer chacun des comportements associés ou alors des enchainements de comportements à l aide de scénario d utilisation. Cela se traduira en pratique par une séquence d actions sur l application, pour deux raisons principales : Le test d un comportement donné n est pas forcément réalisable depuis l état courant (ou initial du système) : il est alors nécessaire que le test intègre des étapes de mise en contexte, 43

on nomme cette partie préambule, pour permettre le déclenchement du comportement testé et la vérification du résultat attendu ; Lorsque le comportement testé a été couvert et les résultats attendus vérifiés, il est souvent pertinent de réaliser une séquence d actions pour remettre l application dans un état connu (par exemple à l état initial) de façon à enchaîner le test suivant sans effet de bord avec le test précédent, on nomme cette partie postambule. Ainsi, la structure d un test, de manière générale, peut être vu comme une séquence d actions et de vérification composée de trois parties (cf. Figure 4-5) : Le préambule de test comprend l ensemble des actions permettant la mise en contexte de l application pour tester le (ou les) exigence(s) à couvrir par le test; Le corps de test comprend l ensemble des actions et des vérifications du résultat attendu associées qui permettent de tester le (ou les) exigence(s) à couvrir par le test; Le postambule de test comprend l ensemble des actions permettant de remettre l application dans un état connu permettant d enchaîner le test suivant. Figure 4-5: Structure d un cas de test Chaque action (du préambule, du corps de test, ou du postambule) est aussi appelée pas de test. Un test peut ne pas intégrer de postambule, ou même ne pas nécessiter de préambule. 4.2 Génération automatique de tests à partir de modèle 4.2.1 Principes de la génération de tests La génération automatique de tests à partir d un modèle, s appuie sur les techniques de conception introduites dans la section précédente pour outiller et automatiser la production du référentiel de tests. Le principe général est schématisé dans la Figure 4-6. 44

Figure 4-6: Positionnement de la génération de tests La Figure 4-6 montre les différentes étapes de la construction du référentiel de tests : Les exigences sont définies par les experts métiers et gérées dans un outil spécialisé ou généraliste (cf. chapitre 1) ; Le référentiel de tests est produit par l architecte de test à partir d une modélisation pour la génération de tests et avec la mise en œuvre du générateur de tests ; Les tests générés sont exportés par l outil de génération de tests dans le référentiel de tests flèche. S il s agit de tests nouveaux, ils sont crées dans le référentiel ; s il s agit de tests existants, leur information (description des pas de test, ) est mise à jour dans le référentiel ; si un test est supprimé, il est rendu obsolète (invalidé) dans le référentiel ; Les liens de traçabilité entre les cas de tests et les exigences de test sont mis à jour - flèche ; Dans le cas de la production de tests automatisés, le script de tests est crée (ou mis à jour s il existait déjà) flèche. Le testeur peut ainsi exploiter les tests générés pour l exécution manuelle des tests dans le cadre de la campagne de test en cours. Dans le cas de tests automatisés, les scripts sont générés, et font appels à des fonctions (appelés aussi mots-clés ou composants de tests) qui devront être automatisé (voir section 3.4) par l ingénieur d automatisation, aussi appelé Automaticien de test. Ce processus met en œuvre les compétences des différents acteurs de la chaîne outillée : l expert métier, l architecte de test, le testeur et l automaticien de test. La Figure 4-7 montre les relations entre ces acteurs dans la production et l exploitation du référentiel de test fonctionnel. Il est envisageable qu un même acteur puisse cumuler plusieurs rôles. 45

Figure 4-7: Intervenants dans la production et l exploitation du référentiel de tests 4.2.2 Modélisation pour la génération de tests Comme le montre la Figure 4-6, la génération automatique des tests s appuie sur le modèle de test qui synthétise les comportements à tester de l application. La spécificité de cette modélisation est de traduire une vision comportementale de l application : Les comportements à tester sont modélisés ; Les entités métiers utiles et les données de test sont représentées ; Les actions utilisateurs et les points de vérification sont décrits dans le modèle de test ; Le niveau d abstraction du modèle est directement lié à la stratégie de test définie pour le projet (cf. chapitre 2). Par niveau d abstraction, nous entendons les éléments comportementaux couverts, que ce soient des comportements nominaux (appelés aussi cas passants) ou des comportements d erreurs (appelés aussi cas non passants), mais aussi le niveau de détail avec lequel ils sont représentés. L état de l art en génération automatique de tests [Utting07] montre que différentes notations de modélisation sont utilisées, et en particulier 6 : UML Unified Modeling Language [Rumb2005], qui est devenu le standard de modélisation dans le domaine des systèmes d information, mais qui est aussi une notation très répandue quel que soit le domaine applicatif, La notation propriétaire Simulink - http://www.mathworks.com/products/simulink/ - très utilisée dans le domaine des systèmes embarqués. 6 Il existe d autres notations utilisées, en particulier issues des travaux en méthodes formelles tels que B ou Z par exemple (cf [Utting07]), mais leur utilisation industrielle est plus confidentielle. 46

Dans ce document, nous basons nos exemples sur la modélisation UML, ou plus exactement un sous-ensemble adapté à la génération de tests. En effet, UML constitue une notation de modélisation ciblant toutes les étapes du cycle de vie du logiciel, depuis l expression de besoins, en passant par l architecture, jusqu au déploiement, et intégrant dans sa version courante, UML 2.1, 13 types de diagrammes différents. Figure 4-8: Types de diagrammes UML utilisés pour la génération de tests Ce modèle de test met en œuvre 3 types de diagrammes UML (cf. Figure 4-8): Le diagramme de classes permet la définition des entités métiers (nom d entités, attributs), des relations entre ces entités (par des associations) et les actions réalisées sur l application (par des opérations) ; il s agit d une représentation statique des entités et des points de contrôle et d observation de l application testée ; Le diagramme d états permet de représenter le comportement dynamique de l application : il spécifie les effets des actions de l utilisateur sur l application testée en termes d évolutions des valeurs des attributs des entités métiers. Ainsi, le modèle de test représente le comportement attendu de l application dans les différentes sollicitations dont il peut faire l objet. Le diagramme d objets (aussi appelé diagramme d instances) permet de représenter les données (logique) de test et l état initial de l application au travers d instances du diagramme de classe. A titre d illustration, nous détaillons dans cette section le modèle de test correspondant à notre application fil-rouge ecinema. Les figures suivantes (Figure 4-9, Figure 4-10, Figure 4-11) fournissent le diagramme de classes, d énumération et le diagramme d états associés à cet exemple. 47

Figure 4-9: ecinema Modèle de test Diagramme de classes Le diagramme de classes de l application ecinema (Figure 4-9) fournit d une part les entités métiers (classes «User», «Showtime», «Ticket», «Movie») et d autres part les actions de l utilisateur sur l application au sein de la classe «ECinema» (les opérations «back», «buyticket», «deletealltickets»,.). Figure 4-10: ecinema Modèle de test Diagramme d énumérations Le diagramme d énumérations de l application ecinema (Figure 4-10) fournit les types de données mais aussi les classes d équivalence de données définie pour cette application. Par exemple, pour l utilisateur (énumération «User»), on considère la classe d équivalence des utilisateurs déjà enregistrés («REGISTERED_USER»), et celle des utilisateurs potentiels, pas encore enregistrés («UNREGISTERED_USER»). La classe d énumération MSG décrit au niveau logique chaque valeur de message attendu. 48

Figure 4-11: ecinema Modèle de test Diagramme d états La Figure 4-11 présente le diagramme d états qui spécifie les comportements attendus de l application ecinema. Chaque état («welcome», «register» et «displaytickets») définit une fenêtre de l application. Les transitions entre états spécifient le passage d une fenêtre à l autre, et les transitions internes aux états spécifient les actions réalisées sur une fenêtre de l application. Par exemple, l action «gotoregister» appelle la fenêtre d enregistrement d un nouvel utilisateur, alors que l action «login» reste sur la fenêtre d accueil, tout en autorisant la sélection de séances de cinéma. Il faut noter que l ensemble des comportements à tester est représenté : aussi bien les comportements nominaux (cas passants) dans lesquels l application change d état, que les comportements d erreur (cas non passants). A noter aussi que le diagramme d états supporte la traçabilité des exigences fonctionnelles : chaque comportement (transitions d un état à l autre ou transition interne) est relié à une exigence fonctionnelle. Par exemple, l exigence «Registration» est représentée dans le modèle par 4 transitions : «gotoregister», qui lance la fenêtre d enregistrement, «registration» - cas nominal, lorsque l enregistrement est réalisé, «registration» - Empty_UserName, lorsque l enregistrement est refusé à cause d un nom d utilisateur vide, «registration» - Existing_UserName, lorsque l enregistrement est refusé à cause du choix d un nom d utilisateur déjà existant. Les transitions sont décrites sous la forme UML : Evénement déclencheur [Garde] / Effet de la transition. Le modèle de test doit permettre la génération automatique de tests complets, c'est-à-dire de séquences d actions avec les paramètres d entrée calculés et les valeurs attendues pour la vérification de conformité de l application sous test. Le langage OCL 7 fournit cette précision : il est utilisé pour spécifier les gardes et les effets des transitions du diagramme d états. Par exemple, l opération «login» est spécifiée par une contrainte OCL présentée dans la Figure 4-12. Cette contrainte spécifie quatre cas : 7 OCL Object Constraint Language est le langage standard au sein de la notation UML pour définir des contraintes sur le modèle. Cf [Warm2003] 49

lorsque le mot de passe est correct, alors l utilisateur est identifié et le message «welcome» est affiché, lorsque le mot de passe est incorrect, alors l utilisateur n est pas identifié et le message «wrong_password» est affiché, lorsque le nom de l utilisateur n est pas renseigné, le message affiché est «empty_user_name», lorsque l utilisateur n est pas reconnu, le message affiché est «unknown_user». Figure 4-12: ecinema Modèle de test Définition OCL de l opération «login» A noter que l on trouve au sein de cette modélisation comportementale en OCL le lien entre le comportement modélisé et l exigence couverte au travers d'un élément appelé tag «---@Req: Identifiant d exigence». Un autre type de tag «---@AIM:» permet d indiquer une intention de test associée au détail de chaque comportement, en relation avec les spécifications de tests définis lors de l élaboration de la stratégie de test. Par exemple, l intention «---@AIM: Log_Invalid_Password» spécifie le cas non passant où le mot de passe fourni est invalide. Ces informations (REQ et AIM) sont exploitées lors de la génération de tests d une part pour automatiser la gestion de la traçabilité entre les cas de tests générés et les exigences fonctionnelles, et d autre part pour donner du sens à chaque test généré. 4.2.3 Données de test La sélection des données de test constitue un point clé de la production des tests fonctionnels. Les cas de test et les scripts exécutables associés doivent pouvoir être valorisés sur des jeux de données synchronisés avec la base de recette. En génération de tests, les données logiques sont définies dans le modèle sous la forme d un diagramme d instances. Un diagramme d instances permet de représenter des instances (donc les données de test) liées aux différentes classes du modèle de test. Les figures (de Figure 4-13 à Figure 4-15) présentent les diagrammes d instances définissant les données de test sur le modèle de test de l application ecinema. 50

Figure 4-13: ecinema Modèle de test Définition des données «utilisateurs» Figure 4-14: ecinema Modèle de test Définition des données «séances disponibles» Figure 4-15: ecinema Modèle de test Définition des données «tickets disponibles» Les données de tests logiques ainsi définies sont exploitées lors de la génération automatique de tests pour produire des tests incluant des paramètres d entrées définis et des résultats attendus explicites. Ce niveau de précision des tests calculés permet l automatisation de l exécution des tests et du rendu de verdict (tests en «Succès» ou en «Echec»). 51

A noter que la concrétisation des données de tests logiques en données de test concrètes (physique) peut soit donner lieu à une substitution directe, un pour un, par exemple en associant un utilisateur particulier enregistré issu de la base de test pour le «REGISTERED_USER». La substitution peut aussi être gérée au travers d'une table de données permettant d associer plusieurs valeurs pour un même paramètre et donc créer plusieurs cas de test physique pour un cas de test logique comme le montre la Figure 4-16. Figure 4-16: ecinema Gestion des données Association entre données logique et données concrètes On voit dans cette figure que la classe d équivalence «REGISTERED_USER», définie au niveau du modèle de test, sera instanciée par 3 valeurs concrètes lors de la concrétisation des tests. 4.2.4 Génération automatique des tests Le modèle de test définit l ensemble des comportements attendus à tester sur l application ciblée. Le modèle est exporté depuis l outil de modélisation UML vers l'outil de génération de tests 8. A partir du modèle ecinema et des comportements modélisés par le diagramme d états, la génération automatique des tests réalise une couverture systématique des comportements à tester (appelées «cibles de test»). Chaque test correspond à une séquence d actions sur l application. Cette séquence est structurée en 3 parties : Preambule, Corps de test et Postambule (optionnel). La Figure 4-17 montre la suite de test ecinema générée à partir du modèle de test présenté précédemment. 8 Nous utilisons dans cette section Smartesting Test Designer 3.3 52

Figure 4-17: ecinema Génération de tests Interface de Smartesting Test Designer 3.3 Les comportements modélisés sont couverts par 23 cas de tests en lien avec les exigences fonctionnelles. L interface présentée montre les graphiques de suivi de couverture (en bas de la Figure 4-17) : couverture des exigences et couverture des cibles de test, (c'est-à-dire des comportements à tester). Ces graphiques permettent à l architecte de test de mesurer la couverture fonctionnelle atteinte tant au niveau des exigences fonctionnelles qu au niveau des objectifs de test associés. Dans le cas présent, les cibles et les exigences sont couvertes à 100%. 53

Figure 4-18: ecinema Génération de tests Détail d un test La Figure 4-18 montre le scénario associé au cas de test «deletealltickets» visant à tester la suppression des tickets sélectionnés. La première partie du test, le préambule, crée le contexte (login + sélection ticket 1 + sélection ticket 2 + visualisation des tickets), la deuxième partie, le corps du test, permet de supprimer un ticket et la troisième partie, le postambule, ferme l application pour se remettre dans l état de départ du test. Ce test est totalement généré à partir du modèle par le générateur de tests. Il inclut pour chaque pas de test : les paramètres d entrée des actions utilisées, et les résultats attendus. Le générateur de tests utilise une stratégie permettant de calculer ces éléments à partir d une simulation du modèle de test, mettant en œuvre des algorithmes de recherche pour déterminer la mise en contexte adéquate en fonction de la cible de test. Par exemple, pour le cas de test «deletealltickets», le calcul automatique des pas de tests a déterminé la double sélection de tickets pour se mettre dans le cas où plusieurs tickets sont à supprimer. Le générateur de test automatise ainsi des techniques de conception de test: analyse de classe d équivalence, calcul de chemin à partir des conditions des règles de gestion définies en OCL, calcul de données représentatives, couverture de l ensemble de cibles de test, La stratégie mise en œuvre dans l exemple ecinema (cf. Figure 4-17) vise à couvrir par un test chaque comportement modélisé, et porteur d un objectif de test. 4.2.5 Publication des tests dans le référentiel Les tests ainsi générés sont ensuite publiés dans un référentiel de tests. La Figure 4-19 montre la publication des tests générés sur l application ecinema dans le référentiel de tests HP Quality Center 9.2. 54

Figure 4-19: ecinema Publication des tests Vue Test Plan de HP Quality Center La publication des tests permet d'insérer et de maintenir l ensemble des informations pertinentes pour chaque cas de test : Le panel «Detail» du test qui est complété par l intention de test définie dans le modèle de test (grâce aux tags @AIM positionnés dans le modèle), Le panel «Design Steps» permet de décrire les pas de test structurés en préambule, corps de test et postambule ; la description de chaque pas de test est obtenue grâce à la description des opérations au sein du modèle de test (voir par exemple la description de l opération «login» au sein du modèle de test en Figure 4-20), Le panel «Script» est aussi renseigné lorsqu il s agit de produire des tests automatisés (voir ci-dessous la section automatisation) La traçabilité entre les exigences et les cas de tests est aussi générée et maintenue automatiquement par le générateur de tests au moment de la publication (grâce aux tags @REQ positionnés dans le modèle). 55

Figure 4-20: ecinema Modèle de tests Description de l opération «login» au niveau du modèle de test Conseil : En génération automatique de tests, le référentiel de tests est maintenu à partir du modèle. Lors d évolution fonctionnelle, les cas de test ne sont donc pas modifiés directement dans le référentiel, mais le modèle est mis à jour et les tests re-générés. Seuls les tests modifiés seront impactés par la génération et la publication. Les tests ainsi publiés au sein du référentiel de tests sont également directement exploitables en exécution de tests manuelle par un testeur applicatif. 4.2.6 Génération des scripts de test La génération de tests est une approche basée sur les mots clés 9 : c'est-à-dire que le modèle de test synthétise les comportements associés aux actions de l utilisateur sur l application. Ces actions constituent des mots clés qui sont appelés dans les scripts de test. Par exemple, dans l application ecinema, ces actions sont «login», «buyticket», «deleteticket», «deletealltickets»,. Elles sont définies en tant qu opérations dans le modèle de test en UML (voir Figure 4-9). La Figure 4-21 montre le panel «Test Script» de HP Quality Center pour le test «deletealltickets». Ce script pourra être exécuté avec l automate de test HP QuickTest Professional. Chaque pas de test correspond à un appel de fonction liée avec chaque mot clés modélisé. 9 Approche appelée Keyword based testing dans la littérature internationale sur le test. Nous utilisons aussi le vocable mots d action pour le même concept. 56

Figure 4-21: ecinema Modèle de tests Script du test «deletealltickets» L automatisation consiste donc à définir pour chaque action la suite des contrôles à réaliser sur l interface mise en œuvre avec les outils contenus dans l automate de test. Conseil : En génération automatique de tests, les scripts sont générés automatiquement et maintenu automatiquement avec l outil de génération. Seuls la librairie de fonctions (ou de composants de test) fait l objet d une implémentation et d une maintenance manuelle. En conclusion : Mutation du test fonctionnel - De planche à dessin à la CAO tridimensionnelle la Toute proportion gardée, le test fonctionnel est aujourd hui dans la situation de la conception mécanique au début de la révolution de la CAO 10 : «La CAO décolla dans les années 75-90, lorsque le coût de mise en place d un poste se rapprocha du coût annuel d un dessinateur. La mise en place fut un peu pénible au début en raison d une nécessité de reprendre les plans existants. On s aperçu à cette occasion que statistiquement près de 10% des cotations sur les plans existants étaient inexactes, que des références de plans existaient en double, qu une référence unique pouvait correspondre à plusieurs plans légèrement différents, etc. Au bout du compte, le gain de fiabilité de l information se révéla constituer un argument supplémentaire important décidant à généraliser la CAO. La CAO assure des fonctions très lourdes en calcul numérique : Modélisation numérique Simulation mécanique et calcul des matériaux Représentation graphique 10 Conception Assistée par Ordinateur 57

Dessin de plan Manipulation d objets 3D Gestion de grands assemblages 11» Aujourd hui, c est la totalité des équipements et objets complexes qui nous entourent qui bénéficies de l apport de la CAO. Il serait hors de question de gérer la complexité de la conception d un Airbus A380, ou de la nouvelle génération de TGV avec des planches à dessin (cela serait-il même possible?). Il en est de même pour le test logiciel. La création manuelle d un plan de test géré dans un document Word ne permet pas de passer à l échelle de la complexité des systèmes d information actuels, des applications embarquées ou des progiciels du marché. Et en particulier dans la gestion des évolutions des exigences métiers dans un environnement changeant. Le test fonctionnel est en pleine mutation, avec quelques années de retard sur le développement. Mais tous les indices sont là : le besoin de qualité et les retours d expériences incitent aux changements, les méthodologies basées sur les concepts du «Requirements & Risk based testing» ont beaucoup muri. La chaîne outillée complète, les exigences métiers aux référentiels de test automatisés, a émergé et fourni des solutions matures. Enfin (last but not least), la professionnalisation des métiers du test est en cours permettant ainsi d'accompagner la mutation technologique et psychologique au niveau des compétences et des qualifications. 11 Issu du portail de la CAO - http://www.cao-dao.com/ 58