Technique de tests pratiques par « Analyseur de spectre »

Pour pouvoir tester le prototype, la technique de test s’inspirant du fonctionnement de l’analyseur de spectre [30] est utilisée.

Les analyseurs de spectre sont largement utilisés pour mesurer la réponse en fréquence, le bruit et les caractéristiques de distorsion de toutes sortes de circuits RF (Radiofréquence), en comparant les spectres d'entrée et de sortie. Ils peuvent être utilisés pour caractériser les signaux de test et mesurer la réponse de l'équipement à tester.

Cette technique consiste, dans le cadre du test du prototype d’automatisation, à utiliser une séquence de spécifications en entrée en partant de spécifications ne comportant qu’un seul processus fonctionnel et ayant la combinaison minimale obligatoire de mouvement de données, puis en progressant d’une manière méthodique et systématique pour arriver à la combinaison la plus complexe en terme de complétude de combinaisons de flux.

Le protocole utilise des échantillons au niveau de l'entrée de l'outil d'automatisation pour essayer de couvrir la plupart des types de cas d'entrée qui pourraient être rencontrés. Pour des fins de vérification, les échantillons doivent être mesurés manuellement, selon les procédures de mesure proposées. Ainsi, en plus de la taille fonctionnelle obtenue, tous les processus fonctionnels et les mouvements de groupes de données sont identifiés par la mesure manuelle. De plus, comme la source d'une erreur peut être le processus manuel de mesurage ou être causée par le prototype, l’application de ce protocole permet l’identification de la partie qui est responsable de tout genre d'erreur.

Un outil d'automatisation doit répondre à trois propriétés des procédures FSM: • l'exactitude,

129

• la répétabilité et • la reproductibilité.

Par exemple, la propriété d’exactitude est définie dans le VIM comme l'étroitesse de l'accord entre une quantité mesurée et la quantité vraie d'un mesurande [37]. La propriété de répétabilité peut être vérifiée et confirmée lorsque l'outil génère les mêmes résultats pour une spécification donnée en entrée dans les mêmes conditions. La reproductibilité est vérifiée si deux outils différents qui mettent en œuvre les mêmes procédures FSM, donnent le même résultat pour la même entrée.

Pour utiliser cette technique, les spécifications (à mesurer) en entrée du prototype sont divisée en 3 groupes dans lesquelles se trouvent les échantillons d’entrée du prototype. Ces groupes sont aussi divisés en sous-groupes en fonction du nombre de mouvements de données. Ces groupes sont définis comme présentés dans le tableau 7.6.

Tableau 7.6 Séparations des groupes d'échantillons des entrées

Nombre de PFs Nombre de mouvements de

données par PF Groupes de tests

1 à 5 2 à 4 A 5 à 10 B 10 à 50 C 50 à 100 D >100 E 6 à 10 2 à 4 F 5 à 10 G 10 à 50 H 50 à 100 I >100 J >10 2 à 4 K 5 à 10 L 10 à 50 M 50 à 100 N >100 O

7.4.1 1ère phase : comparaison des résultats numériques finaux

Dans cette phase, les résultats (en termes de la CFP - points de fonction COSMIC) produits automatiquement par le prototype et ceux obtenus à partir du processus manuel de mesurage de la même entrée sont comparés. S'il ya un match entre ces deux séries de résultats, cela signifie qu'aucune différence n'a été détectée entre la mesure manuelle et la mesure automatisée. L'évaluation peut s'arrêter à ce stade. Toutefois, on peut continuer à vérifier, même s’il n’y a pas de différence au niveau du total (résultat final), qu’il n’y a pas des différences importantes au niveau des processus eux-mêmes. Ceci est très important si le nombre d’échantillons de spécifications utilisées en entrée est petit.

131

Tableau 7.7 Format de la présentation des résultats en boîte noire

Données Résultat en

manuel automatique Résultat en Match ?

Nombre des E x y Oui/non

Nombre des X x y Oui/non

Nombre des W X y Oui/non

Nombre des R X y Oui/non

Taille fonctionnelle totale obtenue

X y Oui/non

7.4.2 2ème phase : Comparaison détaillée

Si les résultats numériques finaux à la fin de la phase 1 ne correspondent pas, la phase 2 commence par la comparaison des résultats au niveau détaillé, ce qui signifie la vérification du nombre des processus fonctionnels obtenus automatiquement et manuellement sont égaux, et donc, une vérification du mesurage manuel au cas d'une erreur humaine en parallèle à la vérification détaillée du mesurage automatique :

1. Si aucune différence n'est observée dans le nombre de processus fonctionnels, chaque processus fonctionnel obtenu est automatiquement vérifié par rapport à ses «homologues» obtenus manuellement, afin de déterminer si oui ou non il ya une différence dans leurs noms (ou leurs identificateurs).

2. Si tous les processus fonctionnels obtenus automatiquement correspondent à leurs «homologues» obtenus manuellement, leurs tailles fonctionnelles sont comparées : s’il y a des différences, un ou plusieurs mouvements de données à l'intérieur du processus fonctionnel doivent être responsable.

À la fin de cette phase, les mouvements de données responsables de l'erreur sont isolés.

Tableau 7.8 Format de la présentation des résultats en boîte grise

Données Résultat en

manuel automatique Résultat en Match ?

Nombre de PF x y Oui/non PF n°=1 x y Oui/non Mouvement de données n°=1 Mouvement de données n°=1 Oui/non Mouvement de

données n°=2 Mouvement de données n°=2 Oui/non . . . . . . Oui/non Mouvement de

données n°=n Mouvement de données n°=n Oui/non

PF n°=2 x y Oui/non

Mouvement de

données n°=1 Mouvement de données n°=1 Oui/non .

. .

Mouvement de

données n°=2 Mouvement de données n°=2 Oui/non

PF n°=n . . . . . . Oui/non Mouvement de données n°=n Mouvement de données n°=n Oui/non

7.4.3 3ème phase : l'inspection du prototype et de la spécification

Cette phase est déclenchée lorsque l'erreur humaine (au niveau du mesurage manuel) est écartée à la fin de la phase 2.

Puisqu'une erreur détectée peut avoir deux sources, cette phase consiste :

1. D'une part, à l'inspection du module (pour le prototype 1 développé pour Renault, les modules sont : le parseur, le générateur de données, ou l’unité de mesure) du prototype responsable de l'erreur, et

133

2. D'autre part et en parallèle, l’inspection de la spécification d'entrée pour trouver un éventuel défaut qui puisse être l’origine de l'erreur.

Une fois qu’un bug et/ou un défaut est détecté, il est enregistré. Si le problème peut être résolu s’il a été causé par le prototype, la spécification appropriée est réévaluée avec la nouvelle version du prototype. Si le problème a été dans la spécification d'entrée, le défaut responsable est enregistré pour d’éventuelles améliorations futures de la spécification fonctionnelle en entrée et/ou une implémentation spécifique pour résoudre ce type de problème rencontré dans les spécifications du même genre est implémentée dans l’outil.

Finalement, la nouvelle version corrigée de la spécification d'entrée est ensuite vérifiée par ce protocole pour s’assurer que les résultats des mesurages manuel et automatique sont égaux.

Nombres de PF égaux? Mêmes PFs man/auto? Mêmes mouvements de données ? oui oui Inspection de la qualité de la spécification Inspection des modules de l’outil Taille fonctionnelle égale? non Continuer la vérification en détail de la mesure ? non oui oui oui non non non

Écart causé par une erreur humaine ? non Fin de l’évaluation Fin de l’évaluation Fin de l’évaluation oui

Relevé des défauts de la spécification et/ou bugs

de l’outil Tentative de traitement du

défaut et/ou bug

Phase 2 Phase 3

Phase 1

Figure 7.5 Phases du protocole d'évaluation

7.5 Application du protocole d’évaluation sur la spécification fonctionnelle du