Domaine Regle

MODULARITE REG_001

MODULARITE REG_002

MODULARITE REG_003

MODULARITE REG_004

LE SCENARIO REG_005

LE SCENARIO REG_006

LE SCENARIO REG_007

LA MANŒUVRE REG_008

LA MANŒUVRE REG_009

LA MANŒUVRE REG_010

Tests génériques REG_052

Tests génériques REG_053

Vérifications par analyse REG_054

COMPLETUDE REG_011
COMPLETUDE REG_012

COMPLETUDE REG_013

COMPLETUDE REG_014

COMPLETUDE REG_015

COMPLETUDE REG_016

COMPLETUDE RECOM_017

COMPLETUDE REG_018

COMPLETUDE RECOM_001

COMPLETUDE REG_019

COMPLETUDE REG_020
COMPLETUDE REG_021

COMPLETUDE REG_022

COMPLETUDE REG_023

COMPLETUDE REG_024

COMPLETUDE REG_025

CLARTE REG_026

CLARTE REG_027

CLARTE REG_028

CLARTE REG_029

CLARTE RECOM_002

CLARTE RECOM_057

DESCRIPTION DES
RECOM_030
SCENARIOS
DESCRIPTION DES
REG_031
SCENARIOS
DESCRIPTION DES
RECOM_032
SCENARIOS

DESCRIPTION DES
REG_033
SCENARIOS

DESCRIPTION DES
REG_034
MANŒUVRES

DESCRIPTION DES
REG_035
MANŒUVRES

DESCRIPTION DES
REG_036
MANŒUVRES

DESCRIPTION DES
REG_037
MANŒUVRES
DESCRIPTION DES
REG_038
MANŒUVRES
DESCRIPTION DES
REG_039
MANŒUVRES

DESCRIPTION DES
RECOM_003
MANŒUVRES

DESCRIPTION DES
REG_040
MANŒUVRES

DESCRIPTION DES
RECOM_004
MANŒUVRES

RESULTATS ATTENDUS REG_041

RESULTATS ATTENDUS REG_041 bis

RESULTATS ATTENDUS REG_042

RESULTATS ATTENDUS RECOM_058

RESULTATS ATTENDUS RECOM_059

GESTION DES MANOEUVRES
REG_061
ET DES SCENARIOS

GESTION DES MANOEUVRES

REG_062
ET DES SCENARIOS

PROCEDURES DE TESTS REG_043

PROCEDURES DE TESTS REG_044

PROCEDURES DE TESTS REG_045

UNICITE REG_046

TRAÇABILITE REG_047

TRAÇABILITE REG_048

TRAÇABILITE REG_055

TRAÇABILITE RECOM_056

TRAÇABILITE REG_060

TRAÇABILITE RECOM_049

TRAÇABILITE REG_050

TRAÇABILITE REG_051
 Description
Les exigences de tests sont saisies à l'aide du modèle défini sous
DOORS
Il existe une spécification de tests en regard de chaque groupe à tester.
C'est à dire qu'il existe un module DOORS de tests pour chaque module
DOORS d'exigences logicielles.
Dans chaque module DOORS correspondant à un groupe, les
exigences de tests sont regroupées par chapitre correspondant au
composant logiciel.
Par chapitre est défini un ensemble de scénarios correspondant aux
tests des fonctions logicielles caractérisées par leurs exigences. Il n'y a
pas forcément adéquation directe entre fonctions et scénarios (une
fonction peut être testée par plusieurs scénarios, un scénario peut
tester plusieurs fonctions)
Un scénario comporte un titre définissant le comportement du modèle
SCADE testé. Il est composé des paragraphes suivants
Supprimée depuis la version B du guide
L'attribut « TM Nature » doit être positionné à la valeur 'Scénario', au
niveau du titre de scénario.
La manoeuvre définit le chronogramme d'activation des entrées du
modèle SCADE testé afin de lui faire réaliser l'ensemble du traitement
fonctionnel défini par ses exigences.
En regard de chaque manoeuvre, le résultat attendu résultant de
l'application de celle -ci doit être défini.
L'attribut « TM Nature » doit être positionné à la valeur 'Manoeuvre' ,
au niveau de la description de la manoeuvre.
Les tests génériques doivent être définis dans le module DOORS «
IVVQ » de la LDB dans le chapitre « Tests génériques »
Les scénarios d’un projet qui utilisent des plans de test génériques
doivent le préciser. Cette précision est apportée dans le paragraphe «
But » du scénario.
Pour les exigences dont la vérification par test ne peut être réalisée,
une vérification par analyse du modèle peut être directement effectuée
dans le plan de tests. Ces analyses doivent alors être regroupées dans
un chapitre « Analyse » du plan de tests sous DOORS.

Elles sont considérées comme des manoeuvres (attribut « TM
Manoeuvre ») et sont liées aux exigences qu’elles justifient.

Ce type de vérification doit se limiter à des exigences difficilement
testables ou non testables. Il s’agira essentiellement d’exigences
d’initialisation ou de cas de tests de points singuliers dont les entrées
sont difficilement pilotables (issues de calculs ou de données
intermédiaires).
Toutes les exigences liées au modèle SCADE testé doivent faire l'objet
d'au moins une manoeuvre.
A l’exception des manoeuvres nécessaires uniquement au
positionnement des entrées du test ou autres conditions opératoires,
toutes les manoeuvres doivent être liées aux exigences logicielles
qu'elles couvrent (liens au sens Doors du terme). Ces manoeuvres de
mise en oeuvre des tests doivent avoir l’attribut « TM Méthode
Vérification » positionné à la valeur « MEO ».

Pour les exigences logicielles conditionnées par un "grand IF"

(exigences liées à un critère), les manoeuvres de tests
correspondantes doivent également être associées à ce critère (cf.
exemple en annexe 2). Dans ce cas, dans le catalogue, il faut définir
une manoeuvre pour chaque variante de l’exigence.
Pour les exigences logicielles conditionnées par un "petit if" (exigences
sélectionnables par paramétrage), le scénario de tests doit couvrir à lui
seul les deux cas liés à la valeur du "petit if" fonctionnel (cf. exemple en
annexe 2).
Pour les exigences logicielles conditionnées par un "petit if" (exigences
sélectionnables par paramétrage), les manoeuvres de tests
correspondantes seront liées aux exigences couvertes. Dans ce cas,
une seule manoeuvre doit couvrir les différentes conditions associées
au paramétrage.
Pour les exigences logicielles conditionnées par un "petit if" (exigences
sélectionnables par paramétrage), la prise en compte du "petit if"
fonctionnel (condition activée) est faite au travers de l’attribut « TM
Résultats Attendus » (cf. 3.1.5 de DR2).
Les scénarios de tests doivent être définis afin de provoquer une
variation des sorties du modèle SCADE représentative des exigences
vérifiées (cf. 3.1.5 de DR2).
Les scénarios de tests doivent assurer que tous les seuils de
basculement (points singuliers) définis dans la spécification ont bien
été testés (cf. 3.1.5 de DR2).
Afin de mieux maîtriser la détection des seuils de basculement, il est
préférable de privilégier une variation de la donnée d'entrée du test par
échelon plutôt que par gradient (problème lié à la maîtrise du temps
réel).
Les scénarios de tests doivent assurer que l'amplitude de la variation
des signaux appliqués sur les entrées du modèle SCADE testé est
représentative du fonctionnement opérationnel de celui-ci. C'est à dire,
que cette variation doit être à l'intérieur des valeurs possibles définies
par les exigences
Dans le cas d'utilisation de tables, les scénarios de tests de modèles
SCADE ne devant tester que l'algorithmique implémenté et non
l'ensemble de la variation du paramétrage sur toute la plage de la table,
il sera donc réalisé un test fonctionnel représentatif du
fonctionnement

nominal du modèle SCADE.
Dans le cas d'utilisation de tables, du fait de la saturation de leurs
sorties au delà du minimum et du maximum spécifiés, les tests aux
limites seront complétés par deux tests hors limites par activation des
tables à leur "valeur MIN – DELTA" et "valeur MAX + DELTA". Le DELTA
doit être choisi afin de s'assurer de l'effectivité réelle de la saturation.

Les scénarios de tests, pour les spécifications logicielles exprimées par

des équations logiques, doivent assurer que les combinatoires de
valeurs des données d’entrée booléennes (de l’équation logique)
sélectionnées montrent avec indépendance l’influence de la variation
d’une entrée sur la valeur de sortie (cf. 3.1.5 de DR2 et 6.4.2.1 de DR1).

Les scénarios de tests doivent assurer que la variation de la sortie du

modèle SCADE sous test n'est produite que par la variation de l'entrée
devant provoquer ce cas de fonctionnement (cf. 3.1.5 de DR2).

Les scénarios de tests doivent assurer que tout événement temporel

se produit bien dans le temps spécifié (cf. 3.1.5 de DR2). De ce fait, on
ne peut se contenter de vérifier une évolution de sortie après "t" sec
mais il faut déterminer avec exactitude le temps réellement écoulé qui
a provoqué l'événement

Le périmètre permettant d'assurer que le résultat obtenu est conforme

au résultat attendu doit être totalement défini sans ambiguïté. De ce
fait, les résultats attendus doivent intégrer

- définition complète de l'état des entrées du modèle SCADE

- prise en compte de l'état précédent de la sortie si utilisé

- prise en compte des transition

Un objet DOORS est de façon exclusive, soit un titre, soit du texte.

Dans le cas d'un titre, l’attribut « Object Heading » est renseigné.

Dans le cas d'un texte, l’attribut « Object Text » est renseigné

Il ne doit pas y avoir d'élément de texte qui n'apporte pas d'information.

Chaque définition de scénario ou de manoeuvre doit avoir une seule

interprétation possible : il ne doit pas y avoir d’ambiguïté.
Les phrases doivent être simples et claires et les mots précis.
Lorsque la définition d'une manoeuvre ou d'un résultat attendu n'est
pas facilement compréhensible, l'introduction d'un commentaire est
fortement recommandée.
Afin de garantir la lisibilité des manoeuvres à l’écran, le contenu d’une
manoeuvre (pilotage et résultat attendus) sera limité à 50 lignes de
texte (sauts de ligne inclus) (cf. Annexe 1 – exemple A1.2).

supprimée depuis la version D du guide

supprimée depuis la version D du guide

La période d'appel du composant ou de la fonction sous test doit être
indiquée au niveau de la configuration de tests. Cette période doit être
nommée comme suit
Le fichier MATLAB (*.m) qui regroupe les stimuli des entrées
permettant d'exécuter le scénario est référencé dans le chapitre
correspondant.
Lorsqu‘il est nécessaire de parler de cycle de calcul, on utilisera
l'expression "cycle d'appel de la fonction".
Pour décrire une manoeuvre de demande de changement d'état d'un
booléen, il faut utiliser l'expression

- setBool booléen

Pour décrire un échelon sur une variable, il faut utiliser l'expression

- Positionner/Augmenter / Diminuer instantanément variable à

Pour décrire une rampe sur une variable, il faut utiliser l'expression

Pour décrire un changement d'état d'un énuméré, il faut utiliser

l'expression
Pour décrire une valeur qui est calculée, l'expression décrivant le calcul
est toujours entre "[ ]".
Les manoeuvres s'enchaînant dans un même scénario, il n'est pas
indispensable de rappeler dans chaque manoeuvre les données
d'entrée qui n'évoluent pas d'une manoeuvre à l'autre, sauf dans le cas
où le nombre de manoeuvres ne permet pas de retrouver facilement les
conditions initiales
Lors du test d'une exigence temporelle exprimée en nombre de cycles,
la manoeuvre doit être aussi exprimée en nombre de cycles et non en
temps.
Lorsqu’il est nécessaire d’attendre un évènement, l’attente doit être
dimensionnée au plus juste en utilisant au maximum les paramètres de
l’exigence couverte.
Dans le cas de l'utilisation de l'outil ADEP_AUTO (outil de dépouillement
automatique des résultats), les résultats attendus seront décrits à
l'aide du macro-langage de commande de cet outil. La syntaxe du
langage « ADEP_AUTO » est définie dans DR5.

Dans le cas de l'utilisation de l'outil SCTL Analyzer (outil de

dépouillement automatique des résultats), les résultats attendus
seront décrits à l'aide du macro-langage de commande de cet outil. La
syntaxe du langage « SCTL » est définie dans DR7.
Pour les projets, excepté pour la valeur zéro, les résultats attendus
sont exprimés en utilisant le nom des paramètres définis dans les
exigences.
Pour les résultats attendus contenant plus de 5 assertions, soit

Pour les résultats attendus vérifiant des combinatoires, dans le cas où

la combinatoire comporte moins de trois conditions, chaque assertion
devra reprendre toutes les conditions de la combinatoire.
Chaque scénario ou manoeuvre doit avoir un attribut « TM Statut ».

L’attribut « TM Statut » doit être « obsolète » lorsque le scénario ou la
manoeuvre sont supprimés, sinon vide par défaut.

Chaque scénario ou manoeuvre doit avoir un attribut « TM Modif ».

L’attribut « TM Modif » doit être renseigné lorsque le scénario ou la
manoeuvre sont modifiés, sinon vide par défaut. L’attribut « TM Modif
» est purgée au préalable d’une

nouvelle campagne de tests.

Un fichier MATLAB est édité pour chaque scénario

Chaque manoeuvre doit comporter

- Temps de début et de fin de manoeuvre ( tf_manoeuvre)

- Un champ identifiant le nom de la manoeuvre (titre défini sous
DOORS)

- Un numéro de manœuvre
Chaque manoeuvre doit prendre en compte les IF fonctionnels.

Chaque manoeuvre ou scénario doit être identifié de façon unique.

Un lien doit être réalisé depuis la manoeuvre vers la ou les exigences

qu’elle teste, à l’exception des manoeuvres effectuant seulement du
positionnement pour les conditions initiales du test (cf. REG_012).

Supprimée depuis la version B du guide

Le titre d’une manoeuvre doit être explicite sur l’objectif du test et le
périmètre des exigences ou des fonctions vérifiées par cette
manoeuvre.
Une manoeuvre ne doit pas vérifier plus de trois exigences. Ceci afin de
faciliter l’analyse de traçabilité.
Dans le cas où l’exigence exprime une combinatoire, chaque condition
doit être testée dans une manoeuvre dédiée à la vérification de cette
condition.
supprimée depuis la version D du guide
Les entrées d'un scénario de test sont défini au paragraphe «
Conditions initiale de Tests » du scénario. On ne référence que les
données qui ont un effet direct sur le test en précisant leur valeur
d’initialisation.
Supprimée depuis la version B du guide
 Critère de Couverture / Justification

Couvert par l'ensemble du paragraphe: "Plan de test - (IVVQ Doors)"

Documentation (transverse) - Tracabilité_CR

Couvert par l'ensemble du paragraphe: "Plan de test - (IVVQ Doors)"

Couvert par l'ensemble du paragraphe: "Plan de test - (IVVQ Doors)"

Plan de test - (IVVQ Doors) - Nommage

Plan de test - (IVVQ Doors) - Attributs des plans de test

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Attributs des plans de test

Hors projet

(seulement lors de l'activité de la LdB)

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Analyses

Documentation (transverse) - Tracabilité_CR

Plan de test - (IVVQ Doors) - Attributs des plans de test

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Notion à rediscuter avec le client

Notion à rediscuter avec le client

Notion à rediscuter avec le client

Recommendation - non vérifiée

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Recommendation - non vérifiée

Non applicable car la spécification ne spécifie pas la variation possible

des signaux

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Couvert par l'ensemble du paragraphe: "Plan de test - (IVVQ Doors)"

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Recommendation - non vérifiée

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

-
Recommendation - non vérifiée

Procedure de test - Cohérence au regard du plan de test

Notion à rediscuter avec le client

Résultats de test - Log d'exécution

Résultats de test - Log d'exécution

Résultats de test - Log d'exécution

Résultats de test - Log d'exécution

Résultats de test - Log d'exécution

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Résultats de test - Log d'exécution

Résultats de test - Log d'exécution

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Plan de test - (IVVQ Doors) - Contenu Action / Vérification

Recommendation - non vérifiée

Plan de test - (IVVQ Doors) - Attributs des plans de test

Perimetre - Couverture des exigences modifiées

Procedure de test - Cohérence au regard du plan de test

Procédure de test - Contenu de la procédure

Procédure de test - Contenu de la procédure

Plan de test - (IVVQ Doors) - Attributs des plans de test

Plan de test - (IVVQ Doors) - Traçabilité opérationnelle et Tracabilité

fonctionnelle

Plan de test - (IVVQ Doors) - Nommage

Plan de test - (IVVQ Doors) - Tracabilité fonctionnelle

Plan de test - (IVVQ Doors) - Tracabilité fonctionnelle

Couvert par l'ensemble du paragraphe: "Plan de test - (IVVQ Doors)"

-
1.Scope

1.1 Coverage of the changed requirements

1.2 Scope of the Development

1.3 Completeness of the review

1.4 Completeness of the formal campaign

1.5 MTC

1.6 Specific setpoint of the activity

2.IVVQ

2.1 Attributes of test plans

2.2 Naming rule

2.3 Operational traceability

2.4 Functional traceability

2.5 Contents Action and verification

2.6 Analyzes

3.Procedure

3.1 Folder of delivery

3.2 Consistency in the light of the test plan

3.3 Content of the procedure

3.4 Corresp

3.5 Deleted_Scenario

3.6 Coverage Justification

4.Results
4.1 Execution Log

4.2 Simulation des justifications

4.3 Consistency with the test plan

4.4 Consistency IVVR vs Execution Log

4.5 Consistency IVVR vs IVVQ

4.6 CR of the formal execution

5.Transverse
5.1 QAL and QUERY

5.2 FFT

5.3 SQAR

5.4 CR of Tracability
5.5 CR of Review

5.6 Global sheet Data

5.7 Summary
-

1. Each requirement which has 1 TM Modification, has a manœuvre/scenario with same

TM Modification - REG_062

1. During the campaign TC1 -> TC2, it is the FFT specified in the "Input_sheet" which
defines the scope

1. la revue de paire" (TC3) is done: all changed requirements have been checked and all
manoeuvrechanged without evolution of specifications have also been checked

1. The whole of scenario have been played on CIBLE and structural coverage (QMTC)
has been checked

1. Check that the MTC scope defined is well done

1. All the specific remarks have been followed. (See Input_sheet) whose FFTs affecting
directly TC

REG_001 - REG_003 - REG_004 - REG_026 - REG_050

1. All scenarios are identified as scenario REG_007 - REG_046

2. All manoeuvre are tagged as a manoeuvre REG_010 - REG_046

3. TM Modification completed (at manoeuvre and/or scenario level)

4. TM method of checking completed (case of Initialisation manoeuvre / Analyzes) -
REG_012

5. TM status to "Obsolete" if Scenario or Manoeuvre has been deleted - REG_061

1. Title of scenarios clear and without language mixture (quotation marks could be
accepted) REG_005

2. Consistency between the name of the Covered function (column "Function Coverage")
and the name of the directory (Field "Test Script File" or "File MATLAB")

3. Consistency between the title of the scenario and the name of the file (Field "Test
Script File" or "File MATLAB")

4. Title of the manoeuvre must be explicit in order quickly understand the purpose of the
test - REG_055

1. Check that the links are done on the current version of the specification, not on the
baseline. REG_047

1. Redundant links - requirement should be tested once only and should be linked to a
Manoeuvre (outside combinatorial) REG_047

2. Check if the test plan covers all cases MC/DC - REG_060

3. Manoeuvre must not check more than three requirements. - recom_056

In the manoeuvre we checks that:

1. there is no "Waiting for 1 second" without reason - recom_004 - REG_040

2. If there is more than 5 proposals, there is clear comments - recom_058

3. The good use of the #if - REG_013

4. Parameter of the SRS is used REG_042

5. Check Use test plans Generic - REG_053

6. Test must be complete REG_018 - REG_020 -REG_021 -REG_022 -REG_023 -REG_024 -
REG_025

7. each scenario / manœuvre has to be clear and without ambiguity REG_008 - REG_009
- REG_027 - REG_028 - REG_029 - RECOM_057 - RECOM_003

The written analyzes are:

1. Clean and understandable

2. All of the analyzes are tagged as a manoeuvre with a title Analysis tagged as
scenario.

3. Are not testable by scenario or not achievable (check ALQ) - REG_054

4. Does not contain any id of requirement for the Portability (except if blocking the
Understanding)

5. In each component with a title tagged Analysis Scenario

-
The folder of delivery of test procedures (TO PUT IN CONF under ClearCase) must
contain only the following files:

Session XML (ATC and SCTL)



scenario.m / prop.txt (ATC only)

Manual_modification.xls (ATC only)

temps_echantillonnage.txt (ATC only)



scenario.csv (SCTL only)

Corresp.txt (SCTL only)

enum.csv (SCTL only)

param csv (SCTL only)
1. Check that files present in the directory of delivery are consistent (name and path)
with the IVVQ - REG_033 - REG_043

1. The content of the procedure must be consistent with the IVVQ

2. The identifiers of the manoeuvremust be the same REG_044 - REG_045

1. Check that if there is a corresp_manual_modification.xls, it must be justified by a QAL

1. Check the reason for the Suppression of the scenario(s) (Requirement "obsoléte",
duplicate…)

1. All justifications of "non structural coverage" present in the files.jf are correct (Case not
achievable by execution)

-
1. All problems (error, NOK and war) present in the .log files have been notified in a QAL
point

2. Each scenario that have not been performed must be notified in a QAL point (Check
the consistency list of file doors vs list of files running)

3. All the logs of ATC session / SCTL are present: 1 Log for target and 1 log for QMTC at
minimum (full check) REG_035 - REG_036 - REG_037 - REG_038 - REG_039 - REG_041 -
REG_041bis

1. Check that the justifications have been taken into account correctly by the Tool. That
is means to verify that QMTC present in its log file contains all justifications defined in the
file .jf

2. Check the "Irrelevant Operators" at the bottom of the files C_composant_QMTC.txt (do
not have any logic)

1. Check that the numbers of manoeuvre match between IVVQ and the results obtained
(1 or 2 manually) - this is quickly sees in the IVVR (last column)

2. Check the number of proposal in the result in relation to the test plan

1. Consistency of the NOK/KO of log executions with theIVVR (full check)

2. All manoeuvre have a result (full check)

1. The IVVR is consistent with the IVVQ doors

2. The inconsistencies of numbers of manoeuvre are in the column "Comment"

3. The number of proposals (case of check by manoeuvre) is consistent

Check the CR and check-lists:

1. The CR are consistent and complete

2. All justifications are clear

3. Check the baselines vs input to SESI

-
1. All points QAL must be closed by SESI before their delivery

Check that the FT supplemented by SESI are legible

1. Good name of TFF

2. Same topic in Tab Description and Analysis

3. Not of @TC = to do in the'Analysis Tab

1. Inspected items identification shall be precise and correct.

2. Check the comments and the responses to the review of quality SESI (Annex of the
SQAR, last page)

1. Check that the column "version" of each tab is filled.

2. Check the list of FT in first page vs other tabs REG_002 - REG_011

1. The CR are consistent and complete

2. All justifications are clear

3. Check Baseline vs Inputs sheet from SESI

1. Check that it contains no reference to the FFT which will be closed

1. Overall check of the document (scope, FFT, Baseline, FCD...)

2. Summary_report must contain all FFT open during the campaign

3. Check that all the tabs of all the files attached to the Summary_DEFERRAL are well to
provide to the customer (doc internal)

4. Check the consistency between the'estimate and the Summary Report (example: NBR
requirements, nbr of scenario, NBR impacted requirements),

5. See if the metrics are always consistent

-

1. Toute Exigences ayant 1 TM Modification ont en face une manœuvre/scenario avec

même TM Modification - REG_062

1. Lors de la campagne TC1 -> TC2, c'est la FFT spécifiée dans "input_sheet" qui définit le
périmètre.

1. La revue de paire (TC3) est complète : toutes les exigences modifiées ont été relues ET
toutes les manœuvres modifiées sans évolution de spécification ont également été
relues.

1. L'ensemble des scénarios ont été joués sur Cible ainsi que la couverture structurelle
(QMTC) a été vérifiée.

1. Vérifier que le périmètre MTC défini est bien traité.

1. Toutes les remarques particulières ont été respectées. (voir input_sheet) dont les FFTs
impactant les TC directement

REG_001 - REG_003 - REG_004 - REG_026 - REG_050

1. Tous les scénarios sont bien identifiés en tant que scénario REG_007 - REG_046

2. Toutes les manœuvres sont taguées en tant que manœuvre REG_010 - REG_046

3. TM Modification rempli (au niveau manœuvre et/ou scenario)

4. TM Méthode de vérification complété (cas de manœuvre d'initialisation / cas des
analyses) - REG_012

5. TM Statut à obsolète si le scénario ou la manœuvre a été supprimé - REG_061

1. Titre des scenarios explicites et sans mélange de langue (sauf entre guillemets)
REG_005

2. Cohérence entre le nom du la fonction couverte (Colonne "Couverture Fonction") et le
nom du répertoire (champ "Test Script File" ou "Fichier MATLAB")

3. Cohérence entre le titre du scénario et le nom du Fichier (champ "Test Script File" ou "
Fichier MATLAB")

4. Titre de la manœuvre - il doit être explicite afin de cibler rapidement le but du test -
REG_055

1. Bien vérifier que les liens pointent vers la version en cours de la specification, pas sur la
Baseline d'entrée.
REG_047

1. Liens redondants - une exigence ne doit être testée qu’une seule fois et ne doit être liée
qu’à une manœuvre (hors combinatoire) REG_047

2. vérifier si le plan de test couvre bien tous les cas MC/DC - REG_060

3.Une manoeuvre ne doit pas vérifier plus de trois exigences. - RECOM_056

 Dans les manœuvres on vérifie par échantillonnage que :

1. l'on ne fait pas d'attente de 1 seconde sans raison - RECOM_004 - REG_040

2. si on a plus de 5 propositions, il y a des commentaires clairs - RECOM_058

3. le bon usage des #IF - REG_013

4. l'utilisation des Paramètre de la SRS REG_042

5. vérifier utilisation plans de test génériques - REG_053

6. le test doit être complet REG_018 - REG_020 -REG_021 -REG_022 -REG_023 -
REG_024 -REG_025

7. Chaque scénario / manœuvre doivent être clair et sans ambiguïté REG_008 - REG_009
- REG_027 - REG_028 - REG_029 - RECOM_057 - RECOM_003

Les analyses écrites sont :

1. propres et compréhensibles

2. Toutes les analyses sont taggées en tant que manœuvre avec un titre Analyse taguée
Scénario.

3. ne sont pas testables par scenario OU pas atteignables (vérifier QAL) - REG_054

4. ne contient pas d'identifiant d'exigence pour la portabilité (sauf si bloquant la
compréhension)

5. dans chaque composant avec un titre Analyse tagué Scénario

-
Le dossier de livraison des procédures de tests (à mettre en conf sous ClearCase) ne doit
contenir que les fichiers suivant:

Session XML (ATC and SCTL)



scenario.m / prop.txt (ATC only)

Manual_modification.xls (ATC only)

temps_echantillonnage.txt (ATC only)



scenario.csv (SCTL only)

Corresp.txt (SCTL only)

enum.csv (SCTL only)

param csv (SCTL only)
1. Vérifier que les fichiers présent dans le répertoire de livraison soient cohérent (nom et
chemin) avec l'IVVQ - REG_033 - REG_043

1. Le contenu de la procédure doit être cohérente à l'IVVQ

2. Les identifiants des manœuvres doivent être les mêmes

REG_044 - REG_045

1. Vérifier que si il y a un corresp_manual_modification.xls, il doit être justifié par un QAL

1. Vérifier la raison de la suppression du/des scénario(s) (exigence obsoléte, doublon…)

1. Toutes les justifications de non couvertures structurelles présentes dans les fichiers.jf
sont correctes (cas non atteignable par exécution)

-
 1. Tous le problèmes (ERROR, NOK et WAR) présents dans les traces d'exécution
(fichier.log) ont été signalés au préalable via un QAL

2. L'ensemble des scénarios qui n'ont pas été exécutés doivent être signalée au préalable
par un QAL (Vérifier cohérence liste de fichier DOORS/liste de fichiers exécuté)

3. Tous les logs de session ATC / SCTL sont présents : 1 log pour Cible et 1 log pour
QMTC au minimum (vérification complète)

REG_035 - REG_036 - REG_037 - REG_038 - REG_039 - REG_041 - REG_041bis

1. Vérifier que les justifications ont été prises en compte correctement par l'outil c'est-à-
dire de vérifier que QMTC présente dans son log toutes les justifications définies dans le
fichier .jf

2. Bien vérifier les "Irrelevant Operators" présents à la fin des fichiers
C_composant_QMTC.txt (ne doit pas contenir de logiques)

1. Vérifier que les numéros de manœuvre correspondent entre IVVQ et les résultats
obtenues (1 ou 2 manuellement) - Cela se voit rapidement dans les IVVR (dernière
colonne)

2. Vérifier le nombre de proposition dans le resultat par rapport au plan de test

1. Cohérence des NOK/KO des log d'executions avec l'IVVR (vérification complète)

2. Toutes les manœuvres ont un résultat (vérification complète)

1. L’IVVR est bien cohérent avec l’IVVQ DOORS

2. Les incohérences de numéros de manœuvres sont dans la colonne commentaire

3. Le nombre de propositions (cas de vérif. par manœuvre) est bien cohérent

Vérifier les CR et check-lists :

1. Les CR sont cohérents et complets

2. Tous les justifications sont claires

3. Vérifier les baselines vs entrants vers SESI

-
1. Tous les points QAL doivent être clos par SESI avant leur livraison

Vérifier que les FT complétés par SESI sont lisibles

1. Bon nom de FFT

2. Même sujet dans onglet Description et Analyse

3. Pas de @TC = To DO dans l'onglet analyse

1. L'identification des objets inspectés doit être précise et correcte.

2. Vérifier les remarques et les réponses apportées à le revue de qualité SESI (Annexe du
SQAR, dernière page)

1. Vérifier que la colonne version de chaque onglet est remplie.

2. Vérifier la liste des FT en première page vs autres onglets

REG_002 - REG_011

1. Les CR sont cohérents et complets

2. Tous les justifications sont claires

3. Vérifier les baselines vs entrants vers SESI

1. Vérifier qu'il ne contient pas de référence à des FFT qui vont être fermés

1. Relecture globale du document (Scope, FFT, Baseline, FCD...)

2. Summary_Report doit contenir toutes les FFT ouvertes pendant la campagne

3. Vérifier que tous les onglets de tous les fichiers attachés au Summary_Report sont
bien à fournir au client (doc interne)

4. Vérifier la cohérence entre l'estimation et le Summary report (exemple: nbr exigences,
nbr de scénario, nbr exigences impactées),

5. Voir si les métriques sont toujours cohérents