SALOMÉ Test Management Framework

Table des matières

Introduction Installation de Salomé-TMF Administration Utilisation de Salomé Automatisation

IntroductionSALOMÉ offre des fonctionnalités de création de tests (suivant les concepts de la norme ISO9646) et d'exécution de ces tests. Les tests, qui peuvent être manuels ou automatiques, sont organisés en campagnes et exécutés, avec différents jeux de données, sur des environnements différents. En outre, leur exécution est entièrement automatisable grâce à l'intégration d'un langage de scripts fondé sur JAVA, disponible avec l'un des plug-ins existants.

Table des matières

Introduction o Concepts de base

Exigence Test Suite de tests Famille de tests Jeu de données Campagne de tests Environnement Exécution Anomalie

o Gestion des exigences o Organisation et description des tests o Création des campagnes de test o Exécution des tests o Gestion des anomalies

Concepts de base

ExigenceC'est la description fonctionnelle ou non fonctionnelle d'un élèment de ce que doit faire un système (réponse à un besoin MOA).

TestUn test est l'exécution d'un programme automatique ou d'une séquence d'actions manuelles sur un environnement, pour vérifier qu'il répond à ses spécifications, en identifiant les différences entre les résultats attendus et les résultats obtenus.

Suite de testsC'est un ensemble logique de tests.

Famille de tests

C'est un ensemble de suites de tests.

Jeu de données

C'est un ensemble de paramètres valorisés.

Campagne de tests

C'est un ensemble de tests destinés à être exécutés avec différents jeux de données et dans différents environnements.

Environnement

C'est un ensemble d'éléments décrivant un environnement sous test (cible d'exécution des tests) :

script d'initialisation : exécuté avant le lancement des tests ; script de restitution : exécuté après le lancement des tests ; ensemble de paramètres valorisés : utilisés par les scripts ou les tests eux-

mêmes.

Exécution

C'est l'ensemble "Campagne de test", "Jeux de données", "Environnement" qui peut être lancé et dont les résultats sont archivés et consultables.

Anomalie

Une anomalie (ou bug) est le constat d'une réaction inattendue ou d'une situation non désirée du système.

Gestion des exigencesLes fonctionnalités de gestion des exigences sont implémentées dans Salomé-TMF par un plugin. La documentation de celui-ci est accessible ici.

Organisation et description des testsLa description de tests est volontairement très encadrée dans SALOMÉ et respecte les concepts de la norme ISO9646. Concrètement, les tests sont classés par famille, puis par suite, une suite étant constituée d'un

ensemble atomique de tests (Figure ).

Figure: Plan de testsLes tests sont de type manuel ou automatique. Le test manuel est constitué de la description de différentes actions de test à exécuter, avec, pour chacune d'elles, une vérification à effectuer par un utilisateur réel.

Le test automatique correspond à un script ou un programme de test qui sera exécuté par l'outil qui reportera automatiquement le résultat dans l'exécution correspondante.

Création des campagnes de test

Une fois l'ensemble des tests décrit dans l'outil, il est possible de définir des campagnes de tests (Figure ). Une campagne de tests représente un ensemble de tests possiblement hétérogène vis-à-vis des notions de famille et de suite, que l'on destine à être exécuté sur des environnements sous test, à partir de différents jeux de données.

Figure: Campagne de tests

Exécution des testsLes campagnes de test sont constituées indépendamment des jeux de données et des environnements d'exécution. Pour lancer les tests d'une campagne, il faut associer à celle-ci un environnement d'exécution et un jeu de données.

Ces nouvelles notions d'environnement et de jeux de données permettent de lancer les tests d'une même campagne, sur plusieurs versions d'un environnement sous test, et avec différents jeux de données, et ceci, de façon simple pour l'utilisateur qui est assisté.

Un environnement correspond donc à la cible d'exécution des tests. Il est constitué d'une description, d'un script d'initialisation, et d'un ensemble d'évaluations de paramètres utilisés dans les tests.

Un jeu de données, associé à une campagne, donne une valeur à chacun des paramètres utilisés dans un ou

plusieurs tests. L'exécution (Figure ) définit alors l'association de ces trois éléments : campagne, environnement et jeux de données. Une fois définie, une exécution peut être lancée une ou plusieurs fois et les

résultats des tests lui sont attachés pour chaque lancement.

Figure: Exécution des tests

Gestion des anomaliesLes fonctionnalités de gestion des anomalies sont implémentées dans Salomé-TMF par le plugin Mantis. La documentation de celui-ci est accessible ici.

Administration

Administration de Salomé_TMF

Pour accéder à l'administration de Salomé (Figure ), il faut :

accéder à la page d'accueil en tapant l'URL dans son navigateur ; sélectionner l'onglet "Admin Salomé_TMF" ; sélectionner le login et mot de passe de l'administrateur de Salomé (par défaut

le mot de passe est "admin"); cliquer sur le bouton "Admin Salomé_TMF".

Figure: Connexion à l'administration de Salomé_TMF

Changer le mot de passe de l'administrateur de Salomé_TMFPour accéder au changement du mot de passe de l'administrateur, il faut sélectionner le bouton "Changer le mot de passe". Pour changer le mot de passe de l'administrateur de Salomé_TMF, il faut :

saisir l'ancien mot de passe saisir le nouveau mot de passe confirmer le nouveau mot de passe valider

Gérer les projetsPour accéder à la gestion des projets, il faut sélectionner le bouton "Gérer les projets"

Créer les projetsPour créer un projet, il faut :

cliquer sur le bouton "Créer"; sélectionner l'administrateur de projet dans la liste déroulante; spécifier le nom et la description du projet; valider

Créer un projet à partir d'un projet existantIl est aussi possible de créer un projet par import de données d'un projet existant. La procédure est quasiment identique à la création d'un projet :

cliquer sur le bouton "Créer"; sélectionner l'administrateur de projet dans la liste déroulante; spécifier le nom et la description du projet; cocher la case qui suit le texte "Copier à partir d'un projet existant"; sélectionner le projet à importer dans la liste "A partir du projet"; sélectionner les données du projet à importer parmi :

o les suites de testso les campagnes de testso les utilisateurso les groupes

valider

Modifier un projetIl est possible de modifier le nom et/ou la description du projet :

cliquer sur le bouton "Modifier"; saisir le nom et/ou la nouvelle description du projet; valider

Geler un projetCette fonction a pour but de conserver un projet dans la base sans qu'il soit possible de l'utiliser.

sélectionner un projet dans la liste; cliquer sur le bouton "Geler"; valider

Supprimer un projetPour supprimer un projet, il faut:

sélectionner le projet à supprimer dans la liste; cliquer sur le bouton "Supprimer"; confirmer la suppression

Gérer les utilisateursPour accéder à la gestion des utilisateurs, il faut sélectionner le bouton "Gérer les

utilisateurs" (Figure ), à partir de la fenêtre d'administration de SaloméTMF.

Figure: Vue de la gestion des utilisateurs

Créer un utilisateur

Pour créer un utilisateur (Figure ), il faut :

cliquer sur le bouton "Créer" saisir les champs Login, Nom, Prénom, Email et Mot de passe (le champ

Téléphone est facultatif) valider

Figure: Création d'un utilisateur

Modifier les informations d'un utilisateurPour modifier les informations d'un utilisateur, il faut :

sélectionner un utilisateur dans la liste cliquer sur "Modifier" valider

Supprimer les informations d'un utilisateurPour supprimer un utilisateur, il faut :

sélectionner un utilisateur dans la liste cliquer sur "Supprimer" confirmer la suppression

Changer le mot de passe d'un utilisateurPour changer le mot de passe d'un utilisateur, il faut :

sélectionner un utilisateur dans la liste cliquer sur "Changer le mot de passe" valider

Administration d'un projet

Pour accéder à l'administration d'un projet existant (Figure ) , il faut :

accéder à la page d'accueil en tapant l'URL dans son navigateur ; sélectionner l'onglet "Admin a project" ; sélectionner un projet existant ; sélectionner le login et mot de passe de l'administrateur du projet ; cliquer sur le bouton "Admin Project".

Figure: Administration de projet

Créer les utilisateursPour accéder à la gestion des utilisateurs, il faut sélectionner le bouton "Gérer les

utilisateurs" (Figure ), à partir de la fenêtre d'administration du projet.

Figure: Gestion des utilisateurs d'un projetCette fenêtre présente la liste des utilisateurs du projet. Pour visualiser les propriétés de l'utilisateur, il faut le sélectionner dans la liste. Ses coordonnées et son appartenance aux groupes seront affichés.

Spécifier les groupes auxquels appartient l'utilisateurPour gérer l'appartenance de l'utilisateur sélectionné à des groupes, il faut utiliser les boutons d'ajout ou suppression de groupes présents dans la partie "Propriété" de la fenêtre.

Ajouter ou supprimer un utilisateur

Pour ajouter un utilisateur au projet, il faut (Figure ) :

cliquer sur le bouton "Ajouter" ; sélectionner l'utilisateur voulu ; valider.

Figure: Ajout d'utilisateurs dans un projetNotons que seuls les utilisateurs ayant été créés à partir de l'administration de l'outil sont disponibles.

Pour supprimer un utilisateur, il faut (Figure ) :

sélectionner un utilisateur dans la liste ; cliquer sur le bouton "Supprimer" ; confirmer la suppression.

Créer les groupesPour accéder à la gestion des groupes, il faut sélectionner le bouton "Gérer les groupes"

(Figure ) , à partir de la fenêtre d'administration du projet.

Figure: Gestion des groupes d'un projet

Cette fenêtre (Figure ) permet de :

consulter la liste des groupes existants ; consulter et modifier la liste des utilisateurs appartenant à un groupe ; voir les permissions associées à un groupe prédéfini ou propre au projet ; modifier les permissions associées à un groupe propre au projet ; créer un groupe propre au projet.

Créer un groupe propre au projet

Pour créer un groupe propre au projet il faut (Figure ) :

cliquer sur le bouton "Nouveau" ; spécifier le nom et la description du groupe ; cliquer sur "Valider".

Figure: Ajout d'un groupe dans un projetLe nouveau groupe s'ajoute à la liste des groupes existant et il est possible de modifier les permissions qui lui ont été associées par défaut.

Modifier les permissions associées à un groupe propre au projet

Pour modifier les permissions associées à un groupe propre au projet, il faut (Figure ) :

sélectionner le groupe dans la liste des groupes existants ; cliquer sur "Modifier" ; préciser les droits de "ajout/modification/suppression" de suites de test ; préciser les droits de "ajout/modification/suppression/exécution" de

campagnes de test ; cliquer sur "Valider".

Figure: Administration des perminissions d'un groupe

Utilisation de Salomé Gestion des exigences Gestion des tests Gestion des campagnes Gestion des environnements Gestion des paramètres Gestion des anomalies L'indicateur ICAL

Plugin RequirementsMika�l Marche,Jean-Marie Hallou�t

Le plug-in « Requirements » permet de g�rer dans SALOME-TMF, au sein d'un projet, un repository d'exigences de validation. Ces exigences peuvent �tre associ�es � un ou plusieurs tests, et ainsi, les campagnes sont implicitement (ou explicitement) li�es � v�rification de la satisfaction des ces exigences.

Table des matières

Gestion de l'arbre d'exigences o Ajout/Suppression d'exigences o Chercher/Renommer une exigence

Couverture des exigences par les tests Couverture des exigences par les campagnes Satisfaction des exigences vis- � -vis d'une ex � cution de campagne G � n � ration du dossier des tests

o Lancement du module o La cr � ation du dossier des tests o Retirer les liens exigence-test o Quelques r � gles de gestion

Gestion de l'arbre d'exigencesLe repository d'exigences est formalis� par un arbre infini, tel que chaque n ud de cet arbre est une famille d'exigences et chaque feuille une exigence. Les exigences sont

identifi�es par un nom unique auquel il est possible d'associer une description textuelle, et un ensemble d'attachements (Fichier ou URL).

Ajout/Suppression d'exigences

L'ajout (resp. la suppression) d'exigences est r�alis�e � partir des boutons «  Ajouter Exigences » pour les feuilles /� « Ajouter Branche » pour les noeuds (resp. « Supprimer Exigences »). La suppression d'une exigence d�truit les liens entre l'exigence supprim�e et les tests qui la couvrent, mais les tests sont conserv�s.

Chercher/Renommer une exigence

Le bouton « renommer » permet de renommer une exigence et le bouton « chercher » de trouver une exigence dans l'arbre � partir du noeud s�lectionn�. La recherche d'exigences s'effectue suivant le nom exact de l'exigence ou suivant une expression r � guli � re .

Couverture des exigences par les testsLe plug-in de gestion d'exigences permet d'associer � chaque test du plan de tests, une ou plusieurs exigences, cette association d�finissant la couverture d'une exigence par les tests. Pour r�aliser cette association, � partir de l'onglet « Plug-in Exigences » d'un test (Figure 1), cliquer sur le bouton « utiliser ».

Figure 1: Panel exigences d'un testCette commande ouvre une fen�tre de s�lection (Figure 2), qui contient dans sa partie gauche, les exigences du projet, et dans sa partie droite les exigences couvertes par le test. Pour ajouter (resp. supprimer) une association, utiliser les boutons « -> » (resp.« <- »).

Figure 2: S�lection d'exigencesLe bouton ��Supprimer�� de l'onglet « Plug-in Exigences » d'un test permet de supprimer une couverture d'exigence, en supprimant la liaison entre le test courant, et l'exigence s�lectionn�e dans le tableau.

Le bouton ��Visualiser�� de l'onglet « Plug-in� Exigences » d'un test permet de visualiser les informations de l'exigence s�lectionn�e dans le tableau.

A partir de l'onglet « Plug-in� Exigences » du projet, en s�lectionnant une exigence dans l'arbre, et en choisissant l'information « couverture » (panel droit, Figure : 3), il est possible de visualiser l'ensemble des tests couvrant l'exigence. De la m�me mani�re que pr�c�demment, le bouton « Visualiser » permet de visualiser les informations du test associ�.

Figure 3: Couverture d'une exigenceNotons que la s�lection de la racine de l'arbre d'exigence (Figure : 4), affiche le graphique du taux de couverture de l'ensemble des exigences par les tests. Ce graphique est export� lors de la g�n�ration de document via le plug-in gen-doc-xml.

Figure 4: Couverture des exigences

Couverture des exigences par les campagnesPour chacune des campagnes d'un projet, l'onglet « Plug-in� Exigences » d'une campagne (Figure : 5) r�capitule les exigences couvertes par la campagne (sous forme de tableau) et calcul (sous forme de graphique), le ratio entre les exigences couvertes par la campagne et l'ensemble des exigences du projet. Ce graphique est export� lors de la g�n�ration de document via le plug-in gen-doc-xml.

Figure 5: Couverture des exigences par une campagneLe menu « Outils-> Plug-in� Exigences�->Importer Exigences » permet de d�finir une campagne de tests, non pas directement � partir des tests, mais � partir des exigences. Concr�tement, l'activation de cette fonctionnalit� ouvre une fen�tre de s�lection (Figure :2) qui contient dans sa partie gauche, les exigences du projet couvertes par des tests, et dans sa partie droite les exigences couvertes par la campagne. Pour ajouter (resp. supprimer) une association, utiliser les boutons « �->� » (resp. « �<-� »). L'utilisation de cette

fonctionnalit� � par cons�quence de remplir la campagne de test avec uniquement tous les tests qui couvrent les exigences s�lectionn�es. Attention, l'utilisation de cette fonction dans une campagne contenant des tests, peut avoir comme cons�quence, la suppression de test dans la campagne, si les tests ne couvrent pas les exigences s�lectionn�es.

Satisfaction des exigences vis-�-vis d'une ex�cution de campagneLors de la consultation de r�sultats d'ex�cution d'une campagne, il est possible d'afficher les r�sultats en fonction de la satisfaction des exigences (Figure : 6). Cette fen�tre d�crit sous forme de tableau, pour l'ensemble des exigences couverte par la campagne, si l'exigence est satisfaite ou non. La notion de satisfaction d'exigence est li�e au r�sultat d'ex�cution de l'ensemble des tests li�s � l'exigence. Par exemple, une exigence R1 (resp. R2) couverte par T1 et T2 (resp. T2 et T3) est satisfaite (resp. non satisfaite) si T1 et T2 sont des succ�s (resp. T1 ou T3 est un �chec). Le bouton « d�tail » de la fen�tre permet d'afficher le r�sultat des tests li�s � l'exigence.

Figure 6: Satisfaction des exigences vis-�-vis d'une ex�cutionLe graphique en bas de la fen�tre r�capitule le ratio entre les exigences satisfaites et non satisfaite de la campagne. Ce graphique est export� lors de la g�n�ration de document via le plug-in gen-doc-xml.

G�n�ration du dossier des tests

Lancement du moduleLe module de g�n�ration des tests se pr�sente sous la forme d'une fen�tre de s�lection qui s'ex�cute � partir du bouton « G�n�rer les tests » du menu requirements.

Figure 7: Vue des exigences avec le bouton `G�n�rer les test'Ce module offre deux fonctionnalit�s principales :

1. Il permet de g�n�rer le dossier des tests � partir du dossier des exigences. Les exigences feuilles c'est � dire les exigences feuilles g�n�rent chacune un test. Suite � cette g�n�ration, le lien entre l'exigence et le test est automatiquement ajout�

2. Il permet de retirer des liens aux tests.

La cr�ation du dossier des testsÉtant donn� que le niveau d'arborescence des exigences n'est pas limit�e et que le niveau d'arborescence des tests est limit� � 3 niveaux (famille, suite, test), un algorithme d'aplatissement est utilis�. Toute exigence feuille g�n�re la cr�ation d'un test avec son ascendance (famille,suite).

L'algorithme d'aplatissement se pr�sente comme suit :

Si le niveau d'une exigence est �gal � 1 :

le nom de la famille correspond au nom de la famille par d�faut. Le nom de la suite correspond au nom de la suite par d�faut. Le nom du test correspond au nom l'exigence associ�e de niveau 3 pr�fix� par

'RT_F'.

Prenons l'exemple suivant : (Figure : 9)

Figure 8: G�n�ration test niveau 1 (1/2)qui g�n�re le r�sultat suivant : (Figure : 9)

Figure 9: G�n�ration test niveau 1 (2/2)Si le niveau d'une exigence est �gal � 2 :

le nom de la famille correspond au nom de la branche de niveau 1 pr�fix� par 'RF_'.

Le nom de la suite correspond au nom de la suite par d�faut. Le nom du test correspond au nom l'exigence associ�e de niveau 3 pr�fix� par

'RT_'.

Prenons l'exemple suivant : (Figure : 10)

Figure 10: G�n�ration test niveau 2 (1/2)qui g�n�re le r�sultat suivant : (Figure : 11)

Figure 11: G�n�ration test niveau 2 (2/2)Si le niveau d'une exigence est �gal � 3 :

le nom de la famille correspond au nom de la branche de niveau 1 pr�fix� par 'RF_'.

Le nom de la suite correspond au nom de la branche de niveau 2 pr�fix� par 'RS_'.

Le nom du test correspond au nom l'exigence associ�e de niveau 3 pr�fix� par 'RT_'.

Prenons l'exemple suivant : (Figure : 12)

Figure 12: G�n�ration test niveau 3 (1/2)qui g�n�re le r�sultat suivant : (Figure : 13)

Figure 13: G�n�ration test niveau 3 (2/2)Si le niveau d'une exigence est sup�rieure strictement � 3 :

le nom de la famille correspond au nom de la branche de niveau 1 pr�fix� par 'RF_'.

Le nom de la suite correspond au nom de la branche de niveau 2 pr�fix� par 'RS_'.

Pour l'exigence E_i de niveau i>3, le nom du test correspond � la concat�nation des noms exigences de niveau sup�rieur ou � 3.

Prenons l'exemple ci-dessous : (Figure : )

Figure 14: G�n�ration test de niveau sup�rieur � 3 (1/2)qui g�n�re le r�sultat suivant : (Figure : 15)

Figure 15: G�n�ration test de niveau sup�rieur � 3 (2/2)Une fois la g�n�ration valid�e, les tests sont cr�es en base et li�es � leur exigence respective. Si l'on relance la fen�tre de s�lection apr�s validation, on s'aper�oit que les exigences ne sont plus visibles en partie gauche et les tests cr�es sont bien visibles partie droite.

Retirer les liens exigence-test

La deuxi�me fonctionnalit� offerte par le module de g�n�ration est de pouvoir retirer les liens exigences-tests. Les liens concern�s ne sont que les liens cr�es suite � une g�n�ration automatique des tests et non tous les liens exigence-test. Lors du chargement du module, l'arbre du dossier des tests (� droite) est charg� en prenant en compte l'existence des tests d�j� g�n�r�s qui sont li�es aux exigences. Si l'on s�lectionne un test ou une suite ou une famille et que l'on clique sur le bouton '<-' alors la ou les exigences associ�es r�apparaissent en partie gauche.

Quelques r�gles de gestion

Si vous utilisez des exigences de type � branche � alors aucun test ne pourra �tre g�n�r� dans le dossier des tests.

Tout test g�n�r� poss�de un lien vers une exigence. Cependant, si vous supprimez ce lien ou �ventuellement vous le remplacer par un lien d'une autre exigence, alors ce lien ne sera plus visible par le module de g�n�ration des tests.

Il en est de m�me pour une exigence qui a �t� li�e � un test. Si ce lien est supprim� pour un lien vers un test qui n'a pas le m�me nom alors l'exigence appara�tra comme une exigence non-li� � un test dans le module de g�n�ration du dossier des tests

Enfin, tout renommage d'un test ou d'une exigence impliquera la perte de coh�rence de la bijection exigence <-> test dans le module de g�n�ration du dossier des tests.

Table des matières

Gestion des tests o Ajouter une famille o Ajouter une suite o Ajout d'un test manuel o Ajout de paramètres o Ajouter des actions de tests o Utiliser les paramètres dans les actions o Ajouter des attachements au test

Gestion des tests

Les tests sont organisés (Figure ) dans une arborescence à deux niveaux : Famille et Suite.

Une famille peut contenir des suites et une suite peut contenir des tests, manuels ou automatiques.

Figure: Arbre de test

Ajouter une famille

Pour ajouter une famille (Figure ) :

cliquer sur "Ajouter une famille" ; spécifier le nom et la description de la nouvelle famille ; valider.

Figure: Ajout d'une famille de testsLa nouvelle famille est alors créée sous le répertoire racine "Suites de test".

Ajouter une suite

Pour ajouter une suite (Figure ) :

cliquer sur "Ajouter une suite" ; spécifier le nom et la description de la nouvelle suite ; valider.

Figure: Ajout d'une suite de testsLa nouvelle suite est alors créée :

dans la famille "Famille par défaut" si celle-ci était sélectionnée, si une suite ou un test lui appartenant était sélectionné ou si aucune famille n'était sélectionnée ;

dans une famille existante si celle-ci était sélectionnée, si une suite ou un test lui appartenant était sélectionné ou si aucune famille n'était sélectionnée.

Ajout d'un test manuel

Pour créer un test manuel (Figure ) :

sélectionner la suite dans laquelle le test doit être ajouté ; cliquer sur "Ajouter un test" ; compléter le nom et la description du test ; sélectionner le type "Manuel" ; valider.

Figure: Ajout d'un test manuelLe test est ajouté à la suite qui était sélectionnée. Il reste à le modifier pour le décrire entièrement.

Ajout de paramètres

L'onglet "Paramètre" (Figure ) permet de visualiser les paramètres pouvant être

utilisés par ce test et d'en ajouter de nouveaux (Consulter la section pour plus de détails).

Figure: Onglet des paramètres de test

Ajouter des actions de tests

Pour ajouter une action à un test manuel (Figure ) :

se positionner sur le test ; activer l'onglet "Actions" ; cliquer sur le bouton "Ajouter" ; compléter le nom, la description et le résultat attendu ; ajouter si nécessaire des attachements, fichiers ou URL, auxquels une

description peut être associée ; valider la création de l'action en cliquant sur "Valider" ; renouveler la procédure pour créer d'autres actions.

Figure: Ajout d'une action de test

Utiliser les paramètres dans les actions

Pour utiliser un paramètre dans la description de l'action ou du résultat attendu (Figure ) :

cliquer sur "Paramètre" ; pour utiliser un paramètre existant, cliquer sur "Utiliser" ; pour utiliser un nouveau paramètre, cliquer sur "Nouveau" ; valider.

Figure: Utilisation de paramètre

Ajouter des attachements au test

Il est possible d'attacher des éléments à un test (Figure ). Pour cela :

se positionner sur le test ; activer l'onglet "Attachements" ; cliquer sur le bouton "Ajouter fichier" ou "Ajouter URL" ; indiquer le fichier ou l'URL ; valider.

Figure: Ajout d'attachementIl est ensuite possible d'associer une description à chaque élément attaché et de les visualiser.

Gestion des campagnesA partir de l'onglet "Gestion des campagnes", différentes actions sont possibles :

création/modification de campagnes ; création d'exécution de campagnes ; lancement d'exécution de campagnes ; consultation des résultats.

Créer une campagne

Le bouton "Créer une campagne" (Figure ) permet la création d'une nouvelle campagne.

Figure: Ajout d'une campagne de tests

Ajouter des tests dans une campagne

Pour ajouter des tests dans une campagne (Figure ) :

1. sélectionner la campagne ;2. cliquer sur le bouton "Importer" ;3. la fenêtre qui apparaît permet :

o d'ajouter tous les tests inclus dans les suites de test d'une famille ;o d'ajouter tous les tests appartenant à une suite de test ;o d'ajouter un test particulier.

Figure: Ajout des tests au campagneAprès validation, les tests sont visibles dans la campagne, et organisés dans leurs familles et suites.

Définir un jeu de données pour une campagneIl s'agit de valoriser les paramètres des tests de la campagne, s'il y en a. Pour définir un

jeu de données (Figure ) :

1. sélectionner une campagne ;2. activer l'onglet "Jeux de données". La liste des jeux de données existants

apparaît ;3. cliquer sur le bouton "Ajouter", une fenêtre apparaît :

o nommer le jeu de données ;o décrire le jeu de données ;o donner une valeur pour chacun de ses paramètres ;o valider.

Figure: Ajout d'un jeu de données

Définir une exécution pour une campagnePour lancer les tests d'une campagne, il est nécessaire de lui associer une exécution

(Figure ) possédant un environnement et un jeu de données.

Pour définir une exécution pour une campagne :

1. sélectionner la campagne ;2. sélectionner l'onglet "Exécution" ;3. cliquer sur le bouton "Ajouter", une fenêtre apparaît :

o donner le nom de l'exécution ;o choisir un jeu de données existant ou en créer un nouveau ;o choisir un script d'initialisation qui sera exécuté avant le lancement des

tests ;o choisir un script de restitution qui sera exécuté après le lancement des

tests ;o attacher un ou plusieurs fichiers ou URL ;o décrire l'exécution ;o valider.

Figure: Ajout d'une exécution de campagne

Gérer le lancement des exécutions

Lancer une exécution

Pour lancer une (ou plusieurs) exécution(s) ( Figure ):

sélectionner la campagne correspondante ; activer l'onglet "Exécution" ; sélectionner (les) l'exécution(s) désirée(s) dans la liste des exécutions

existantes ; cliquer sur le bouton "Lancer".

Figure: Lancement d'exécution

Reprendre une exécutionLorsque le lancement d'une exécution a été interrompu, il est possible de le reprendre :

sélectionner la campagne correspondante activer l'onglet "Exécution" sélectionner l'exécution désirée dans la liste des exécutions existantes, la liste

des résultats de son différent lancement apparaît sélectionner un résultat de lancement de l'exécution cliquer sur "Reprendre"

Consulter les résultats du lancement d'une exécution

Pour consulter les résultats d'une exécution (Figure ) :

sélectionner la campagne correspondante ; activer l'onglet "Exécution" ; sélectionner l'exécution désirée dans la liste des exécutions existantes, la liste

des résultats de ses différents lancements apparaît ; sélectionner un résultat de lancement de l'exécution ; cliquer sur "Détails"; les résultats de chaque test de l'exécution apparaissent.

Figure: Consultation des résultats d'exécution

Gestion des environnementsLes environnements permettent de décrire l'environnement d'exécution de tests inclus dans une campagne de test.

La gestion des environnements se fait à partir de l'onglet "Gestion des données" (Figure ).

Figure: Gestion des environnments d'un projet

Ajout d'un nouvel environnement

Cette fonctionnalité, accessible en cliquant sur le bouton "Ajouter" (Figures , ) ,

permet de décrire les éléments constituant un environnement (Figure ).

Figure: Description d'un environnmentLes champs définissant l'environnement sont :

nom de l'environnement ; script : le script choisi sera exécuté avant les tests appartenant à la campagne de

tests correspondante ; description de l'environnement ; paramètres de l'environnement : ces paramètres, une fois valorisés, sont utilisés

dans les tests et éventuellement dans les scripts pouvant être attachés aux environnements et aux exécutions.

Modification d'un environnement

Cette fonctionnalité, accessible en cliquant sur le bouton "Modifier" (Figure ) , permet de modifier l'environnement, à condition que celui-ci n'ait pas déjà été sollicité par une exécution.

Suppression d'un environnement

Cette fonctionnalité, accessible en cliquant sur le bouton "Supprimer" (Figure ), permet de supprimer l'environnement, à condition que celui n'ait pas déjà été sollicité par une exécution.

Définir des paramètres d'un environnementIl est possible, dans un environnement de définir ou d'utiliser des paramètres d'un projet afin de les valuer pour l'exécution de tests. Ces fonctionnalités sont décrites en

sections et .

Gestion des paramètresLa gestion globale des paramètres d'un projet se fait à partir de l'onglet "Gestion des

données" (Figure ), toutefois, comme nous l'avons introduit en section un paramètre peut être créé à partir de différents endroits.

Figure: Gestion des paramètres d'un projetCet onglet permet de :

consulter les paramètres définis sur le projet et utilisés dans les tests ou les environnements ;

créer de nouveaux paramètres ; modifier des paramètres existants en changeant leur description ; supprimer des paramètres.

Création d'un paramètre à partir de l'onglet gestion de donnéesL'ensemble des paramètres utilisables sur un projet est consultable à partir de l'onglet "Gestion des données", en cliquant sur "Paramètres". Il est aussi possible d'ajouter de

nouveaux paramètres en cliquant sur "Nouveau" (Figure ).

Figure: Ajout de paramètres au projet

Pour poursuivre la création du paramètre (Figure : ), il faut le nommer et le décrire avant de cliquer sur "Valider". Le paramètre créé est ensuite utilisable par les tests et les environnements.

Figure: Description d'un paramètre

Création d'un paramètre à partir d'une action de testLors de la description d'une action de test manuel, il est possible de créer un nouveau paramètre qui sera utilisé par l'action de test. Pour cela, à partir de la fenêtre d'ajout

d'une action de test (Figure ), cliquer sur le bouton "Paramètre".

Figure: Utilisation d'un paramètre à partir d'une action

La fenêtre (Figure ) d'ajout de paramètres apparaît, cliquer alors sur nouveau. Il est aussi possible d'utiliser un paramètre existant. Pour cela, sélectionner le paramètre désiré, et valider.

Figure: Vue des paramètres utilisés par un test

Pour terminer la création du paramètre (Figure ) il faut le nommer et le décrire avant de valider.

Figure: Description des paramètres utilisés par un test

Ensuite, pour utiliser le paramètre dans l'action courante (Figure ), sélectionner le paramètre créé dans la liste des paramètres disponibles puis valider.

Figure: Utilisation d'un paramètre

Finalement, (Figure ) le paramètre apparaît dans la description de l'action.

Figure: Vue d'un paramètre dans une action

Création d'un paramètre à partir d'un environnement

A partir de l'onglet "Gestion des données" (Figure ), en sélectionnant "Environnements" et en cliquant sur "Ajouter", il est possible d'ajouter un nouvel environnement pour lequel des nouveaux paramètres peuvent être créés.

Figure: Ajout d'un environnement

La fenêtre d'ajout d'un environnement apparaît (Figure ), cliquer alors sur "Nouveau".

Figure: Création d'un paramètre dans un environnement

Un nouveau paramètre peut être créé (Figure ).

Figure: Déclaration d'un paramètre dans un environnement

Utilisation d'un paramètre dans un environnementL'utilisation dans un environnement de paramètres existants se fait à partir de l'onglet "Gestion des données", en sélectionnant "Paramètres" :

sélectionner un environnement ;

cliquer sur "Modifier", la fenêtre de modification apparaît (Figure ) ;

Figure: Modification d'un environnement cliquer sur "Utiliser", la fenêtre "Utiliser un paramètre existant" apparaît (Figure

).

Figure: Utilisation d'un paramètre dans un environnement sélectionner puis valoriser le paramètre désiré ; valider.

Le paramètre ainsi valorisé est intégré à l'environnement.

Valorisation d'un paramètre

Un paramètre peut également être valorisé par l'intermédiaire d'un jeu de données associé à une exécution. Lors du lancement d'un test possédant un paramètre, la valeur utilisée pour ce paramètre est :

celle donnée pour le paramètre dans l'environnement associé à l'exécution correspondante, si ce paramètre est présent dans cet environnement ;

celle donnée pour le paramètre dans le jeu de données associées à l'exécution correspondante, si ce paramètre n'est pas présent dans l'environnement associé à l'exécution.

Plugin MantisFay�al SOUGRATI

Afin d'offrir la possibilit� d'une gestion des anomalies dans Salom� TMF, un plugin a �t� d�velopp� pour l'outil Open source de gestion des anomalies Mantis.

Table des matières

Installation du plugin Mantis Premi � re � tape : cr � ation du projet et l'utilisateur dans Mantis Saisie/consultation d'une anomalie Consultation des anomalies li � es � un environnement d'ex � cution

Installation du plugin MantisPour installer le plugin Bugzilla, il faut suivre les �tapes suivantes :

1. Installer Mantis (www.mantisbt.org).2. Installer le plugin Mantis (voir la documentation sur l'installation de Salom�

TMF et des plugins).3. Copier le fichier "view_salome_bug_page.php" (se trouvant dans le r�pertoire

d'installation du plugin Mantis) � la racine du r�pertoire d'installation de Mantis.

4. Cr�er un utilisateur distant de la base de donn�es de Mantis pour Salom� TMF :

o Se connecter au serveur MySQL (en ligne de commande) :

> mysql -u root -p;o cr�er l'utilisateur :

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES ON <mantis_db>.* TO <salomeTMF_user>@'%' IDENTIFIED BY '<salomeTMF_password>';

O� : - <mantis_db> : la base de donn�es de Mantis. - <salomeTMF_user> : le login de l'utilisateur. - <salomeTMF_password> : son mot de passe.

5. Ouvrir le fichier "CfgMantis.properties" sous le r�pertoire cfg/ du plugin Mantis, et renseigner les variables suivantes :

o MANTIS_URL_DB : URL de la base de donn�es Mantis.o MANTIS_USER_LOGIN : Login de l'utilisateur distant de la base de

donn�es Mantis cr�� pour Salom� TMF.o MANTIS_USER_PWD : Mot de passe de l'utilisateur.o MANTIS_URL_HTTP : URL de Mantis.o JDBC_DRIVER : Driver JDBC.

Premi�re �tape : cr�ation du projet et

l'utilisateur dans MantisLa premi�re �tape de l'activation du plugin Mantis dans Salom� TMF consiste en la cr�ation du projet et de l'utilisateur dans Mantis. Ces fonctionnalit�s se trouvent dans le menu "Outils" comme le montre la figure suivante :

Apr�s la cr�ation du projet et l'utilisateur dans Mantis, un message invite l'utilisateur � quitter et red�marrer Salom� TMF pour que ces modifications prennent effet.

Saisie/consultation d'une anomalieDurant l'ex�cution d'une campagne, et comme le montre la capture d'�cran suivante, l'utilisateur peut ajouter une anomalie via le sous-menu "Mantis" du menu "Ajouter une anomalie" dans la fen�tre d'ex�cution d'un test :

Une autre fen�tre s'affiche contenant des informations pr�-remplies dans le champs "Description" de l'anomalie que l'utilisateur peut modifier :

Ensuite, appuyer sur le bouton "Envoyer" pour enregistrer l'anomalie dans Mantis. L'utilisateur est alors redirig� vers une page confirmant la cr�ation de l'anomalie dans Mantis uniquement � titre indicatif (pas de traitement � effectuer � ce niveau, l'anomalie est cr�e). Suite � la cr�ation de l'anomalie, un lien est ajout� en attachement au r�sultat d'ex�cution du test, comme le montre la figure suivante :

la visualisation du lien (en rouge dans la figure) ouvre la page qui correspond aux anomalies dans Mantis.

Remarque : L'utilisateur peut �galement saisir une anomalie au niveau de la consultation du r�sultat d'ex�cution via le menu mis en �vidence en bleu dans la capture d'�cran ci-dessus.

Consultation des anomalies li�es � un environnement d'ex�cutionUne autre fonctionnalit� offerte par le plugin Mantis de Salom� TMF est la possibilit� de visualiser tous les anomalies li�es � un environnement d'ex�cution donn�. Cette fonctionalit� est accessible par le sous-menu "Afficher les anomalies" dans l'onglet "Environnements" dans la gestion des donn�es, comme le montre la capture d'�cran ci-dessous :

Remarque : Comme le montre la figure pr�c�dente, le plugin Mantis impl�mente les fonctionnalit�s li�es

au calcul de l'ICAL (Indicateur de Correction Avant Livraison). Ces fonctionnalit�s sont expliqu�es dans le guide utilisateur de Salom�.

La visualisation des anomalies li�es � l'environnement s'effectue par l'interm�diaire de l'interface de Mantis :

Remarque 1 : Comme mis en �vidence en vert dans la figure, l'utilisateur connect�, le projet et l'environnement dans Mantis correspondent � ceux dans Salom� TMF.

Remarque 2 : Pour plus d'informations sur l'utilisation de Mantis, consulter le manuel utilisateur de l'outil disponible ici.

L'indicateur ICALSalomé TMF offre la possibilité de calculer et de suivre l'évolution de l'ICAL (Indicateur de Correction Avant Livraison) : Nombre d'anomalies G0 (critiques) et G1 (majeures) corrigées par rapport au nombre de G0 et G1 découvertes pour une version d'un produit au moment de sa livraison. En effet, pour chaque plugin Salomé TMF de gestion d'anomalies (Mantis par exemple), on peut accéder à ces fonctionnalités via le menu "Outils" comme le montre la figure ci-dessous :

Figure: Fonctionnalités relatives à l'ICAL pour un projetAinsi, il est possible via ce menu de :

calculer la valeur de l'ICAL à un instant donné et éventuellement de sauvegarder cette information dans la base de données.

visualiser l'historique de toutes les valeurs sauvegardées et de supprimer celles qui ne sont plus utiles.

visualiser le graphique de l'évolution de l'indicateur pour chaque environnement du projet. En effet, chaque anomalie étant liée à un environnement, les valeurs de l'ICAL sont calculées pour chaque environnement du projet.

La figure ci-dessous montre un exemple de graphique d'évolution de l'indicateur ICAL d'un projet :

Figure: Exemple de graphique de l'évolution de l'ICAL pour un projet

Remarques :

1. Un menu contextuel est disponible en clic droit sur le graphique, offrant la possiblité d'enregistrer, d'imprimer ou de personnaliser le graphique.

2. Il est également possible de calculer l'ICAL ou d'en visualiser l'évolution pour un environnement donné via le menu "Bug Tracking" comme le met en évidence la figure ci-dessous :

Figure: Fonctionnalités ICAL liées à un environnement

AutomatisationSi l'installation de Salomé comporte des plugins d'exécution automatique de tests et/ou de scripts (environnement et exécution de tests), il est possible de créer des tests et/ou des scripts automatiques qui seront pris en charge par le moteur des plugins.

L'architecture à plugin présente dans Salomé est ouverte, et vous permet ainsi de créer vos propres plugins. Pour plus d'informations sur le développement de plugin consultez le manuel de développement de plugins.

Figure: Plugins présent dans Salomé

Pour consulter les plugins présents dans Salomé, ouvrez l'onget "Plugins" de la fenêtre principale (Figure ). Les Plugins pour les tests automatiques sont du type TestDriver, et ScriptEngine pour les scripts d'environnement ou d'exécution de tests.

Le reste de ce chapitre décrit l'utilisation des plugins d'automatisation dans un cadre général, mais certaines fonctionnalités peuvent varier d'un plugin à l'autre, ainsi, pour plus d'informations sur l'utilisation d'un plugin en

particulier, consultez l'aide correspondante.

Créer un test automatiqueLa procédure de création d'un test automatique est la suivante :

dans l'onglet plan de test (Figure ), sélectionner la suite dans laquelle le test doit être ajouté ;

cliquer sur "Ajouter un test" ; compléter le nom et la description du test ;

sélectionner le type de plugin à utiliser (Figure ) ; valider.

Figure: Choix du driver de test automatiqueLe test est ajouté à la suite qui était sélectionnée. Il reste à définir le code d'exécution lié au plugin pour le

décrire entièrement. Pour cela cliquez sur "Ajouter" dans l'onglet "script" du test (Figure ).

Figure: Ajout d'un script (code) de test automatique

Comme les tests manuels, les tests automatiques peuvent utiliser des paramètres (voir section ) qui seront valués lors des exécutions. Notez, que l'utilisation de paramètres est dépendante du plugin selectionné, consultez ainsi, l'aide du plugin pour plus d'informations.

Modifier un test automatiqueLa modification d'un test automatique, hormis la partie script, est identique à la modification d'un test manuel (nom, description, attachement, paramètres). La modification du script de test est quand à elle dépendante du plugin, et activable dans le

menu script en Figure .

Figure: Modification d'un script (code) de test automatique L'entrée Modifier le Script appelle la fonctionnalité de modification au niveau du

plugin. L'entrée Actualiser le Script met à jour le script dans la base de données de

Salomé. L'entrée SetUp Driver appelle la fonctionnalité de configuration du plugin. L'entrée About Driver affiche les informations du plugin.

Utiliser des scripts dans les environnements et les exécutionsComme les tests automatiques, les environnements et les exécutions peuvent utiliser des scripts automatiques dépendants des plugins de types ScriptEngine.

Lors d'une exécution de campagne de tests, le script d'environnement est exécuté en premier, puis le script d'initialisation de l'exécution, les scripts des tests, et finalement le script de restitution de l'exécution.

La Figure décrit comment ajouter un ou plusieurs scripts à une exécution.

Figure: Ajout de scripts à une exécutionLa modification des scripts d'exécutions et/ou d'environnements est dépendante du plugin utilisé, et est

activable dans les menus Script des exécutions (Figure ) et/ou environnements.

Figure: Modification d'un script (code) d'exécution

Contexte d'exécutionSuivant les plugins utilisés pour décrire les scripts de tests, les scripts d'environnement et d'exécution, le contexte d'exécution des scripts peut être identiques tout au long de l'exécution de la campagne (c'est-à-dire, partage des mêmes références), c'est par exemple le cas avec les plugins Benshell et simpleJunit.

Plus généralement, les scripts de tests, d'exécution et d'environnement possèdent des références sur les variables décrites dans le tableau suivantes (*=org.objectweb.salome_tmf.data) :

Nom Classe Description Disponible

date Java.lang.Date Date de l'exécution T, Env, Ex

time Java.lang.Time Heure de l'exécution T, Env, Ex

salome_projectName Java.lang.String Nom du projet courant T, Env, Ex

salome_projectObject *.ProjectRéférence de l'objet projet de Salomé

T, Env, Ex

salome_debug booleanFaut lors de l'évaluation du script dans l'éditeur

T, Env, Ex

salome_ExecResultObject *.ExecutionResultRéférence sus les résultats d'exécution courant

T, Ex

salome_ExecTestResultObject *.ExecutionTestResultRéférence sur le résultat d'exécution du test courant

T

salome_CampagneName Java.lang.String Nom de la campagne courante T, Env, Ex

salome_CampagneObject *.CampaignRéférence de la campagne courante

T, Env, Ex

salome_environmentName Java.lang.StringNom de l'environnement courant

T, Env, Ex

salome_environmentObject *.EnvironmentRéférence sur l'environnement courant

T, Env, Ex

salome_ExecName Java.lang.String Nom de l'éxécution courante T, Env, Ex

salome_ExecObject *.ExecutionRéférence sur l'exécution courante

T, Env, Ex

salome_TestName Java.lang.String Nom du test courant T

salome_TestObject *.Test Référence sur le test courant T

salome_SuiteTestName Java.lang.StringNom de la suite de tests courante

T

salome_SuiteTestObject *.TestListRéférence sur la suite de tests courante

T

salome_FamilyName Java.lang.String Nom de la famille courante T

salome_FamilyObject *.FamilyRéférence sur la famille courante

T

testLog Java.lang.StringLog de tests à ajouter comme attachement à l'éxécution

T

Verdict Java.lang.StringVerdict du test (pass, fail, unconclusif)

T

salome_classloader Java.net.URLClassLoader Classe loader de BeanShell T, Env, Ex

La colonne disponible décrit où peuvent être utilisées ces variables (T pour les tests, Env pour les Environnements, et Ex pour les Exécutions).

En plus de ces variables, les scripts de tests, d'exécution et d'environnement ont accès aux paramètres valués lors des exécutions par les jeux de données, suivant leur nom et le type Java.lang.String.

l'architecture à plug-ins de SALOMÉ TMFMikaël Marche

Table des matières

Liste des figures Framework "JPF" (Java Plugin Framework)

o Introduction o Architecture

Architecture à plugins de SALOMÉ TMF o Initialisation de JPF o Le plugin "core" et les points d'extension

Fichier manifest du plugin core Activation du plugin core

o Le point d'extension "Common" L'interface "Common" Utilisation des composants graphiques de Salomé TMF par les plug-

ins Composants graphiques de Salomé-TMF

Tutoriel : développement du plugin "bugzilla" o Le fichier Manifest o Implémentation de l'interface "Common"

Liste des figures

1. Architecture du framework JPF 2. Menu outils des plug-ins 3. Onglet plan de test 4. Vue "attachements" (Commune à tous les éléments pouvant avoir des

attachements)5. Vue "Script" pour un test automatique 6. Vue "Paramètres" pour les tests ainsi que dans le panel de gestion des données 7. Vue "Actions" pour un test manuel 8. Onglet campagnes de tests 9. Vue "Exécutions" pour une campagne de test 10. Vue "Jeux de données" pour une campagne de test 11. Fenêtre principale pour la gestion des données 12. Vue "Environnements" dans le panel de gestion des données 13. Fenêtre d'exécution d'un test manuel 14. Fenêtre pour le détail d'un résultat d'exécution d'une campagne de test 15. Fenêtre pour le détail d'un résultat d'exécution d'un test manuel 16. Fenêtre pour l'ajout/modification d'un nouvel environnement

Framework "JPF" (Java Plugin Framework)Ce chapitre présente le framework JPF (Java Plugin Framework) sur lequel s'appuie l'architecture à plugins de Salomé TMF.

IntroductionJPF est le fruit d'un projet Open Source, sous licence LGPL, portant le même nom et accessible dans le portail Source Forge sous le lien http://jpf.sourceforge.net.

ArchitectureLe schéma en Figure 1.1 présente l'architecture générale du framework JPF.

Figure 1.1: Architecture du framework JPF Plugin registry : ensemble d'interfaces qui enregistrent les plugins présents à

partir des méta-information présentes dans le fichier manifest (XML) de chaque plugin. JPF en propose une implémentation standard (standard plugin registry).

Path resolver : composant qui répertorie pour chaque plugin la localisation physique de ses ressources. JPF en propose également une implémentation standard (standard path resolver).

Plugin manager : classe principale du framework qui charge et active les plugins. Une instance "standard" du plugin manager peut être créée en utilisant les implémentations standards du plugin regitry et du path resolver

Architecture à plugins de SALOMÉ TMFCe chapitre présente l'architecture à plugins de Salomé TMF suivant le framework JPF.

Initialisation de JPFCette initialisation est effectuée par la méthode "startJPF" de la classe JPFManager se trouvant dans le package org.objectweb.salome_tmf.plugins. Afin d'initialiser les paramètres nécessaires à JFP, un fichier "properties" est utilisé. Ce fichier est nommé "CfgPlugins.properties" et se trouve dans le sous répertoire "plugins" du répertoire d'installation de Salomé TMF. Il contient le nom du répertoire qui abrite les plugins, la liste des plugins présents ainsi que d'autres paramètres utilisés par le système de trace (log4j).

Une fois ces paramètres initialisés, on crée une table de hachage qui contient autant d'éléments que de plugins, chaque élément ayant la forme suivante :

Clé : fichier manifest Valeur : URL du répertoire contenant les ressources du plugin.Cette table de hachage permet alors de créer un plugin manager comme le montre le code suivant :// Pamameters for PluginManager StringTokenizer PluginsFolders = new StringTokenizer(

props.getProperty(PARAM_PLUGINS_FOLDERS), ",", false); Map pluginLocations = new HashMap(); for (; PluginsFolders.hasMoreTokens();) {

String currentPlgFolder = appliRoot + PluginsFolders.nextToken().trim(); StringTokenizer PluginsList = new StringTokenizer(

props.getProperty(PARAM_PLUGINS_LIST), ",", false); for (; PluginsList.hasMoreTokens();) { String currentPlg = currentPlgFolder + "/" + PluginsList.nextToken().trim(); try { pluginLocations.put(new URL(currentPlg + "/plugin.xml"), new URL(currentPlg)); } catch(Exception e) {

e.printStackTrace(); } } } // New instance of PluginManager PluginManager pluginManager = PluginManager.createStandardManager(pluginLocations);

Le plugin "core" et les points d'extensionLe plugin core est un plugin particulier. En effet; c'est un plugin qui doit être obligatoirement présent, et qui est activé par défaut.

Fichier manifest du plugin coreChaque plugin possède un fichier manifest. C'est un fichier XML qui respecte la DTD spécifiée dans le framework JPF. Pour le plugin "core", Ce fichier est composé de trois parties. La première partie est commune à tous les plugins et se présente de la façon suivante:<plugin id="core" version="0.0.1" class="org.objectweb.salome_tmf.plugins.core.CorePlugin">

Cette entête spécifie l'identificateur du plugin, sa version ainsi que sa classe principale. La deuxième partie du fichier manifest est sous la forme suivante :

<runtime> <library id="core" path="core/core.jar" type="code"> <export prefix="*"/> </library> </runtime>

Cette partie spécifie que le plugin utilise une librairie (core.jar) qui se trouve dans le répertoire "core" (lui-même se trouvant dans le répertoire qui contient les plugins), et que cette librairie est du type "code". Il est également précisé dans cette partie que toutes les classes et packages (*) de ce plugin sont visibles pour les autres plugins qui peuvent par conséquent les utiliser.

La troisième et dernière partie de ce fichier est celle qui est la plus intéressante car elle offre à l'application la possibilité d'être extensible. Il s'agit de la définition des points d'extension du plugin core, c'est-à-dire la manière avec laquelle d'autres plugins peuvent étendre celui-ci. Il n'y pas de restriction sur le nombre de points d'extension pour un plugin.

Cette partie se présente ainsi :

<extension-point id="Common"> <parameter-def id="class"/> <parameter-def id="name"/> <parameter-def id="description"

multiplicity="none-or-one"/> </extension-point>

Ici, un point d'extension nommé "Common" est défini. Il est également précisé que tout plugin qui est extension de ce point doit valoriser trois paramètres :

Le paramètre "class" : c'est le nom de la classe principale du plugin. Le paramètre "name" : il s'agit du nom du plugin. Le paramètre "description" : c'est la description du plugin.

Comme pour les points d'extension, il n'y a pas de restriction sur le nombre de paramètres que l'on peut associer à un point d'extension.

Activation du plugin coreL'activation du plugin core est déclenchée après l'initialisation de JPF et la création d'une instance du plugin manager.

Ensuite, pour chaque point d'extension, une méthode implémentée dans la classe principale du plugin core (org.objectweb.salome_tmf.plugins.core.CorePlugin) permet de récupérer ce point d'extension sous forme d'un objet de type "ExtensionPoint". Voici le code qui effectue ces tâches (source : méthode "startJPF" de la classe org.objectweb.salome_tmf.plugins.JPFManager) :

// Running the "core" plugin Plugin corePlugin = pluginManager.getPlugin("core"); if (corePlugin == null) { throw new Exception("can't get plug-in core"); } // Extension points initialization ExtensionPoint Common = (ExtensionPoint)corePlugin.getClass().getMethod (

"getCommonExtPoint", new Class[] {}).invoke(corePlugin, new Object[] {});

Le point d'extension "Common"Pour chaque point d'extension défini dans le fichier manifest du plugin core, une interface portant le même nom lui est associée dans le package org.objectweb.salome_tmf.plugins.core. Parmi ces interfaces figure l'interface Common.

L'architecture à plugins de Salomé TMF propose ce point d'extension dans le but de fournir une interface générique qui peut être utilisée par la plupart des plugins (sauf dans le cas de plugins spécifiques; plugins pour l'exécution automatique des tests par exemple).

L'interface "Common"Tout plugin qui déclare dans son fichier manifest qu'il est une extension du point Common doit implémenter l'interface org.objectweb.salome_tmf.plugins.core.Common proposée dans Salomé TMF. Cette interface facilite l'accès pour un plugin aux composants graphiques de Salomé TMF, afin qu'il puisse y ajouter ses fonctionnalités.

Cette interface est divisée en deux parties. La première a pour objet les fonctionnalités du plugin qui seront mises dans les menus "Outils" pour les suites de test, les campagnes de test et la gestion de données. La capture d'écran en Figure 2.1 montre un exemple de fonctionnalités de plugins dans un de ces trois menus.

Figure 2.1: Menu outils des plug-insLa deuxième partie de l'interface Common concerne le reste des composants graphiques de Salomé TMF utilisés par le plugin. En effet, le plugin doit spécifier les composants Salomé qu'il utilise ou dans lesquels il rajoute des

fonctionnalités, et dans le dernier cas il doit implémenter la manière avec laquelle ses fonctionnalités doivent être intégrées à Salomé.

Salomé TMF propose une multitude de ses composants graphiques exploitables par des plugins, c'est l'objet de la section 2.3.3.

Utilisation des composants graphiques de Salomé TMF par les plug-insSi un plugin de type Common utilise des composants graphiques de Salomé TMF (autres que les menus outils), il doit implémenter la fonction "getUsedUIComponents()" de l'interface Common qui retourne la liste de ces composants. Afin que l'utilisation de ces composants graphiques soit transparente pour les plugins, les composants de Salomé TMF qui peuvent être utilisés par des plugins ou qui sont susceptibles d'abriter leurs fonctionnalités sont répertoriés.

A chacun de ces composants est associée une constante 2.1.Ainsi, le plugin fournit à l'application Salomé TMF la liste des constantes correspondant aux composants graphiques utilisés, et dans Salomé TMF on active le plugin dans ces objets graphiques selon leur type (statique ou dynamique) via les fonctions : activatePluginInStaticComponent() et activatePluginInDynamicComponent().

Composants graphiques de Salomé-TMFLes Figures de cet section dont la légende est donnée par le Tableau 2.1, illustrent les correspondances entre les objets graphiques de Salomé TMF et les constantes pour l'accès des plug-ins. des composants graphiques de Salomé TMF) :

Tableau 2.1: Légende

Composant graphiques utilisables par les plugins de type Common

Objet A

La constante X correspond à l'objet graphique A qui est de type statique

Objet B

La constante Y correspond à l'objet graphique B qui est de type dynamique

Objet C

La constante Z correspond à l'objet graphique C

qui peut être de type statique ou dynamique selon les cas

Correspondances entre les objets graphiques de Salomé TMF et les constantes de plug-ins

Figure 2.2: Onglet plan de test

(1) Ces composants graphiques sont statiques lorsqu'il s'agit des attachements liés à une suite de test, un test ou une campagne. Ils sont dynamiques dans les autres cas.

Figure 2.3: Vue "attachements" (Commune à tous les éléments pouvant avoir des attachements)

Figure 2.4: Vue "Script" pour un test automatique

Figure 2.5: Vue "Paramètres" pour les tests ainsi que dans le panel de gestion des données

Figure 2.6: Vue "Actions" pour un test manuel

Figure 2.7: Onglet campagnes de tests

Figure 2.8: Vue "Exécutions" pour une campagne de test

Figure 2.9: Vue "Jeux de données" pour une campagne de test

Figure 2.10: Fenêtre principale pour la gestion des données

NB : La vue "Paramètre" dans le panel de gestion des données est la même que la vue "Paramètres" pour les tests

Figure 2.11: Vue "Environnements" dans le panel de gestion des données

Figure 2.12: Fenêtre d'exécution d'un test manuel

Figure 2.13: Fenêtre pour le détail d'un résultat d'exécution d'une campagne de test

NB. : Les objets graphiques de la partie pour les attachements de la précédente fenêtre sont les mêmes que pour tous les éléments ayant des attachements.

Figure 2.14: Fenêtre pour le détail d'un résultat d'exécution d'un test manuel

Figure 2.15: Fenêtre pour l'ajout/modification d'un nouvel environnement

Tutoriel : développement du plugin "bugzilla"Afin d'illustrer le développement d'un plugin de type Common par un exemple, nous allons détailler le développement du plugin "Bugzilla", plugin ayant pour but d'offrir des fonctionnalités de gestion de bug dans Salomé TMF en utilisant le bugtracker Bugzilla2.16.

Le fichier ManifestLa première partie du développement d'un plugin de Salomé TMF consiste en l'écriture du fichier manifest : plugin.xml. Ci-dessous le contenu du fichier manifest du plugin Bugzilla :~ <?xml version="1.0" ?> <!DOCTYPE plugin PUBLIC "-//JPF//Manifest 0.2" "http://jpf.sourceforge.net/plugin_0_2.dtd"> <plugin id="bugzilla" version="0.0.1" class="salomeTMF_plug.bugzilla.BugzillaPlugin"> <requires>

<import plugin-id="core"/> </requires> <runtime> <library id="Bugzilla" path="bugzilla/bugzilla.jar" type="code"/> </runtime> <extension plugin-id="core" point-id="Common" id="bugzilla.Common">

<parameter id="class" value="salomeTMF_plug.bugzilla.BugzillaPlugin"/> <parameter id="name" value="Bugzilla"/> <parameter id="description" value="Plugin Bugzilla"/> </extension> </plugin

La première partie du fichier (après l'entête) précise le nom du plugin, sa version et la classe principale qui étend la classe Plugin.

Ensuite, dans la balise "requires", le plugin déclare le ou les plugins dont la présence est nécessaire pour son activation. Ici, il s'agit du plugin core, puisque le pluing Bugzilla utilise le point d'extension Common.

Dans la balise "runtime", le plugin déclare la liste des librairies utilisées, ainsi que leurs types.

La dernière partie du fichier (balise "extension") précise les informations relatives aux points d'extensions utilisés : plugin fournissant le point d'extension, nom du point d'extension, ainsi que les paramètres spécifiques au point d'extension.

Implémentation de l'interface "Common"La classe d'entrée du plugin, en l'occurrence la classe BugzillaPlugin du package salomeTMF_plug.bugzilla pour le plugin Bugzilla, doit implémenter l'interface Common puisque le plugin utilise le point d'extension Common.

Les fonctions principales de cette classe se composent en deux parties :

fonctions relatives aux menus "Outils" ; fonctions relatives aux autres composants graphiques de Salomé TMF.

En ce qui concerne les menue "Outils" (présents dans les parties "Gestion des tests", "gestion des campagnes" et "Gestion des données"), il existe deux méthodes par menu. Pour la partie "Gestion des tests" par exemple, ces deux méthodes sont les suivantes :

isActivableInTestToolsMenu() : méthode qui renvoie un booléen précisant l'utilisation du menu par le plugin.

activatePluginInTestToolsMenu() : méthode permettant au plugin d'ajouter ces fonctionnalités dans le menu (le menu est passé en paramètre à cette méthode).

Pour ce qui est des fonctionnalités du plugin utilisant d'autres composants graphiques de Salomé TMF (définies en section 2.3.2), il existe quatre méthodes à implémenter par le plugin :

usesOtherUIComponents() : méthode qui retourne un booléen précisant l'utilisation d'autres composants graphiques de Salomé TMF par le plugin.

getUsedUIComponents() : méthode qui retourne la liste (de type java.util.Vector) des composants graphiques utilisés pas le plugin. Ci-dessous un extrait de l'implémentation de cette méthode pour le plugin Bugzilla :

~ public Vector getUsedUIComponents() { Vector uiComponentsUsed = new Vector();

uiComponentsUsed.add(0,UICompCst.MANUAL_EXECUTION_BUTTONS_PANEL); uiComponentsUsed.add(1,UICompCst.ATTACHMENTS_BUTTONS_PANEL);

[?] return uiComponentsUsed; }

activatePluginInStaticComponent () : méthode permettant d'activer le plugin dans les composants graphiques statiques parmi ceux renseignés par la méthode précédente. Le plugin doit préciser dans cette méthode la manière avec laquelle il sera activé selon les composants graphiques. Voici un extrait de cette méthode

pour le plugin Bugzilla :

~ public void activatePluginInStaticComponent(Integer uiCompCst) { if (uiCompCst == UICompCst.DATA_MANAGEMENT_ENV_TABLE) {

environmentTable = (JTable)SalomeTMF.getUIComponent(uiCompCst); return; } if (uiCompCst == [?]) { [?] }

[?] }

activatePluginInDynamicComponent() : idem que la méthode précédente pour les composants graphiques dynamiques de Salomé TMF.

Plugin JUnitMika�l Marche

Junit est une API Java permettant de d�crire des tests unitaires d'une application. Le plugin Junit pr�sent dans Salom�-TMF permet d'ex�cuter automatiquement des tests st�r�otyp�s « TestCase » de Junit.

Table des matières

Cr � er une suite de tests Junit Modifier un test Junit Utilisation d'objets et de param � tres de tests Exemple

o Cr � ation de la suite de tests Junit o Cr � ation de l'environnement sous tests o Lancement de l'ex � cution

Cr�er une suite de tests JunitLe plugin Junit permet cr�er une suite de tests Junit � partir des tests d�clar�s dans un objet st�r�otyp� « TestCase ». Il faut disposer pour cela d'un fichier « .jar » ou « .zip » contenant le code compil� de cet objet.

Il existe deux modes de cr�ation de suite de tests Junit, un mode dit « natif » et un autre li� au plugin BeanShell. Le mode natif utilise la r�flexion Java pour instancier les tests, alors que le mode BeanShell produit des scripts de tests BeanShell qui d�crivent l'instanciation et l'ex�cution de la classes de tests.

Dans le mode natif le fichier « .jar ou .zip » doit contenir en plus de l'objet de test st�r�otyp� « TestCase », l'ensemble des classes n�cessaires � l'ex�cution des tests. Cette restriction est due au principe d'ex�cution du mode natif qui ne peut �tre li� � un script d'environnement ou d'ex�cution pour charger d'autres classes.

Pour cr�er une suite de tests Junit, apr�s avoir s�lectionn� une suite de tests dans le projet, actionner dans le menu « Outils->Plugin junit » la fonctionnalit� « Cr�er une suite de tests Junit ».

Remplissez ensuite le formulaire de cr�ation de classes comme suivant :

A partir de ces informations le plugin Junit analyse la classe de test s�lectionn�e pour produire l'ensemble des tests contenus sous forme de tests automatique dans Salom� (BeanShell ou natif, suivant le mode s�lectionn�).

Modifier un test JunitLa modification d'un test Junit d�pend du mode de cr�ation de la suite de tests. En mode natif, le formulaire de cr�ation permet de modifier les informations « classpath, Tester class, et TestMethod » qui identifient le test. En mode BeanShell, il est possible de modifier le programme d'ex�cution de la classe de test (se reporter pour cela aux informations relatives au plugin BeanShell).

Utilisation d'objets et de param�tres de testsQuelque soit le mode de cr�ation d'un test Junit, il est possible d'utiliser dans la classe de test Junit, les param�tres de tests li�s � une ex�cution et les objets de l'IHM de Salom� (*=org.objectweb.salome_tmf.data).

Nom Classe Description

date Java.lang.Date Date de l'ex�cution

time Java.lang.Time Heure de l'ex�cution

salome_projectName Java.lang.String Nom du projet courant

salome_projectObject *.Project R�f�rence de l'objet projet de Salom�

salome_debug boolean Faut lors de l'�valuation du script dans l'�diteur

salome_ExecResultObject *.ExecutionResultR�f�rence sus les r�sultats d'ex�cution

courant

salome_ExecTestResultObject *.ExecutionTestResultR�f�rence sur le r�sultat d'ex�cution du test

courant

salome_CampagneName Java.lang.String Nom de la campagne courante

salome_CampagneObject *.Campaign R�f�rence de la campagne courante

salome_environmentName Java.lang.String Nom de l'environnement courant

salome_environmentObject *.Environment R�f�rence sur l'environnement courant

salome_ExecName Java.lang.String Nom de l'�x�cution courante

salome_ExecObject *.Execution R�f�rence sur l'ex�cution courante

salome_TestName Java.lang.String Nom du test courant

salome_TestObject *.Test R�f�rence sur le test courant

salome_SuiteTestName Java.lang.String Nom de la suite de tests courante

salome_SuiteTestObject *.TestList R�f�rence sur la suite de tests courante

salome_FamilyName Java.lang.String Nom de la famille courante

salome_FamilyObject *.Family R�f�rence sur la famille courante

testLog Java.lang.StringLog de tests � ajouter comme attachement �

l'�x�cution

En mode Junit natif, si la classe de tests poss�de un constructeur qui prend comme argument une Hashtable, la classe de tests est instanci�e avec ce constructeur et un objet Hashtable qui contient les param�tres de tests valu�s ainsi que les objets pr�c�dents.

import junit.framework.TestCase; import org.objectweb.salome_tmf.data.Environment; import java.util.Hashtable; public class TestParam extends TestCase{ String url_serveur_Env; String Adresse_services_schema_Env; String url_serveur_DS; String Adresse_services_schema_DS; public TestParam(String name) {

System.out.println("Constructor with String used, arg=" + name); } public TestParam(Hashtable params) {

System.out.println("Constructor with Hashtable used, arg=" + params); /*sample to salome_tmf object in Java

Environment env = (Environment)params.get("salome_environmentObject"); /* sample to use environment parameters */ url_serveur_Env = env.getParameterValue("url_serveur"); Adresse_services_schema_Env = env.getParameterValue("Adresse_services_schema"); /* sample to use dataset parameters */ url_serveur_DS = (String) params.get("url_serveur"); Adresse_services_schema_DS = (String) params.get("Adresse_services_schema"); } public void testParam() throws Exception { System.out.println("(env) url_serveur = " + url_serveur_Env); System.out.println("(env) Adresse_services_schema = " + Adresse_services_schema_Env); System.out.println("(DataSet) url_serveur = " + url_serveur_DS);

System.out.println("(DataSet) Adresse_services_schema = " + Adresse_services_schema_DS); } }

En mode BeanShell, l'affectation de la Hashtable se fait � partir d'un appel de m�thode « setParam(Hashtable) » si celle-ci existe dans la classe de tests.import junit.framework.TestCase; import org.objectweb.salome_tmf.data.Environment; import java.util.Hashtable; public class TestParam extends TestCase{ String url_serveur_Env; String Adresse_services_schema_Env; String url_serveur_DS; String Adresse_services_schema_DS; public void setParam(Hashtable params) { /*sample to salome_tmf object in Java Environment env = (Environment)params.get("salome_environmentObject"); /* sample to use environment parameters */ url_serveur_Env = env.getParameterValue("url_serveur"); Adresse_services_schema_Env = env.getParameterValue("Adresse_services_schema"); /* sample to use dataset parameters */ url_serveur_DS = (String) params.get("url_serveur"); Adresse_services_schema_DS = (String) params.get("Adresse_services_schema"); } public void testParam() throws Exception { System.out.println("(env) url_serveur = " + url_serveur_Env); System.out.println("(env) Adresse_services_schema = " + Adresse_services_schema_Env); System.out.println("(DataSet) url_serveur = " + url_serveur_DS);

System.out.println("(DataSet) Adresse_services_schema = " + Adresse_services_schema_DS); } }

ExempleL'exemple suivant pr�sente l'utilisation du plugin Junit en mode natif et Beanshell en utilisant une classe de tests issue de la distribution Junit3.8.1. On consid�re en pr�-requis que l'on dispose de deux fichiers « .jar », l'un contenant le code compil� de la classe � junit.samples.money.MoneyTest �, et l'autre contenant le code compil� de la classe sous tests « junit.samples.money.Money ».

Note : L'exemple utilise les scripts d'environnement pour charger les classes de l'objet sous test, il est possible de ne pas utiliser les scripts d'environnement, si le fichier « .jar » contenant les tests contient aussi les classes de l'objet sous tests.

Cr�ation de la suite de tests JunitSoit le fichier � TestMoney.jar � contenant la classe de tests « junit.samples.money.MoneyTest », on cr�e une suite de tests junit comme suivant :

L'ensemble des tests trouv�s dans cette classe est :

Cr�ation de l'environnement sous testsSoit le fichier « SUTMoney.jar » contenant les classes n�cessaires pour l'ex�cution des tests de la classe « junit.samples.money.MoneyTest ». Il s'agit maintenant de cr�er un environnement dont le script chargera les classes contenues dans le fichier « SUTMoney.jar ». On note que cette op�ration est uniquement n�cessaire si le fichier « TestMoney.jar » ne contient pas toutes les classes n�cessaires � l'ex�cution des tests.

On suppose que l'on a cr�e un environnement « JavaMoney », et on va ajouter � cet environnement un script BeanShell qui chargera les classes du fichier « SUTMoney.jar ». Pour cela, le script d'environnement est le suivant :

addJar("file:/home/marchemi/pub/junit3.8.1/SUTMoney.jar");

On note que le script d'environnement peut charger plusieurs fichiers « .jar », et au besoin faire des traitements en BeanShell.

On note qu'il est aussi possible de modifier le fichier plugin.xml du r�pertoire simpleJunit pour charger un ensemble de librairies Java.

<?xml version="1.0" ?> <!DOCTYPE plugin PUBLIC "-//JPF//Java Plug-in Manifest 0.2" "http://jpf.sourceforge.net/plugin_0_2.dtd"> <plugin id="simpleJunit" version="1" class="salomeTMF_plug.simpleJunit.SimpleJunitPlugin"> <requires> <import plugin-id="core"/> </requires> <runtime>

<library id="simpleJunit" path="simpleJunit/simpleJunit.jar" type="code"/> <library id="junit" path="simpleJunit/libs/HTTPUnits/junit.jar" type="code"/>

<library id="httpjunit" path="simpleJunit/libs/HTTPUnits/httpunit.jar" type="code"/> <library id="xsdlib" path="simpleJunit/libs/libeXist/xsdlib.jar" type="code"/> </runtime> <extension plugin-id="core" point-id="TestDriver" id="simpleJunit.TestDriver"> <parameter id="class" value="salomeTMF_plug.simpleJunit.SimpleJunitPlugin"/>

<parameter id="name" value="Junit"/> <parameter id="description" value="Plugin Junit pour la definition de classe de tests"/> <parameter id="extensions" value=".junit"/> </extension> <extension plugin-id="core" point-id="Common" id="simpleJunit.Common"> <parameter id="class" value="salomeTMF_plug.simpleJunit.SimpleJunitPlugin"/>

<parameter id="name" value="JunitTestSuite"/> <parameter id="description" value="Creation de suite HTTPJunit

TVMoblie"/> </extension> </plugin>

Lancement de l'ex�cutionPour ex�cuter la suite de tests, il suffit de cr�er une campagne comportant les tests Junit, et de lui associer une ex�cution avec l'environnement « JavaMoney ».

Plugin GendocAurore Penault

Le plugin de g�n�ration de documents offre quatre principales fonctionnalit�s s�par�es en deux groupes : d'une part, celles concernant la cr�ation de rapports et d'autre part celles permettant l'�change de donn�es entre diff�rents projets.

Les donn�es g�n�r�es ou export�es concernent le plan de tests, les campagnes et les exigences (si le plugin est pr�sent).

L'acc�s aux fonctionnalit�s du plugin de g�n�ration de documents se fait via le bouton « Outils », pr�sent dans les trois premiers onglets de Salom� : « Gestion des tests », « Gestion des campagnes » et « Gestion des donn�es ».

Le menu « Plugin de g�n�ration de documents » propose via deux sous-menus de g�n�rer le document se rapportant au plan de tests ou de g�n�rer le document des campagnes.

Le menu « Echange de donn�es au format XML » permet soit d'exporter les donn�es d'un projet sous forme de document XML, soit d'importer des donn�es dans un projet � partir d'un document XML.

Table des matières

G � n � rer le document des tests G � n � rer le document des campagnes Exporter les donn � es d'un projet

Importer des donn � es dans un projet D � tails sur l'import des donn � es dans un projet

o Strat � gie g � n � rale o Gestion des suppressions o Importer des donn � es dans un projet Salom �

G�n�rer le document des testsPour g�n�rer le document des tests, il faut tout d'abord s�lectionner le sous-menu « G�n�rer le document des tests ».

Ensuite, une fen�tre � onglets appara�t.

Dans cette fen�tre, le seul champ obligatoire est celui contenant le nom du fichier html r�sultant de la g�n�ration. Dans ce premier onglet, l'utilisateur peut �galement choisir de g�n�rer le rapport de tests en mode multi-frames. Par d�faut, le rapport est g�n�r� en html simple, ce qui est le mode � privil�gier

pour toute impression, en revanche, le mode multi-frames facilite la navigation.

Un deuxi�me onglet permet d'ajouter une mise en forme au rapport de test. Deux options existent : soit la mise en forme est g�n�r�e automatiquement apr�s remplissage d'un formulaire, soit l'utilisateur donne sa propre mise en forme par l'interm�diaire de pages html.

Le formulaire se pr�sente de la fa�on suivante :

Le troisi�me onglet de cette fen�tre propose diff�rentes options. Une premi�re option permet de s�lectionner les tests que l'on veut inclure dans le rapport Les deux options suivantes concernent les graphiques, la premi�re permet d'inclure ou non le graphique r�capitulatif dans le rapport, la deuxi�me permet de s�lectionner le mode, noir et blanc ou couleur, en cas d'impression. La derni�re option propos�e concerne l'inclusion des fichiers attach�s.

Le bouton "S�lection des tests..." ouvre une fen�tre qui permet de s�lectionner des tests. Cette fen�tre se d�coupe en deux parties. La premi�re, � gauche, contient l'ensemble du plan de tests et la deuxi�me, � droite, contient les tests s�lectionn�s. Pour ajouter ou supprimer des tests � la s�lection, il suffit de s�lectionner des tests (ou des familles ou des suites) dans l'une ou l'autre des parties puis de cliquer sur la fl�che correspondante. Par ailleurs, les touches "Shift" et "Ctrl" peuvent �tre utilis�es pour faire de la s�lection multiple.

G�n�rer le document des campagnesPour g�n�rer le document des campagnes, il faut tout d'abord s�lectionner le sous-menu « G�n�rer le document des campagnes ».

Comme pour la g�n�ration du document se rapportant aux tests, le seul champ obligatoire est celui qui indique le nom du fichier r�sultat. Dans l'onglet principal de cette fen�tre, le choix peut �tre fait de ne pas inclure les ex�cutions ou les r�sultats d'ex�cutions dans le rapport. Une option permet �galement de g�n�rer le rapport en html multi-frames, ce qui facilite la navigation dans le document.

L'onglet mise en forme est le m�me que celui de la g�n�ration du document pour les tests, il permet d'int�grer une mise en page soit en remplissant un formulaire soit en int�grant ses propres documents html au rapport.

Ce dernier onglet pr�sente diff�rentes options. Une premi�re option de filtrage permet de s�lectionner les diff�rentes campagnes et ex�cutions � int�grer dans le document r�sultant. Une autre option permet de s�lectionner les graphiques r�capitulatifs � inclure dans le document. Enfin, l'utilisateur peut choisir d'inclure le contenu des fichiers attach�s, suivant le type des fichiers, dans le rapport.

Exporter les donn�es d'un projetCette option du plugin de g�n�ration de documents permet d'exporter les donn�es au format XML. Pour exporter les donn�es, il suffit de s�lectionner le sous-menu « Exporter au format XML ».

Ensuite, la donn�e du nom du fichier XML r�sultat est suffisante � l'export de donn�es. L'utilisateur poss�de n�anmoins deux options : soit il exporte toutes ses donn�es, c'est-�-dire l'ensemble du plan de tests mais aussi les campagnes contenues dans son projet. Soit il choisit de n'exporter que le plan de tests et dans ce cas, il peut �galement choisir les tests � exporter.

Importer des donn�es dans un projetCette option du plugin de g�n�ration de documents permet d'importer des donn�es issues d'un fichier XML dans un projet. On acc�de � cette fonctionnalit� gr�ce au sous-menu « Importer des donn�es � partir d'un fichier XML ».

L'onglet principal permet d'indiquer le fichier XML � partir duquel l'import des donn�es doit �tre fait. Il permet �galement de choisir d'importer uniquement les donn�es du plan de tests. Dans ce cas, l'utilisateur peut �galement s�lectionner les tests � importer.

Le deuxi�me onglet propose plusieurs options pour l'import des donn�es. Les deux premi�res options concernent la suppression des donn�es du projet qui n'apparaissent pas dans le document XML. Si la premi�re option est coch�e, les donn�es du projet qui n'apparaissent pas dans le document XML sont supprim�s, cette option ne concerne pas les actions d'un test manuel et les donn�es relatives � cette action. La s�lection de la deuxi�me option entra�ne la suppression des actions des tests manuels et des donn�es qui lui sont rattach�es, dans le cas o� ils n'apparaissent pas dans le document d'import.

Lorsque des tests ont �t� ex�cut�s, certaines donn�es ne peuvent plus �tre modifi�es. Dans ce cas, le traitement d�pend de l'option s�lectionn�e. Soit l'utilisateur choisit de conserver les donn�es de son projet telles quelles et de copier les donn�es dans son projet avec un nom pr�fix� par "copy_", soit seule la mise � jour des donn�es qui ne sont pas sources de conflit est demand�e, soit l'utilisateur choisit de conserver les donn�es de son projet telles quelles.

D�tails sur l'import des donn�es dans un

projet

Strat�gie g�n�raleLorsque les donn�es sont pr�existantes dans le projet, une mise � jour de ces donn�es est effectu�e. Sinon, elles sont ajout�es, en conservant les r�f�rences avec l'existant. Pour les propri�t�s des donn�es, les donn�es mises � jour conservent les informations du cr�ateur et les donn�es nouvelles ont comme cr�ateur l'utilisateur en cours.

Avant l'import des donn�es, l'utilisateur peut choisir des options qui sont valables en cas de conflit avec les donn�es existantes dans le projet courant :

Conserver les donn�es de son projet et importer les donn�es conflictuelles en pr�fixant leurs noms par "copy_".

Mettre � jour les �l�ments possibles (description et attachements des tests, scripts des tests automatiques, attachements des actions...).

Conserver les donn�es du projet courant et ne rien faire de plus.

Gestion des suppressionsAvant l'import de donn�es, l'utilisateur peut choisir des options qui lui permettront de supprimer les donn�es de son projet qui ne sont pas dans le document XML. Il faut noter que ces options entra�nent une suppression des donn�es avant tout import du document XML, elles peuvent donc permettre de supprimer des conflits. La premi�re option permet de supprimer toutes les donn�es du projet qui n'apparaissent pas dans le document d'import. Cette option ne concerne pas les actions et les donn�es relatives aux actions. Si l'utilisateur veut supprimer ces informations, il doit cocher la deuxi�me option. Les deux options de suppressions peuvent �tre actives ou inactives ind�pendamment l'une de l'autre.

ProjetPour le projet, les donn�es suivantes qui ne sont pas dans le document XML sont supprim�es :

param�tres du projet ; environnements ;

o param�tres valu�s dans l'environnement ;o script de l'environnement ;o attachements de l'environnement.

TestsDans le plan de tests, on supprime �galement les diff�rentes donn�es qui n'apparaissent pas dans le document XML :

familles ; suites :

o attachements de la suite. tests :

o param�tres du test ;o attachements du test ;o script du test si celui-ci est automatique ;o si le test est manuel et que la deuxi�me option de suppression est active,

les actions non pr�sentes dans le document XML sont supprim�es : ainsi que les param�tres des actions ; et enfin, les attachements des actions.

Pour les tests manuels, si la suppression des actions est effectu�e, les param�tres du test qui ne sont plus utilis�s du fait de cette action, sont �galement supprim�s.

CampagnesPour les campagnes, la strat�gie est un peu diff�rente. En effet, lorsque l'utilisateur cr�e des ex�cutions, un nom est propos� � l'utilisateur. Le nom des ex�cutions peut donc �tre identique dans le fichier XML et dans le projet Salom� mais en fait correspondre � deux ex�cutions diff�rentes. Lors de l'import des donn�es, deux ex�cutions seront alors cr��es, l'ex�cution pr�sente dans le projet Salom� ne doit donc pas �tre modifi�e. Le raisonnement est identique pour les r�sultats d'ex�cution, l'outil proposant �galement un nom de r�sultat par d�faut lors de la cr�ation de ce r�sultat.

Les donn�es supprim�es sont :

les campagnes ; les jeux de donn�es associ�s aux campagnes ; les attachements des campagnes ; les tests appartenant aux campagnes ; les ex�cutions qui n'ont pas le m�me nom qu'une ex�cution existante dans le

document XML ; es r�sultats d'ex�cution qui n'ont pas le m�me nom qu'un r�sultat

d'ex�cution pr�sent dans le XML.

Importer des donn�es dans un projet Salom�Lors de l'import, les donn�es non pr�sentes dans le projet sont ajout�es, sinon elles sont mises � jour.

ProjetLes param�tres du projet qui n'�taient pas pr�sents dans le projet sont ajout�s, sinon leur description est mise � jour.

Pour les environnements, les donn�es ajout�es ou mises � jour sont :

le nom et la description de l'environnement ; les param�tres de l'environnement ; le script de l'environnement ; les attachements de l'environnement.

TestsPour les familles de test, il n'y a aucune pr�caution particuli�re � prendre, les donn�es sont ajout�es ou mises � jour suivant les cas. Les donn�es qui concernent les familles sont leur nom et leur description.

Les donn�es � mettre � jour ou � ajouter pour les suites de tests sont leur nom, leur description et leurs �ventuels attachements.

Pour les tests eux-m�mes, deux cas sont possibles :

Soit le test n'appartient pas au projet Salom� courant, dans ce cas, on ajoute toutes les informations li�es � ce test : nom, description, ordre, login du concepteur, attachements, param�tres, type de test (manuel ou automatique). Si c'est un test manuel, on ajoute �galement les actions avec leurs param�tres et leurs attachements. Si c'est un test automatique, on ajoute le script du test automatique.

Sinon, une d�tection de l'existence ou non d'un conflit est effectu�e. Dans le cas o� le test � importer dans le projet courant appartenait d�j� au plan de test, on doit d�tecter s'il existe un conflit pour la mise � jour des donn�es de ce test. Il peut y avoir un conflit lorsque le test fait partie d'une campagne dont il existe un r�sultat d'ex�cution pour ce test. Le conflit n'est vraiment r�el que lorsqu'il existe des donn�es � modifier dans le projet telles que les param�tres du test, les actions d'un test manuel... Les mises � jour qui ne sont pas sources de conflit sont : la mise � jour des attachements du test ou des actions d'un test manuel, la mise � jour de la description du test ou enfin, la mise � jour du script d'un test automatique. Les mises � jour qui sont sources de conflit sont donc : la mise � jour des param�tres du test, la mise � jour des actions, c'est-�-dire un ajout ou une suppression d'action mais aussi la mise � jour de la description des actions, de leur r�sultat attendu ainsi que leurs param�tres.

CampagnesLa strat�gie g�n�rale d'import des donn�es est la m�me que pour les tests, mais il existe quelques diff�rences au niveau de la gestion des jeux de donn�es, des ex�cutions et des r�sultats d'ex�cution, dues au fait que l'outil propose des noms par d�faut pour ces diff�rentes donn�es.

Par ailleurs, une v�rification de la pr�sence ou non d'un conflit est effectu�e avant tout import de donn�es. Un conflit est d�tect� lorsque la campagne qui doit �tre import�e a le m�me nom qu'une campagne du projet, mais elle contient de nouveaux tests. Si un conflit est d�tect�, l'import s'effectue en fonction de

l'option s�lectionn�e par l'utilisateur.

Pour les campagnes, les ajouts et les mises � jour concernent la description des campagnes, ses attachements, les jeux de donn�es qui lui sont associ�es ainsi que les tests qui lui appartiennent. Pour les jeux de donn�es, il faut v�rifier que ceux qui ont le m�me nom sont exactement les m�mes. Pour cela, on v�rifie que les diff�rents param�tres valu�s dans les jeux de donn�es du projet et du document XML sont les m�mes et qu'ils ont la m�me valeur. S'ils se r�v�lent diff�rents, alors on cr�e un nouveau jeu de donn�es avec le m�me nom que l'ancien suffix� par "_Bis".

Pour les mises � jour des donn�es d'une ex�cution, il faut v�rifier que les ex�cutions qui ont le m�me nom dans le document XML et dans le projet sont vraiment les m�mes. On v�rifie donc que l'ex�cution analys�e poss�de exactement le m�me jeu de donn�es avec les m�mes valeurs pour chaque param�tre. Une v�rification est �galement faite au niveau de l'environnement et des scripts de l'ex�cution. Si les ex�cutions s'av�rent diff�rentes, on en cr�e alors une autre qui aura comme nom le m�me nom que l'ex�cution de d�part suffix� par "_Bis".

Pour les r�sultats d'ex�cution, comme l'outil propose �galement des noms par d�faut, il faut v�rifier que les r�sultats sont identiques. Pour cela, une recherche des diff�rences est effectu�e au niveau des r�sultats d'ex�cution des tests, mais aussi au niveau des r�sultats des ex�cutions de chaque action s'il s'agit d'un test manuel. Comme pour les jeux de donn�es et les ex�cutions, si les r�sultats d'ex�cutions sont diff�rents, on cr�e un autre r�sultat d'ex�cution avec comme nom l'ancien r�sultat d'ex�cution suffix� par "_Bis".