Support de cours de Génie logiciel GL2

Chapitre 1 : LE CYCLE DE VIE D’UN LOGICIEL

1.1Introduction
Le cycle de vie d’un logiciel (en anglais software life cycle), désigne toutes les étapes du
développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel
découpage est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c’est-dire la conformité du logiciel avec les besoins exprimés, et
la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes
mises en œuvre. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de
maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
 Définition des objectifs – Cet étape consiste à définir la finalité du projet et son
inscription dans une stratégie globale.
 Analyse des besoins et faisabilité – c’est-à-dire l’expression, le recueil et la
formalisation des besoins du demandeur (le client) et de l’ensemble des contraintes,
puis l’estimation de la faisabilité de ces besoins.
 Spécifications ou conception générale – Il s’agit de l’élaboration des
spécifications de l’architecture générale du logiciel.
 Conception détaillée – Cette étape consiste à définir précisément chaque sous-
ensemble du logiciel.
 Codage (Implémentation ou programmation) – c’est la traduction dans un
langage de programmation des fonctionnalités définies lors de phases de
conception.
 Tests unitaires – Ils permettent de vérifier individuellement que chaque sous-
ensemble du logiciel est implémenté conformément aux spécifications.
 Tests d'Intégration – L’objectif est de s’assurer de l’interfaçage des différents
éléments (modules) du logiciel. Elle fait l’objet de tests d’intégration consignés
dans un document.
 Tests de Qualification (ou recette) – C’est-à-dire la vérification de la conformité
du logiciel aux spécifications initiales.
 Documentation – Elle vise à produire les informations nécessaires pour
l’utilisation du logiciel et pour des développements ultérieurs.
 Mise en production – C’est le déploiement sur site du logiciel.
 Maintenance – Elle comprend toutes les actions correctives (maintenance
corrective) et évolutives (maintenance évolutive) sur le logiciel.
 Support de cours de Génie Logiciel GL2

La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix d’un
modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie permet de prendre
en compte, en plus des aspects techniques, l’organisation et les aspects humains.

1.2 Modèles de cycles de vie d’un logiciel

1.2.1 Modèle de cycle de vie en cascade

L’inconvénient majeur du modèle de cycle de vie en cascade est que la vérification du bon
fonctionnement du système est réalisée trop tardivement : lors de la phase d’intégration, ou pire, lors
de la mise en production.
 Support de cours de Génie Logiciel GL2

Fig. 1.1 – Modèle du cycle de vie en cascade

1.2.2 Modèle de cycle de vie en V

Le modèle en V (cf. figure 1.2) demeure actuellement le cycle de vie le plus connu et
certainement le plus utilisé. Il s’agit d’un modèle en cascade dans lequel le développement des
tests et du logiciel sont effectués de manière synchrone.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition et
que toute description d’un composant est accompagnée de tests qui permettront de s’assurer
qu’il correspond à sa description.

Fig. 1.2 – Modèle du cycle de vie en V

 Support de cours de Génie Logiciel GL2

Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la
spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier
objectivement après la réalisation.
Cependant, ce modèle source toujours du problème de la vérification trop tardive du bon
fonctionnement du système.

1.2.3 Modèle de cycle de vie en spirale

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il
met l’accent sur l’activité d’analyse des risques : chaque cycle de la spirale se déroule en
quatre phases
 Détermination, à partir des résultats des cycles précédents, ou de l’analyse
préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre
et des contraintes ;
 Analyse des risques, évaluation des alternatives et, éventuellement
maquettage ;
 Développement et vérification de la solution retenue, un modèle « classique »
(cascade ou en V) peut être utilisé ici ;
 Revue des résultats et vérification du cycle suivant.
L’analyse préliminaire est a née au cours des premiers cycles. Le modèle utilise
des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le
dernier cycle se termine par un processus de développement classique.

1.2.4 Modèle par incrément

Dans les modèles précédents un logiciel est décomposé en composants développés
séparément et intégrés à la fin du processus.

Dans les modèles par incrément un seul ensemble de composants est développé à
la fois : des incréments viennent s’intégrer à un noyau de logiciel développé au préalable.
Chaque incrément est développé selon l’un des modèles précédents.

Les avantages de ce type de modèle sont les suivants :

 chaque développement est moins complexe ;
 Support de cours de Génie Logiciel GL2

 les intégrations sont progressives ;

 il est ainsi possible de livrer et de mettre en service chaque incrément ;
 il permet un meilleur lissage du temps et de l’effort de développement grâce à la
possibilité de recouvrement (parallélisation) des différentes phases.

Les risques de ce type de modèle sont les suivants :

 Remettre en cause les incréments précédents ou pire le noyau ;  Ne pas pouvoir

intégrer de nouveaux incréments.

Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés
globalement, au début du projet. Les incréments doivent être aussi indépendants que
possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.
 Support de cours de Génie Logiciel GL2

Chapitre 2 DEMARCHE QUALITE

2.1 Introduction

La démarche Qualité consiste à trouver l’adéquation entre la réponse aux besoins du

projet, l’expression correcte de ces besoins par des spécifications adéquates qui passent
par une écoute attentive du client, et une réalisation répondant à l’expression des besoins.

Si les spécifications sont conformes aux besoins mais que la réalisation ne répond pas
aux spécifications et donc aux besoins, on parle de défauts dans la réalisation. C’est de
la non- qualité. Si la réalisation est conforme aux besoins alors que les spécifications
n’étaient pas bonnes, on a eu de la chance, on parle de qualité aléatoire. Enfin, si la
réalisation est conforme aux spécifications mais que ces dernières ont surévalué les
besoins, on parle de sur-qualité.

2.2 La démarche qualité au cours du projet

La démarche qualité doit s’intégrer à toutes les phases du projet.

 Phases d’études préalables et de définition fonctionnelle du besoin

Lors des phases d’étude préalable et de définition fonctionnelle des besoins, la qualité se
caractérise par la capacité des études produites à adresser les véritables objectifs du projet
et de complètement satisfaire les attentes associées. Lors de ces phases, les contrôles
qualité reposent d’une part, sur la vérification du respect des principes de la méthodologie
mise en œuvre et d’autre part, sur des revues visant à garantir l’adéquation et la cohérence
des solutions proposées avec les attentes entre les différentes phases (schéma directeur,
puis analyse préalable puis définition fonctionnelle du besoin). Le processus qualité
s’attachera également à s’assurer du bon fonctionnement du cycle de validation pour
vérifier que tous les principes et solutions proposés ont fait l’objet d’une validation ad
hoc.
 Support de cours de Génie Logiciel GL2

 Phases de réalisation
Le contrôle de la qualité porte d’une part, sur la vérification de la méthodologie mise en
œuvre et d’autre part, sur des revues de code permettant de garantir les performances et
la maintenabilité des applications développées.

 Phases de test
Les phases de test permettent de vérifier d’une part, le bon fonctionnement intrinsèque
des applications livrées et d’autre part, l’adéquation entre les fonctions réalisées par ces
applicatifs et les fonctions spécifiées dans les dossiers de définition du besoin. En
conséquence, lors de ces phases, le contrôle de qualité va consister à vérifier le bon
fonctionnement de ce processus.

 Contrôle
Contrôle de l’élaboration des fiches de tests (cycle de test, cas de test, description des jeux
de test, description des résultats attendus),

 Reproduction de test par sondage

Lors des phases de test, il est important de refaire quelques tests aléatoirement par une
autre personne pour limiter les risques d'erreur.

Cas d'entreprise :
Lors de la recette d'un module comptable, un consultant qui a passé les écritures
comptables de test dans le système comptable selon les cas de tests prévus les a passé
sans les valider mais les à sauvegarder. Un autre consultant a contrôlé toutes les écritures
passées avant de les valider.

Dans cet exemple, la démarche d'intervention de deux consultants différents s'inscrit dans
une démarche qualité.
 Support de cours de Génie Logiciel GL2

 Contrôle du cycle de traitement des anomalies

Les anomalies détectées lors des phases de test doivent donner lieu à une correction en
termes de paramétrage/développement.

De nouveaux tests doivent alors avoir lieu dans le cadre de la démarche qualité, afin de
s'assurer que les corrections apportées fonctionnent.

2.3.3 Présentation du cycle de Shewart-Deming

Le célèbre cycle de Shewart-Deming est encore appelé le cycle Deming ou le cycle PDCA
(Plan, Do, Check and Act).

Au départ, dans les années 1920, le statisticien Shewart est à l'origine d'une première
version du cycle : planifier, agir et voir le résultat. Ce cycle a été revu et amélioré par
Edward Deming selon les modalités que nous allons voir.

Le cycle Deming montre comment appliquer les principes de la Démarche Qualité au

processus projet, mais aussi à ses tâches élémentaires.

Il se compose de quatre phases :

• La planification ("Plan"): Phase au cours de laquelle sont formalisés les attentes,
les moyens et les objectifs

• La réalisation ("Do"): Elle s'appuie sur les modes opératoires préalablement

définis

• La vérification ("Check"): Elle doit, elle aussi, se conformer aux processus définis
en amont avec un souci d'exhaustivité

• L’action correctrice ("Act"): correction des erreurs constatées et mise en place de

mesures pour éviter qu'elles ne se reproduisent.
 Support de cours de Génie Logiciel GL2

Résultat : la réussite de cette démarche dépendra de la mobilisation de chacun pour une

recherche permanente d'amélioration et des moyens mis en œuvre par les instances de
décision pour l'application de la démarche.
 Support de cours de Génie Logiciel GL2

Chapitre 3 : Analyse fonctionnelle (Spécification)

III.1. Définition
L'analyse fonctionnelle consiste à rechercher et à caractériser les fonctions offertes par un
produit placé dans un système pour satisfaire les besoins de son utilisateur.

Un système est un ensemble d’éléments formant un tout structuré satisfaisant plusieurs

besoins cohérents.

Il existe deux (02) types d’analyse fonctionnelle à savoir :

III.2. La méthode FAST (Function Analysis System Technic)

Elle permet de traduire chacune des fonctions de service en fonction(s) technique(s), puis
matériellement en solution(s) constructive(s).

Principe de fonctionnement

Il se construit de gauche à droite, dans une logique du pourquoi au comment.

Dès lors que les fonctions de services sont identifiées, cette méthode les ordonne et les
décompose logiquement pour aboutir aux solutions techniques de réalisation.

Le diagramme FAST constitue alors un ensemble de données essentielles permettant d’avoir

une bonne connaissance d’un produit complexe et ainsi de pouvoir améliorer la solution
proposée.
 Support de cours de Génie Logiciel GL2

Exemple :

Analyse fonctionnelle interne d’un aspirateur

III.3. Analyse fonctionnelle externe

Cette analyse fonctionnelle concerne l'usage d'un produit, c'est à dire les fonctions qu'il doit
assurer pour satisfaire le besoin du client.

Elle exprime le point de vue du client et met en évidence les fonctions d’usage ou d'estime.

Il existe plusieurs méthodes ou outils mettant en exergue l’analyse fonctionnelle externe donc
nous en citerons deux (02) en particulier à savoir :

III.3.1. La Bête à cornes

Pour formaliser l’énoncé du besoin, l’utilisation de l’outil bête à cornes est le mieux adapté.
Pour cela, il est fondamental de poser les trois questions suivantes:

 À qui rend-il service?

 Sur quoi agit-il ?
 Support de cours de Génie Logiciel GL2

 Dans quel but le produit existe-il ?

Exemple :

III.3.2. Diagramme pieuvre

Il permet de relier le produit ou service à son environnement extérieur. Il met en évidence les
relations entre les différents Eléments du Milieu Extérieur (EME) et le produit ou service au
travers de fonctions : Fonctions Principales (FP) et Fonctions de Contraintes (FC).

Vocabulaire

 Fonctions principales (FP) : C’est la raison d’être du produit

 Support de cours de Génie Logiciel GL2

 Fonctions de contraintes (FC) : Ce sont des limitations à l’imagination du concepteur

 Milieu extérieur : Représente tous les éléments ayant une interaction avec le produit
ou service

Principe de fonctionnement

Pour créer un diagramme pieuvre nous devons tout d’abord placé l’objet à étudier dans une
bulle centrale puis, rechercher les Eléments du Milieu Extérieur (EME) en relation avec le
produit ou service et les placer autour de la première bulle. Identifier les fonctions principales
FP (= relier deux bulles extérieurs en passant par l’objet à étudier) et enfin identifier les
fonctions de contraintes FC en reliant par une ligne les bulles restantes de l’extérieur à l’objet
à étudier.

Fonctions Principales (FP) Fonctions de Contraintes (FC)

FP1 = Sélectionner un élément FC1 = Eviter tout choc excessif

FC2 = Organiser le poste de travail de manière ergonomique

FC3 = S’assurer de la présence de piles 2 x AAA (1.5V)

FC4 = Ne diriger jamais le capteur optique vers les yeux afin

d’éviter une blessure éventuelle
Support de cours de Génie Logiciel GL2

FC5 = Connecter le nano-récepteur USB

 Support de cours de Génie Logiciel GL2

Chapitre 4 TEST D’UN LOGICIEL

I. Fondement du test (pourquoi réaliser un test ?)

Le test est une recherche d'anomalie dans le comportement du logiciel. C’est une activité
paradoxale : il vaut mieux que ce ne soit pas la même personne qui développe et qui teste
le logiciel. D’où le fait qu’un bon test est celui qui met à jour une erreur (non encore
rencontrée).

II. Cycle de développement du test

Support de cours de Génie Logiciel GL2
 Support de cours de Génie Logiciel GL2

II.1. Mise au point inductive

On met une hypothèse sur l’ensemble.

II.2. Mise au point déductive

On traite chaque cause séparément.

 Support de cours de Génie Logiciel GL2

III. Les différentes techniques de test

Plusieurs techniques dépendent de l’objectif du test. Mais aucune technique ne sera jamais
complète. Le problème est de savoir quelle technique nous assure la complétude, car en
fait, aucune ne peut le garantir.

Vocabulaire :

• Espace générateur : Il s’agit de l’ensemble des tests générés pour assurer la

complétude du logiciel
 Support de cours de Génie Logiciel GL2

• Espace de cas possibles : Il s’agit de l’ensemble des erreurs possibles pouvant être
rencontrées sur le logiciel

Propriétés recherchées :

Si l’espace générateur est couvert alors la probabilité d'une défaillance dans l'espace de cas
possibles est très faible (inférieure à une limite fixée à l'avance). La difficulté est de faire que
l'espace générateur soit consistant et complet.

III.1. Test statique

Test réalisé par l’humain par revue ou relecture du code.

III.2. Test dynamique

Ici on exécute chaque module ou composante du logiciel avec des valeurs en entrée et on
observe le comportement.

III.3. Test en « Boîte noire »

Les tests en « boîte noire » consistent à examiner uniquement les fonctionnalités d’une
application, c’est-à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait.
Sa structure et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel
 Support de cours de Génie Logiciel GL2

est le rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un
profil uniquement « utilisateur ».

Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une
application fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs sont à
la recherche de fonctions incorrectes ou manquantes, d’erreurs d’interface, de performance,
d’initialisation et de fin de programme, ou bien encore d’erreurs dans les structures de données
ou d’accès aux bases de données externes.

Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur possibles sur
le système testé. Toutes les fonctionnalités doivent être prises en compte, pour qu’une fois tous
les tests effectués, elles aient toutes été éprouvées (appréciées). Les tests consistent à suivre un
scenario, et à vérifier pour chaque fonctionnalité que les entrées (inputs) valides sont acceptées,
que celles non valides sont refusées, et bien entendu, qu’à chaque fois, le résultat (sortie ou
output) attendu est bien obtenu. C’est ce que l’on appelle la méthode « trial and error » (essais
et erreurs).

Les avantages de cette méthode sont les suivants :

• Simplicité : ces tests sont simples à réaliser, car on se concentre sur les entrées et les
résultats. Le testeur n’a pas besoin d’apprendre à connaître le fonctionnement interne
du système ou son code source, qui n’est pas accessible. Cette méthode est donc
également non intrusive.
• Rapidité : en raison du peu de connaissances nécessaires sur le système, le temps de
préparation des tests est très court. Les scénarios sont relativement rapides à créer et à
tester, puisqu’ils suivent les chemins utilisateurs, qui sont relativement peu nombreux
selon la taille du système.
• Impartialité : on est ici dans une optique « utilisateur » et non « développeur ». Les
résultats du test sont impartiaux : le système marche, ou il ne marche pas. Il n’y a pas
de contestation possible, comme par exemple sur l’utilisation de tel processus plutôt
qu’un autre selon l’opinion du développeur.
Mais les tests en « boîte noire » ont également des inconvénients :
• Superficialité : étant donné que le code n’est pas étudié, ces tests ne permettent pas de
voir, en cas de problème, quelles parties précises du code sont en cause. De plus, les
testeurs peuvent passer à côté de problèmes ou vulnérabilités sous-jacentes. Certains
problèmes sont également difficilement repérables avec cette méthode, comme par
exemple ceux liés à la cryptographie, ou à des aléas (évènements imprévisibles) de
mauvaise qualité. C’est donc l’un des tests les moins exhaustifs.
 Support de cours de Génie Logiciel GL2

• Redondance : si d’autres tests sont effectués, il est possible que celui-ci perde
grandement de son intérêt, puisque son champ d’action a tendance à être inclus dans
celui d’autres tests.

III.4. Test en « Boîte blanche »

Les tests en « boîte blanche » consistent à examiner le fonctionnement d’une application et sa
structure interne, ses processus, plutôt que ses fonctionnalités. Sont ici testés l’ensemble des
composants internes du logiciel ou de l’application, par l’intermédiaire du code source,
principale base de travail du testeur.

Pour réaliser un test en « boîte blanche », ce dernier doit donc avoir des compétences de
programmation, afin de comprendre le code qu’il étudie. Il doit également avoir une vue
globale du fonctionnement de l’application, des éléments qui la composent, et naturellement
de son code source. Contrairement aux tests en « boîte noire », le testeur ici a un profil
développeur, et non pas utilisateur.

En effectuant un test en « boîte blanche », on voit en effet quelle ligne de code est appelée
pour chaque fonctionnalité. Cela permet de tester le flux de données ainsi que la gestion des
exceptions et des erreurs. On s’intéresse également à la dépendance des ressources, ainsi qu’à
la logique interne et justesse du code. C’est pourquoi ces tests sont surtout utiles pendant le
développement d’une application, même s’ils peuvent être effectués durant de nombreuses
phases de la vie d’un projet. La méthode en « boîte blanche » peut être appliquée pour les tests
unitaires (majoritairement), les tests d’intégration et les tests système.

La méthode en « boîte blanche » utilise des scénarios de test, créés par le testeur selon ce qu’il
a appris du code source de l’environnement. L’objectif est qu’en testant l’ensemble de ces
scénarios, toutes les lignes de code soient vérifiées. Ce qui est regardé, c’est le processus
effectué par l’application après une entrée (input) pour obtenir un résultat. On ne fait que
vérifier si le code produit les résultats espérés.

Cette méthode a plusieurs avantages :

• Anticipation : effectuer ces tests au cours du développement d’un programme permet

de repérer des points bloquants qui pourraient se transformer en erreurs ou problèmes
dans le futur (par exemple lors d’une montée en version, ou même lors de l’intégration
du composant testé dans le système principal).
 Support de cours de Génie Logiciel GL2

• Optimisation : étant donné qu’il travaille sur le code, le testeur peut également profiter
de son accès pour optimiser le code, pour apporter de meilleures performances au
système étudié (sans parler de sécurité…).
• Exhaustivité : étant donné que le testeur travaille sur le code, il est possible de vérifier
intégralement ce dernier. C’est le type de test qui permet, s’il est bien fait, de tester
l’ensemble du système, sans rien laisser passer. Il permet de repérer des bugs et
vulnérabilités cachées intentionnellement (comme par exemple des portes dérobées).

Mais on ne peut pas tout avoir… C’est pourquoi ces tests ont également des
inconvénients.

• Complexité : ces tests nécessitent des compétences en programmation, et une

connaissance accrue du système étudié.
• Durée : de par la longueur du code source étudié, ces tests peuvent être très longs.
• Industrialisation : pour réaliser des tests en « boîte blanche », il est nécessaire de se
munir d’outils tels que des analyseurs de code, des débogueurs… Cela peut avoir un
impact négatif sur les performances du système, voire même impacter les résultats.
• Cadrage : il peut être très compliqué de cadrer le projet. Le code source d’un
programme est souvent très long, il peut donc être difficile de déterminer ce qui est
testé, ce qui peut être mis de côté… En effet, il n’est pas toujours réaliste de tout tester,
ce qui prendrait trop de temps. Il est également possible que le testeur ne se rende pas
compte qu’une fonctionnalité prévue dans le programme n’y a pas été intégrée. Il n’est
donc pas dans le scope du testeur de vérifier si tout est là : il ne fait que tester ce qui est
effectivement présent dans le code.
• Intrusion : il peut en effet être risqué de laisser son code à la vue d’une personne
externe à son entreprise : il y a des risques de casse, de vol, voire même d’intégration
de portes dérobées… Choisissez donc toujours des testeurs professionnels !

III.5. Test en « Boîte grise »

Les tests en « boîte grise » compilent ces deux précédentes approches (tests en « boîte noire
» et tests en « boîte blanche ») : ils vérifient à la fois les fonctionnalités et le fonctionnement
d’un système. C’est-à-dire qu’un testeur va par exemple donner une entrée (input) à un système,
vérifier que la sortie obtenue est celle attendue, et vérifier par quel processus ce résultat a été
obtenu.
 Support de cours de Génie Logiciel GL2

Dans ce type de tests, le testeur connaît le rôle du système et de ses fonctionnalités, et a

également une connaissance, bien que relativement limitée, de ses mécanismes internes (en
particulier la structure des données internes et les algorithmes utilisés). Attention cependant, il
n’a pas accès au code source !

Ces tests peuvent difficilement être effectués pendant la phase de développement du projet, car
elle implique des tests sur les fonctionnalités du programme : celui-ci doit déjà être dans un
état proche de final pour que ces tests puissent être pertinents. En effet, pendant les tests en «
boîte grise », ce sont surtout des techniques de « boîte noire » qui sont utilisées, puisque le code
n’est pas accessible. Cependant, les scénarios sont orientés pour jouer sur les processus sous-
jacents, et ainsi les tester également.

Bien entendu, la méthode « boîte grise » combine surtout les avantages des méthodes
« boîte blanche » et « boîte noire ». On peut cependant noter deux gros bénéfices de
cette technique :

• Impartialité : les tests en « boîte grise » gardent une démarcation entre les
développeurs et le testeur, puisque ce dernier n’étudie par le code source et peut
s’appuyer sur les résultats obtenus en testant l’interface utilisateur.
• Intelligence : en connaissant la structure interne du programme, un testeur peut créer
des scénarios plus variés et intelligents, afin d’être certain de tester toutes les
fonctionnalités mais également tous les processus correspondants du programme.

En parallèle, l’un des inconvénients les plus importants de ces tests est le suivant :

• Non exhaustivité : étant donné que le code source n’est pas accessible, il est impossible
avec des tests en « boîte grise » d’espérer avoir une couverture complète du programme.
 Support de cours de Génie Logiciel GL2

Chapitre 4 TEST D’UN LOGICIEL

I. Fondement du test (pourquoi réaliser un test ?)

Le test est une recherche d'anomalie dans le comportement du logiciel. C’est une activité
paradoxale : il vaut mieux que ce ne soit pas la même personne qui développe et qui teste
le logiciel. D’où le fait qu’un bon test est celui qui met à jour une erreur (non encore
rencontrée).

II. Cycle de développement du test

 Support de cours de Génie Logiciel GL2

II.1. Mise au point inductive

On met une hypothèse sur l’ensemble.

 Support de cours de Génie Logiciel GL2

II.2. Mise au point déductive

On traite chaque cause séparément.

III. Les différentes techniques de test

Plusieurs techniques dépendent de l’objectif du test. Mais aucune technique ne sera jamais
complète. Le problème est de savoir quelle technique nous assure la complétude, car en
fait, aucune ne peut le garantir.
 Support de cours de Génie Logiciel GL2

Vocabulaire :

• Espace générateur : Il s’agit de l’ensemble des tests générés pour assurer la

complétude du logiciel
• Espace de cas possibles : Il s’agit de l’ensemble des erreurs possibles pouvant être
rencontrées sur le logiciel

Propriétés recherchées :

Si l’espace générateur est couvert alors la probabilité d'une défaillance dans l'espace de cas
possibles est très faible (inférieure à une limite fixée à l'avance). La difficulté est de faire que
l'espace générateur soit consistant et complet.

III.1. Test statique

Test réalisé par l’humain par revue ou relecture du code.

III.2. Test dynamique

Ici on exécute chaque module ou composante du logiciel avec des valeurs en entrée et on
observe le comportement.
 Support de cours de Génie Logiciel GL2

Eléments d’entrés

III.3. Test en « Boîte noire »

Les tests en « boîte noire » consistent à examiner uniquement les fonctionnalités d’une
application, c’est-à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait.
Sa structure et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel
est le rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un
profil uniquement « utilisateur ».

Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une
application fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs sont à
la recherche de fonctions incorrectes ou manquantes, d’erreurs d’interface, de performance,
d’initialisation et de fin de programme, ou bien encore d’erreurs dans les structures de données
ou d’accès aux bases de données externes.

Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur possibles sur
le système testé. Toutes les fonctionnalités doivent être prises en compte, pour qu’une fois tous
les tests effectués, elles aient toutes été éprouvées (appréciées). Les tests consistent à suivre un
scenario, et à vérifier pour chaque fonctionnalité que les entrées (inputs) valides sont acceptées,
que celles non valides sont refusées, et bien entendu, qu’à chaque fois, le résultat (sortie ou
output) attendu est bien obtenu. C’est ce que l’on appelle la méthode « trial and error » (essais
et erreurs).

Les avantages de cette méthode sont les suivants :

 Support de cours de Génie Logiciel GL2

• Simplicité : ces tests sont simples à réaliser, car on se concentre sur les entrées et les
résultats. Le testeur n’a pas besoin d’apprendre à connaître le fonctionnement interne
du système ou son code source, qui n’est pas accessible. Cette méthode est donc
également non intrusive.
• Rapidité : en raison du peu de connaissances nécessaires sur le système, le temps de
préparation des tests est très court. Les scénarios sont relativement rapides à créer et à
tester, puisqu’ils suivent les chemins utilisateurs, qui sont relativement peu nombreux
selon la taille du système.
• Impartialité : on est ici dans une optique « utilisateur » et non « développeur ». Les
résultats du test sont impartiaux : le système marche, ou il ne marche pas. Il n’y a pas
de contestation possible, comme par exemple sur l’utilisation de tel processus plutôt
qu’un autre selon l’opinion du développeur.
Mais les tests en « boîte noire » ont également des inconvénients :
• Superficialité : étant donné que le code n’est pas étudié, ces tests ne permettent pas de
voir, en cas de problème, quelles parties précises du code sont en cause. De plus, les
testeurs peuvent passer à côté de problèmes ou vulnérabilités sous-jacentes. Certains
problèmes sont également difficilement repérables avec cette méthode, comme par
exemple ceux liés à la cryptographie, ou à des aléas (évènements imprévisibles) de
mauvaise qualité. C’est donc l’un des tests les moins exhaustifs.
• Redondance : si d’autres tests sont effectués, il est possible que celui-ci perde
grandement de son intérêt, puisque son champ d’action a tendance à être inclus dans
celui d’autres tests.

III.4. Test en « Boîte blanche »

Les tests en « boîte blanche » consistent à examiner le fonctionnement d’une application et sa
structure interne, ses processus, plutôt que ses fonctionnalités. Sont ici testés l’ensemble des
composants internes du logiciel ou de l’application, par l’intermédiaire du code source,
principale base de travail du testeur.

Pour réaliser un test en « boîte blanche », ce dernier doit donc avoir des compétences de
programmation, afin de comprendre le code qu’il étudie. Il doit également avoir une vue
globale du fonctionnement de l’application, des éléments qui la composent, et naturellement
de son code source. Contrairement aux tests en « boîte noire », le testeur ici a un profil
développeur, et non pas utilisateur.

En effectuant un test en « boîte blanche », on voit en effet quelle ligne de code est appelée
pour chaque fonctionnalité. Cela permet de tester le flux de données ainsi que la gestion des
exceptions et des erreurs. On s’intéresse également à la dépendance des ressources, ainsi qu’à
 Support de cours de Génie Logiciel GL2

la logique interne et justesse du code. C’est pourquoi ces tests sont surtout utiles pendant le
développement d’une application, même s’ils peuvent être effectués durant de nombreuses
phases de la vie d’un projet. La méthode en « boîte blanche » peut être appliquée pour les tests
unitaires (majoritairement), les tests d’intégration et les tests système.

La méthode en « boîte blanche » utilise des scénarios de test, créés par le testeur selon ce qu’il
a appris du code source de l’environnement. L’objectif est qu’en testant l’ensemble de ces
scénarios, toutes les lignes de code soient vérifiées. Ce qui est regardé, c’est le processus
effectué par l’application après une entrée (input) pour obtenir un résultat. On ne fait que
vérifier si le code produit les résultats espérés.

Cette méthode a plusieurs avantages :

• Anticipation : effectuer ces tests au cours du développement d’un programme permet

de repérer des points bloquants qui pourraient se transformer en erreurs ou problèmes
dans le futur (par exemple lors d’une montée en version, ou même lors de l’intégration
du composant testé dans le système principal).
• Optimisation : étant donné qu’il travaille sur le code, le testeur peut également profiter
de son accès pour optimiser le code, pour apporter de meilleures performances au
système étudié (sans parler de sécurité…).
• Exhaustivité : étant donné que le testeur travaille sur le code, il est possible de vérifier
intégralement ce dernier. C’est le type de test qui permet, s’il est bien fait, de tester
l’ensemble du système, sans rien laisser passer. Il permet de repérer des bugs et
vulnérabilités cachées intentionnellement (comme par exemple des portes dérobées).

Mais on ne peut pas tout avoir… C’est pourquoi ces tests ont également des
inconvénients.

• Complexité : ces tests nécessitent des compétences en programmation, et une

connaissance accrue du système étudié.
• Durée : de par la longueur du code source étudié, ces tests peuvent être très longs.
• Industrialisation : pour réaliser des tests en « boîte blanche », il est nécessaire de se
munir d’outils tels que des analyseurs de code, des débogueurs… Cela peut avoir un
impact négatif sur les performances du système, voire même impacter les résultats.
• Cadrage : il peut être très compliqué de cadrer le projet. Le code source d’un
programme est souvent très long, il peut donc être difficile de déterminer ce qui est
testé, ce qui peut être mis de côté… En effet, il n’est pas toujours réaliste de tout tester,
ce qui prendrait trop de temps. Il est également possible que le testeur ne se rende pas
 Support de cours de Génie Logiciel GL2

compte qu’une fonctionnalité prévue dans le programme n’y a pas été intégrée. Il n’est
donc pas dans le scope du testeur de vérifier si tout est là : il ne fait que tester ce qui est
effectivement présent dans le code.
• Intrusion : il peut en effet être risqué de laisser son code à la vue d’une personne
externe à son entreprise : il y a des risques de casse, de vol, voire même d’intégration
de portes dérobées… Choisissez donc toujours des testeurs professionnels !

III.5. Test en « Boîte grise »

Les tests en « boîte grise » compilent ces deux précédentes approches (tests en « boîte noire
» et tests en « boîte blanche ») : ils vérifient à la fois les fonctionnalités et le fonctionnement
d’un système. C’est-à-dire qu’un testeur va par exemple donner une entrée (input) à un système,
vérifier que la sortie obtenue est celle attendue, et vérifier par quel processus ce résultat a été
obtenu.

Dans ce type de tests, le testeur connaît le rôle du système et de ses fonctionnalités, et a

également une connaissance, bien que relativement limitée, de ses mécanismes internes (en
particulier la structure des données internes et les algorithmes utilisés). Attention cependant, il
n’a pas accès au code source !

Ces tests peuvent difficilement être effectués pendant la phase de développement du projet, car
elle implique des tests sur les fonctionnalités du programme : celui-ci doit déjà être dans un
état proche de final pour que ces tests puissent être pertinents. En effet, pendant les tests en «
boîte grise », ce sont surtout des techniques de « boîte noire » qui sont utilisées, puisque le code
n’est pas accessible. Cependant, les scénarios sont orientés pour jouer sur les processus sous-
jacents, et ainsi les tester également.

Bien entendu, la méthode « boîte grise » combine surtout les avantages des méthodes
« boîte blanche » et « boîte noire ». On peut cependant noter deux gros bénéfices de
cette technique :

• Impartialité : les tests en « boîte grise » gardent une démarcation entre les
développeurs et le testeur, puisque ce dernier n’étudie par le code source et peut
s’appuyer sur les résultats obtenus en testant l’interface utilisateur.
 Support de cours de Génie Logiciel GL2

• Intelligence : en connaissant la structure interne du programme, un testeur peut créer

des scénarios plus variés et intelligents, afin d’être certain de tester toutes les
fonctionnalités mais également tous les processus correspondants du programme.

En parallèle, l’un des inconvénients les plus importants de ces tests est le suivant :

• Non exhaustivité : étant donné que le code source n’est pas accessible, il est impossible
avec des tests en « boîte grise » d’espérer avoir une couverture complète du programme.