Vérification par la méthode de test

Comme le montre la figure 2.17, le test fait partie intégrante du cycle de développement du logiciel. Il s'intéresse au produit final et intervient après la phase de réalisation pour tester

des constituants indépendants et puis tester le système global après intégration. C’est une activité qui a pour objectif d’exécuter le système dans l’intention de détecter une erreur [Myers, 1979]. Le principe de cette exécution consiste à appliquer des données d’entrées au système sous test et puis à observer les sorties afin de les comparer aux spécifications du cahier des charges. Le test peut être défini ainsi [Beizer, 1995]:

Pouvoir du testPouvoir du testPouvoir du testPouvoir du test

: le test met seulement en évidence des dysfonctionnements éventuels mais ne permet pas de prouver l’absence d’erreurs.

Coût du testCoût du testCoût du testCoût du test

: le test couvre près de 50 % du coût total du développement d'un logiciel.

Phases du tePhases du tePhases du tePhases du testststst

: plusieurs niveaux définissent le test tout au long du cycle de développement d’un logiciel : tests unitaires, tests d’intégration, tests système, tests recette et test non-regression (cf. Fig.2.17).

Les différentes phases de test du cycle de développement d’un logiciel sont représentées dans la figure 2.18 et expliquées ci-dessous.

Figure 2.18: Les différentes phases de test

Test unitaireTest unitaire « Test unitaireTest unitaire

Testing of individual software units or groups of related units

» [IEE, 1990]: C’est le processus qui permet de tester les composants d'un petit programme informatique, tels que les sous-programmes. L’objectif de cette phase de test est de vérifier le fonctionnement des différentes parties du programme de manière indépendante.

TestTestTestTest inininintégrationtégrationtégrationtégration «

Testing in which software components, hardware components, or

both are combined and tested to evaluate the interaction between them

» [IEE, 1990]: Il fait suite au test unitaire et détermine si tous les composants du programme fonctionnement correctement quand ils sont liés ensemble. Ce test permet de vérifier les interactions entre les composants et a pour but de trouver des erreurs liées à la mise en interaction de ces derniers.

Test systèmeTest système « Test systèmeTest système

Testing conducted on a complete, integrated system to evaluate the

system’s compliance with its specified requirements

» [IEE, 1990]: Ce test examine le programme entier alors que le test d’intégration s’intéressait aux connexions d’interfaces entre composants. Son objectif est de détecter les erreurs qui peuvent apparaître à travers une vision globale du programme.

Test recetteTest recetteTest recetteTest recette «

Test réalisé par l’utilisateur pour vérifier si l’application répond bien à

ses besoins

»: Ce test permet au client de s’assurer du bon fonctionnement du logiciel par rapport aux spécifications du cahier des charges. Il conditionne en effet l’acceptation du produit par le client. Le cahier des charges peut contenir des scénarios d’utilisation préétablis qui peuvent servir comme test de recette.

TestTestTestTest de nonde nonde nonde non----régression régression régression «régression

Processus de test d'un programme dont le code a été

modifié

» : La modification du code peut se produire lors de l’ajout de nouvelles fonctionnalités par exemple. L'objectif de ce test de non-régression est de s'assurer que le programme modifié satisfait encore les exigences et que ses fonctionnalités précédentes n'ont pas été affectées.

Au niveau du test de logiciel ([Myers, 1979], [Beizer, 1990]), on distingue principalement deux

typestypes de teststypestypesde testsde testsde tests

: le test structurel et le test fonctionnel (cf. Fig.2.19). Le test structurel se base sur l’analyse de la structure interne d’une implantation tandis que le test fonctionnel consiste à vérifier si une implantation logicielle ou matérielle est conforme à sa spécification. Cette dernière est définie comme une description des comportements désirés qui décrit ce que le système doit faire et non pas comment il est fait.

Figure 2.19: Le test fonctionnel et le test structurel

2.3.2.1 Le test structurel

Le test structurel, ou

le test boite blanchele test boite blanchele test boite blanchele test boite blanche

[Beizer, 1990], est une méthode qui s’appuie sur la connaissance de la structure interne du programme. L'objectif de cette méthode consiste à tester le code du programme (1) en choisissant des données de test à vérifier par exemple chaque déclaration ou chaque chemin dans le code; ou (2) en vérifiant les conditions de sélection et de répétition des structures de contrôle du programme. Parmi les techniques de test structurel, le Data-Flow Testing [Rapps et Weyuker, 1985] qui permet d’analyser comment les variables d'un programme sont liées aux valeurs et comment ces variables sont utilisées. Plus précisément, l’objectif de cette technique est de construire une suite de tests

qui force l'exécution des différentes interactions entre le moment où les variables sont définies et le moment où elles sont utilisées dans le programme.

2.3.2.2 Le test fonctionnel

Le test fonctionnel,

connu par le test boîte noireconnu par le test boîte noireconnu par le test boîte noireconnu par le test boîte noire

[Beizer, 1995], est une méthode qui permet de vérifier que les fonctionnalités d'un programme donné correspondent bien à ses spécifications sans faire aucune référence à sa structure interne. L’objectif de cette méthode consiste à générer des tests à partir d'une spécification, les exécuter sur le programme réel et de s'assurer que ce dernier se comporte correctement en comparant les résultats obtenus par le programme à ceux requis dans la spécification. Ci-dessous, nous présentons des exemples de

méthodes de test de boîte noireméthodes de test de boîte noireméthodes de test de boîte noireméthodes de test de boîte noire

.

Le test de conformité Le test de conformitéLe test de conformité

Le test de conformité ([Beizer, 1995], [Tretmans, 1992]) est une technique de test permettant de s’assurer que les fonctionnalités mentionnées dans la spécification d'un programme donné ont été bien implémentées dans ce programme. L’objectif du test de conformité est de générer un ensemble de cas de test qui vérifient que le programme satisfait ses spécifications. La question qui se pose: « Est-ce que le programme fait ce qu’il doit faire ? » Le test de conformité est présenté en détail dans la section suivante.

Le test de performance Le test de performanceLe test de performance

Le test de performance [IEEE, 1990] est une technique permettant de comparer la conformité d'un programme donné aux critères de performance. L’objectif du test de performance est d’évaluer les ressources (telles que le temps d'exécution, le temps de réponse, l'utilisation de la mémoire, etc.) qui sont nécessaires à la réalisation du programme. La question typique qui se pose est: Quelle est la vitesse du programme pour réaliser sa tâche?

Le test de robustesse Le test de robustesseLe test de robustesse

Le test de robustesse est une technique définie comme « the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions » [IEEE, 1990]. L’objectif de cette technique est de vérifier le comportement d'un programme donné dans un environnement erroné. La principale question qui se pose est : Comment le programme va réagir si son environnement ne se comporte pas comme prévu?

Le test de fiabilité Le test de fiabilitéLe test de fiabilité

Le test de fiabilité [Musa, 1975] est une technique permettant de vérifier le bon fonctionnement d’un programmé donné durant une période de temps spécifiée et dans un environnement spécifié. La question qui se pose : durant combien de temps peut-on compter sur le bon fonctionnement du programme donné ?

Dans la pratique, plusieurs types d’observabilité peuvent être utilisés pour générer les tests. Si le code source du logiciel à tester est disponible, nous avons le choix de générer des tests de type boîte blanche ou boîte noire selon l’observabilité que l’on souhaite. Dans le cas où

nous disposons uniquement des interfaces, le test est uniquement de type boîte noire. Comme nous l’avons déjà expliqué, les méthodes de test de logiciels varient également en fonction de la nature du test. Par exemple, au niveau du test fonctionnel, ces méthodes diffèrent si nous parlons de test de conformité, de test de performance, de test de robustesse ou de test de fiabilité.

Dans la partie qui suit, nous nous focalisons sur

les tests de conformitéles tests de conformitéles tests de conformitéles tests de conformité

étant donné que nous voulons tester un système dont on ne connaît pas le code. En effet,

l’objectif de cette l’objectif de cette l’objectif de cette l’objectif de cette

thèse est de tester des constituants réactifs dans l

thèse est de tester des constituants réactifs dans lthèse est de tester des constituants réactifs dans l

thèse est de tester des constituants réactifs dans leur environnement d’interactioneur environnement d’interactioneur environnement d’interactioneur environnement d’interaction

. On ne connaît pas forcément comment ces constituants fonctionnement mais les spécifications nous informent comment ils doivent interagir ensemble. Dans la figure 2.20, on compare les deux cycles suivants : le premier est celui de la mise en œuvre du système ERTMS conformément à la norme 50126 concernant les FDMS, le deuxième est celui d’un cycle de développement de logiciel classique en V (cf. Fig. 2.20). Nos travaux de thèse correspondent, au niveau du cycle à gauche, aux

tests fonctionnels de sécuritétests fonctionnels de sécuritétests fonctionnels de sécuritétests fonctionnels de sécurité

, ce qui représente au niveau du deuxième cycle à droite, les

tests d’intégration des constituantstests d’intégration des constituantstests d’intégration des constituantstests d’intégration des constituants

. Ainsi, le premier axe de recherche que nous avons choisi est celui des tests de conformité vérifiant l’intégration des constituants dans leur environnement. Pour résumer cette section,

au niveau des phases de

test

, on se place dans les

tests d’intégrationtests d’intégrationtests d’intégrationtests d’intégration

; au niveau des

types de tests

, on se place dans les

tests fonctionnels

tests fonctionnelstests fonctionnels

tests fonctionnels

; et enfin au niveau des

méthodes

, on se place dans les

tests de conformitétests de conformitétests de conformitétests de conformité

.

Figure 2.20: Comparaison entre cycle de vie ERTMS et cycle de vie de logiciel classique

Dans le document Génération de scénarios de tests pour la vérification de systèmes complexes et répartis : application au système européen de signalisation ferroviaire (ERTMS) (Page 67-74)