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 matières

Gestion de l'arbre d'exigences

Le repository d'exigences est formalisé par un arbre infini, tel que chaque n $\oe$ 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-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 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-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 campagne

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

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é
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.

À propos de ce document...

Plugin Requirements

This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.71)

The command line arguments were:
latex2html -split 1 -no_navigation -dir ../.././src_requirements/plugins/requirements/docs/html/fr -no_footnode fr/requirements.tex

The translation was initiated by on 2006-05-17

2006-05-17