SALOM Test Management Framework

Table des matires

Introduction Installation de Salom-TMF Administration Utilisation de Salom Automatisation

Introduction
SALOM offre des fonctionnalits de cration de tests (suivant les concepts de la norme ISO9646) et d'excution de ces tests. Les tests, qui peuvent tre manuels ou automatiques, sont organiss en campagnes et excuts, avec diffrents jeux de donnes, sur des environnements diffrents. En outre, leur excution est entirement automatisable grce l'intgration d'un langage de scripts fond sur JAVA, disponible avec l'un des plug-ins existants.

Table des matires

Introduction o Concepts de base Exigence Test Suite de tests Famille de tests Jeu de donnes Campagne de tests Environnement Excution Anomalie o Gestion des exigences o Organisation et description des tests o Cration des campagnes de test o Excution des tests o Gestion des anomalies

Concepts de base

Exigence
C'est la description fonctionnelle ou non fonctionnelle d'un lment de ce que doit faire un systme (rponse un besoin MOA).

Test
Un test est l'excution d'un programme automatique ou d'une squence d'actions manuelles sur un environnement, pour vrifier qu'il rpond ses spcifications, en identifiant les diffrences entre les rsultats attendus et les rsultats obtenus.

Suite de tests
C'est un ensemble logique de tests.

Famille de tests
C'est un ensemble de suites de tests.

Jeu de donnes
C'est un ensemble de paramtres valoriss.

Campagne de tests
C'est un ensemble de tests destins tre excuts avec diffrents jeux de donnes et dans diffrents environnements.

Environnement
C'est un ensemble d'lments dcrivant un environnement sous test (cible d'excution des tests) :

script d'initialisation : excut avant le lancement des tests ; script de restitution : excut aprs le lancement des tests ; ensemble de paramtres valoriss : utiliss par les scripts ou les tests euxmmes.

Excution
C'est l'ensemble "Campagne de test", "Jeux de donnes", "Environnement" qui peut tre lanc et dont les rsultats sont archivs et consultables.

Anomalie
Une anomalie (ou bug) est le constat d'une raction inattendue ou d'une situation non dsire du systme.

Gestion des exigences

Les fonctionnalits de gestion des exigences sont implmentes dans Salom-TMF par un plugin. La documentation de celui-ci est accessible ici.

Organisation et description des tests

La description de tests est volontairement trs encadre dans SALOM et respecte les concepts de la norme ISO9646. Concrtement, les tests sont classs par famille, puis par suite, une suite tant constitue d'un ensemble atomique de tests (Figure ).

Figure: Plan de tests

Les tests sont de type manuel ou automatique. Le test manuel est constitu de la description de diffrentes actions de test excuter, avec, pour chacune d'elles, une vrification effectuer par un utilisateur rel. Le test automatique correspond un script ou un programme de test qui sera excut par l'outil qui reportera automatiquement le rsultat dans l'excution correspondante.

Cration des campagnes de test

Une fois l'ensemble des tests dcrit dans l'outil, il est possible de dfinir des campagnes de tests (Figure ). Une campagne de tests reprsente un ensemble de tests possiblement htrogne vis--vis des notions de famille et de suite, que l'on destine tre excut sur des environnements sous test, partir de diffrents jeux de donnes.

Figure: Campagne de tests

Excution des tests

Les campagnes de test sont constitues indpendamment des jeux de donnes et des environnements d'excution. Pour lancer les tests d'une campagne, il faut associer celle-ci un environnement d'excution et un jeu de donnes.
Ces nouvelles notions d'environnement et de jeux de donnes permettent de lancer les tests d'une mme campagne, sur plusieurs versions d'un environnement sous test, et avec diffrents jeux de donnes, et ceci, de faon simple pour l'utilisateur qui est assist. Un environnement correspond donc la cible d'excution des tests. Il est constitu d'une description, d'un script d'initialisation, et d'un ensemble d'valuations de paramtres utiliss dans les tests. Un jeu de donnes, associ une campagne, donne une valeur chacun des paramtres utiliss dans un ou plusieurs tests. L'excution (Figure ) dfinit alors l'association de ces trois lments : campagne, environnement et jeux de donnes. Une fois dfinie, une excution peut tre lance une ou plusieurs fois et les rsultats des tests lui sont attachs pour chaque lancement.

Figure: Excution des tests

Gestion des anomalies

Les fonctionnalits de gestion des anomalies sont implmentes dans Salom-TMF par le plugin Mantis. La documentation de celui-ci est accessible ici.

Administration Administration de Salom_TMF

Pour accder l'administration de Salom (Figure

), il faut :

accder la page d'accueil en tapant l'URL dans son navigateur ; slectionner l'onglet "Admin Salom_TMF" ; slectionner le login et mot de passe de l'administrateur de Salom (par dfaut 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_TMF

Pour accder au changement du mot de passe de l'administrateur, il faut slectionner 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

Grer les projets

Pour accder la gestion des projets, il faut slectionner le bouton "Grer les projets" Crer les projets Pour crer un projet, il faut :

cliquer sur le bouton "Crer"; slectionner l'administrateur de projet dans la liste droulante; spcifier le nom et la description du projet; valider

Crer un projet partir d'un projet existant Il est aussi possible de crer un projet par import de donnes d'un projet existant. La

procdure est quasiment identique la cration d'un projet :

cliquer sur le bouton "Crer"; slectionner l'administrateur de projet dans la liste droulante; spcifier le nom et la description du projet; cocher la case qui suit le texte "Copier partir d'un projet existant"; slectionner le projet importer dans la liste "A partir du projet"; slectionner les donnes du projet importer parmi : o les suites de tests o les campagnes de tests o les utilisateurs o les groupes valider

Modifier un projet Il 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 projet Cette fonction a pour but de conserver un projet dans la base sans qu'il soit possible de l'utiliser.

slectionner un projet dans la liste; cliquer sur le bouton "Geler"; valider

Supprimer un projet Pour supprimer un projet, il faut:

slectionner le projet supprimer dans la liste; cliquer sur le bouton "Supprimer"; confirmer la suppression

Grer les utilisateurs

Pour accder la gestion des utilisateurs, il faut slectionner le bouton "Grer les utilisateurs" (Figure ), partir de la fentre d'administration de SalomTMF.

Figure: Vue de la gestion des utilisateurs Crer un utilisateur Pour crer un utilisateur (Figure

), il faut :

cliquer sur le bouton "Crer" saisir les champs Login, Nom, Prnom, Email et Mot de passe (le champ Tlphone est facultatif) valider

Figure: Cration d'un utilisateur Modifier les informations d'un utilisateur Pour modifier les informations d'un utilisateur, il faut :

slectionner un utilisateur dans la liste cliquer sur "Modifier" valider

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

slectionner un utilisateur dans la liste cliquer sur "Supprimer" confirmer la suppression

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

slectionner un utilisateur dans la liste cliquer sur "Changer le mot de passe" valider

Administration d'un projet

Pour accder l'administration d'un projet existant (Figure

) , il faut :

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

Figure: Administration de projet

Crer les utilisateurs

Pour accder la gestion des utilisateurs, il faut slectionner le bouton "Grer les utilisateurs" (Figure ), partir de la fentre d'administration du projet.

Figure: Gestion des utilisateurs d'un projet

Cette fentre prsente la liste des utilisateurs du projet. Pour visualiser les proprits de l'utilisateur, il faut le slectionner dans la liste. Ses coordonnes et son appartenance aux groupes seront affichs.

Spcifier les groupes auxquels appartient l'utilisateur Pour grer l'appartenance de l'utilisateur slectionn des groupes, il faut utiliser les boutons d'ajout ou suppression de groupes prsents dans la partie "Proprit" de la fentre. Ajouter ou supprimer un utilisateur Pour ajouter un utilisateur au projet, il faut (Figure

):

cliquer sur le bouton "Ajouter" ; slectionner l'utilisateur voulu ; valider.

Figure: Ajout d'utilisateurs dans un projet

Notons que seuls les utilisateurs ayant t crs partir de l'administration de l'outil sont disponibles.

Pour supprimer un utilisateur, il faut (Figure

):

slectionner un utilisateur dans la liste ; cliquer sur le bouton "Supprimer" ; confirmer la suppression.

Crer les groupes

Pour accder la gestion des groupes, il faut slectionner le bouton "Grer les groupes" (Figure ) , partir de la fentre d'administration du projet.

Figure: Gestion des groupes d'un projet

Cette fentre (Figure

) permet de :

consulter la liste des groupes existants ; consulter et modifier la liste des utilisateurs appartenant un groupe ; voir les permissions associes un groupe prdfini ou propre au projet ; modifier les permissions associes un groupe propre au projet ; crer un groupe propre au projet.

Crer un groupe propre au projet Pour crer un groupe propre au projet il faut (Figure

):

cliquer sur le bouton "Nouveau" ; spcifier le nom et la description du groupe ; cliquer sur "Valider".

Figure: Ajout d'un groupe dans un projet

Le nouveau groupe s'ajoute la liste des groupes existant et il est possible de modifier les permissions qui lui ont t associes par dfaut.

Modifier les permissions associes un groupe propre au projet

Pour modifier les permissions associes un groupe propre au projet, il faut (Figure ):

slectionner le groupe dans la liste des groupes existants ; cliquer sur "Modifier" ; prciser les droits de "ajout/modification/suppression" de suites de test ; prciser les droits de "ajout/modification/suppression/excution" 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 paramtres Gestion des anomalies L'indicateur ICAL

Plugin Requirements
Mika 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 matires

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'exigences

Le repository d'exigences est formalispar 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 tests

Le 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 test

Cette 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'exigences

Le 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-inExigences 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 exigence

Notons 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 campagnes

Pour chacune des campagnes d'un projet, l'onglet Plug-inExigences 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 campagne

Le menu Outils-> Plug-inExigences ->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 campagne

Lors 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 cution

Le graphique en bas de la fen tre r capitule le ratio entre les exigences satisfaites et non satisfaite de la campagne. Ce graphique est exportlors de la g n ration de document via le plug-in gen-doc-xml.

G n ration du dossier des tests

Lancement du module
Le 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 donnque le niveau d'arborescence des exigences n'est pas limit e et que le niveau d'arborescence des tests est limit3 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 fixpar '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 fixpar '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 fixpar '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 fixpar 'RF_'. Le nom de la suite correspond au nom de la branche de niveau 2 pr fixpar 'RS_'. Le nom du test correspond au nom l'exigence associ e de niveau 3 pr fixpar '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 fixpar 'RF_'. Le nom de la suite correspond au nom de la branche de niveau 2 pr fixpar '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 fonctionnalitofferte 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 chargen prenant en compte l'existence des tests d jg 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 rdans 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 supprimpour un lien vers un test qui n'a pas le m me nom alors l'exigence appara tra comme une exigence non-liun 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 matires

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

Gestion des tests

Les tests sont organiss (Figure et Suite. ) dans une arborescence deux niveaux : Famille

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" ; spcifier le nom et la description de la nouvelle famille ; valider.

Figure: Ajout d'une famille de tests

La nouvelle famille est alors cre sous le rpertoire racine "Suites de test".

Ajouter une suite

Pour ajouter une suite (Figure

):

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

Figure: Ajout d'une suite de tests

La nouvelle suite est alors cre :

dans la famille "Famille par dfaut" si celle-ci tait slectionne, si une suite ou un test lui appartenant tait slectionn ou si aucune famille n'tait slectionne ; dans une famille existante si celle-ci tait slectionne, si une suite ou un test lui appartenant tait slectionn ou si aucune famille n'tait slectionne.

Ajout d'un test manuel

Pour crer un test manuel (Figure

):

slectionner la suite dans laquelle le test doit tre ajout ; cliquer sur "Ajouter un test" ; complter le nom et la description du test ; slectionner le type "Manuel" ; valider.

Figure: Ajout d'un test manuel

Le test est ajout la suite qui tait slectionne. Il reste le modifier pour le dcrire entirement.

Ajout de paramtres
L'onglet "Paramtre" (Figure ) permet de visualiser les paramtres pouvant tre pour plus de

utiliss par ce test et d'en ajouter de nouveaux (Consulter la section dtails).

Figure: Onglet des paramtres 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" ; complter le nom, la description et le rsultat attendu ; ajouter si ncessaire des attachements, fichiers ou URL, auxquels une description peut tre associe ; valider la cration de l'action en cliquant sur "Valider" ; renouveler la procdure pour crer d'autres actions.

Figure: Ajout d'une action de test

Utiliser les paramtres dans les actions

Pour utiliser un paramtre dans la description de l'action ou du rsultat attendu (Figure ):

cliquer sur "Paramtre" ; pour utiliser un paramtre existant, cliquer sur "Utiliser" ; pour utiliser un nouveau paramtre, cliquer sur "Nouveau" ; valider.

Figure: Utilisation de paramtre

Ajouter des attachements au test

Il est possible d'attacher des lments 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'attachement

Il est ensuite possible d'associer une description chaque lment attach et de les visualiser.

Gestion des campagnes

A partir de l'onglet "Gestion des campagnes", diffrentes actions sont possibles :

cration/modification de campagnes ; cration d'excution de campagnes ; lancement d'excution de campagnes ; consultation des rsultats.

Crer une campagne

Le bouton "Crer une campagne" (Figure campagne. ) permet la cration d'une nouvelle

Figure: Ajout d'une campagne de tests

Ajouter des tests dans une campagne

Pour ajouter des tests dans une campagne (Figure ):

1. slectionner la campagne ; 2. cliquer sur le bouton "Importer" ; 3. la fentre qui apparat 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 campagne

Aprs validation, les tests sont visibles dans la campagne, et organiss dans leurs familles et suites.

Dfinir un jeu de donnes pour une campagne

Il s'agit de valoriser les paramtres des tests de la campagne, s'il y en a. Pour dfinir un jeu de donnes (Figure ):

1. slectionner une campagne ; 2. activer l'onglet "Jeux de donnes". La liste des jeux de donnes existants apparat ; 3. cliquer sur le bouton "Ajouter", une fentre apparat : o nommer le jeu de donnes ; o dcrire le jeu de donnes ; o donner une valeur pour chacun de ses paramtres ; o valider.

Figure: Ajout d'un jeu de donnes

Dfinir une excution pour une campagne

Pour lancer les tests d'une campagne, il est ncessaire de lui associer une excution (Figure ) possdant un environnement et un jeu de donnes.

Pour dfinir une excution pour une campagne :

1. slectionner la campagne ; 2. slectionner l'onglet "Excution" ; 3. cliquer sur le bouton "Ajouter", une fentre apparat : o donner le nom de l'excution ; o choisir un jeu de donnes existant ou en crer un nouveau ; o choisir un script d'initialisation qui sera excut avant le lancement des tests ; o choisir un script de restitution qui sera excut aprs le lancement des tests ; o attacher un ou plusieurs fichiers ou URL ; o dcrire l'excution ; o valider.

Figure: Ajout d'une excution de campagne

Grer le lancement des excutions

Lancer une excution Pour lancer une (ou plusieurs) excution(s) ( Figure

):

slectionner la campagne correspondante ; activer l'onglet "Excution" ; slectionner (les) l'excution(s) dsire(s) dans la liste des excutions existantes ; cliquer sur le bouton "Lancer".

Figure: Lancement d'excution Reprendre une excution Lorsque le lancement d'une excution a t interrompu, il est possible de le reprendre :

slectionner la campagne correspondante activer l'onglet "Excution" slectionner l'excution dsire dans la liste des excutions existantes, la liste des rsultats de son diffrent lancement apparat slectionner un rsultat de lancement de l'excution cliquer sur "Reprendre"

Consulter les rsultats du lancement d'une excution

Pour consulter les rsultats d'une excution (Figure ):

slectionner la campagne correspondante ; activer l'onglet "Excution" ; slectionner l'excution dsire dans la liste des excutions existantes, la liste des rsultats de ses diffrents lancements apparat ; slectionner un rsultat de lancement de l'excution ; cliquer sur "Dtails"; les rsultats de chaque test de l'excution apparaissent. Figure: Consultation des rsultats d'excution

Gestion des environnements

Les environnements permettent de dcrire l'environnement d'excution de tests inclus dans une campagne de test.
La gestion des environnements se fait partir de l'onglet "Gestion des donnes" (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 dcrire les lments constituant un environnement (Figure ). , ),

Figure: Description d'un environnment

Les champs dfinissant l'environnement sont :

nom de l'environnement ; script : le script choisi sera excut avant les tests appartenant la campagne de tests correspondante ; description de l'environnement ; paramtres de l'environnement : ces paramtres, une fois valoriss, sont utiliss dans les tests et ventuellement dans les scripts pouvant tre attachs aux environnements et aux excutions.

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 dj t sollicit par une excution.

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 dj t sollicit par une excution.

Dfinir des paramtres d'un environnement

Il est possible, dans un environnement de dfinir ou d'utiliser des paramtres d'un projet afin de les valuer pour l'excution de tests. Ces fonctionnalits sont dcrites en sections et .

Gestion des paramtres

La gestion globale des paramtres d'un projet se fait partir de l'onglet "Gestion des donnes" (Figure ), toutefois, comme nous l'avons introduit en section paramtre peut tre cr partir de diffrents endroits. un

Figure: Gestion des paramtres d'un projet

Cet onglet permet de :

consulter les paramtres dfinis sur le projet et utiliss dans les tests ou les environnements ; crer de nouveaux paramtres ; modifier des paramtres existants en changeant leur description ; supprimer des paramtres.

Cration d'un paramtre partir de l'onglet gestion de donnes

L'ensemble des paramtres utilisables sur un projet est consultable partir de l'onglet "Gestion des donnes", en cliquant sur "Paramtres". Il est aussi possible d'ajouter de nouveaux paramtres en cliquant sur "Nouveau" (Figure ).

Figure: Ajout de paramtres au projet

Pour poursuivre la cration du paramtre (Figure :

), il faut le nommer et le dcrire avant de cliquer sur

"Valider". Le paramtre cr est ensuite utilisable par les tests et les environnements.

Figure: Description d'un paramtre

Cration d'un paramtre partir d'une action de test

Lors de la description d'une action de test manuel, il est possible de crer un nouveau paramtre qui sera utilis par l'action de test. Pour cela, partir de la fentre d'ajout d'une action de test (Figure ), cliquer sur le bouton "Paramtre".

Figure: Utilisation d'un paramtre partir d'une action

La fentre (Figure ) d'ajout de paramtres apparat, cliquer alors sur nouveau. Il est aussi possible d'utiliser un paramtre existant. Pour cela, slectionner le paramtre dsir, et valider.

Figure: Vue des paramtres utiliss par un test

Pour terminer la cration du paramtre (Figure

) il faut le nommer et le dcrire avant de valider.

Figure: Description des paramtres utiliss par un test

Ensuite, pour utiliser le paramtre dans l'action courante (Figure liste des paramtres disponibles puis valider.

), slectionner le paramtre cr dans la

Figure: Utilisation d'un paramtre

Finalement, (Figure

) le paramtre apparat dans la description de l'action.

Figure: Vue d'un paramtre dans une action

Cration d'un paramtre partir d'un environnement

A partir de l'onglet "Gestion des donnes" (Figure ), en slectionnant "Environnements" et en cliquant sur "Ajouter", il est possible d'ajouter un nouvel environnement pour lequel des nouveaux paramtres peuvent tre crs.

Figure: Ajout d'un environnement

La fentre d'ajout d'un environnement apparat (Figure

), cliquer alors sur "Nouveau".

Figure: Cration d'un paramtre dans un environnement

Un nouveau paramtre peut tre cr (Figure

).

Figure: Dclaration d'un paramtre dans un environnement

Utilisation d'un paramtre dans un environnement

L'utilisation dans un environnement de paramtres existants se fait partir de l'onglet "Gestion des donnes", en slectionnant "Paramtres" :

slectionner un environnement ; cliquer sur "Modifier", la fentre de modification apparat (Figure );

Figure: Modification d'un environnement

cliquer sur "Utiliser", la fentre "Utiliser un paramtre existant" apparat (Figure ).

Figure: Utilisation d'un paramtre dans un environnement

slectionner puis valoriser le paramtre dsir ; valider.

Le paramtre ainsi valoris est intgr l'environnement.

Valorisation d'un paramtre

Un paramtre peut galement tre valoris par l'intermdiaire d'un jeu de donnes associ une excution. Lors du lancement d'un test possdant un paramtre, la valeur utilise pour ce paramtre est :

celle donne pour le paramtre dans l'environnement associ l'excution correspondante, si ce paramtre est prsent dans cet environnement ; celle donne pour le paramtre dans le jeu de donnes associes l'excution correspondante, si ce paramtre n'est pas prsent dans l'environnement associ l'excution.

Plugin Mantis
Fay al SOUGRATI Afin d'offrir la possibilitd'une gestion des anomalies dans SalomTMF, un plugin a td velopppour l'outil Open source de gestion des anomalies Mantis.

Table des matires

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 Mantis

Pour 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 SalomTMF 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 SalomTMF : o Se connecter au serveur MySQL (en ligne de commande) : > mysql -u root -p; 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 SalomTMF. 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 Mantis

La premi re tape de l'activation du plugin Mantis dans SalomTMF 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 SalomTMF pour que ces modifications prennent effet.

Saisie/consultation d'une anomalie

Durant 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 ajouten 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 cution

Une autre fonctionnalitofferte par le plugin Mantis de SalomTMF est la possibilitde visualiser tous les anomalies li es un environnement d'ex cution donn . Cette fonctionalitest 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 SalomTMF.

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

L'indicateur ICAL
Salom 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) corriges par rapport au nombre de G0 et G1 dcouvertes 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 accder ces fonctionnalits via le menu "Outils" comme le montre la figure ci-dessous :

Figure: Fonctionnalits relatives l'ICAL pour un projet

Ainsi, 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 donnes. visualiser l'historique de toutes les valeurs sauvegardes 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 lie un environnement, les valeurs de l'ICAL sont calcules 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: Fonctionnalits ICAL lies un environnement

Automatisation
Si l'installation de Salom comporte des plugins d'excution automatique de tests et/ou de scripts (environnement et excution de tests), il est possible de crer des tests et/ou des scripts automatiques qui seront pris en charge par le moteur des plugins.
L'architecture plugin prsente dans Salom est ouverte, et vous permet ainsi de crer vos propres plugins. Pour plus d'informations sur le dveloppement de plugin consultez le manuel de dveloppement de plugins.

Figure: Plugins prsent dans Salom

Pour consulter les plugins prsents dans Salom, ouvrez l'onget "Plugins" de la fentre principale (Figure ). Les Plugins pour les tests automatiques sont du type TestDriver, et ScriptEngine pour les scripts

d'environnement ou d'excution de tests. Le reste de ce chapitre dcrit l'utilisation des plugins d'automatisation dans un cadre gnral, mais certaines fonctionnalits peuvent varier d'un plugin l'autre, ainsi, pour plus d'informations sur l'utilisation d'un plugin en particulier, consultez l'aide correspondante.

Crer un test automatique

La procdure de cration d'un test automatique est la suivante :

dans l'onglet plan de test (Figure ), slectionner la suite dans laquelle le test doit tre ajout ; cliquer sur "Ajouter un test" ; complter le nom et la description du test ; slectionner le type de plugin utiliser (Figure valider. );

Figure: Choix du driver de test automatique

Le test est ajout la suite qui tait slectionne. Il reste dfinir le code d'excution li au plugin pour le dcrire entirement. 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 paramtres (voir section ) qui seront valus lors des excutions. Notez, que l'utilisation de paramtres est dpendante du plugin selectionn, consultez ainsi, l'aide du plugin pour plus d'informations.

Modifier un test automatique

La modification d'un test automatique, hormis la partie script, est identique la modification d'un test manuel (nom, description, attachement, paramtres). La modification du script de test est quand elle dpendante du plugin, et activable dans le menu script en Figure .

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

L'entre Modifier le Script appelle la fonctionnalit de modification au niveau du plugin. L'entre Actualiser le Script met jour le script dans la base de donnes de Salom. L'entre SetUp Driver appelle la fonctionnalit de configuration du plugin. L'entre About Driver affiche les informations du plugin.

Utiliser des scripts dans les environnements et les excutions

Comme les tests automatiques, les environnements et les excutions peuvent utiliser des scripts automatiques dpendants des plugins de types ScriptEngine.
Lors d'une excution de campagne de tests, le script d'environnement est excut en premier, puis le script d'initialisation de l'excution, les scripts des tests, et finalement le script de restitution de l'excution.

La Figure

dcrit comment ajouter un ou plusieurs scripts une excution.

Figure: Ajout de scripts une excution

La modification des scripts d'excutions et/ou d'environnements est dpendante du plugin utilis, et est activable dans les menus Script des excutions (Figure ) et/ou environnements.

Figure: Modification d'un script (code) d'excution

Contexte d'excution
Suivant les plugins utiliss pour dcrire les scripts de tests, les scripts d'environnement et d'excution, le contexte d'excution des scripts peut tre identiques tout au long de l'excution de la campagne (c'est--dire, partage des mmes rfrences), c'est par exemple le cas avec les plugins Benshell et simpleJunit.
Plus gnralement, les scripts de tests, d'excution et d'environnement possdent des rfrences sur les variables dcrites dans le tableau suivantes (*=org.objectweb.salome_tmf.data) : Nom date time salome_projectName salome_projectObject salome_debug salome_ExecResultObject salome_ExecTestResultObject salome_CampagneName salome_CampagneObject salome_environmentName salome_environmentObject salome_ExecName salome_ExecObject Classe Java.lang.Date Java.lang.Time Java.lang.String *.Project boolean *.ExecutionResult *.ExecutionTestResult Java.lang.String *.Campaign Java.lang.String *.Environment Java.lang.String *.Execution Description Date de l'excution Heure de l'excution Nom du projet courant Rfrence de l'objet projet de Salom Faut lors de l'valuation du script dans l'diteur Rfrence sus les rsultats d'excution courant Rfrence sur le rsultat d'excution du test courant Nom de la campagne courante Rfrence de la campagne courante Nom de l'environnement courant Rfrence sur l'environnement courant Nom de l'xcution courante Rfrence sur l'excution Disponible T, Env, Ex T, Env, Ex T, Env, Ex T, Env, Ex T, Env, Ex T, Ex T T, Env, Ex T, Env, Ex T, Env, Ex T, Env, Ex T, Env, Ex T, Env, Ex

courante salome_TestName salome_TestObject salome_SuiteTestName salome_SuiteTestObject salome_FamilyName salome_FamilyObject testLog Verdict salome_classloader Java.lang.String *.Test Java.lang.String *.TestList Java.lang.String *.Family Java.lang.String Java.lang.String Nom du test courant Rfrence sur le test courant Nom de la suite de tests courante Rfrence sur la suite de tests courante Nom de la famille courante Rfrence sur la famille courante Log de tests ajouter comme attachement l'xcution Verdict du test (pass, fail, unconclusif) T T T T T T T T T, Env, Ex

Java.net.URLClassLoader Classe loader de BeanShell

La colonne disponible dcrit o peuvent tre utilises ces variables (T pour les tests, Env pour les Environnements, et Ex pour les Excutions). En plus de ces variables, les scripts de tests, d'excution et d'environnement ont accs aux paramtres valus lors des excutions par les jeux de donnes, suivant leur nom et le type Java.lang.String.

l'architecture plug-ins de SALOM TMF

Mikal Marche

Table des matires

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

Le point d'extension "Common" L'interface "Common" Utilisation des composants graphiques de Salom TMF par les plugins Composants graphiques de Salom-TMF

Tutoriel : dveloppement du plugin "bugzilla" o Le fichier Manifest o Implmentation de l'interface "Common"

Liste des figures

1. 2. 3. 4. Architecture du framework JPF Menu outils des plug-ins Onglet plan de test Vue "attachements" (Commune tous les lments pouvant avoir des attachements) 5. Vue "Script" pour un test automatique 6. Vue "Paramtres" pour les tests ainsi que dans le panel de gestion des donnes 7. Vue "Actions" pour un test manuel 8. Onglet campagnes de tests 9. Vue "Excutions" pour une campagne de test 10. Vue "Jeux de donnes" pour une campagne de test 11. Fentre principale pour la gestion des donnes 12. Vue "Environnements" dans le panel de gestion des donnes 13. Fentre d'excution d'un test manuel 14. Fentre pour le dtail d'un rsultat d'excution d'une campagne de test 15. Fentre pour le dtail d'un rsultat d'excution d'un test manuel 16. Fentre pour l'ajout/modification d'un nouvel environnement

Framework "JPF" (Java Plugin Framework)

Ce chapitre prsente le framework JPF (Java Plugin Framework) sur lequel s'appuie l'architecture plugins de Salom TMF.

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

Architecture
Le schma en Figure 1.1 prsente l'architecture gnrale du framework JPF.

Figure 1.1: Architecture du framework JPF

Plugin registry : ensemble d'interfaces qui enregistrent les plugins prsents partir des mta-information prsentes dans le fichier manifest (XML) de chaque plugin. JPF en propose une implmentation standard (standard plugin registry). Path resolver : composant qui rpertorie pour chaque plugin la localisation physique de ses ressources. JPF en propose galement une implmentation standard (standard path resolver). Plugin manager : classe principale du framework qui charge et active les plugins. Une instance "standard" du plugin manager peut tre cre en utilisant les implmentations standards du plugin regitry et du path resolver

Architecture plugins de SALOM TMF

Ce chapitre prsente l'architecture plugins de Salom TMF suivant le framework JPF.

Initialisation de JPF
Cette initialisation est effectue par la mthode "startJPF" de la classe JPFManager se trouvant dans le package org.objectweb.salome_tmf.plugins. Afin d'initialiser les paramtres ncessaires JFP, un fichier "properties" est utilis. Ce fichier est nomm "CfgPlugins.properties" et se trouve dans le sous rpertoire "plugins" du rpertoire d'installation de Salom TMF. Il contient le nom du rpertoire qui abrite les plugins, la liste des plugins prsents ainsi que d'autres paramtres utiliss par le systme de trace ( log4j). Une fois ces paramtres initialiss, on cre une table de hachage qui contient autant d'lments que de plugins,

chaque lment ayant la forme suivante :

Cl : fichier manifest Valeur : URL du rpertoire contenant les ressources du plugin. Cette table de hachage permet alors de crer 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();) { props.getProperty(PARAM_PLUGINS_LIST), ",", false); for (; PluginsList.hasMoreTokens();) { String currentPlg = currentPlgFolder + "/" + PluginsList.nextToken().trim(); try { instance of PluginManager PluginManager pluginManager = PluginManager.createStandardManager(pluginLocations);

String curre

Le plugin " core" et les points d'extension

Le plugin core est un plugin particulier. En effet; c'est un plugin qui doit tre obligatoirement prsent, et qui est activ par dfaut.

Fichier manifest du plugin core

Chaque plugin possde un fichier manifest. C'est un fichier XML qui respecte la DTD spcifie dans le framework JPF. Pour le plugin "core", Ce fichier est compos de trois parties. La premire partie est commune tous les plugins et se prsente de la faon suivante:
<plugin id="core" version="0.0.1" class="org.objectweb.salome_tmf.plugins.core.CorePlugin"> Cette entte spcifie l'identificateur du plugin, sa version ainsi que sa classe principale. La deuxime partie du fichier manifest est sous la forme suivante : <runtime> <library id="core" path="core/core.jar" type="code">

<export pref

Cette partie spcifie que le plugin utilise une librairie (core.jar) qui se trouve dans le rpertoire "core" (lui-mme se trouvant dans le rpertoire qui contient les plugins), et que cette librairie est du type "code". Il est galement prcis dans cette partie que toutes les classes et packages (*) de ce plugin sont visibles pour les autres plugins qui peuvent par consquent les utiliser.
La troisime et dernire partie de ce fichier est celle qui est la plus intressante car elle offre l'application la possibilit d'tre extensible. Il s'agit de la dfinition des points d'extension du plugin core, c'est--dire la manire 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 prsente ainsi : <extension-point id="Common"> <parameter-def <parameter-def id="name"/> <parameter-def multiplicity="none-or-one"/> </extension-point> id="class"/> id="description"

Ici, un point d'extension nomm "Common" est dfini. Il est galement prcis que tout plugin qui est extension de ce point doit valoriser trois paramtres :

Le paramtre "class" : c'est le nom de la classe principale du plugin.

Le paramtre "name" : il s'agit du nom du plugin. Le paramtre "description" : c'est la description du plugin.

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

Activation du plugin core

L'activation du plugin core est dclenche aprs l'initialisation de JPF et la cration d'une instance du plugin manager.
Ensuite, pour chaque point d'extension, une mthode implmente dans la classe principale du plugin core (org.objectweb.salome_tmf.plugins.core.CorePlugin) permet de rcuprer ce point d'extension sous forme d'un objet de type "ExtensionPoint". Voici le code qui effectue ces tches (source : mthode "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 (

"getCommonEx

Le point d'extension "Common"

Pour chaque point d'extension dfini dans le fichier manifest du plugin core, une interface portant le mme nom lui est associe 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 gnrique qui peut tre utilise par la plupart des plugins (sauf dans le cas de plugins spcifiques; plugins pour l'excution automatique des tests par exemple).

L'interface "Common"
Tout plugin qui dclare dans son fichier manifest qu'il est une extension du point Common doit implmenter l'interface org.objectweb.salome_tmf.plugins.core.Common propose dans Salom TMF. Cette interface facilite l'accs pour un plugin aux composants graphiques de Salom TMF, afin qu'il puisse y ajouter ses fonctionnalits.
Cette interface est divise en deux parties. La premire a pour objet les fonctionnalits du plugin qui seront mises dans les menus "Outils" pour les suites de test, les campagnes de test et la gestion de donnes. La capture d'cran en Figure 2.1 montre un exemple de fonctionnalits de plugins dans un de ces trois menus.

Figure 2.1: Menu outils des plug-ins

La deuxime partie de l'interface Common concerne le reste des composants graphiques de Salom TMF utiliss par le plugin. En effet, le plugin doit spcifier les composants Salom qu'il utilise ou dans lesquels il rajoute des fonctionnalits, et dans le dernier cas il doit implmenter la manire avec laquelle ses fonctionnalits doivent tre intgres 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-ins

Si un plugin de type Common utilise des composants graphiques de Salom TMF (autres que les menus outils), il doit implmenter 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 utiliss par des plugins ou qui sont susceptibles d'abriter leurs fonctionnalits sont rpertoris.
A chacun de ces composants est associe une constante 2.1.Ainsi, le plugin fournit l'application Salom TMF la liste des constantes correspondant aux composants graphiques utiliss, 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-TMF

Les Figures de cet section dont la lgende est donne par le Tableau 2.1, illustrent les correspondances entre les objets graphiques de Salom TMF et les constantes pour l'accs des plug-ins. des composants graphiques de Salom TMF) : Tableau 2.1: Lgende

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 lis une suite de test, un test ou une campagne. Ils sont dynamiques dans les autres cas. Figure 2.3: Vue "attachements" (Commune tous les lments pouvant avoir des attachements)

Figure 2.4: Vue "Script" pour un test automatique

Figure 2.5: Vue "Paramtres" pour les tests ainsi que dans le panel de gestion des donnes

Figure 2.6: Vue "Actions" pour un test manuel

Figure 2.7: Onglet campagnes de tests

Figure 2.8: Vue "Excutions" pour une campagne de test

Figure 2.9: Vue "Jeux de donnes" pour une campagne de test

Figure 2.10: Fentre principale pour la gestion des donnes

NB : La vue "Paramtre" dans le panel de gestion des donnes est la mme que la vue "Paramtres" pour les tests Figure 2.11: Vue "Environnements" dans le panel de gestion des donnes

Figure 2.12: Fentre d'excution d'un test manuel

Figure 2.13: Fentre pour le dtail d'un rsultat d'excution d'une campagne de test

NB. : Les objets graphiques de la partie pour les attachements de la prcdente fentre sont les mmes que pour tous les lments ayant des attachements. Figure 2.14: Fentre pour le dtail d'un rsultat d'excution d'un test manuel

Figure 2.15: Fentre pour l'ajout/modification d'un nouvel environnement

Tutoriel : dveloppement du plugin " bugzilla"

Afin d'illustrer le dveloppement d'un plugin de type Common par un exemple, nous allons dtailler le dveloppement du plugin "Bugzilla", plugin ayant pour but d'offrir des fonctionnalits de gestion de bug dans Salom TMF en utilisant le bugtracker Bugzilla2.16.

Le fichier Manifest
La premire partie du dveloppement 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 premire partie du fichier (aprs l'entte) prcise le nom du plugin, sa version et la classe principale qui tend la classe Plugin.
Ensuite, dans la balise "requires", le plugin dclare le ou les plugins dont la prsence est ncessaire 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 dclare la liste des librairies utilises, ainsi que leurs types.

La dernire partie du fichier (balise "extension") prcise les informations relatives aux points d'extensions utiliss : plugin fournissant le point d'extension, nom du point d'extension, ainsi que les paramtres spcifiques au point d'extension.

Implmentation de l'interface " Common"

La classe d'entre du plugin, en l'occurrence la classe BugzillaPlugin du package salomeTMF_plug.bugzilla pour le plugin Bugzilla, doit implmenter 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" (prsents dans les parties "Gestion des tests", "gestion des campagnes" et "Gestion des donnes"), il existe deux mthodes par menu. Pour la partie "Gestion des tests" par exemple, ces deux mthodes sont les suivantes :

isActivableInTestToolsMenu() : mthode qui renvoie un boolen prcisant l'utilisation du menu par le plugin. activatePluginInTestToolsMenu() : mthode permettant au plugin d'ajouter ces fonctionnalits dans le menu (le menu est pass en paramtre cette mthode).

Pour ce qui est des fonctionnalits du plugin utilisant d'autres composants graphiques de Salom TMF (dfinies en section 2.3.2), il existe quatre mthodes implmenter par le plugin :

usesOtherUIComponents() : mthode qui retourne un boolen prcisant l'utilisation d'autres composants graphiques de Salom TMF par le plugin. getUsedUIComponents() : mthode qui retourne la liste (de type java.util.Vector) des composants graphiques utiliss pas le plugin. Ci-dessous un extrait de l'implmentation de cette mthode pour le plugin Bugzilla :

~ public Vector getUsedUIComponents() { Vector uiComponentsUsed = new Vector(); uiComponentsUsed.add(0,UICompCst.MANUAL_EXECUTION_BUTTONS_PANEL); uiComponents

activatePluginInStaticComponent () : mthode permettant d'activer le plugin dans les composants graphiques statiques parmi ceux renseigns par la mthode prcdente. Le plugin doit prciser dans cette mthode la manire avec laquelle il sera activ selon les composants graphiques. Voici un extrait de cette mthode pour le plugin Bugzilla :

~ public void activatePluginInStaticComponent(Integer uiCompCst) { if (uiCompCst == UICompCst.DATA_MANAGEMENT_ENV_TABLE) { environmentTable = (JTable)SalomeTMF.getUIComponent(uiCompCst);

retu

activatePluginInDynamicComponent() : idem que la mthode prcdente pour les composants graphiques dynamiques de Salom TMF.

Plugin JUnit
Mika 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 matires

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 Junit

Le 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 compilde cet objet.
Il existe deux modes de cr ation de suite de tests Junit, un mode dit natif et un autre liau 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 liun script d'environnement ou d'ex cution pour charger d'autres classes. Pour cr er une suite de tests Junit, apr s avoir s lectionnune 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 Junit

La 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 tests

Quelque 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 date time salome_projectName salome_projectObject salome_debug salome_ExecResultObject salome_ExecTestResultObject salome_CampagneName salome_CampagneObject salome_environmentName salome_environmentObject salome_ExecName salome_ExecObject salome_TestName salome_TestObject salome_SuiteTestName salome_SuiteTestObject salome_FamilyName Classe Java.lang.Date Java.lang.Time Java.lang.String *.Project boolean *.ExecutionResult *.ExecutionTestResult Java.lang.String *.Campaign Java.lang.String *.Environment Java.lang.String *.Execution Java.lang.String *.Test Java.lang.String *.TestList Java.lang.String Description Date de l'ex cution Heure de l'ex cution Nom du projet courant R f rence de l'objet projet de Salom Faut lors de l' valuation du script dans l' diteur R f rence sus les r sultats d'ex cution courant R f rence sur le r sultat d'ex cution du test courant Nom de la campagne courante R f rence de la campagne courante Nom de l'environnement courant R f rence sur l'environnement courant Nom de l' x cution courante R f rence sur l'ex cution courante Nom du test courant R f rence sur le test courant Nom de la suite de tests courante R f rence sur la suite de tests courante Nom de la famille courante

salome_FamilyObject testLog

*.Family Java.lang.String

R f rence sur la famille courante Log 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) { params); /*sample to salome_tmf object in Java Environment env = (Environment)params.get("salome_environmentObject"); env.getParameterValue("Adresse_services_schema"); } public void testParam() throws Exception { System.out.println("(env) url_serveur = " + url_serveur_Env); System.out.println("(DataSet) Adresse_services_schema = " + Adresse_services_schema_DS); } }

System.out.p

/* sample to /* sample to

Syst

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"); /* s env.getParameterValue("Adresse_services_schema"); /* sample to } public void testParam() throws Exception { System.out.println("(env) url_serveur = " + url_serveur_Env); Syst System.out.println("(DataSet) Adresse_services_schema = " + Adresse_services_schema_DS); } }

Exemple
L'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 compilde la classe junit.samples.money.MoneyTest , et l'autre contenant le code compilde 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 Junit

Soit 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 tests

Soit 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> path="simpleJunit/libs/HTTPUnits/junit.jar" type="code"/> <library id="httpjunit" path="simpleJunit/libs/HTTPUnits/httpunit.jar" type="code"/> <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"> value="Creation de suite HTTPJunit TVMoblie"/> </extension> </plugin>

<imp

<lib

<par

Lancement de l'ex cution

Pour 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 Gendoc
Aurore 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 matires

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 tests

Pour 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 ren 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 campagnes

Pour g n rer le document des campagnes, il faut tout d'abord s lectionner le sousmenu 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 projet

Cette 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 projet

Cette 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 fonctionnalitgr ce au sousmenu 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 oils 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 fixpar "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 rale
Lorsque 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 suppressions

Avant 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. Projet Pour 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.

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

familles ; suites :

tests :
o o o o

attachements de la suite. param tres du test ; attachements du test ; script du test si celui-ci est automatique ; 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.

Campagnes Pour les campagnes, la strat gie est un peu diff rente. En effet, lorsque l'utilisateur cr e des ex cutions, un nom est proposl'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 Salomne 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. Projet Les 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.

Tests Pour 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 Salomcourant, 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 ole test importer dans le projet courant appartenait d jau 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.

Campagnes La 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 tectlorsque 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 suffixpar "_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 suffixpar "_Bis".