Dossier Projet - caron.nicolas.free.frcaron.nicolas.free.fr/cnam/Projet Methodologie/Methodes de...

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

CENTRE REGIONAL ASSOCIE DE LILLE

DOSSIER PROJET

TP METHODOLOGIE 2003 - 2004

« LES METHODES DE TEST »

DATE REDACTEURS Validation N° AUDITEUR 08/12/03 CRISAN Cornel 19 878 08/12/03 FIRMIN Philippe 12 889 08/12/03 KAOUANE Kamel 17 819 08/12/03 VEREMME Olivier 18 801

DESTINATAIRES

NOMS ACTIONS DATE C.CRISAN Rédaction 09/02/2004 P.FIRMIN Rédaction 09/02/2004

K.KAOUANE Rédaction 09/02/2004 O.VEREMME Rédaction 09/02/2004

C.RAYNAL Lire et Apprécier ASAP G.MOREL Lire et Apprécier ASAP

CNAM 2003 – 2004 TP Méthodes de test

Référence Document : Dossier_Projet.doc Version : 2.2

Dossier Projet. (Document principal) Page : 2 / 118

HISTORIQUE DES MODIFICATIONS

Version Date Description Rédacteur

DRAFT Le 01/11/03 Version draft Olivier VEREMME ;

Kamel KAOUANE

1 Le 23/12/03 Version initiale

Kamel KAOUANE ; Cornel CRISAN ;

Philippe FIRMIN ; Olivier VEREMME

2 Le 31/12/03 Révision de la mise en forme Olivier VEREMME

2.1 Le 07/01/04 Correction grammaticale Olivier VEREMME

2.2 Le 12/01/04 Correction grammaticale Olivier VEREMME




TABLE DES MATIERES I INTRODUCTION.......................................................................................................................................7 II Méthodes de développement .......................................................................................................................9

1 L’approche objet ....................................................................................................................................10 1.1 La portée de l’approche objet ........................................................................................................12 1.2 Le cycle de vie itératif ...................................................................................................................12

2 L’approche structurée ............................................................................................................................16 2.1 Le cycle de vie en cascade .............................................................................................................17

3 Conclusion .............................................................................................................................................20 III Quelle est la typologie des tests ? ..........................................................................................................21

1 Introduction à la notion de test ..............................................................................................................21 2 Les tests unitaires...................................................................................................................................24

2.1 Notion des Tests Unitaires .............................................................................................................24 2.2 Formalisme des tests unitaires : Fiche des tests unitaires..............................................................25

2.2.1 Mais à quoi sert cette fiche ? .................................................................................................25 2.2.2 Formalisme ............................................................................................................................26

3 Les tests d’intégration ............................................................................................................................30 3.1 Définition des tests d’intégration...................................................................................................30 3.2 Intégration globale versus intégration incrémentale ......................................................................31 3.3 Intégration ascendante versus intégration descendante .................................................................31 3.4 Outils de tests d'intégration ............................................................................................................32

4 Les tests de recette .................................................................................................................................33 4.1 Organisation de la recette ..............................................................................................................35

4.1.1 Description du périmètre:......................................................................................................37 4.1.2 Inventaire des fonctionnalités à recetter : ..............................................................................37 4.1.3 Plate forme de recette : ..........................................................................................................38 4.1.4 Jeux d’essais : ........................................................................................................................38 4.1.5 Identification des thèmes .......................................................................................................39 4.1.6 Cartographie ..........................................................................................................................40 4.1.7 Description des tests ..............................................................................................................41 4.1.8 Synthèse de déroulement (Fiche de recette) ..........................................................................43

IV Le plan et les scénarios de tests .............................................................................................................44 1 Le plan de tests : ....................................................................................................................................44

1.1 Rôle :..............................................................................................................................................44 1.2 Objectif : ........................................................................................................................................44 1.3 Contenu d’un plan de test : ............................................................................................................45

2 Les scénarios de tests :...........................................................................................................................50 2.1 Rôle :..............................................................................................................................................50

2.1.1 Cas de la preuve .....................................................................................................................53 2.1.2 Les tests unitaires...................................................................................................................53

2.2 Aspect outils de tests : ...................................................................................................................54 2.2.1 Les tests fonctionnels .............................................................................................................55 2.2.2 Les tests d’interface ...............................................................................................................56




2.3 Aspect plates-formes : ...................................................................................................................57 2.4 Suivi des anomalies : .....................................................................................................................58 2.5 Aspect ressources humaines : ........................................................................................................59 2.6 Conclusion : ...................................................................................................................................63

V Les outils de test ........................................................................................................................................64 1 Modes de fonctionnement ......................................................................................................................66 2 Les outils statiques.................................................................................................................................67

2.1 Les correcteurs intelligents de programmes ..................................................................................68 2.2 Les analyseurs de complexité ........................................................................................................68 2.3 Les analyseurs de graphes de contrôle ...........................................................................................70 2.4 Les analyseurs du flux des données...............................................................................................70 2.5 Outils de gestion et de documentation...........................................................................................71 2.6 Outils d’exécution symbolique ......................................................................................................71 2.7 Démonstrateurs d’exactitude .........................................................................................................72

3 Les outils dynamiques ...........................................................................................................................73 3.1 Les évaluateurs de couverture .......................................................................................................73 3.2 Les évaluateurs d’assertions locales ..............................................................................................74 3.3 Les simulateurs d’environnement ..................................................................................................75 3.4 Les analyseurs dynamiques du flux des données ..........................................................................75 3.5 Générateurs automatiques de Données de Test structurel .............................................................76 3.6 Les débuggueurs ............................................................................................................................76

4 Conclusion .............................................................................................................................................77 VI Comment se conduit un test ? ................................................................................................................78

1 La constitution d’un jeu d'essai fonctionnel ..........................................................................................78 2 Exécution des tests.................................................................................................................................79

2.1 Qui réalise les tests : ......................................................................................................................80 2.2 L’ordonnancement des tests : ........................................................................................................81 2.3 Suivi de l’exécution des tests :.......................................................................................................82

3 L’analyse des tests .................................................................................................................................84 3.1 Les cycles de test : .........................................................................................................................84 3.2 La journalisation des tests :............................................................................................................85 3.3 Le rapport de test ...........................................................................................................................86

VII Le PAQ, les coûts et la législation. ........................................................................................................87 1 le Plan d’Assurance Qualité...................................................................................................................87 2 Les Coûts : .............................................................................................................................................93 3 La Législation : ......................................................................................................................................95

3.1 Les éditeurs :..................................................................................................................................95 3.2 Les sociétés de service :.................................................................................................................96 3.3 La norme ISO 9000 : .....................................................................................................................98

VIII CONCLUSION....................................................................................................................................105




TABLE DES SCHEMAS Schema 2.1 : Le modèle en spirale de Boehm...................................................................................................15 Schéma 2.2 : Le cycle de vie en cascade ...........................................................................................................17 Schéma 2.3 : Le cycle de vie en cascade – feed-back.......................................................................................18 Schéma 3.1 : Intervention des tests unitaires dans le modèle en V de Golberg................................................24 Schéma 3.2 : Ancienne Ecran saisie des commandes clients ............................................................................27 Schéma 3.3 : Nouvel écran saisie des commandes client..................................................................................28 Schéma 3.4 Recette............................................................................................................................................34 Schéma 4.1 : Découpage de la structure d’un logiciel en unité élémentaire : ...................................................45 Schéma 4.2 : Assemblage d’unité élémentaire déjà testée ................................................................................46 Schéma 4.3 : L’insertion de l’élaboration du scénario dans le cycle en V........................................................52 Schéma 4.4 : Présentation schématique d’un outil de test .................................................................................56 Schéma 4.3 Schéma de l’utilisation d’un outil de test.......................................................................................57 Schéma 4.5 Conclusion scenario de test ............................................................................................................63 Schéma 5.1 : Le diagramme de Kiviat...............................................................................................................69 Schéma 5.2 : Instrumentation code source ........................................................................................................74 Schéma 7.2 : Schéma récapitulatif de la mise en œuvre d’une norme ISO.....................................................101




TABLE DES TABLEAUX Tableau 2.1 : Légende Schéma 1.1....................................................................................................................15 Tableau 2.2 : Comparaison Méthodes classiques – Méthodes objet .................................................................20 Tableau 5.1 : Les outils de test et leurs champs d’application. .........................................................................77




I INTRODUCTION

Le développement des logiciels occupe une place croissante dans les dépenses informatiques,

dépassant souvent largement celui du matériel. L'augmentation de la part des dépenses logicielles est bien sûr

liée à l'amélioration des performances des ordinateurs utilisés, mais également à la complexité croissante des

problèmes considérés et aux variations des demandes des utilisateurs nécessitant des ajustements permanents.

L’essor de l’informatique dans le monde, fait qu’aujourd’hui elle s’est intégrée dans notre vie de tous les

jours à tel point qu’elle a bouleversé le fonctionnement de notre société. En relation avec cet essor, le bug

informatique est lui aussi devenu de plus en plus présent.

La qualité du logiciel est une exigence constante. Une des questions les plus préoccupante dans un projet de

développement est :

Comment limiter le nombre d’erreur ainsi que leur coût. ?

La solution qui se présente tout de suite à l’esprit est : TESTER.

La détection d’erreur logicielle est aujourd’hui considérée comme un marché. Ce marché a été évalué à 180

millions de dollars en 1999 par IDC1 , et il devrait atteindre 412 millions en 2004.

La détection d’erreur s’étend sur l’ensemble du cycle de vie, lors de l'approbation des documents

intermédiaires et pendant des phases réservées: tests unitaires, intégration, qualification... Le coût de

correction d’une erreur croit exponentiellement avec le temps. Plus tôt une erreur est détectée et corrigée,

plus faible est sont coût. En passant ainsi d'une démarche corrective à une démarche préventive, voire

prédictive, les développeurs comptent gagner à la fois en temps et en qualité.

1 : I D C




Ainsi, le test unitaire peut déceler les erreurs dans les premières phases du développement, lorsqu'elles sont

faciles à localiser et moins coûteuses à corriger. Mais il nécessite beaucoup de temps et il est souvent bâclé

afin de respecter les dates de remise du logiciel. Malgré cela il est impossible d’éliminer l’intégralité des

anomalies d’une application.

Un taux d’anomalies de l’ordre de 1% à 5% est acceptable pour une application « classique », mais ce taux

peut être descendu à 0,1% pour des applications concernant des domaines très sensibles comme l’armé ou la

recherche.

Il est donc nécessaire de trouver et de corriger ces anomalies avant la diffusion du produit fini. Ce qui

implique la mise en œuvre de tests, qui joue un rôle de vérification par rapport aux exigences fonctionnelles

et techniques, et devant suivre une démarche bien organisée. Il existe pour cela des outils de test, des

logiciels simulants des utilisateurs, qui facilitent la reproduction des conditions de test et accélèrent le

processus, car ils sont exécutés plus souvent et plus complètement.

Dans ce dossier, il sera présenté deux méthodes de développement de logiciel informatique. La méthode

classique (ou structurée) et la méthode objet.

Et, afin de mieux comprendre ce que sont les tests et où ils interviennent, nous détaillerons une typologie des

tests, les scénarios et les plans de test.

Par la suite, nous présenterons le déroulement des tests. Et pour terminer, il sera rappelé les aspects qualité,

avec un plan d’assurance qualité pour la conduite des tests, ainsi que les aspects juridiques et économiques.




II METHODES DE DEVELOPPEMENT

Nombreuses études tendent à prouver que plus de la moitié des erreurs observées pendant la phase de

réalisation d'un logiciel auraient pu être évitées par une meilleure analyse du problème. Il importe donc de

définir de façon précise la méthodologie de développement d'un système informatique et de disposer de

techniques permettant d'améliorer la productivité des équipes de développement.

Les méthodes de développement imposent une structure aux activités de développement de logiciels dans le

but de les rendre plus systématiques et plus fructueuses. Elles fournissent une syntaxe et un vocabulaire, des

procédures pour la réalisation de tâches précises et des directives pour la vérification du produit ainsi que du

processus associé.

Pour mieux maîtriser le processus développement on se réfère à des modèles de cycle de vie , permettant de

prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains.

La continuité du cycle de vie du logiciel implique qu'il faut respecter l'enchaînement des différentes phases.

Le processus de développement consiste à décomposer le problème en veillant à :

• A chaque niveau de décomposition, bien décrire le problème et sa décomposition en sous problèmes.

• Préciser le procédé de recomposition : l'assemblage des solutions des sous problèmes ne donne pas

automatiquement la solution du problème ;

• Concevoir des solutions réutilisables.

Plusieurs équipes ont tenté de formaliser d'une part les différentes étapes de développement d'un système

d'information et d'autre part les activités de modélisation associées. La plupart des approches consistent à

diviser le développement en phases ou étapes séparées par des points de contrôle. Une étape ne peut être

engagée que si l'étape précédente a été validée lors d'un point de contrôle. On parle ainsi de méthodes en

cascade. Les approches plus récentes, dites orientées objets, visent à obtenir rapidement un retour de la part

des utilisateurs finaux.




1 L’approche objet

Les avantages de l’objet sont la stabilité de la modélisation, par rapport aux entités du monde réel, la

construction itérative facilitée par le couplage faible entre composants et la possibilité de réutiliser des

éléments d’un développement à un autre.

Certains insistent également sur la simplicité du modèle qui fait appe l à seulement cinq concepts fondateurs :

• Les objets

• Les messages

• Les classes

• La généralisation

• Le polymorphisme

pour exprimer de manière uniforme l’analyse, la conception et la réalisation d’une application informatique.

D’une manière générale, toute méthode de construction de logiciels doit prendre en compte l’organisation, la

mise en relation et l’articulation de structures pour en faire émerger un comportement macroscopique

complexe : le système à réaliser.

L’approche objet repose à la fois sur le rationalisme d’une démarche cartésienne et sur une démarche

systémique qui considère un système comme une totalité organisée, dont les éléments solidaires ne peuvent

être définis que les uns par rapport aux autres. Elle propose une méthode de décomposition, non pas basée

sur ce que le système fait, mais plutôt sur l’intégration de ce que le système est fait.

Initialement basée sur l’utilisation d’objets en tant qu’abstractions du monde réel, l’approche objet a pour but

une modélisation des propriétés statiques et dynamiques de l’environnement dans lequel sont définis les

besoins, appelé le domaine du problème. Elle formalise notre perception du monde et des phénomènes qui

s’y déroulent, et met en correspondance l’espace du problème et l’espace de la solution, en préservant la

structure et le comportement du système analysé. Les fonctions se représentent alors par des formes de

collaboration entre les objets qui composent le système. Le couplage devient dynamique, et les évolutions

fonctionnelles ne remettent plus en cause la structure statique du logiciel.




La force de l’approche objet provient de sa double capacité à décomposer et à recomposer du fait de la

richesse de ses mécanismes d’intégration, qui concernent à la fois les aspects statiques et les aspects

dynamiques des logiciels. L’intégration apparaît comme la qualité fondamentale des objets. Elle assure la

cohérence entre les composants d’un système informatique au sein d’un modèle uniforme applicable à toutes

les phases du cycle de vie du logiciel. L’approche objet tire sa force de sa capacité à regrouper ce qui a été

séparé, à construire le complexe à partir de l’élémentaire, et surtout à intégrer statiquement et

dynamiquement les composants d’un système.

La communication entre informaticiens et non-informaticiens est meilleure dans la mesure ou le concept

d'objet est plus intuitif. D'autre part, les langages objets sont plus proches des schémas de représentation et

permettent de mettre facilement en oeuvre les concepts de l'analyse objet.

L'encapsulation permet de progresser dans la résolution de l'incompatibilité entre structuration des

traitements et structuration des données puisqu'un objet en constitue une synthèse. L'approche orientée objet

permet de substituer à la dualité données et procédures une structure unique. Toutefois, les schémas de

représentation de type donné et ceux de type traitements sont toujours utilisés dans les phases d'analyse et de

conception. Cependant, le premier souci de l'analyste n'est plus de trouver les fonctionnalités du système,

mais d'identifier les objets. Il faut ensuite attribuer les procédures à ceux-ci. Les priorités sont radicalement

différentes : On s'appuie sur la structure sous-jacente du domaine d'application plutôt que sur des besoins

fonctionnels liés à un seul problème.

Les phases d'études préliminaires sont raccourcies et la conception se fait par un cycle en spirale. En effet,

l'héritage permet de tester facilement un objet avant même de le définir complètement. Le temps global

consommé par les activités de développement n'est par contre pas plus court en objet : les gains se font par la

suite lors des phases de maintenance. D'ailleurs la réversibilité des choix est aisée par l'introduction de

nouveaux objets ou l'ajout d'attributs ou de services. Finalement la nature décentralisée de l'architecture objet

permet de répartir les décisions tout le long du cycle de développement. Il s'agit plus d'un travail par

raffinages successifs qu'un effort de conversion d'une représentation à une autre.




1.1 La portée de l’approche objet

Le développement d’une application peut être divisé en plusieurs grandes parties : elles s’enchaînent

de manière séquentielle au sein d’un cycle de vie en cascade ou elles se distribuent sur les différents

itérations d’un cycle de vie ascendant.

Les besoins sont d’abord par rapport aux différents types d’acteurs et décrits par des cas d’utilisation

exprimés dans le langage des acteurs. Le processus continue par une démarche d’analyse objet. Les objets

qui appartient fondamentalement au domaine de l’application sont identifiés, puis décrits de manière générale

par leurs classes. Le passage de l’analyse à la conception est marqué par l’introduction de considérations de

réalisation dans les modèles.

L’approche objet est bâtie autour de concepts comme l’encapsulation et la modularité qui encouragent un

style de programmation défensif.

1.2 Le cycle de vie itératif

Le cycle de vie itératif repose sur une idée simple : lorsqu’un système est trop complexe pour être

compris, conçu ou réalise du premier coup, il vaut mieux procéder en plusieurs fois par évolutions. Le cycle

de vie itératif est basé sur l’évolution de prototypes mesurables, et donc sur l’évolution d’éléments concrets.

Les livraisons forcent l’équipe à donner des résultats concrets régulièrement, ce qui permet d’éviter le

syndrome 90% finis encore 90% à faire. Le déroulement régulier des itérations facilite la prise en compte des

problèmes, les changements sont incorporés dans les itérations futures, plutôt que d’interrompre l’effort en

cours. Au cours du projet les prototypes sont montrés aux clients, cette démonstration présentent de

nombreux avantages :

• L’utilisateur est placé devant des situations d’utilisation concrètes qui lui permettent de

mieux structurer ses attentes et de les communiquer ;

• L’utilisateur prend sa part de responsabilité dans le nouveau système et l’accepte plus

facilement ;

• L’encadrement dispose d’éléments objectifs et peut évaluer les progrès et l’état

d’avancement avec plus de fiabilité.




En revanche, le cycle de vie itératif demande plus d’attention et d’implication de l’ensemble des acteurs du

projet. Il doit être présenté et compris par tous : les clients, les utilisateurs, l’encadrement, l’assurance qualité,

les développeurs, les testeurs.

Dans le cycle de vie itératif, chaque itération reproduit le cycle de vie en cascade, à une plus petite échelle.

Les objectifs d’une itération sont établis en fonction de l’évaluation des itérations précédentes. Les activités

s’enchaînent ensuite dans une mini-cascade dont la portée est limitée par les objectifs de l’itération. Les

phases traditionnelles sont couvertes graduellement, itération après itération. Chaque itération comprend les

activités suivantes :

• La planification de l’itération est élaborée en fonction des résultats de l’étude des risques.

• L’analyse étudie les cas d’utilisation et les scénarios à réaliser au cours de l’itération. Elle

met à jour le modèle d’analyse pour prendre en compte les nouvelles classes et associations

découvertes pendant l’analyse de l’itération.

• La conception se concentre sur les choix tactiques nécessaires pour réaliser les mécanismes

alloués à l’itération. Au besoin, des retouches sont apportées à l’architecture et le modèle de

conception est mis à jour. La définition des procédures de test et la conception des nouveaux

mécanismes sont réalisées parallèlement.

• Le codage et les tests définissent et valident le code. La charpente du code est générée

automatiquement depuis le modèle de conception. Le détail des opérations est ensuite réalisé

manuellement. L’intégration du nouveau code avec le code existent, issu des itérations

précédentes, est réalisée graduellement pendant la construction. Les procédures de test

unitaires et d’intégration sont appliquées au prototype.

• L’évaluation de la livraison repose sur l’examen des résultats des tests, évalués par rapport

aux critères définis avant de lancement de l’itération.

• Au cours de la préparation de la livraison, le prototype est gelé et l’ensemble des éléments

qui sont entrés dans son développement est placé dans des bibliothèques contrôles. Les

différents documents de description et d’installation du prototype sont mis au point.

Le cycle de vie itératif encourage la créativité en ménageant des espaces de liberté, sans règles trop strictes. Il

révèle précocement des problèmes qui auraient été détectés tardivement avec le cycle de vie en cascade.




Le cycle de vie itératif demande plus de planification et une attention soutenue. Il vient au secours des

utilisateurs en leur fournissant des prototypes à évaluer. Dès le début du développement, un cycle itératif

produit des prototypes qui peuvent être évalués objectivement : il met le logiciel en avant.

L’analyse des risques consiste à évaluer le projet, la technologie et les ressources, dans le but de déterminer

et de comprendre la nature et l’origine des risques. La réduction du risque global associé pilote les itérations

dans le cycle de vie itératif. Chaque itération, construite comme un petit projet, a pour objectif d’éliminer une

part du risque global associé au développement d’une application. L’approche itérative identifie et traite les

risques plus rapidement dans le cycle de vie, de sorte que le risque peut être réduit de manière significative

dès la phase d’élaboration. D’itération en itération, les prototypes valident les choix du projet de manière

concrète et mesurable, et le niveau de confiance dans l’application augmente. Chaque itération est basée sur

la construction d’un nombre réduit de scénarios qui s’attaquent d’abord aux risques les plus importants et

déterminent les classes et les sous -systèmes à construire. Les testeurs utilisent les mêmes schémas pour

construire le plan de test et les procédures de test de l’itération.

Le modèle en Spirale de Boehm, en 1988, découpe le processus de développement en quatre grandes phases.

Chacune d’elle s’inscrit dans un quadrant, comme nous le montre la figure 1.1.

Ces étapes se succèdent au fur et à mesure de la construction de la spirale. La première regroupe la

détermination des objectifs, des alternatives et des contraintes. La seconde permet l’évaluation des

alternatives, l’identification et la résolution des risques. La troisième, comprend le développement et la

vérification. Enfin, le quatrième et dernier point est dédié à la planification des phases suivantes. Ainsi au

dernier tour de la spirale le produit est totalement défini, les risques d’erreurs ont été considérablement

réduits et l’application est développée.




Schema 2.1 : Le modèle en spirale de Boehm

Numéro tâche Libellé

1, 6, 10, 14 Analyse des risques 2, 7, 11 Prototypes réalises à chaque cycle de la spirale

15 Prototype final opérationnel 3 Simulations, modélisations, benchmarks 4 Conception des opérations 5 Plan général de cycle de vie 8 Définition puis validation des besoins 9 Plan de développement 12 Conception, validation et vérification 13 Plan d’intégration et de test 16 Analyse détaillée 17 Codage 18 Tests unitaires 19 Tests d’intégration 20 Tests d’acceptation 21 Implémentation

Tableau 2.1 : Légende Schéma 1.1




2 L’approche structurée

L’approche structurée désigne une démarche de développement de logiciels, basée sur une succession

d’étape, depuis l’élaboration du cahier des charges jusqu’à la réalisation.

Le principe est très simple : chaque phase se termine à une date précise et se concrétise par la production de

certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes et activités,

ils sont soumis à une revue approfondie, on ne passe à la phase suivante que s'ils sont jugés satisfaisants.

Certaines phases portent le nom d'une activité ce qui signifie que l'activité est essentielle pour cette phase,

mais n'impose pas qu'elle n'ait lieu que dans cette étape. D'autres activités interviennent, par exemple le

contrôle technique et la gestion de la configuration sont présents tout au long du processus.

Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement

sur la base qu'une étape ne remet en cause que l'étape précédente, ce qui, dans la pratique, s'avère insuffisant.

Les développements récents de ce modèle font paraître de la validation-vérification à chaque étape :

• faisabilité et analyse des besoins : validation ;

• conception du produit et conception détaillée : vérification ;

• intégration : test d'intégration et test d'acceptation ;

• installation : test du système.




2.1 Le cycle de vie en cascade

Le cycle de vie en cascade, décrit par Royce dès 1970, a été largement employé depuis, pour la

description générale des activités liées au développement de logiciels.

Le cycle de vie en cascade présente le développement logiciel comme une suite de phases qui s’enchaînent

dans un déroulement linéaire, depuis l’analyse des besoins jusqu’à la livraison du produit au client.

Schéma 2.2 : Le cycle de vie en cascade

• L'analyse des besoins permet de définir les objectifs du système informatique et de préciser la demande

des utilisateurs.

• La phase de spécification permet de traduire la demande des utilisateurs en termes de fonctionnement,

vu de façon externe, du système informatique.

• La phase de conception permet d'obtenir un modèle précis du système et une description détaillée de sa

mise en œuvre.

• La phase de réalisation concerne l'écriture et la mise au point des programmes.

• La phase de validation concerne la mise en place du système en situation réelle d'utilisation.

• La maintenance concerne la mise à jour et les améliorations successives qui doivent être apportées au

système.




Chaque phase correspond à une activité. Le développement en cascade est rythmé par la génération des

divers livrables. Ceux-ci servent de support tangible lors des revues de validation et lors du passage d’une

phase à l’autre.

Toutefois, la preuve effective du bon fonctionnement du système est réalisée tardivement dans le cycle,

précisément pendant la phase d’intégration. En fait, la démarche en cascade donne des résultats satisfaisants

lorsqu’il est effectivement possible d’enchaîner les phases sans trop de problèmes.

Il faut que l’ensemble des besoins soit parfaitement connu et le problème complètement compris par les

analystes. Il faut aussi que la solution soit facile à déterminer par les concepteurs et le codage réduit

idéalement à la génération automatique de code, à partir des documents de conception.

Hélas, les projets ne présentent pas tous ces conditions idéales et il est nécessaire d’avoir des retours

d’information entre ses phases pour incorporer des corrections en amont, en fonction des découvertes

réalisées en aval. Les retours entre phases ne sont que le reflet de la réalité. Tant que ces retours restent

marginaux et concernent uniquement les phases adjacentes, le modèle en cascade conserve toute sa

pertinence. Dans le cas contraire, le modèle en cascade n’est plus vraiment adapté.

Schéma 2.3 : Le cycle de vie en cascade – feed-back

Le cycle en cascade correspond assez bien à la vision intuitive du développement d'un système informatique.

Il importe de spécifier un système de façon générale, puis de façon plus détaillée, avant d'entreprendre tout

développement.

Les points de contrôle effectués entre chaque étape permettent de valider le travail effectué. Finalement de

nombreux projets ont pu être menés à terme suivant cette approche.

Cependant plusieurs inconvénients ont rapidement été signalés. L'approche ne tient pas toujours compte des

ressources nécessaires ou des processus de vérification de la qualité des produits fournis à chaque étape.

L'approche s'adapte mal à des projets importants dans lesque ls les spécifications évoluent significativement.

ANALYSE

CONCEPTION

REALISATION

VALIDATION




Le cycle en cascade est souvent représenté sous la forme d’une lettre V. Ce symbole exprime le fait que le

développement des tests et le développement du logiciel sont effectués de manière synchrone. Cette approche

permet de vérifier la conformité à ce qui devrait être livré et non ce qui a été fait.

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




3 Conclusion

Cycle de vie et assurance qualité sont fortement liés, il faudra donc en permanence assurer :

§ la validation: sommes nous en train de faire le bon produit?

§ la vérification: est ce que nous faisons le produit correctement

En suivant l’approche en cascade, la réduction des risques est insignifiante jusqu’à ce que la phase

d’intégration commence. Les plus grands risques techniques sont liés à l’architecture : performances,

intégrité des interfaces du système, qualité du système. Ces éléments ne peuvent être évalués avant qu’une

quantité significative de code ait été développée et intégrée.

L’approche itérative identifie et traite les risques plus rapidement dans le cycle de vie, de sorte que le risque

peut être réduit de manière significative dès la phase d’élaboration. D’itération en itération, les prototypes

valident les choix du projet de manière concrète et mesurable, et le niveau de confiance dans l’application

augmente.

Ci-dessous un tableau de synthèse de la comparaison entre les deux méthodes de développement :

Méthodes classiques Méthodes objet

Approche globale Approche locale Cycle de conception en cascade séquentiel Cycle de conception en spirale itératif Problème décomposé en sous-problèmes Problème réparti entre un réseau objets Sous-programmes partageant des données Encapsulation, communication par messages Séparation des données et des traitements Pas de séparation Décisions importantes prises au début du

développement Décisions réparties au cours du cycle de

développement

Tableau 2.2 : Comparaison Méthodes classiques – Méthodes objet




III QUELLE EST LA TYPOLOGIE DES TESTS ?

1 Introduction à la notion de test

Qu’est ce qu’un test ? : définition du test.

Un test ou un essai est une activité consistant à évaluer un système ou un composant d’un système à

l’aide de moyens manuels ou automatisés pour :

• vérifier qu’il satisfait aux exigences spécifiées,

• ou identifier les différences entre les résultats attendus et ceux obtenus.

La validation de logiciel a pour but de répondre à la délicate question : a-t-on décrit le bon système, celui

répond à l’attente des utilisateurs ? Elle consiste essentiellement en des revues et inspections de

spécifications ou de manuels et du prototypage rapide.

La vérification de logiciel répond à la question : le développement est-il correct par rapport à la spécification

globale ? Ce qui consiste à s’assurer que les descriptions successives et, in fine, le logiciel lui-même satisfont

la spécification globale. Elle inclut des inspections de spécifications et de programmes ainsi que de la preuve

et du test.

On distingue les tests statistiques (examen ou analyse du texte) des tests dynamiques. Ceux derniers

consistent en l’exécution du logiciel sur un sous-ensemble des données permettant de vérifier :

• tous les chemins d’accès logiques ;

• la plage de validité des données et en particulier les « conditions limites » ;

• la conformité des résultats aux spécifications.




Par ailleurs, on distingue différents niveaux de test :

• les tests unitaires pour les composants isolés ;

• les tests d’intégrations pour un assemblage de composants

• les tests de recette ou validation

Ces différents niveaux de tests couvrent l’ensemble des tests à valider :

• Tests de non regression

- Pour détecter les erreurs liées à l’intégration d’un nouvel objet et s’assurer que l’application

tourne comme avant et donne les mêmes résultats.

Ce test se déroule en cinq étapes :

1- Préparation d’un ensemble des tests génériques du composant ;

2- Application de ces tests à la version existante du composant et stockage des résultats

obtenus dans un ou plusieurs fichiers ;

3- Modification du composant ou programme ;

4- Application des mêmes tests au composant modifié et stockage des résultats obtenus

dans un ou plusieurs fichiers différents de ceux utilisés à l’étape 2 ;

5- Comparaison des fichiers issus de l’étape 2 et ceux issus de l’étape 4.

• Tests des instructions

- Isoler l’objet ou programme afin de tester et valider les instructions.(tester les règles de

gestions – ceux sont des tests symboliques )

• Tests des conditions

- Vérifications de tous les cas possibles (y compris ceux qui ne sont pas utilisés -- ceux sont

des tests symboliques)

• Tests de revue de code

- Cela a pour objectif le respect de la sémantique du programme et le respect de la qualité

base sur le respect des normes et standards (cartouches, commentaires, optimisation…).




• Tests aux limites

- Ces tests ont pour objectif de détecter les anomalies du logiciel lors de l’utilisation de

valeurs aux extrêmes.

• Tests grandeur réelle

- Mise en charge du système, consiste à détecter les problèmes de fonctionnement du logiciel

dans son environnement d’exécution.

• Tests d’exploitation

- Mesure de la fiabilité du système sur une longue période

• Tests de performance

- Il s’agit notamment des problèmes liés aux performances (temps de réponses, débit, …)

• Tests de surcharge

- Dégradation des performances par la surcharge

• Tests négatifs

- Réaction du système face à des erreurs de manipulation

• Tests d’ergonomie

- Cohérence des Interfaces Homme Machine

• Tests de recette utilisateur

- Fait par l’utilisateur pour savoir si le système répond à ses besoins




2 Les tests unitaires

2.1 Notion des Tests Unitaires

Un test unitaire est un test conduit pour s’assurer qu’un composant du système répond bien à ses spécifications. Ce test a pour objectif de vérifier si chaque composant individuel ou programme fonctionne correctement, indépendamment des autres composants.

Les tests unitaires sont les premiers tests réalisés juste après l’écriture du code et ils permettent de détecter rapidement la découverte d’anomalie. Donc cela permet de résoudre rapidement les problèmes lors de la phase de réalisation.

Schéma 3.1 : Intervention des tests unitaires dans le modèle en V de Golberg

Ainsi lors de la phase des tests unitaires on va valider les règles de gestion qui vont être tester. Cela consiste

à indiquer que telle règle de gestion doit donner tel comportement applicatif et que telle donnée en entrée

donnera tel résultat. La différence obtenue entre les deux résultats constituant une anomalie.

Analyse fonctionnelle

Analyse détaillée

Développements Test unitaires

Recette interne

Recette externe A

C

B




2.2 Formalisme des tests unitaires : Fiche des tests unitaires

Les tests unitaires sont formalisés par une fiche que l’on appel la fiche de test unitaire

2.2.1 Mais à quoi sert cette fiche ?

Cette fiche est une liste (aide mémoire) qui doit permettre de rappeler les grandes actions d’une phase de test

mais également de préparer les tests en l’enrichissant lors de la réalisation des développements. Elle permet

de stipuler que tous les points à contrôler ont été testés (tels que les tests d’instructions, de conditions, tests

aux limites…).

Comment l’utiliser ? Dés le démarrage d’un développement ou affectation d’une nouvelle tâche, il faut initialiser une fiche et

compléter l’entête qui est la liaison entre l’entité à développer et la fiche. Au fur et à mesure des

développements celle-ci peut être enrichie par des descriptions de contrôles ou de tests spécifiques qui

peuvent paraître importants. Lors de la réalisation des tests unitaires, déroulez cette liste d'actions, réalisez les

actions et validez (OK ou non OK). Un "non OK" doit toujours être justifié. Il est possible, dans certains cas,

que des actions mentionnées dans la fiche ne s'appliquent pas tels que les tests de surcharge pour cause

d’environnement non adéquat... précisez le en remarque.

Quand l'utiliser ? ... à chaque développement, issu d'un cycle.

Quel est sont objectif ?

Elle est une aide dans les tests et elle assure un passage en recette dans le meilleur possible.




Qui en est responsable ?

Chaque personne affectée à une tâche de développement doit avoir initialisé la fiche de test associée. Elle

doit être complétée lors des tests. Chaque analyste ou chef de projet responsable d'une phase de recette peut

réclamer l'ensemble des fiches de tests d'un projet afin de cibler au mieux la phase de recette.

Cette fiche s'inscrit dans un objectif qualité. Elle doit être considérée comme un outil et non comme une contrainte.

2.2.2 Formalisme

En voici son formalisme :

Entête :

Nom de l’entité ou des entités : nom du programme à tester

Libellé : Résumé en une phrase ce que fait l’objet du programme(ex : édition des factures)

Nom ou code du projet : nom ou code du projet à laquelle le cycle est rattaché

Nom collaborateur : Nom de la personne qui test le programme

Date : date à la quelle ont eu lieu les tests

Corps de la fiche de test

Nom de l’objet Evenement Résultats attendus OK/NOK

AB123 Lancement batch Edition de facture OK

En bas de page :

Remarque :

…………………………………………………………………………………………………………………

…………………………………………………………………………………………………………………

…………………………………………………………………………………………………………………




2.3 Exemple :

Objectif du test ou de la règle de gestion à tester est de permettre la saisie du numéro de carte

bancaire lors de la passation de commande client si le choix de paiement est CB sinon ne pas permettre cette

saisie ( de même pour les autres modes de paiement)

Saisie des commandes Clients

N° Client : ………… Nom Client : ………………….. Prénom ………….

Rue : …….. N° :……. Adresse : ……………………… Ville : ……………. CP : ……

N° Commande : ….. Type de commande : … Libellé commande : ……………

Lignes commandes :

Code produit Quantité PU Remise Total

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

Total commande : ………..

Mode de paiement : .. CP :Chèque – VR : Virement Bancaire

N° RIB : code établissement : ….. code guichet : ….. n°compte : ……….. clé : ..

Schéma 3.2 : Ancienne Ecran saisie des commandes clients




Saisie des commandes Clients

N° Client : ………… Nom Client : ………………….. Prénom ………….

Rue : …….. N° :……. Adresse : ……………………… Ville : ……………. CP : ……

N° Commande : ….. Type de commande : … Libellé commande : ……………

Lignes commandes :

Code produit Quantité PU Remise Total

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

…………………………… ……… ……. …….. ……..

Total commande : ………..

Mode de paiement : .. CP :Chèque – VR : Virement Bancaire – CB : Carte Bancaire

N° RIB : code établissement : ….. code guichet : ….. n°compte : ……….. clé : ..

N°Carte Bancaire : …. ….. ….. …..

Schéma 3.3 : Nouvel écran saisie des commandes client

Ces champs sont saisissables selon le choix du mode de paiement. Par exemple si le mode de paiement est CB alors les champs constituant le N° RIB ne sont pas saisissables et les champs constituant le N° CB deviennent saisissables et obligatoires




Nom de l’entité ou des entités : Commande client

Libellé : Programme Transactionnel de la saisie des commandes clients

Nom ou code du projet : Cycle 1 : Adaptation du choix du paiement lors des commandes clients ;

Autoriser les paiements par carte bancaire

Nom collaborateur : Dupont Albert

Date : 23 Octobre 2003

Corps de la fiche de test

Nom de l’objet Evenement Résultats attendus OK/NOK

PCDECLI Appel de la fonction commandes

Affichage de l’écran de saisi des commandes OK

Renseigner tous les champs

sauf celui du mode paiement et ‘entrée’

Le curseur se positionne sur le champ mode de paiement et

affichage le message suivant : Ce champ est obligatoire

OK

Je renseigne le champ mode de paiement par XX

Le curseur se positionne sur le champ mode de paiement avec le message d’erreur Les valeurs

possibles sont CP, VR ou CB

OK

Choix du mode CP Les champs N°RIB et N°CB restent insaisissables. OK

Choix du mode CB Seules les champs du n° CB

deviennent saisissables et obligatoires

OK

En bas de page :

Remarque : Les tests effectués ont permit de mettre en évidence les contrôles du choix du mode de paiement

et la possibilité de choisir.

…………………………………………………………………………………………………………………

…………………………………………………………………………………………………………………

…………………………………………………………………




3 Les tests d’intégration

3.1 Définition des tests d’intégration

Cette étape doit permettre de vérifier le fonctionnement en réseau correct de l’ensemble des

applicatifs déployés sur le site client.

Cette étape comprend :

ð la mise en exploitation réelle des applicatifs

ð la recette définitive globale dans un environnement de production réelle

L’ensemble des dispositions concernant la période de validation de service régulier

Un système à objets est composé de plusieurs composantes qui se collaborent. Une composante demande des

services d’autres composantes. C’est cette collaboration que le test d’intégration (dans la phase de

développement) vérifie.

A cause de la forte collaboration entre les composantes dans un système à objets, la plupart des tests unitaires

sont les tests d’intégration. Le test de collaboration entre des composantes est donc le plus important pour un

système à objets.

Quand on teste une composante, on crée un environnement de test dans lequel les composants se collaborent.

La collaboration demande que les services requis d’une composante soient fournis quand on teste la

composante. Cette demande implique l’existence des composantes qui fournissent ces services.

Ainsi la phase d’intégration intervient après la vérification unitaire des modules. Le plan d’intégration est

rédigé pendant la phase de conception globale (cycle de vie en V). Il prévoit comment les modules, une fois

vérifiés, sont intégrés les uns aux autres. Il définit des tests d’intégration (tests de non-régression) que le

produit doit subir pour pouvoir être mis en exploitation. On utilise le graphe d’appel des modules pour

aborder l’intégration de deux façons : de manière incrémentale ou de manière globale.




3.2 Intégration globale versus intégration incrémentale

En intégration globale, tous les modules vérifiés sont intégrés en même temps. En mode incrémental,

chaque intégration partielle est le test d’un nouveau module avec d’autres déjà intégrés et testés.

Du point de vue de l’assurance qualité et du coût, l’intégration incrémentale est de loin supérieure à

l’intégration globale. En particulier le travail de développement est moindre, la détection des erreurs

d’interfaces est plus précoce, leur localisation est plus aisée ; les tests d’intégration sont menés de manière

plus approfondie.

On peut toutefois noter que sur le plan de l’organisation du travail l’intégration globale est supérieure à

l’intégration incrémentale puisqu’elle favorise la parallélisation des tests unitaires de modules. Rien

n’empêche toutefois la parallélisation des tests unitaires en mode d’intégration incrémentale.

3.3 Intégration ascendante versus intégration descendante

L'intégration incrémentale peut se faire selon deux stratégies: l'intégration ascendante ou l'intégration

descendante ; elles nécessitent toutes deux la construction d'outils de simulation: des muets (stubs) ou des

lanceurs de tests.(drivers )

Il est toutefois opportun de vérifier que cet outil lui-même est correct! contrairement à la même instruction en

C++ qui est une instruction de debug...

Validation- vérification

On se réfère au graphe d'appel des modules décrit dans le chapitre sur la conception. . La stratégie

d'intégration descendante prévoit d'intégrer le module racine en premier, un module est ensuite sélectionné

pour l'intégration si tous ses ancêtres ont déjà été intégrés.

A contrario, la stratégie d'intégration ascendante prévoit l' intégration des modules feuilles en premier; un

module est sélectionné pour l'intégration si ses descendants ont tous été testés. Il existe des stratégies mixtes

mélangeant les deux approches.




L'intégration ascendante présente l'avantage d'éviter la construction de muets ou stubs (simulateurs de

modules feuilles non encore intégrés). La répartition du travail est plus aisée, les erreurs dans les parties

critiques sont localisées plus tôt, le test de chemins particuliers est facilité. Toutefois on peut regretter que le

produit lui-même n'apparaisse que fort tard, en particulier les erreurs d'interface ne sont découvertes que très

tardivement.

Dans l'intégration descendante, le programme apparaît tôt et les erreurs d'interfaces sont découvertes de

manière plus précoce. Un des gros désavantages provient de la nécessité de

construire des stubs ce qui ralentit le processus et provoque une montée en charge lente. On éprouve de la

difficulté à tester des chemins particuliers et on regrette l'absence des modules d'entées/sorties. La

représentation des jeux de tests est plus facile une fois les entrées-sorties insérées.

L'approche mixte ou approche sandwich peut être une alternative tirant le meilleur parti des deux stratégies.

3.4 Outils de tests d'intégration

Le passage des tests fonctionnels peut s'avérer long et coûteux en particulier lorsque le produit

possède une interface nécessitant la présence d'un utilisateur pour tester l' ensemble des scénarios. Il existe

des outils d'aide au test fonctionnel qui permettent de capturer, contrôler et rejouer automatiquement les

interactions des utilisateurs permettant d'identifier les anomalies. On peut ainsi s'assurer que les processus

métier, qui font intervenir des applications et des bases de données multiples, fonctionnent parfaitement dès

la première fois et qu'ils demeurent fiables lors des passages de tests de non-régression en cas d 'évolution du

logiciel en phase de maintenance.




4 Les tests de recette

4.1 Introduction à la recette

La recette un métier ?

La recette s’effectue en maîtrise d’ouvrage et est un métier à part entière. Lorsque ce sont les utilisateurs qui

effectuent cette recette, c’est à dire ceux qui sont le plus à même, de part leur expertise métier, de valider

fonctionnellement une nouvelle application, il convient en premier de leur apprendre ce métier ou tout du

moins de contrôler leur production. La production des utilisateurs est tout document qui est en sortie du

processus de recette. En l’occurrence, il s’agit ici des dossiers de conception de scénarios de test, des jeux

d’essai de données.

Qu’est ce qu’une recette ?

La recette définit le métier. Une recette est une validation des aspects fonctionnels d’une application. Elle se

déroule du coté du client, effectuer une recette c’est se placer de ce coté de la relation entre le fournisseur de

la nouvelle application et celui qui va ensuite l’utiliser.

Deux recettes, il peut exister deux appellations de recette :

• Recette Interne

• Recette Externe

Selon l’organisation du projet, on parlera de recette interne si la recette est effectuée par la maîtrise d’œuvre

et de recette externe si la recette est effectuée par la maîtrise d’ouvrage. Ceci lorsque la maîtrise d’ouvrage

sous traite à la maîtrise d’œuvre la réalisation et s’établit alors une relation de client -fournisseur entre la

maîtrise d’œuvre et la maîtrise d’ouvrage.




Si la réalisation de la maîtrise d’œuvre se fait dans le service informatique interne à l’entreprise alors la

recette interne sera fait par la maîtrise d’ouvrage seule et la recette externe sera réalisée par l’utilisateur en

présence d’un informaticien de la maîtrise d’ouvrage.

L’organisation de la recette externe ou interne d’un projet démarre dès la phase de spécification (analyse) et

se déroule tout au long du process amont d’un projet.

Schéma 3.4 Recette

A – Lors de l’analyse fonctionnelle, les étapes à la réussite de la recette interne sont :

• Identification des règles métier

• Identifications des points de contrôle obligatoires

• Définition des thèmes de recette

• Définition des besoins (plate forme, fichiers…)

B- Lors de l’analyse détaillée, les étapes à la réussite de la recette interne sont :

• Identification des pré-requis

• Identification des actions de test par thèmes

• Description des jeux d’essai

• Identification des besoins en ressources (pour la phase)


Analyse détaillée

Développements

Test unitaires

Recette interne

Recette externe A

C

B

MOA

MOE

RECETTE




C – Lors des développements :

• Evolutions des actions de test

Ainsi toute entrée dans le processus de recette est un livrable, en tant que tel, il satisfait aux caractéristiques

de qualité que le client est en droit d’attendre.

Se placer de ce côté de la relation fournisseur client, c’est se placer du coté de celui qui reçoit des entrées, et

non celui qui doit adapter ce que l’on lui livre à son environnement.

Ainsi tout livrable est directement utilisable dans l’environnement client. Lors de la livraison dans

l’environnement, le fournisseur peut effectuer des tests permettant la signature du PV de recette technique.

Le PV de recette définitive étant signé à la fin de la recette, libérant généralement le fournisseur de ses

engagements de garantie, cette signature constitue également le début du processus de maintenance.

4.1 Organisation de la recette

Description :

S’il n’est pas toujours évident pour un responsable du SI de tester une application, il n’en demeure pas moins

que lorsque l’idée du test est acceptée, le projet n’en est pas réussi pour autant. Les tests doivent être menés

selon une démarche et être organisés. On parlera de campagne, de scénarios, de cas de test, ainsi que des tests

fonctionnels …




Problématique :

Les tests doivent être menés de manière organisée et être gérés en tant que projet à part entière. Dans une

application, il n’est pas possible de tout tester, des facteurs humains entrent en ligne de compte et dès lors ne

peuvent être pris en compte par l’infor matique, cependant il faut bien s’assurer que ce qu’on décide de tester

de répondre à une couverture soit fonctionnel soit technique d’une telle ampleur que les risques pris soient

minimes, par rapport au SI.

Méthodologie :

La méthodologie employée peut-être la suivante : il s’agit de tester le comportement d’un système applicatif

sous divers aspects définis dans un cahier des charges.

Un plan de test est élaboré pour déterminer ce que l’on va tester, il se décompose en un ou plusieurs

scénarios.

Un scénario est un document rédigé qui présente, par rapport à l’application, le test en lui-même avec la

cinématique des fonctions applicatives testées ainsi que le résultat attendu à l’issu du scénario.

Le jeu de données est alors défini en parallèle ave le scénario. L’exécution du scénario permettra de

déterminer le résultat obtenu. Ce résultat attendu est alors comparé au résultat attendu du scénario et inscrit

dans le document du scénario.

Une différence notée entre les deux résultats permet de déterminer une anomalie. Un ensemble de plan de

tests peut ensuite être joué dans une campagne de tests. Il est alors intéressant, notamment en recette

fonctionnelle d’exécuter des campagnes dites transversales, permettant de tester l’application d’un bout à

l’autre en enchaînant des éléments de vie de l’application (exemple : création, vie et suppression d’éléments

de l’application : compte bancaire, portefeuille boursier, police d’assurance…)




4.3 Cahier de recette La réalisation de la recette se formalise par l’élaboration de livrable c’est à dire la production

d’un cahier de recette et de la fiche PV de recette. (Voir le PAQ pour le PV).

Ce cahier de recette doit comprendre plusieurs points :

1. Description du périmètre

2. inventaire des fonctionnalités à recetter

3. plate forme de recette

4. jeux d’essais

5. identification des thèmes

6. cartographie

7. descriptions des tests

8. synthèse de déroulement

4.1.1 Description du périmètre:

La description du périmètre doit être conforme au projet à tester. Elle vise avant tout les limites

de la phase de recette : mettre en évidence ce que l’on va recetter pour valider le projet en précisant ce que

l’on ne va pas faire, parce qu’inutile ou également impossible (contrainte de plate forme).

Inventaire des fonctionnalités à recetter : Ce chapitre doit préciser les différentes fonctionnalités métier qui

feront l’objet d’une recette. Cette liste doit être exhaustive et venir compléter le périmètre ci avant.

4.1.2 Inventaire des fonctionnalités à recetter :

L’inventaire peut faire l’objet d’un classement par type de fonctionnalités : Les fonctions interactives :

Saisie des factures

Saisie des créances




Chaines :

Traitement quotidien des factures

Gestion des rejets

…

Etats :

Etats de situation mensuels…

4.1.3 Plate forme de recette :

Préciser la ou les configurations de recette nécessaires à la validation du projet et associés aux

contraintes de plates formes :

• Mise en configuration centrale

• Mise en configuration magasin

• Mise en configuration entrepôt

• Gestion des envois de fichier entre magasins, entre magasin et entrepôt…

• …

Préciser également les opérations physiques et/ou logicielles nécessaires pour obtenir une configuration

optimale et performante.

4.1.4 Jeux d’essais :

• Identification

Identifier l’environnement de recette et d’écrire l’ensemble des jeux d’essais nécessaires et suffisant à

la validation du projet.

Identifier les entités réutilisables ainsi que ceux devant être créées.




• Création de l’environnement

Ce chapitre doit permettre de créer un environnement optimal pour la phase de recette. Il est nécessaire

donc d’y décrire TOUTES les actions permettant la conception de l’environnement de recette cible :

• Copie de fichier

• Alimentation de fichiers (règles, outils)

• Création de nouveaux fichiers(règles outils)

• Paramétrage

• Bibliothèques en ligne

• …

4.1.5 Identification des thèmes

Identifier et préciser les thèmes majeurs de la phase de recette. Ces thèmes doivent permettre de tester

l’ensemble des entités impliquées dans le projet en déroulant les règles métier identifiées.

• Théme 1 : non-régression

Ce thème est obligatoire. Décrire l’ensemble des actions nécessaire aux tests de non-régression.

• Thème 2

Description du thème 2 (règles métier à recetter)

• Thème …

Description du thème 3 (règles métier à recetter)




4.1.6 Cartographie

Lister par type les entités concernées pa r le projet :

Entités Libellés des

Thèmes Actions

Programmes avec écrans

Nom 1

Nom 2

Nom 3

Programmes (simples)

Programmes d’édition

Fichiers

Remarque de codification :

Chaque action doit être identifiée précisément. La règle de codification est la suivante :

XNNN

X : Identification du thème d’appartenance (de A à Z)

NNN : n° de l’action. - Exemple : A003 = action de test n°3 du thème A.

4.1.7 Description des tests

Les actions correspondent aux différents cas de tests fonctionnels d’un thème donné. Certaines

actions (en début de thème) peuvent être des pré-requis. Dans ce cas l’action doit décrire les tâches

nécessaires à réaliser afin de dérouler ensuite correctement le thème. Cette description peut aussi faire l’objet

d’un chapitre de ce même document (jeux d’essai) et il suffira dans la description de l’action, d’y faire

référence.

THEME A : Libellé du thème A

Actions Identification jeux d’essai

Description du test Résultats attendus

Remarques / Points de contrôle particulier

1. Libellé action Description ou

identification des jeux d’essai

Décrire le test fonctionnel

Décrire les résultats attendus
























THEME B : Libellé du thème B

Actions Identification jeux d’essai Description du test Résultats attendus Remarques / Points de

contrôle particulier
























4.1.8 Synthèse de déroulement (Fiche de recette)

Nom du RECETTEUR :

Actions Résultats obtenus Date OK validation

Anomalies générées (PAI)

Remarques

La réalisation de test unitaire ne nécessite pas un grand nombre de ressources ou d’outils de test. Par contre,

les phases d’intégration et de validation requièrent un scénario et plan de test pour valoriser et réussir ces

phases.

IV LE PLAN ET LES SCENARIOS DE TESTS

1 Le plan de tests :

1.1 Rôle :

Le plan de test a pour rôle de lister les différents besoins nécessaires au bon déroulement des tests.

Il va permettre de définir un coût global, ainsi que le temps nécessaire, à la réalisation de ceux-ci.

Il va déterminer la méthode et les différents types de tests nécessaires aux contrôles du projet.

Il permettra également de définir, par rapport à la date de livraison du produit, un nombre de personnes

dédiées aux tests, ainsi que le temps imparti, par rapport à l’avancement générale du projet.

Il définira également l’attitude à adopter face aux différentes anomalies rencontrées, leurs intégrations dans

les scénarios de tests et la gestion des versions.

1.2 Objectif :

L’objectif du plan de test est de définir les éléments nécessaires au bon déroulement des tests.

Par exemple, de définir l’utilité et la nécessité d’utiliser les preuves de programme pour compléter des tests

structurels.

Il va définir la marche à suivre pour définir les différents scénarios de tests. Pour cela il va tenir compte de la

méthode de conception du logiciel. Dans le cas d’une programmation structurée, la méthode la plus

généralement appliquée sera la méthode descendante, alors que dans le cas d’une programmation objet, elle

sera bien souvent ascendante.

Il précise ce que sera le test, quelles fonctionnalités de l'application seront testées , en précisant leur ordre

ainsi que leur enchaînement. Le plan de test défini, qu’elles seront les règles de gestion, du dossier de

conception qui seront testées.




1.3 Contenu d’un plan de test :

Le plan de test va appliquer, à partir de la méthode choisie, descendante ou ascendante, des scénarios

de tests qui seront basés sur un découpage de l’application par entités de plus en plus petites, pour arriver aux

unités élémentaires. Les unités élémentaires sont des parties d’application qu’il n’est plus possible de réduire

sans perdre leur intégrité.

Cette décomposition pourra être testée de deux manières :

Soit en partant de la spécification globale pour descendre vers l’unité élémentaire, c’est le type d’approche de

test, dit en « V ». L’élaboration des tests se réalise à la descente et leurs déroulements à l’intégration, ou

graphiquement sur la branche ascendante du V.

Schéma 4.1 : Découpage de la structure d’un logiciel en unité élémentaire :

Soit, dans le cas d’une approche objet, par l’agrégation d’unités déjà testées, et dans ce cas, seul les unités

spécifiques de l’application font l’objet de scénarios spécifiques. Mais dans un tel schéma, des scénarios liés

à l’intégration, seront élaboré afin de tester l’assemblage de ses modules. Dans ce cas précis une des

difficultés est de différencier les tests unitaires des tests d’intégration.

Le risque de ne pas réaliser ce type de scénarios est une perte de fiabilité tant du point de vue de l’application

que de celui de la démarche qualité.

A

B C D

F E G H I




Exemple : Sur 100 unités testées à 0,99 l’assemblage ne donnera une fiabilité de 0,37.

Schéma 4.2 : Assemblage d’unité élémentaire déjà testée

Le schéma général d’un plan de tests doit être abordé dès la phase de spécifications fonctionnelles lors de la

rédaction du plan projet et du plan qualité.

Il doit préciser les points suivants:

• Définir les préconditions pour les tests.

• Définir les étapes de tests et critères de satisfaction associée.

• Chronologie et durée des étapes de tests.

• Pour chaque étape chronologie et moyens de mise en œuvre des différents jeux de tests.

• Modes d’intégration.

• Equipes concernées et responsabilités.

• Procédures de suivi pour l’évaluation du degré de réalisation des tests.

• Procédure de collecte de données statistiques.

• Actions à prendre en cas d’erreur.

• Procédures de mise au point.

• Tests de non régression.

• Procédure de report des corrections.

A

B C D

F E G H I




• Normes.

• Outils et méthodes recommandés.

• Temps de calcul et configuration matérielle.

• Bibliothèques de tests.

Les critères de satisfaction suivant doivent être défini :

• Epuisement des ressources.

• Aucune erreur révélée.

• Taux de couverture atteint.

• Durée.

• Nombre d’erreurs découvertes (avec catégories).

• Etude de courbe nombre d’erreurs en fonction de la durée.

Le plan de test devra également définir les métriques à utiliser afin de mesurer la qualité des tests et des

résultats obtenus. Il devra permettre, à l’aide de ses mesures, de définir la qualité finale du projet ; mais

également de mettre en évidence, les points à améliorer.

Les métriques servent :

• A quantifier l'architecture d'un système.

• A évaluer la productivité.

• A évaluer le temps de réalisation d'un projet.

• A évaluer la maintenabilité d'un système.

• A évaluer le coût d'un projet.

• A analyser les méthodologies.

Ces métriques définissent des paramètres qui sont regroupés en deux grandes catégories, les paramètres

internes et les paramètres externes.

Les paramètres internes sont des mesures faites en tout objectivité. (Par exemple, le nombre de lignes de

codes d'un objet).




Les paramètres externes, regroupent les données non quantifiables. (Par exemple la maintenabilité ou la

qualité).

Exemples de métriques :

• Nombre de méthodes par classes.

• Dépendances hiérarchiques.

• Degré de couplage entre les objets.

• Degré de cohésion des objets.

• Efficacité des librairies.

• Degré de réutilisabilité des méthodes.

• Complexité moyenne des méthodes.

• Profondeur de l'arbre d'héritage.

• Nombre de classes enfants.

• Niveau de cohésion dans les méthode s.

• ...

Cette notion est surtout utilisée lors de projets conséquents, afin d’éviter l’une des causes principales d’échec,

qui est un management inadapté. De plus une bonne appréciation des coûts est indispensable pour des projets

réunissant de nombreuses technologies différentes.

Ses métriques permettent de contrôler les modifications, les caractéristiques non fonctionnelles, tel que la

fiabilité, le rendement et la maintenabilité. Mais aucune méthode ne peut être efficace si les utilisateurs ne la

prennent pas en compte ou/et ne la mettent pas en œuvre.

Le plan de test va également mettre en œuvre une analyse des risques, afin de les prévenir voir de les éviter.

Le déroulement d’un plan de test, et c’est encore plus vrai sur au niveau global d’un projet, nécessite des

compétences managériales qui doivent faire partie de l’analyse de risque.




Quelques exemples de risques :

• Humains :

- Défaillance du personnel ; surestimation des compétences.

- Travailleur solitaire, héroïsme, manque de motivation.

• Processus

- Pas de gestion de projet.

- Calendrier et budget irréalistes.

- Calendrier abandonné sous la pression des clients.

- Composants externes manquants.

- Tâches externes défaillantes.

- Insuffisance de données.

- Validité des besoins.

- Développement de fonctions inappropriées.

- Développement d'interfaces utilisateurs inappropriées.

• Technologiques

- Produit miracle, "plaqué or".

- Changement de technologie en cours de route.

- Problèmes de performance.

- Exigences démesurées par rapport à la technologie.

- Incompréhension des fondements de la technologie.




2 Les scénarios de tests :

2.1 Rôle :

C'est le concept qui précise la fonction à tester, ce document est lié à un document de jeux de données

de test. La description y est précise et se réfère pour la recette fonctionnelle aux dossiers de conception. Un

scénario de test est composé de un ou plusieurs cas de tests.

Le scénario de test doit définir l’échantillonnage et la couverture des tests, le type de test, et le

nombre d’itération nécessaire.

Le scénario va également mettre en place les métriques nécessaires au suivi du déroulement des

différentes phases de tests et l’enchaînement des différents scénarios.

C’est le scénario qui va définir la nécessité de développer des bouchons afin de tester

indépendamment des unités élémentaires. Les bouchons étant là pour simuler l’unité élémentaire qu’ils

remplacent. Leur développement nécessitant aussi des tests ils sont à définir et à prendre en compte dans le

coût global d’un projet.

Tous les tests définis dans le chapitre précédent peuvent être utilisés. Ils peuvent définir différents

scénarios afin de structurer les tests. Le but est de dérouler ces différents scénario soit les un après les autres,

soient en parallèle par plusieurs équipes. Ainsi les tests de boites blanches et de boites noirs sont

indissociables et doivent être exécuté l’un après l’autre.

Un résumé sous forme de liste des tests intervenant dans un ou plusieurs scénarios, plusieurs tests

peuvent être intégrés selon le niveau d’intervention dans le logiciel du scénario :




Type de TEST Description

Test boîte noire Test qui permet de s'assurer que l'unité qui est testée fournit, à partir de paramètres d'entrées conforme, le résultat attendu.

Test aux limites Test sur des valeurs inhabituelles, particulières ou limites que le système doit pouvoir gérer.

Test de classe Tâche qui permet de s'assurer qu'une classe et ses instances (objets) fonctionnent comme défini.

Test d'intégration des classes

Tâche qui permet de s'assurer qu'une classe et ses instances (objets) issus de logiciels externes fonctionnent comme défini

Revue de code Revue technique qui consiste en une révision du code source : vérification de la conformité du code par rapport aux normes de programmation et aux spécifications.

Test de composant Tâche de validation du bon fonctionnement d'un composant.

Couverture de test La tâche qui consiste à s'assurer que chacune des lignes de code a été testée.

Revue de conception Revue technique qui consiste à explorer le modèle de conception.

Test de non-régression avec l'héritage

Tâche permettant de s'assurer que les cas de tests fonctionnent sur la classe "mère" et les classes "filles" ("mère" et "fille" : notions entre les classes introduites avec l'héritage).

Test d'intégration Test pour vérifier que des lots fonctionnels fonctionnent correctement ensemble.

Test de méthode Test pour vérifier que des méthodes (ou opérations) fonctionnent comme défini.

Revue de modèle La revue de modèle consiste à explorer complètement le modèle. La revue est d'autant plus pertinente qu'elle est réalisée par des personnes qui n'ont pas participé à la mise en œuvre de ce modèle.

Test des chemins logiques

Tâche permettant de s'assurer que tous les chemins possibles ont été testés au moins une fois (Le composant est considéré comme un ensemble de branches constituant des chemins possibles qui doivent tous être vérifiés).

Revue de prototype (ou Test de prototype)

Pour cette revue, les futurs utilisateurs utilisent aux travers d'une collection de cas d'utilisation (c'est à dire diverse manière d'utiliser le système) le prototype comme ils utiliseraient la future application. L'objectif principal est de s'assurer que le prototype répond bien aux attentes des utilisateurs.

Preuve par le code Le meilleur moyen de s'assurer que le modèle correspond au besoin ou bien encore à ce qui doit être construit est de produire le logiciel basé sur ce modèle. Ceci permettra de valider l'exactitude du modèle.

Test de non-régression Tâche permettant de s'assurer que les précédents "modules" testés fonctionnent encore après des modifications apportées à l'application.

Test de stress (voir aussi Test de charge)

Tâche permettant de s'assurer que le système supporte les gros volumes de transactions, de charge, d'utilisateurs... (supporte dans le sens de




fonctionner correctement).

Revue technique

Technique d'assurance qualité qui consiste à faire examiner et critiquer la conception de l'application par des pairs. La revue typique se concentre sur la qualité, la facilité d'utilisat ion, la cohérence, la couverture. On peut également parler de "Revue par ses pairs".

Test de scénarios d'usage (ou de scénarios

de cas d'utilisation)

Technique de test dans laquelle un ou des membres de l'équipe projet valide le modèle "en déroulant" des scénarios de cas d'utilisation du système.

Test de l'interface utilisateur (Test UI)

Les tests concernant l'interface utilisateur permettent de vérifier le respect des standards d'interface (standard UI) et de s'assurer que l'on répond aux exigences définies au cours du projet concernant l'interface.

Test boîte blanche (ou Test boîte de cristal)

Test qui permet une validation technique du composant testé. (Remarque : Ces tests complètent les tests boîtes noires et permettent de détecter les parties de code non accessibles et les comportements indésirables.).

Certains projets sensibles nécessitent un scénario basé sur des méthodes spécifiques tel que la preuve

définie ci-dessous. Ou alors un même type de tests peut être traité de manière différente selon

l’environnement. Les logiciels en mode objets nécessitent des scénarios de tests unitaires adaptés à leur

spécificité.

Le scénario s’élabore dans la branche descendant du V définissant le cycle en V :

Schéma 4.3 : L’insertion de l’élaboration du scénario dans le cycle en V.


Analyse détaillée

Développements Tests unitaires

Tests d’intégration

Tests d’assemblage

SCENARIO




2.1.1 Cas de la preuve

Les preuves de programme sont utilisées dans le cadre d’une correction absolue pour mettre en

évidence certaines propriétés telle que la complétude1. Elles complètent les tests structurels.

Elles se présentent sous de types de preuves :

• Les preuves informelles : basées sur le principe d’invariants mathématiques qui prouvent le bon

fonctionnement du logiciel s’il restent vrai au cours de son exécution

• Les preuves formelles : basées sur des formules, axiomes2 et règles dans le but de prouver

l’adéquation entre conception et spécifications et l’adéquation entre le code et la conception.

2.1.2 Les tests unitaires

Les tests unitaires ou "tests de module" sont dissociables en deux stratégies :

• les tests fonctionnels ou tests de boîtes noires, qui contrôlent les contraintes liées aux

spécifications et évaluent les réactions du logiciel à certaines entrées, sans rentrer à l'intérieur des

modules : l'aboutissement est un ensemble d'effets testés. Ces tests ne prennent pas en compte la

façon dont le programme est écrit. C’est le rôle des tests de boîte blanche.

• les tests structurels ou tests de boîtes blanches, qui contrôlent la structure de chaque module, via

le graphe de flot de contrôle; le code du programme est testé "petit bout par petit bout" (on parle

de portions) et on nommera, à la fin de cette série de tests, couverture l'ensemble des portions de

code qui auront été testées.

Les tests de boites blanches ne permettent pas de mettre en évidence les oublis du programme par rapport aux

spécifications. Ils sont donc liés aux tests de boites noires.

1 1 Complétude : c’est le taux de couverture ou mesure de complétude qui exprime d’une manière quantitative le degré de satisfaction du critère testé. Elle est calculé en divisant le nombre des objets couverts par le nombre total des objets que le critère de test nous impose(que l’on évalue par simple analyse du code source) 2 Axiome : Proposition admise sans démonstration. Proposition évidente résultant des principes d’identité et de non-contradiction.




Si cette description des tests est écrite en langage manipulable par un ordinateur, cette procédure peut être

automatisée ou semi-automatisée.

Ainsi cette stratégie détermine une bonne couverture des domaines d‘entrée du programme, et des oublis par

rapport aux spécifications peuvent être détectées. Dans le cas d’une modification non liée à la spécification, il

est possible de conserver les mêmes jeux de tests pour vérifier le programme modifié.

Les grandes lignes de ce scénario qui seront réalisées par un testeur sont :

• sélection des tests assurant un bon échantillonnage des comportements possibles.

• Exécution des tests

• observation du comportement du programme avec les comportements attendus.

2.2 Aspect outils de tests :

Depuis l’émergence des langages orientés objets les programmes se sont complexifiés de part leurs

multiples possibilités de dialogues et leur caractère réutilisable.

Ils ont donc entraîné dans leur sillage la croissance du secteur du logiciel de test qui ne se contente plus de

contrôler le code mais s’intègre dés le schéma de conception.

La phase de tests devenant de plus en plus importante, ils doivent répondre à différents critères propres aux

langages tels que le test sur l'héritage, l’encapsulation ou le polymorphisme mais aussi à la nécessité

t’intégrer facilement la phase de test.

Le passage des tests fonctionnels peut s'avérer long et coûteux en particulier lorsque le produit possède une

interface nécessitant la présence d’un utilisateur pour tester l’ensemble des scénarios.

Il existe des outils d’aide au test fonctionnel qui permettent de capturer, contrôler et rejouer automatiquement

les interactions des utilisateurs permettant d'identifier les anomalies.




On peut ainsi s’assurer que les processus métier, qui font intervenir des applications et des bases de données

multiples, fonctionnent parfaitement dès la première fois et qu'ils demeurent fiables lors des passages de tests

de non régression en cas d ‘évolution du logiciel en phase de maintenance.

Les outils proposés aujourd’hui sont nombreux et variés. Pour les classer on peut les évalués selon trois

critères qui sont :

• Langages supportés.

• Environnement de développement.

• Les différents types de tests ainsi que l'intégration du logiciel de test au sein d'un projet.

Nous reprenons ici des exemples d’outils utilisés pour répondre aux tests définis ci-dessus.

2.2.1 Les tests fonctionnels

Les logiciels de tests génèrent des jeux d’essais pour systèmes informatiques. Ils comprennent 2 parties :

• Le Système Sous Test = SST

• Le simulateur d’environnement

Les bancs de tests servent à :

• Provoquer et observer les réactions du SST face à son environnement

• Minimiser les essais et intégrations sur site

On simule les équipements absents à partir des scénarios.

Principales fonctionnalités offertes par ses logiciels (voir schéma 4.3) :

• Langage spécifique pour l’écriture des scénarios

• Fusion temporelle de deux scénarios

• Visualisation graphique de l’évolution des variables du SST au cours du temps




• Enregistrement au cours d’une simulation de tous les changements d’état des informations en

provenance ou à destination du Système Sous Test

• IHM conviviale de type graphique

• Exécution d’un scénario de simulation en mode automatique, en mode pas à pas, en mode batch ou en

mode direct

• Exploitation en différé des résultats archivés en simulation : tests de non-régression, statistiques,

vérification logique, exploitation graphique.

Schéma 4.4 : Présentation schématique d’un outil de test

2.2.2 Les tests d’interface

Les tests d'interface homme machine revêtent une importance croissante avec l'explosion

d'applications web. Le développement du e-business en fait des outils stratégiques.

Les logiciels permettant ce type de tests répondent à un certains nombres de besoins :

• possibilité de tester un ensemble de processus locaux en l'absence du reste de l'environnement.

• possibilité d'exécution automatique des tests afin de vérifier facilement la non régression au cours du

développement.

• non intrusion dans le système à tester.

Ce type de logiciel génère automatiquement un programme testeur à partir d’un scénario de test, défini par

l’utilisateur dans un langage dédié.




Les différents modules de l’application sous test sont associés à une bibliothèque de simulation des

primitives de communication, via une édition de liens standard, en lieu et place du jeu de primitives réel. Il

génère aussi des éditions de liens entre les différents modules. (voir schéma 4.4).

Schéma 4.3 Schéma de l’utilisation d’un outil de test

2.3 Aspect plates-formes :

Lors de la mise en place d’une nouvelle application dans l’environnement d’exploitation, il n’est pas

rare de voir apparaître les premiers problèmes. Ceux-ci sont liés aux différences qui existent entre ces deux

environnements. En effet, pour des soucis de temps de réponse et de performances, les environnements de

tests utilisent des configurations matérielles très puissantes, le plus souvent à celles des développeurs. C’est

pourquoi il devient nécessaire d’effectuer des tests sur des plates formes représentatives de l’environnement

utilisateur. Pour cela, on utilise la configuration la moins performante comme référence, ceci après étude du




terrain, sauf si le cahier des charges stipule clairement la configuration requise, au quel cas les tests seront

effectués sur cette plate-forme.

Devant la constante évolution des environnements d’exploitation, il faut s’assurer du parfait fonctionnement

de l’application sur plusieurs plates-formes. Ainsi, les choses se compliquent. En effet, afin de garantir la

parfaite stabilité de l’application dans divers environnements, combien de plates-formes différentes doit-on

tester ? est-il nécessaire de dédier une plate-forme par environnement ? faut-il utiliser la même plate-forme

pour tous ?

On voit apparaître les systèmes multi environnements qui ont pour vocation de rejouer des tests identiques

sur des plates -formes hétérogènes. En effet, il est indispensable de revenir au même point de départ pour

rejouer les jeux d’essais, en particulier pour les tests de régression. Les bases de données, les fichiers

d’environnements, les DLL de l’application et les jeux d’essais sont concernés par cette gestion

d’environnements.

Ce problème de gestion d’environnement devient plus laborieux encore lorsqu’il s’agit de valider des plates-

formes internationales. Car, en plus de gérer des environnements hétérogènes, il faudra gérer des versions

différentes de la même plate-forme. Ainsi, ce travail demande une grande rigueur.

2.4 Suivi des anomalies :

C’est dans cette phase que l’on détermine la circulation des anomalies entre les différents

intervenants. Les anomalies sont consignées, soit sur papier, soit dans des logiciels spécialisés. Cette

deuxième solution est aujourd’hui la plus employée grâce à l’essor des technologies web ou encore des

messageries électroniques. Si cet outil de suivi est très utile pour donner un état des problèmes à un moment

donné. Ce suivi peut-être utilisé comme outil de mesure de l’avance des tests et des actions à mener pour

tenir les délais impartis. Il permettra de mettre en évidence les états ayant fait défaut lors de l’élaboration du

projet afin d’y remédier lors d’un autre projet.

Voyons comment circulent les anomalies entre les divers intervenants. Une action sur une anomalie est

effectuée chaque fois qu’on la prend en compte pour la qualifier ou pour la corriger. Ces actions sont

directement liées à l’organisation des équipes. On distingue quelques actions de base généralement




employées : la création, l’ouverture, la transmission, la correction et la fermeture. Bien entendu cette

énumération n’est pas exhaustive et le nombre d’actions est lié à l’organisation de chaque équipe.

Il faut savoir que chaque anomalie appartient à un propriétaire qui ne pourra en être « débarrassé » qu’en

définissant une nouvelle action et en changeant son état. Ceci permet la traçabilité de chaque action.

Les testeurs pourront créer ou fermer des anomalies. Une anomalie créée sera transmise au chef de projet et

ne pourra être fermée que lorsque la correction sera valide et qu’on ne détectera suite à celle-ci aucune

régression.

Les chefs de projets devront qualifier les anomalies et vérifier les corrections apportées par le développeur. Il

aura donc la possibilité d’ouverture et de transmission sur une action. L’ouverture signifie qu’après analyse

du chef de projet, l’anomalie nécessite une correction. Après correction par le programmeur, l’action est

transmise au chef de projet, qui lui-même, après validation demandera de nouveaux tests au testeur.

Les développeurs créent et corrigent les anomalies. Lorsqu’il reçoit une fiche d’anomalie, le développeur

choisit de la corriger ou de la passer à un autre développeur avant retour au chef de projet.

L’état d’une anomalie est défini suite à une action. Chaque fois que l’anomalie change de propriétaire, elle

change d’état. Les états les plus courants sont : nouveau, en cours de correction, en attente de validation,

corrigé. Ainsi, un état est lié à l’action qu’on lui a appliqué. Par exemple, créer une anomalie consiste à lui

donner l’état nouveau. Bien entendu, un état en précède un autre. Une anomalie ne peut être en cours de

correction si elle n’a pas été auparavant à l’état nouveau.

2.5 Aspect ressources humaines :

Un point incontournable dans l’élaboration d’une campagne de test est la notion de ressources humaines.

L’élaboration d’un plan de test et de ces scénarios ne peut se réaliser correctement sans avoir défini les

différents acteurs, leur niveau d’intervention et le moment ou ils le feront. Chaque acteur participera à une ou

plusieurs phase de la conception à la réalisation des tests.




L’élaboration du plan de test va définir les rôles de chacun et dans quel phase du déroulement des tests il va

intervenir. Ce découpage du travail permet de définir le nombre de ressources nécessaires mais également la

spécificité de chaque groupe d’intervenant.

En effet, les choix et les questions concernant les intervenants sont multiples :

• L’utilisateur final doit il intervenir dans la phase de test si oui à quel niveau et dans quel but?

• Le développeur doit il s’arrêter aux tests unitaires ? Les erreurs de programmation doivent-elles

lui être transmis, voir même doit-il les corrigés ?

• Faut il recruter des personnes ayant un profil spécifique ?

• La communication entre les différents intervenant ?

Le plan de test associé au scénario de test va permettre de répondre à ces questions et bien d’autres.

L’environnement ayant été défini au préalable les questions liées réponses à ces spécificité trouveront une

réponse.

Aucune règle figée n’est établie mais plusieurs profils se distingue dont nous donnerons la fonction :

• Le chef de projet des tests doit avoir une vue d’ensemble du projet. En effet, il a pour mission

d’assurer le bon déroulement et la réussite des tests. Il se doit d’identifier les jeux d’essais à

réaliser, leur ordre et priorité. Pour cela, il dispose du plan de test.

Il est ensuite amené à intégrer les résultats dans le plan de développement et émettre un avis sur

la qualité du logiciel. De surcroît, il a la responsabilité de la formation des testeurs et de la

communication entre les différents groupes.

• Le concepteur de jeux d’essais est en général un programmeur senior. Il doit avoir un expérience

solide en ce qui concerne l’application et l’environnement d’exploitation. C’est lui qui met en

place les scénarios de test. Pour cela, il utilise les spécifications techniques et les cahiers des

charges. Dans le cas d’une application orientée objet, il doit également définir les tests unitaires et

fonctionnels.




• Les testeurs d’intégration et système exécutent les tests. Leur métier requiert une grande

expérience de la conduite des tests, une connaissance du métier de l’application et sur la mise en

œuvre des outils de test.

• Les testeurs d’objets interviennent lors de développement basé sur l’assemblage de composants

objets. Il faut pour cela qu’ils aient une connaissance pointue sur les techniques orientées objets et

ils doivent maîtriser les langages de développement.

• Les testeurs de documentation doivent présenter des qualités d’organisation importantes et une

connaissance approfondie des applications. Cette tâche est primordiale puisqu’elle conditionne la

diffusion et le support de l’application.

• L’utilisateur va intervenir lors de l’élaboration des scénario de tests pour apporter sa connaissance

du logiciel au quotidien mais surtout des règles de fonctionnement auquel le nouveau projet doit

répondre et les réglés déjà présentent qu’ ils ne doit pas transgresser sous peine de régression du

logiciel.

Dans le cadre de projet plus restreint ces différents rôles sont souvent tenus par des personnes ayant un rôle

en amont du plan de test ou elles voient leur rôle s’élargir.

Les interventions a effectuer peuvent être par exemple découpés en deux phases. Les tests unitaires et les

tests fonctionnels rôles qui est alors tenue par le développeur. Qui dans ce cas est une personne expérimentée

sur le domaine de l’application.

Les tests d’intégration qui sont eux imputés aux analystes qui ont participés à l’élaboration du dossier

d’analyse, des spécifications techniques et surtout aux scénarios de test dans un tel cas. Ils ont aussi pour rôle

de dérouler de manière plus élaboré des tests fonctionnels afin de croisés les contrôles effectués par le ou les

développeurs.




Le chef de projet de l’application sera garant de la qualité du logiciel. Il contrôlera le bon déroulement des

tests et des procédures à suivre en cas d‘anomalie détectée. Il coordonnera les différents tests et leur mise en

œuvre. Il aura pour fonction de communiquer avec le client et de résoudre les dysfonctionnements éventuels.




2.6 Conclusion :

Après une campagne de tests correctement menée, il reste la mise en place du logiciel et plus

précisément son utilisation intensive par les utilisateurs. Cette phase engendre une maintenance que toutes les

sociétés sont obligés de recourir.

D’autres problème sont alors mis en évidence tel que la performance de traitement non prévue à cette effet

par le client lui même. Il existe un outil pour les projets de conception objets qui permet de résoudre ou tout

au moins détecter comment est utilisé le logiciel afin d’amener une maintenance évolutive sur les faiblesses

du systèmes.

Cette outils est le PROFILING :

Le profiling d'application permet de déterminer dans quelles portions du code le programme passe la plupart

de son temps et à partir de quelles fonctions celles-ci sont invoquées. Ces informations permettent de révéler

des problèmes d'optimisation. Dans certains cas cela peut également indiquer un bug si on se rend compte

qu'une fonction est appelée plus souvent que prévu.

En conséquence de plus en plus d’outils sont mis à la disposition de toutes les phases d’un logiciel afin

d’obtenir une qualification optimum du système.

Schéma 4.5 Conclusion scenario de test

Qualité

Fiabilité Maintenabilité

Disponibilité Utilisabilité

Compréhension

Modifiabilité Testabilité




V LES OUTILS DE TEST

L’évolution continue et très rapide du monde informatique ainsi que les besoins accrus de stabilité et

de performance ont rendu les outils de développement indispensables pendant toutes les phases du cycle de

vie logiciel. Ainsi parmi les outils qui accompagnent le développement se comptent :

• Outils d’analyse des besoins :

- Outils de modélisation des besoins

- Outils de traçabilité

• Outils de conception

• Outils de développement :

- Editeurs de programmes

- Compilateurs, débuggueurs et générateurs de code

• Outils de test :

- Générateurs de tests – pour assister le développement de cas de test

- Outils d’évaluation de tests – pour l’estimation des résultats des tests et pour les

comparaisons entre le comportement observé et celui attendu

- Outils de management de tests – un soutien à la gestion de tous les aspects du

processus de test

- Outils d’analyse des performances – pour la mesure et l’analyse des performances des

logiciels. Il s’agit d’une forme spécialisée de tests centrée sur l’analyse des

performances plutôt que sur le comportement fonctionnel

• Outils de maintenance :

- Outils de compréhension

- Outils de re-engineering




• Outils de contrôle de qualité :

- Outils d’inspection

- Outils d’analyse statique

• Outils de configuration :

- Outils de gestion de versions

- Outils « build – release »

• Outils de management :

- Outils de planification projet

- Outils de gestion de risque

• Outils divers :

- Outils de gestion de communication

- Outils d’évaluation

Les outils de test représentent un des éléments essentiels dans les environnements de développement. Leur

rôle est d’assister, de faciliter et de rendre plus performantes les procédures de test qui sont devenues de plus

en plus laborieuse, répétitive et nécessitant une concentration des ressources élevée. Elles permettent

d’automatiser, de simplifier et de rendre plus efficaces les tests.

Un outil de test est un programme dont le but est de concrétiser une ou plusieurs méthodes de test. Ce

programme doit avoir une durée de vie dépassant le cycle de développement d’un projet spécifique, et

pouvoir, avec des interfaces généralisées, être réutilisé par plusieurs utilisateurs dans d’autres applications .

Le but des outils est de rendre le développement plus systématique et ils varient, en allant de support pour

des micros tâches jusqu’à englober l'ensemble du cycle de vie.

Dans les outils de test nous pouvons distinguer les outils de test et les applications développées par les

programmeurs dans le cadre des tests unitaires. Ces programmes ont pour objectif de faciliter l’utilisation des

techniques de tests, par exemple les « bouchons ».




1 Modes de fonctionnement

Les outils de tests sont conçus pour répondre à trois types d’objectifs :

• le déroulement automatique des tests déjà enregistrés, réalisé par l’automate de test. L’automate

décrit les différentes actions dans un script afin de pouvoir les reproduire de façon répétitive.

• l’analyse des spécifications des nombreux objets dans le but d’effectuer une sélection de ceux-ci

lors de la ré-exécution de l’outil.

• la réalisation de mesures de performance sur les temps de réponse de l’application testée dans des

conditions d’utilisations distinctes.

Un outil complémentaire à l’automate de tests est le module de planification et de rapports. Les plans de

tests servent à définir les objectifs à atteindre ainsi que les différents scénaros à utiliser. En ce qui concerne

les rapports, ils fournissent des informations sur l’évolution de l’outil par rapport aux plans de tests.

Le troisième élément qui vient compléter les outils de test, est un dispositif de suivi des anomalies qui

permet de supprimer les fiches d’anomalies papier.

Une classification précise des outils de test est une tâche délicate. On peut certes suivre la philosophie de

classification adoptée pour les techniques de test dans la mesure où chaque technique peut être mise en œuvre

par un outil automatique spécifique.

Les outils qui analysent le « code source » seront appelés « les outils statiques » et les outils qui nécessitent

ou visent l’exécution réelle du code binaire seront appelés « les outils dynamiques ».




2 Les outils statiques

Les outils statiques ont comme principale fonction de générer un certain nombre d’informations à

partir d’une représentation « non active » du programme.

Les outils d'analyse statique concernent les composants logiciels comme les analyseurs syntactiques et

sémantiques ou les composants données comme les analyseurs de flux et des dépendances.

Les outils de tests statiques analysent le code source sans exécuter les instructions. Ce type d’outils doivent

être employés pendant la phase de tests unitaires et ils peuvent révéler, par exemple, quelles sont les variables

qui ont été déclarées et initialisées mais ne sont jamais utilisées.

Il y a des outils spécialisés pour chaque langage de programmation qui peuvent effectuer de nombreuses

vérifications du code source.

Les outils de tests statiques doivent être standardisés et renforcés dans tous les projets.

Les outils de test statiques ont comme principe de fonctionnement :

• l’analyse du code source de manière non active ;

• le respect des standards de codage

• le contrôle des chemins de l’application

Afin d’effectuer ces tests, les outils font appel à de nombreux types d’analyseurs :

• les correcteurs intelligents de programmes

• les analyseurs de complexité

• les analyseurs de graphes de contrôle

• les analyseurs du flux des données

• les outils de gestion et de documentation

• Outils d’exécution symbolique

• Démonstrateurs d’exactitude




2.1 Les correcteurs intelligents de programmes

Les correcteurs de programmes sont capables d’analyser le code source et de retrouver, par des

logiques basées sur l’intelligence artificielle, des plans abstraits. Ces plans résument les décisions prises par

le développeur pour résoudre un problème spécifique. L’outil compare par la suite ces plans abstraits avec la

manière dont ils ont été appliqués dans le langage de programmation adopté. Des incohérences sont alors

éventuellement détectées.

Ces outils peuvent aussi localiser des classes de bouclages infinis. Ils travaillent en mode interactif et peuvent

à tout moment expliquer leur raisonnement.

Leurs applications sont surtout pédagogiques et limitées à des programmes de taille réduite élaborés par de s

programmeurs novices dans des langages tels que LISP ou Pascal.

2.2 Les analyseurs de complexité

Pour mieux analyser la complexité d’un programme ainsi que la proportion de commentaires et

d’instructions, les outils utilisent des techniques d’analyse du code ainsi que des modèles de complexité. Les

modèles les plus répandues sont : Mc CABE et HALSTEAD.

Le modèle de Mc CABE est fondé sur l’étude structurelle du graphe de contrôle du programme. Les

différents avantages de ce modèle de complexité sont :

• mise en œuvre relativement aisée.

• permet de mesurer la complexité d’un grand nombre de programme aux designs très

variés.

• peut être mis en œuvre très tôt dans le cycle de développement d’un programme.

• fournit des indications sur les parties des programmes pour lesquelles il faudra être plus

vigilant lors des tests des programmes.

Les points faibles de ce modèle sont :

• il ne prend pas en compte la complexité des conditions

• l’utilisation multiple d’opérateurs booléens




• les expressions arithmétiques complexes.

Le modèle d’HALSTEAD est directement lié à la distribution des différentes instructions et variables qu’il

met en jeu. La complexité du programme est estimée suivant le nombre et la fréquence d’utilisation des

instructions et des termes composant le code source. Les points forts de ce modèle sont l’évaluation de quatre

quantités distinctes :

• le nombre d’opérateurs différents qui apparaissent dans le programme

• le nombre total d’opérateurs du programme

• le nombre d’opérandes différents

• le nombre total d’opérandes

Les contraintes de ce modèle sont dues au fait que les mesures se basent sur le code et pas sur la conception.

En effet, les analyseurs de complexité ne procurent aucune possibilité d’étudier les résultats obtenus. Les

résultats doivent être comparés avec des objectifs définis, par avance, par l’équipe de développement. Ces

confrontations sont généralement effectuées avec le diagramme de Kiviat.

Schéma 5.1 : Le diagramme de Kiviat




Ainsi, les intersections entre le cercle et les axes représentent les limites maximales conseillées, déterminées

par l’équipe de développement, et les points du polygone déterminent les résultats obtenus par les modèles

utilisés. Lorsque le polygone sort du cercle cela signifie que l’on dépasse les limites maximums de

l’application, ce qui peut impliquer des difficultés lors de la phase de tests.

2.3 Les analyseurs de graphes de contrôle

Le principe de fonctionnement de ces analyseurs est lié à l’étude du code source dans le but de

construire une représentation interne de son graphe de contrôle. Une fois cette description réalisée, le testeur

peut suivre le déroulement des différentes structures du programme.

Le graphe permet aussi la mise en évidence de pratiques non structurelles, telles que l’utilisation des

instructions de type sauts inconditionnés.

Les outils utilisant ce type d’analyseur peuvent établir une communication avec les analyseurs dynamiques

dans le but de définir les nœuds couverts par des données de test.

Les analyseurs permettent aux testeurs d’obtenir des informations concernant la composition des nœuds et de

visualiser le programme dans son ensemble or dans le cadre d’ une application complexe et mal structurée les

informations générées sont souvent inexploitables.

2.4 Les analyseurs du flux des données

Le but principal de ces analyseurs réside dans la recherche d’utilisations douteuses de pratique de

codage. Ce type de vérification utilise une représentation graphique étiquetée. Les nœuds de ce graphe nous

procurent un grand nombre d’informations sur les multiples possibilités de définition ou d’utilisations de

chaque variables comprises dans ceux-ci.

Les chemins du graphe étiqueté correspondant aux dr-chaînes. Les outils d’analyse du flot des données

procèdent ensuite à la génération des expressions des chemins du graphe, c’est-à-dire à la génération et à la




simplification des dr-chaînes. Les dr-chaînes irrégulières (variables non référencées, deux définitions

consécutives, etc.) sont par la suite identifiées.

Les analyseurs du flux de données sont souvent utilisés pour la documentation du code source, car ils

sont capables de classer les variables utilisées dans une routine, comme des variables d’entrée, de sor tie,

auxiliaires, etc.

Les limites de ces outils sont celles de toute approche statique et sont dues au manque d’informations

dynamiques :

§ les pointeurs ne peuvent pas être traités

§ les indices des tableaux sont traités d’une façon insuffisante

§ la récursivité et les formes itératives peuvent poser des problèmes.

2.5 Outils de gestion et de documentation

Sont classés dans cette catégorie tous les outils qui sont capables de tirer des conclusions qualitatives

concernant le code source et les documents qui l’accompagnent. Il est possible de contrôler le respect de

certaines méthodes de programmation : nombre et nature de commentaires, noms des routines et de variables,

références croisées. Les résultats d’analyse peuvent être utilisés par les outils de documentation pour

constituer une base de données accessible à toute l’équipe de développement et disponible jusqu’à la phase

de maintenance du produit. En ce qui concerne les outils de documentation proprement dits, nous retrouvons

aussi bien les outils traditionnels de documentation, restructuration du code, gestion des configurations et des

versions, que les générateurs de rapports d’essais ou les gestionnaires des matrices de traçabilité.

2.6 Outils d’exécution symbolique

Il s’agit d’outils capables de manipuler des valeurs symboliques et de les faire évoluer le long d’un

certain ensemble de chemins du graphe de contrôle.

La première fonction de ces outils est en général une analyse syntaxique dans le but de créer une

représentation interne du programme analysé.




Cette représentation est couplée à des valeurs symboliques spécifiées dans un fichier. Le testeur indique par

la suite à l’outil un ensemble de chemins à exécuter symboliquement. Pendant l ‘exécution symbolique, une

arborescence est générée comprenant les différentes valeurs symboliques et les contraintes associées aux

variables. Ces contraintes correspondent aux conditions imposées par les prédicats du programme. L’outil

procède à la simplification des expressions algébriques et à la résolution partielle des différentes contraintes

rencontrées.

L’interactivité est une caractéristique essentielle de ces outils, car, à tout moment, le testeur doit fournir des

informations supplémentaires qui permettront à l’outil de procéder à certains choix et de résoudre des

contraintes.

Les résultats de l’analyse symbolique peuvent être comparés à des spécifications, surtout si le niveau de

formalisation de ces dernières est assez poussé.

2.7 Démonstrateurs d’exactitude

Ces outils adoptent une philosophie analogue aux outils d’exécution symbolique, mais leurs résultats

sont en quelque sorte « binaire » : l’algorithme est ou n’est pas, partiellement ou totalement, correct. Pour ce

faire, le testeur introduit dans certains endroits du programme , des assertions. Ces assertions ne sont pas

autres que des propriétés formelles, que les variables doivent vérifier à un certain instant de l’exécution.

L’outil est capable d’interpréter la sémantique des instructions et de vérifier qu’à tout moment leur exécution

ne viole ces propriétés. En partant d’une propriété initiale et en transformant ces propriétés, on arrive, à

s’assurer que la propriété finale est vérifiée. Ainsi, l’exactitude partielle ou totale de l’algorithme est prouvée.

Ces techniques se cantonnent néanmoins à l’analyse de programmes de taille relativement réduite concernant

des applications à haute sécurité.




3 Les outils dynamiques

Les outils de tests dynamiques examinent l’état d'un programme pendant la phase d'exécution.

Effectuées pendant la phase de tests unitaires, ils examinent l'environnement et la mémoire pendant

l'exécution du programme.

Les outils de test dynamiques sont très spécialisés et en directe liaison avec les plate-formes hardware et les

langages utilisés.

Les sorties d'outils de test dynamique sont constitués d'une liste avec les détails des parties de code exécutées

et qui n'ont pas été exécutées, et combien de fois une partie a été exécutée, quelles sont les variables les plus

utilisées, combien de librairies système ont été appelés pendant une exécution. Lors de ces analyses, les outils

utilisent des routines déterminées, qu’ils introduisent dans les sources afin de récolter dans des fichiers les

différentes réactions du programme. Ce procédé, appelé « instrumentation », ne modifie rien dans le

comportement du programme.

Par une instrumentation adéquate on peut avoir une idée assez précise du temps d’exécution de certaines

parties du code. N’oublions pas la fameuse règle du 80 % et 20 % qui stipule que 80 % du temps d’exécution

est effectué par 20 % du code. Il est alors possible d’améliorer les performances du logiciel en réécrivant

certaines parties de son code. L’évaluation du temps d’exécution doit être prise avec assez de précautions

dans la mesure où toute instrumentation ralentit inévitablement l’exécution réelle.

Ainsi, l'analyse des ces sorties peuvent aider à l'optimisation du système et contrairement aux outils statiques,

ils représentent un comportement proche de la réalité.

3.1 Les évaluateurs de couverture

Lors de la réalisation des phases de test de couverture, on voit apparaître des notions chiffrables

concernant, par exemple, le nombre d’instructions utilisées, le taux de couverture, le nombre de chemins

exécutables ou non-exécutables, etc.




Ces évaluations peuvent poser des difficultés de mise en place, pour le testeur, dans des applications

complexes. Pour palier à ce problème, on utilise de plus en plus les évaluateurs de couverture. Ils ont pour

principe de fonctionnement l’instrumentation de routines de mesures et l’analyse du fichier résultant. Leur

fonctionnement général peut être illustré par le schéma 7.2.

Schéma 5.2 : Instrumentation code source

Signalons enfin que ces outils de mesure de couverture sont en général capables d’évaluer la couverture des

instructions, des branches et de la plupart des couvertures basées sur le flux des données.

3.2 Les évaluateurs d’assertions locales

Les évaluateurs d’assertion locales permettent aux testeurs d’introduire des instructions dans le code

source, dans le but de tester des blocs ciblés. Les testeurs doivent utiliser des moyens de reconnaissance

spécifiques pour permettre à l’outil de différencier ces assertions locales des autres instructions. Les

assertions locales peuvent être utilisées pour suivre les valeurs limites des différentes données, examiner

d’une façon périodique ou systématique la cohérence des entrées / sorties.




Cette classe d’outils constitue une méthode de test en elle-même, mais peut être utilisée par la théorie de la

tolérance aux erreurs et des techniques de génération des données de tests basées sur l’optimisation d’un

espace d’erreurs initiales.

3.3 Les simulateurs d’environnement

Les outils comportant ce procédé de simulation consistent en la construction d’un environnement de

travail dans lequel ils intègrent le programme à tester. Ensuite, ils procèdent à une simulation de l’ensemble

suivant deux procédés :

§ ascendant – qui se comporte comme un moniteur, c’est-à-dire qu’il lance le programme à tester

§ descendant – qui fait office de programme de substitution.

Ces simulateurs sont en mesure d’effectuer une simulation de l’environnement de production, dans lequel le

programme à vérifier doit être intégré. Ils offrent la capacité de comparer les résultats théoriques avec les

réels.

Aussi, dès leur exécution, ils archivent toutes les données récoltées afin d’établir une « base de données »

réutilisable lors de tests de non-régression.

La nécessité de ces outils est incontestable, non seulement pace qu’ils interviennent dans toutes les phases du

test, mais aussi parce qu’ ils sont capables de gérer, avec un archivage adéquat, toute la procédure de passage

des tests : enchaînement de test et gestion des non-régressions qui constituent des aspects fondamentaux de

toute pratique de test.

3.4 Les analyseurs dynamiques du flux des données

Les analyseurs dynamiques du flux des données résolvent tous les problèmes rencontrés par

l’approche statique correspondante. Les variables analysées peuvent être des pointeurs ou des tableaux et les

anomalies détectées correspondent à une véritable exécution du programme.




Le premier inconvénient de ces outils est celui de tout outil dynamique : on ne peut pas être sûr que toutes les

anomalies ont été détectées. Le deuxième inconvénient est la taille de l’instrumentation nécessaire. A chaque

apparition d’une variable, l’outil doit générer la routine de mise à jour de sa dr-chaîne.

3.5 Générateurs automatiques de Données de Test structurel

Le but de ces outils est de trouver les valeurs initiales des variables qui permettent la sensibilisation

d’un chemin déterminé. Sensibiliser un chemin consiste à résoudre un système d’équations et inéquations à N

inconnues. Le problème est intrinsèquement difficile et mène à une explosion combinatoire. On peut

néanmoins avoir des résultats satisfaisants à travers quelques hypothèses simplificatrices, mais réalistes sur la

nature et le nombre des conditions qui apparaissent dans les prédicats.

Dans la classe des générateurs automatiques de données de test sont aussi inclus les générateurs basés sur la

forme des données : générateurs pseudo-aléatoires, générateurs par échantillonnage régulier, générateurs

basés sur une grammaire ou des représentations par des automates.

3.6 Les débuggueurs

Les débuggueurs sont directement associés à toute procédure de test, car ils constituent l’outil

automatique indispensable à la localisation du défaut. Souvent même, et à tort, ils sont utilisés par le

programmeur pour vérifier le déroulement correct de son programme. Il est en outre évident que les

débuggueurs ont une forte analogie avec tous les outils qui procèdent à l’instrumentation du code source,

dans la mesure où, eux aussi, nécessitent une sorte d’instrumentation du binaire pour permettre le suivi pas à

pas de l’exécution.




4 Conclusion

L’utilisation d’outils de tests implique souvent des niveaux de spécialisation élevés et leur utilisation,

souvent difficile, nécessite dans la plupart des cas des formations adéquates, comme l’apprentissage de

langages de programmation.

Un autre inconvénient des outils de test est leur coût très élevé qui le rend inaccessibles aux projets à petit

budget.

Cependant, une fois ces difficultés dépassées, ces outils permettent aux testeurs de gagner beaucoup de temps

dans leur phase de vérification et dans la ré-exécution de différentes phases de tests.

Ci-dessous un tableau de synthèse de la présentation des outils de test et leurs utilisations entre les différentes

phases de test :

Type d’outil Test du

prototype

Test

d’intégration

Test du

système

Test

d’acceptation

Test de

régression

Générateurs de données

de test X X X X X

Analyseurs statiques X

Analyseurs dynamiques X X X

Pilotes, simulateurs,

émulateurs X X X X X

Capture / ré-exécution,

comparateur X X X X X

Analyseurs de

performance X X X X

Gestion des tests X X X X X

Tableau 5.1 : Les outils de test et leurs champs d’application.




VI COMMENT SE CONDUIT UN TEST ?

La conduite d’un test s’effectue en 4 grandes phases. Il faut dans un premier temps constituer le(s)

jeux d’essais, se qui revient à lister une suite de tests à opérer , pour ensuite procéder à l’exécution de ces

tests. La troisième phase consiste à établir une analyse suite aux résultats obtenus. La phase finale étant de

constituer un rapport sur chacun des tests effectués.

Ce rapport permettra de mettre en évidence les principales anomalies rencontrées de l’application testée et

ainsi éventuellement de procéder à une correction.

On poussuivera les tests tant que des anomalies seront décelés, et que des ameliorations auront été

nécessaires.

1 La constitution d’un jeu d'essai fonctionnel

Le jeu d’essai a pour objectif de décrire l’ensemble des situations et des opérations que l'usager

pourrait exécuter lors de l’utilisation de l’application. De la sorte, il contient une description de suites

d’actions à effectuer, ainsi que le(s) résultat(s) attendu(s) à la suite de ces actions.

Voici par exemple un jeu d’essai correspondant à un cas d’utilisation :

• Ouvrir le fichier. • Choisir le nom. • Une fenêtre d’accueil apparaît. • Cliquer sur le menu. • Résultat attendu. • Action.

Le but du jeu d’essai est la validation fonctionnelle de l’application, car il n’est pas rare de découvrir lors de

certaines manipulations , ou combinaisons d’actions , que l’application réagisse anormalement ou de manière

inattendue , rendant son emploi impossible par les utilisateurs potentiels.

Rappelons que le jeu d’essai est notamment constitué grâce aux règles de gestion définies dans la phase de

conception du projet.




2 Exécution des tests

Nous débutons ici, la phase de mise en œuvre effective des tests, nous considérons donc que lors de

réunions prèliminaires, le plan de test a respectivement été validé par les chefs de projet, de la maitrise

d’ouvrage et de la maitrise d’oeuvre.

Durant cette phase, l’objectif principal des tests est de trouver un maximum d’erreurs en un minimum de

temps. Pour cela, nous organiserons l’ordre d’éxécution des tests, en débutant par les tests dits les

plus critiques.

Le temps d’exécution des tests sera conditionné par un certain nombre de facteurs comme :

• La qualité du code de l’application : on devra rapidement détecter et mettre en évidence les

passages dont le code contient beaucoup de bugs.

• La disponibilité des développeurs à corriger les anomalies signalées.

• Les délais de test qui se révèlent souvent trop courts, il faut donc cibler les priorités et ainsi se

concentrer sur les anomalies les plus critiques. Ceci implique souvent que tous les bugs ne

seront et ne pourront être corrigés.

• La couverture des tests qui peut être mal définie, et ainsi de grosses erreurs peuvent passer

inaperçues, les tests ne couvrant pas l’ensemble des fonctionnalités de l’application.

• Le plan de test qui s’avère inadéquat et qui ne permet pas de retracer une utilisation fidèle par

un utilisateur.




2.1 Qui réalise les tests :

Il faut savoir qu’un même test peut être réalisé par plusieurs personnes, ou même, plusieurs

catégories de personnes. Malgré cela , le cercle de ces personnes reste assez restreint puisqu’il ne

comprend que quatres categories, representées par: le developpeur, le testeur professionnel, le chef de projet

et en tout dernier lieu l’utilisateur final.

Il sera donc presenté ici, ces differentes catégories, ainsi que leur rôle respectif.

• Le développeur : Il réalise les tests unitaires de modules qu’il a développé. Le développeur

est celui qui possède la meilleure connaissance technique de l’application et bien evidement,

les bugs sont liés au développement qu’il a lui-même effectué. Ainsi, il pourra les détecter

rapidement et les corriger plus efficacement. Néanmoins, il n’est pas le meilleur testeur pour

les tests fonctionnels puisqu’il ne possède pas la connaissance du «métier » nécessaire à

l’exploitation du logiciel et il aura des préoccupations plus accès sur le coté technique et non

usuel de l’application.

• Le testeur professionnel : Il est l’acteur principal de la phase d’exécution des tests, c’est donc

lui qui va s’occuper de réaliser, d’analyser les tests et enfin de produire le rapport sur les

resultats obtenus. Il faut savoir que, dans le cas de tests sur une application orientée objets, il

sera également impliqué dans les phases de tests unitaires. De plus, il intervient dès que

l’application est stabilisée et que les premiers tests fonctionnels peuvent être effectués. Bien

évidemment, il travaillera plus efficacement encore s’il est épaulé des développeurs et des

utilisateurs.

• Le chef de projet ayant participé à la réalisation du plan de test : Il est donc la personne la

plus à même de donner un avis sur les tests. Sa présence est également nécessaire, afin de

valider l’ava ncement de la phase d’exécution des tests. De plus, il est le représentant et donc

le responsable de l’équipe développement vis-à-vis de l’extérieur , il sera ainsi impliqué dans

toutes les phases de test.




• L’utilisateur final : Il est bien entendu celui qui a la plus grande expérience dans

l’exploitation de l’application, il est donc celui qui saura quelles sont les fonctions les plus

critiques qui nécessitent absolument de fonctionner sans failles. En effet, une fois

l’application validée par l’utilisateur final, elle pourra être diffusée en toute confiance.

2.2 L’ordonnancement des tests :

Le plan de test n’indiquant nulle part l’ordonnancement des tests à réaliser, il est proposé une

organisation de cette chronologie.

Etape 1 : Définition de plusieurs tâches :

• La validation de la structure de la base de test, des triggers et des procédures stockées.

• S’il y a lieu, chargement d’une base vide.

• S’il existe une base de donnée, remplissage des tables.

Etape 2 : Choix de la stratégie d’organisation des scénarios de test.

La stratégie sera déterminée en fonction des choix exprimés dans le plan de test.

On peut appréhender le problème de deux manières :

• Soit par les types de test :

Il faudra alors définir l’ordre dans lequel on va les exécuter en fonction des critères, comme les interfaces

hommes machines et la navigation, les champs obligatoires, les tests fonctionnels et ainsi de suite.

• Soit par les objectifs de test :

Il faudra alors prendre chaque objectif de tests et exécuter les scénarios correspondants, en fonction de

leur priorité définie dans la matrice d’analyse du risque.




Etape 3 : Une fois les priorités établies, il faut choisir la couverture des premiers tests à effectuer. Bien

entendu, il n’y a pas de « recette » ou de solution, adaptée à toutes les situations.

On peut par exemple choisir de naviguer dans l’application en vérifiant l’ouverture de tous les écrans, ainsi

que toutes les fonctionnalités offertes. Ainsi, on valide facilement un grand nombre de fonctions. Ceci est très

pratique lors d’applications avec beaucoup d’écrans.

Une autre solution, plus adapté aux applications utilisant des règles de gestion complexes, serait de procéder

à l’opposé. Et on testera, point par point, toutes les fonctions de façon intensive. Une fois validée, on

considérera l’application comme suffisamment stable.

Etape 4 : Choix multiples des options lorsque l’on utilise une fonction d’une application. En effet, ces options

ont leur importance au niveau des tests car on doit toutes les valider pour rester exhaustif. Or, on risque de se

disperser rapidement si on ne s’organise pas. Ceci fait apparaître la notion de chemin critique qui décrit les

actions indispensables pour réaliser la fonction que l’on teste. Pour cela, il faut créer un diagramme des

tâches unitaires que l’on va exécuter.

2.3 Suivi de l’exécution des tests :

Dans un premier temps, il faut isoler les cas particuliers provoquant des bugs.

En effet, il n’est pas rare que certains modules contiennent plus d’erreurs que d’autres, ces modules seront

donc nommés modules à risque.

Durant le processus de test, les anomalies détectées seront remontées par les différents testeurs et chefs de

projets, aux développeurs qui devront consacrer leur temps à l’analyse et à la correction des problèmes.

Une fois le plan de test réalisé, on peut estimer le temps d’exécution nécessaire, en se basant sur des durées

moyennes de différents types de tests et autres critères techniques qui seront réalisés.




Un dernier point important du suivi de l’exécution des tests, est la couverture qu’ils offrent.

En effet, il existe plusieurs approches permettant de déterminer cette couverture.

Dans un premier cas, on peut par exemple, s’appuyer sur les règles de gestion pour lesquelles on associe à

chaque objectif, un certain nombre de scénarios qui les valideront. Ou, utiliser les tests fonctionnels. Par

conséquent, la couverture des tests fonctionnels est facilitée si on établit un tableau mettant en relation les

scénarios et les objectifs de tests.




3 L’analyse des tests

Il est introduit ici, une notion de cycle de test. Et nous nous attarderons sur les journaux de tests qui

permettent une gestion efficace des campagnes de test.

3.1 Les cycles de test :

A la suite de la détection d’une anomalie, il y a bien sur, une phase de correction. Afin de garantir la

non régression de l’application, on rejoue la totalité des tests depuis le dé but. Cette notion de rejouer

l’ensemble des tests peut être vue comme un cycle de test. Ce cycle incluant une fois encore, les phases de

traitement et les phases d’analyse des résultats.

Plusieurs possibilités peuvent amener à réaliser un nouveau cycle de test.

Soit, simplement, parce que l’on désire reproduire les tests avec de nouvelles données.

Soit parce que l’on considère que les anomalies détectées, lors de l’exécution précédente, sont de réelles

erreurs de régression. On vérifiera alors que la nouvelle version que l’on test , est correctement gérée par le

logiciel de gestion des tests.

On associera à chaque cycle un index à deux dimensions, c'est-à-dire une première partie incluant le nombre

d’exécutions de tests et la seconde indiquant la version de l’application. Cet index de cycle de test permettra

d’éviter une redondance inutile de tests déjà effectués et ainsi de définir l’unicité du cycle. Par conséquent,

les tests seront facilités car on pourra différencier les résultats par rapport à la version de l’application et à

l’exécution précédente.

Les index de cycle de test seront intégrés dans le journal des tests.




3.2 La journalisation des tests :

Le journal des tests est l’outil de travail du testeur. Ce journal référence tous les résultats de chaque

exécution. Si on utilise un outil pour exécuter les tests, ce journal sera alors créé automatiquement par l’outil.

Tous les points de contrôle effectués par l’automate figureront dans le journal. On y trouvera le libellé du

test, l’heure d’exécution, le résultat de la vérification, les mesures de performance, l’heure de début et la

durée totale de l’exécution du scénarios, le cycle de test, le nom de la station sur laquelle est effectué le test et

le nombre d’anomalies de régression détectées.

Le journal des tests fera partie du document final produit par l’équipe de test. On y trouvera au même titre

que le plan de test ou le statut des anomalies. Pourtant son principal intérêt réside dans l’utilisation de

comparateurs.

Les outils de test permettent essentiellement la détection des anomalies de régression par rapport aux

versions précédentes. Cette régression se manifeste par la différence entre les informations consignées durant

l’enregistrement et celles détectées durant la phase de rejoue des tests. Cet outil est appelé comparateur. Il

s’agit d’un logiciel spécialisé qui peut effectuer des comparaisons entre deux fichiers de test.

Lors de l’enregistrement d’une procédure de test, le testeur décide de capturer les informations qu’il souhaite

tester. L’outil de test, par les moyens qui lui sont propres, transférera les données de test qu’il vient de

capturer dans un fichier appelé fichier de référence. Au moment de la phase rejoue des tests, l’outil déroulera

le scénario, capturera les données de l’application et les stockera, en les formatant, dans un autre fichier. A la

fin de l’exécution, le journal de test indiquera les points de contrôle qui auront échoué, et le comparateur

visualisera les données de test en indiquant les différences constatées.




3.3 Le rapport de test

Voici cinq grandes familles de rapports que l’on retrouve généralement dans cette phase :

• Les rapports de synthèse, qui recensent toutes les entités ayant participé aux tests, les regroupant et

les mettant en relation.

• Les rapports de couverture de test mettent en relation les scénarios de test avec les objectifs et les

règles de gestion.

• Les rapports d’avancement relient les objectifs de tests aux scénarios et listeront ceux qui sont

enregistrés. Ils peuvent également lister les scénarios qui se sont correctement exécutés.

• Les rapports de performance permettent de valider les performances de l’application.

• Les rapports d’anomalies sont de plusieurs types :

o En listant les anomalies afin de déterminer les modules fiables et ceux qui le sont moins.

o En faisant des statistiques, en utilisant le temps de correction ou encore le degré de gravité.

Une fois les rapports de tests générés, il faut leur donner une signification. Pour cela il faut prendre en

compte la phase de test que l’on vient d’effectuer.

• Soit, on se trouve dans les phases préliminaires, on aura la possibilité de corriger les anomalies

détectées sans trop perturber l’activité de test.

• Ou alors, on se trouve dans une phase avancée. Par conséquent, on prendra en compte l’impact de la

correction des anomalies sur les tests ultérieurs. On cherchera à qualifier correctement les erreurs et à

cibler les modules comportant un grand nombre d’erreurs.




VII LE PAQ, LES COUTS ET LA LEGISLATION.

1 le Plan d’Assurance Qualité

Le plan d’assurance qualité est un document officiel qui couvre toutes les phases du projet. C’est à

dire les dispositions générales sur l’organisation du projet et ce en termes de structures, outils, méthodes,

documentation, cycle de vie… et les dispositions particulières pour réceptionner les délivrables (documents

et produits logiciels) issus des différentes phases du projet.

Ainsi le PAQ définit, spécifie les dispositions arrêtées entre le maître d’œuvre et le maître d’ouvrage pour

garantir qu’une démarche qualitative sera associée à toutes les étapes du projet notamment à celle de la phase

des tests ou de la définition de la méthodologie des tests à suivre. Cette démarche qualitative anticipe ce qui

doit être fait tant au niveau organisationnel et structurel que sur les moyens techniques et ressources

humaines à mettre en œuvre pour réussir le projet dans les délais négociés conjointement entre les parties. Le

plan d’assurance qualité est le référentiel de l’assurance qualité du projet et est utilisé pour contrôler que

toutes les dispositions prévues ont bien été mises en œuvre et réalisées.

En ce qui concerne le périmètre des tests, le PAQ s’articule autour de trois types de préoccupations :

- définition de la méthodologie des tests à suivre exemple cycle de vie en V

- définition des normes et standards (de la réalisation des tests à la livraison des documents de

validation)

- Mise en place de métrique

Exemple dans le cas de la gestion des anomalies

Anomalie lors de la phase de test unitaire ou d’intégration




Les anomalies détectées lors de la phase de test unitaire ou d’intégration des composants seront consignées

dans le cahier des fiches des unitaires. Elles feront l’objet d’une correction dans l’environnement de

développement et repasseront en recette dès validation des tests unitaires par le développeur.

Le suivi des anomalies est réalisé à l’aide de rédaction des fiches de tests.

Anomalie de recette (ou de validation)

Toute anomalie de validation (et de recette utilisateur) détectée par la maîtrise d’ouvrage donne lieu à

l’ouverture d’une Fiche ANomalie intitulée « FAN ». Celle ci doit être émise au responsable de la maîtrise

d’œuvre en l’occurrence le chef de projet MOE.

Chaque fiche doit faire ensuite l’objet d’un diagnostic et d’une étude.

Les suites donnés seront multiples :

• Correction de l’anomalie

• Etablissement d’une demande de modification

• Déclaration d’un événement

Un suivi des fiches anomalies sera réalisé en réunion d’avancement ou lors de toute autre réunion

exceptionnelle.

Maîtrise de la qualité et évaluation

Les indicateurs qualités mis en place seront :

• NAI : Nombre de FAN (fiche d’Anomalies unitaires remontées après une phase de tests en Interne à

la MOE)

• NAE : Nombres d’anomalies issues d'une fiche d’anomalies utilisateur, remontées après une phase de

validation, de recette externe ou d’assistance à la mise en production.

Cet indicateur permet de déterminer un taux de fiabilité global des entités livrées. Il sera présenté sous

la forme d’une ventilation en nombre et en % :

Taux de fiabilité global des livraisons : 100 – (NAE* 100 /nombre d’entitées livrées)




• DAI : Durée de réparation d’une anomalie déclarée « FAN »

• DAE : Durée de résolution de l’anomalie issue des fiches d’anomalie de recette ou de validation

utilisateur.

Ces indicateurs permettent de déterminer le temps passer à corriger des anomalies sur le temps de

développement complet du logiciel. Il sera présenté sous la forme d’une ventilation en nombre et en % :

Taux des durées d’anomalies : 100 – (DAE* 100 /durée de développement des entités)




Exemple de documents standard prédéfini dans le PAQ

Le Procès Verbal de réception de logiciel :

Date d’émission : _______________

Nom du projet

P.V. DE RECEPTION

Recette provisoire prononcée le ______________ à ____________ n° version :______

______________ à ____________ n°version : ______

______________ à ____________ n°version : ______

Délai de réception : _________ (jours)

Date prévue pour recette définitive : __________ à ____________

PERONNES EMETTRICES DES ELEMENTS A RECEPTIONNER

Nom

Société

Identification

Visa

Identification des éléments à réceptionner (listes des objets)

Recette définitive prononcée le ____________ à _________

PERSONNES DEVANT EFFECTUER LA RECETTE DEFINITIVE

Nom

Société Identification Visa

Visa responsable Qualité :

P.V. DE RECEPTION




Feuille de relevé d’anomalie :

CLIENT

FICHE DE SUIVI D’ANOMALIE N° ____________________

Nom demandeur :

Service :

Type Anomalie :

� En phase de recette � En phase d’exploitation

Lot : ……………. Nom du programme : ………………………………

Anomalie : Bloquante ð de sévérité de 1 à 3

Non bloquante ð

Description de l’anomalie : …………………………………………………………..

…………………………………………………………………………………………..

…………………………………………………………………………………………..

Caractère reproductible : …………………………………………………………..

…………………………………………………………………………………………..

…………………………………………………………………………………………..

…………………………………………………………………………………………..

Joindre tous les documents permettant de compléter la description du problème rencontré

(Copie d’écran, Etats Imprimés, etc…)

TRAITEMENT SOUHAITE :

Correction Obligatoire :………………….

Impérative pour le : ……………………… ou Souhaitée pour le : ……………………..

Date : Signature :

Partie réservée au prestataire ( Description prise en compte de l’anomalie)

…………………………………………………………………………………………..

…………………………………………………………………………………………..

…………………………………………………………………………………………..

Traité le :………………………. Par : ………………………….




Code de sévérité N°1 : Machine désignée bloquée, traitement bloquant tous les tests, empêchant une

réception.

Prise en compte immédiate par le prestataire en un délai de 1 jours au plus. Le temps nécessaire au prestataire

pour éradiquer le défaut constaté viendra augmenter d’autant, en jours entiers, le délai de réception.

Code de sévérité N° 2 : Machine désignée dégradée, traitement bloquant l’exécution d’une fonction, les

autres fonctions pouvant être testées empêchant la réception de la fonction bloquée.

Prise en compte immédiate par le prestataire en un délai de 2 jours au plus. Le temps nécessaire au prestataire

pour éradiquer le défaut constaté viendra augmenter d’autant, en jours entiers, le délai de réception.

Code de sévérité N° 3 : Machine désignée fonctionne, anomalie mineure et d’impact négligeable. Seul code

de sévérité n’empêchant pas une réception. Délai de réception inchangé. Eradication du défaut constaté, soit

sur une future release*, soit à la discrétion du prestataire.




2 Les Coûts :

Le coût des tests est évalué lors de l’estimation du projet global et est souvent sous-estimé par rapport

à l’organisation mis en place sur le projet. Il n’est pas rare de voir des projets dépasser le budget en termes de

coût et de temps, les deux étant plus ou moins liés.

Des enquêtes ont été effectuées à ce sujet et révèlent une tendance par rapport aux différentes phases d’un

projet.

Par exemple aux USA en 1986 une étude menée auprès de 55 entreprises révèle que 53% du budget total d'un

logiciel est affecté à la maintenance. Ce coût est réparti comme suit:

• 34% maintenance évolutive : modification des spécifications initiales ;

• 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ;

• 17% maintenance corrective : correction des bugs ;

• 16% maintenance perfective : améliorer les performances sans changer les spécifications ;

• 6% assistance aux utilisateurs ;

• 6% contrôle qualité ;

• 7% organisation/suivi ;

• 4% divers.

On s’aperçoit que le coût des correction des bugs se situe en seconde position après la maintenance évolutive

et qu’il représente une part non négligeable du budget d’un logiciel.

Pour faciliter et fiabiliser l’estimation des projets , a été mis en œuvre une méthodologie permettant d’évaluer

la complexité de l’environnement et du logiciel à développer.

Le modèle COCOMO pour COnstructive COst Model estime qu’un projet est réparti comme suit :

• 15 à 20% programmation

• 40% spécification et conception

• 40% validation et vérification




Ce n’est pas comme il est souvent constaté la programmation qui requière le plus d’énergie mais bien la

définition du produit et son contrôle.

Cette méthode définit des métriques et des règles afin d’évaluer de manière plus fiable le coût d’un logiciel.

Et cela dans le but d’éviter l’écueil des erreurs de budget et de retards de livraison tant décrié.

Nous constatons que l’estimation d’un logiciel et tout aussi difficile que celle de le tester et nécessite tout

comme les tests de s méthodes et des outils logiciels permettant d’aider à la décision finale. Ceci s'explique

par l'augmentation de la complexité des logiciels avec la montée en puissance des performances du matériel.




3 La Législation :

Quels sont les recours en cas d’anomalie du logiciel ?

Quels sont les moyens et recours que dispose le client face à son fournisseur dans le but d’obtenir satisfaction

ou dédommagement ?

La législation est peu développée à ce sujet et ce sont les contrats signés entre les partenaires qui définissent

les moyens et recours dont disposent les 2 parties pour résoudre un litige.

Deux types de contrats peuvent distingués selon que le fournisseur est un éditeur ou une société de services

(SSII).

3.1 Les éditeurs :

Les éditeurs fournissent des logiciels dont ils ont définies les fonctionnalités au préalable qui

s’avèrent figés dans le temps jusqu’à la version suivante. L’achat doit se faire en connaissant les limites du

produit tant fonctionnel qu’au niveau fiabilité. Le fournisseur délivre dans ce cas une licence qui donne le

droit d’utiliser le produit en l’état. Il se décharge de toutes responsabilités liées à l’utilisation de son produit

et de ces conséquences. L’éditeur n’ayant pas connaissant du contexte de déploiement de son produit.

Exemple de garanties et responsabilité des éditeurs :

Schéma : 7.1

« Le logiciel » et la documentation qui l’accompagne sont fournis dans l’état où ils se trouvent et sans

aucune garantie. En cas de support défectueux, un autre exemplaire sera délivré par « la société » sur

demande. « La société » décline toute responsabilité découlant d’un dommage direct ou indirect en

relation avec l’utilisation ou l’impossibilité d’utilisation de « le logiciel », y compris les dommages

entraînés par la perte de bénéfices, l’interruption des activités, la perte d’informations et autres, et ce

même si « la société » a été informé de la survenance ou de l’éventualité de tels dommages.

Comme l’acheteur n’achète pas le logiciel, mais une licence d’utilisation, l’éditeur retire sa

responsabilité sur son exploitation




3.2 Les sociétés de service :

Le cas d’une société de service d’ingénierie informatique est différent puisqu’elle offre un service à

son client de type clé en main. Elle est pour des raisons marketing, stratégique et économique dans le devoir

de fournir une prestation qui répond aux besoins du client. Elle a connaissance du contexte de déploiement

du produit puisque c’est l’une des contraintes incontournables pour répondre au mieux à la définition des

besoins élaborés par le client.

Elle ne peut pas, comme l’éditeur, se décharger de sa responsabilité de qualité du produit mais aussi de

qualité de la réponse donnée au cahier des charges émis par son client.

Elle va émettre un contrat allant dans ce sens et définissant les actes auxquels elle s’engage ainsi que les

limites de sa prestation. Elle va donc par ce contrat se protéger face aux exigences évolutives du client mais

aussi permettre au client d’exiger la prestation et la qualité mis en avant par son fournisseur.

Le client va donc s’appuyer sur une norme devenue incontournable dans le monde des grands comptes qui est

la norme ISO9000. Cette norme définie une qualité de travail, une méthode, une traçabilité ainsi que des

métriques permettant de mesurer la qualité de la prestation offerte et les actions a mener au niveau des deux

partenaires pour atteindre le niveau de satisfaction proposé à la signature du contrat.

Le client pourra également s’appuyer sur un autre document fourni par la SSII pour exiger les conditions

définis au contrat qui est le PAQ : Plan d’Assurance Qualité. Ce PAQ définit précisément le périmètre

d’intervention du fournisseur et leurs délais mais aussi les obligations et les devoirs de chaque partenaire. Il

définit les limites de l’intervention de l’une ou l’autre des parties. Et permet donc de justifier les surcoût ou

les actions à mener pour les éviter.

La société de service peut par exemple fournir une prestation supplémentaire d’accompagnement à

l’élaboration d’une plate-forme de tests client ou au déploiement et formation des utilisateurs du client dans

les cas les plus complexe ou si le client ne l’a pas inséré dans son contrat.

Ainsi des sociétés émettent dans leur PAQ des métriques sur la base des quels le client peut exiger en accord

avec son fournisseur de définir des pénalités en cas de dépassement de seuils préalablement définis.




Exemple : A l’encontre des Prestataires : respect des indicateurs qualité Les fiches techniques ci-après décrivent en détail chacun des indicateurs retenus pour le projet, ainsi que les

actions à déclencher et à prendre en cas de non - respect.

Indicateur RDL RESPECT DES DELAIS DE LIVRAISON DES LIVRABLES

Objectif Respecter les délais de livraison des livrables (documentaires , logiciels).

Mode de calcul RDL – Ecart dates réelles / prévues inférieur ou égal à 5j

Action Analyse des causes et actions correctives

Pénalité

Indicateur RCM RESPECT DES CONTRAINTES ET DES METHODES

Objectif Respecter les méthodes et outils de gestion de projet du logiciel de développement utilisé et les contraintes du produit

Mode de calcul RCM - Pour chaque thème , respect O/N

Action Prise en compte des remarques par les Prestataires, avec correction sous un délai de 5 jours

Pénalité

Dans cette exemple la mise en œuvre des pénalités applicables par le maître d’œuvre dans le cas de non –

respect des facteurs qualité, dans le cas où le Prestataire est seul responsable, reste à préciser par rapport au

contrat négocié. La négociation et la mise au point du contrat est primordiale et nécessite de passer un temps

important pour le bon déroulement du projet.

Indicateur RDC RESPECT DES DELAIS DE CORRECTION

Objectif Respecter les délais de correction des anomalies logicielles

Mode de calcul RDC - Anomalie bloquante corrigée sous 24h , les autres types d’anomalies sous 48h

Action Analyse des causes et actions correctives

Pénalité




3.3 La norme ISO 9000 :

La norme ISO 9000 définit une méthode de travail basé sur une documentation importante des échanges et de

la traçabilité du travail effectué. Elle est la base de toutes sociétés soucieuses de promouvoir la qualité de

services et de produits.

Définition de la norme ISO :

Un document normatif, élaboré selon des procédures consensuelles, approuvé par les membres de l'ISO et les

membres (P) du comité responsable, conformément à: la Partie 1 des Directives ISO/CEI, en tant que projet

de Norme internationale et/ou de projet final de Norme internationale, et publiée par le Secrétariat central de

l'ISO.

Le but de cette norme est de donner au client une garantie sur le produit ou le service offert par son

fournisseur et d’avoir un recours en cas de litige. Elle définit tous les états du processus de conception mais

aussi l’assurance que l’entreprise répond à une politique qualité en ce qui concerne son organisation.

Deux parties sont donc définies :

• Le produit fabriqué.

• L’organisation et le management.

C’est une définition internationale de la norme ISO que nous allons présenter dans le but de mettre en

évidence l’importance de ce précieux sésame dans un contrat.

Cette norme ISO est un document ratifié par 130 pays contenant la définition d’un processus de fabrication et

les règles techniques à respecter dans le but d’une harmonisation mondiale du produit. Cette harmonisation

permet l’accessibilité du marché à tous et un essor dans tous les pays adhérents à cette norme.

Ainsi l’épaisseur des cartes téléphoniques et autres cartes de paiement répondant à la norme ISO permet une

utilisation mondiale. Cette norme permet de simplifier la vie de l’utilisateur puisqu’il n’est pas nécessaire de




posséder une carte par pays, d’accroître la fiabilité puisque les machine recevant ces cartes répondent

également à la norme.

L' ISO est une organisation non gouvernementale, créée en 1947. Elle a pour but de favoriser les échanges

entre les pays par des accords techniques fournissant un cadre de travail pour les technologies mondialement

compatibles. Elle fournit une méthode de la qualité des produits et service ce qui est un facteur primordiale

de compétitivité des entreprises qui l’applique.

L’ensemble des 5 critères suivant donne l’assurance qualité :

• la confiance du client,

• répondre exactement à ses besoins et attentes,

• améliorer de la performance,

• obtention d’une meilleure rentabilité de l'entreprise

• améliorer de l'accès au marché.

La norme ISO définit la qualité comme étant les exigences du client en terme de service et de normes de

produit. Elles incitent donc les entreprises à répondre aux exigences du client pour être obtenir cette

certification.

Cette certification ISO 9000 est obtenue, par une entreprise, si elle répond aux 20 conditions suivantes

(extraits du site : http://www.essi.fr/~hugues/GL/) :

• Responsabilité de la direction

• Système Qualité

• Revue de contrat

• Maîtrise de la conception

• Maîtrise des documents

• Achats

• Maîtrise du produit fourni par le client

• Identification et traçabilité

• Maîtrise du processus




• Contrôle et essais

• Maîtrise des équipements de contrôle, de mesure et d'essai

• Etat des contrôles et essais

• Maîtrise du produit non conforme

• Actions correctives et préventives

• Manutention, stockage, ...

• Enregistrements relatifs à: la qualité

• Audits qualité internes

• Formation

• Prestations associées

• Techniques statistiques

Ces 20 conditions montrent l’impact psychologique et la qualité du travail qu’est en droit d’attendre le client.

Il démontre le degré d’organisation d’une entreprise certifié.

Le schéma suivant montre clairement cette contrainte et la nécessité de l’appliquer au quotidien pour garder

cette certification qui est remis en cause tous les ans.




Schéma 7.2 : Schéma récapitulatif de la mise en œuvre d’une norme ISO




La norme ISO se décline en trois normes spécifiques internationales et ont évoluées avec le besoins des

entreprises. Au départ elles étaient tournées vers les entreprises manufacturieres elles ont évoluées pour

répondre autres entreprises tel que le service.

ISO 8402 en 1994 : Management de la qualité et assurance de la qualité. Vocabulaire

La norme définit les termes fondamentaux utilisés dans les diverses autres normes de la famille ISO 9000

afin de pouvoir éviter tout malentendu lors des communications internationales.

ISO 9000-1 en 1994 Norme pour le management de la qualité. Partie 1 : Ligne directrice pour leur sélection

et utilisation.

La norme clarifie les principaux concepts relatifs à la qualité et fournit des conseils pour la sélection et

l'utilisation des Normes internationales de la famille ISO 9000.

ISO 9000-2 en 1997 Normes pour le management de la qualité et l'assurance de la qualité - Partie 2: Lignes

directrices pour l'application de l'ISO 9001, l'ISO 9002 et l'ISO 9003

Cette norme a pour objectif d'aider à l'interprétation et à l'application de ISO 9001, ISO 9002 et ISO 9003.

ISO 9000-3 en 1997 Normes pour le management de la qualité et l'assurance de la qualité - Partie 3: Lignes

directrices pour l'application de l'ISO 9001:1994 au développement, à la mise à disposition, à l'installation

et à la maintenance de logiciel.

Cette norme a pour objectif de pouvoir appliquer la norme ISO 9001 au développement de logiciels.

ISO 9000-4 en 1993 Normes pour la gestion de la qualité et l'assurance de la qua lité - Partie 4: Guide de

gestion du programme de sûreté de fonctionnement

Cette norme est une liste de conseils en matière de planification, d'organisation et de maîtrise des ressources

afin de fabriquer des objets fiables et maintenables.

ISO 9001 en 1994 : Systèmes qualité - Modèle pour l'assurance de la qualité en conception, développement,

production, installation et prestations associées




Cette norme établit les exigences relatives à une organisation dont les activités vont de la conception et du

développement à la production, à l'installation et aux prestations associées.

ISO 9002 en 1994 : Systèmes qualité - Modèle pour l'assurance de la qualité en production, installation et

prestations associées

Cette norme est identique à la norme ISO 9001 sauf qu'elle ne prends pas en compte la partie conception /

développement.

ISO 9003 en 1994 : Systèmes qualité - Modèle pour l'assurance de la qualité en contrôle et essais finals

Norme sur les exigences à utiliser pour démontrer uniquement l'aptitude de l'entreprise à maîtriser son

produit ou service en contrôle et essais finals.

ISO 9004-1 en 1994 : Management de la qualité et éléments de système qualité - Partie 1: Lignes directrices

Cette norme fournit des conseils concernant le management de la qualité et les éléments du système qualité

permettant de répondre aux besoins des clients et de l'organisation.

ISO 9004-2 en 1991 :Gestion de la qualité et éléments de système qualité - Partie 2: Lignes directrices pour

les services

Cette norme est conçue de manière analogue a l'ISO 9004-1 excepter le fait que l'ISO 9004-2 ne s'applique

qu'au secteur du service.

ISO 9004-3 en 1993 : Management de la qualité et éléments de système qualité - Partie 3: Lignes directrices

pour les produits issus de processus à caractère continu

Cette norme donne les lignes directrices pour l'application du management de la qualité aux produits issus de

processus à caractère continu.

ISO 9004-4 en 1993 : Gestion de la qualité et éléments de système qualité - Partie 4: Lignes directrices pour

l'amélioration de la qualité




Cette norme fournit des lignes directrices en matière de management, destinées à la mise en œuvre, au sein

d'un organisme, d'une amélioration continue de la qualité au moyen d'outils et de techniques fondés sur la

collecte et l'analyse de données.

Cette évolution est l’extension de la famille ISO montre l’intérêt portée à cette norme tant par le client que

par les fournisseurs. Elle apporte une trame à l’organisation de l’entreprise et à son évolution. Elle apporte

également la base d’une règle internationale à laquelle le client trouve tout son intérêt face à son besoin et à

la nécessité d’obtenir ce pourquoi il a fait appel à une société extérieur.

L'ISO est une organisation non gouvernementale, créée en 1947. Une autre norme élaborée dans les années

70 spécialement pour l’élaboration de logiciels n’a pas connu le même impact. Cette norme est tournée vers

la société fournissant une prestation et à pour but de définir un niveau de l’organisation de l’entreprise. Ce

niveau permet à celle-ci d’évoluer d’un niveau 1 à cinq. Mais cette dernière norme ne sera pas détaillée

puisqu’elle ne concerne que très peu les relations client/fournisseur.

___________________________________________________________________________ 1 Le CMM a été introduit en 1986, il s'appelait alors Process maturity model. Aujourd’hui un autre modèle voit le jour : le Personnal Software Process qui permet à chaque ingénieur de s’améliorer personnellement contrastant en cela avec le CMM qui vise lui à l’amélioration globale de l’organisation. Des résultats récents prouvent que l’utilisation du PSP contribue à l’amélioration de la qualité et de la productivité globale.




VIII CONCLUSION

Aujourd’hui, grâce aux efforts de chercheurs, de nombreuses techniques sont nées avec un seul

leitmotiv : la mise en évidence de défauts, aussi fins soient-ils. De plus, les méthodes de développement

tendent à intégrer les aspects contrôle et test et à proposer des cadres de développement conduisant à des

logiciels présentant une meilleure maintenabilité et une meilleure testabilité. Tous ces efforts tendent à

renforcer le niveau d’industrialisation des logiciels.

Progressivement, le processus de contrôle et de test peut être formalisé, son couplage avec le processus de

développement réalisé et étendu aux processus de gestion du projet, des configurations, des risques et de

maintenance.

Les méthodes, techniques et outils que nous avons présentés sont pour la plupart opérationnels, mais leur

intégration au sein d’un projet nécessite un effort important. Une méthode de développement clairement

définie est un préalable à la mise en place d’un processus de contrôle et de test. Le processus de contrôle et

de test doit se caler sur une base stable, une déviation au niveau des standards de production induisant

directement des adaptations plus ou moins importantes au niveau du contrôle et du test, car nous avons vu

que les dépendances avec le processus de développement étaient fortes.

La mise en place d’un processus de contrôle et de test induit le choix de techniques, d’outils, des modes

d’organisation, ainsi qu’une formalisation claire des principes méthodologiques retenu. Un plan de

formation, des expériences pilotes et une estimation du cout des projets sera à prendre en compte, au même

titre que la conception ou le codage.

La plupart des entreprises emploient les méthodes de tests comme une manière d'identifier et corriger les

erreurs. Bien que ce soit le but principal du processus de test, il est bien trop limité. Les tests devraient

également être employés pour assurer la qualité et pour modifier le processus à travers la rétroaction, de sorte

que les erreurs soient évitées, plutôt qu'être corrigées.




L’objectif primordial des tests devrait être de s'assurer que les erreurs n’évoluent pas ou que les erreurs

récurrentes ne se reproduisent plus. Cela est réalisable non seulement en identifiant et en corrigeant les

erreurs mais également en détectant les causes de base de ces erreurs. Si la cause de base des anomalies est

une question de spécifications incorrectes ou incomplètes, il faut employer la rétroaction pour modifier le

processus de recueil des besoins ou le processus de révision des besoins. Si la cause de base de beaucoup

d’anomalies semble provenir des erreurs de programmation, il faudrait modifier le processus pour inclure ou

renforcer des vérifications de code, des check-lists de révision de code, ou programmer des vérifications

supplémentaires pendant la phase d'implémentation.

Pour obtenir le maximum de profit des méthodes des tests, les règles suivantes sont à respecter :

§ Détecter les causes de base des erreurs identifiées

§ Modifier le processus de développement de logiciels afin d’éliminer ou de réduire au

minimum les causes d'erreurs

§ Mesurer l'efficacité de la modification du processus.

Il est important de souligner que les données industrielles indiquent que seulement 50% de toutes les erreurs

sont identifiées pendant les tests. Le reste sera constaté à l'utilisation du logiciel fourni. Afin d’assurer de

bonnes relations clientèle et de produire des logiciels de qualité, le centre d’intérêt de la phase de test devrait

être l’élimination des causes de base des erreurs. L'utilisation de la phase de test simplement pour corriger les

erreurs est une perte de temps et une occasion manquée d'améliorer l’ensemble du processus de conception

du logiciel.

De plus, les entreprises doivent placer le s tests en perspective. Une erreur courante dans des projets de taille

est de diminuer le temps alloué aux tests. Malheureusement, la plupart des projets de conception de logiciels

finissent en retard. Echéance après échéance, les managers projet commencent à regarder l’étape de tests

comme une activité qui peut être éliminée ou raccourcie pour faire avancer le projet plus vite. Mais, comme

mentionné ci-dessus, la phase de tests identifie, corrige, et élimine les causes des erreurs. Évidemment, si on

diminue le temps de test, le nombre d'erreurs restantes augmente. Quand des erreurs qui ont été omises dans

la phase de test sont trouvées, peut-être pendant la maintenance, l'occasion d'éliminer les causes de base est




perdue. L’élimination du temps de test diminue seulement la qualité et non pas le délai de livraison. Les

erreurs seront toujours là et elles nécessiteront d’être réparées avant que les utilisateurs n’acceptent le

logiciel.

Les tests des logiciels:

§ Ils sont une partie essentielle du processus de développement. Ils réduisent l'impact et le coût

des erreurs en les identifiant et en les corrigeant avant que le système ne devienne opérationnel

§ Ils attestent que les spécifications du contrat sont respectées et placent les bases de

l’acceptation

§ Ils devraient être exécutés tout au long du cycle de vie

§ Ils peuvent inclure le contrôle de l'adéquation du logiciel, d’un module ou d’un système par

rapport aux spécifications fonctionnelles et d'exécution

§ Ils indiquent si le logiciel emploie les ressources hardware efficacement, respecte les normes

et peut être utilisé efficacement par ses utilisateurs prévus

Les métriques de test sont très utiles car elles permettent de quantifier l’activité et prédire le nombre

d’anomalies à détecter. C’est en se basant sur la connaissance du passé que l’on va pouvoir prédire le futur.

Pour être utilisables et cohérentes, il faut qu’elles soient constamment tenues à jour. Pour cela, on utilise des

outils de tests qui facilitent l’alimentation du référentiel servant aux estimations.

Le logiciel doit être évalué à des intervalles constants pendant et après le développement pour déterminer s'il

fonctionne comme prévu.

Deux types de performances sont prises en compte à l’évaluation du logiciel: la validation et la vérification.

Pour la validation on se pose la question de savoir si le logiciel créé est le bon. Répond-il aux exigences

établies dans les phases initiales du projet? La vérification détermine si le logiciel a été conçu selon les

spécifications. En effet, on peut concevoir un bon système sans pour autant concevoir LE bon. En d'autres

termes, le logiciel peut être vérifié mais pas validé. En définitive, le système doit répondre aux deux critères:

être construit selon les spécifications et être utile.




Il convient de noter que le test d’acceptation par les utilisateurs devrait être une simple formalité, car les vrais

tests devraient avoir été réalisés pendant les phases de tests de l'intégration et du système.

Pour être efficace dans les opérations de tests, il est impératif de disposer de personnel qualifié, d’outils

adéquats et d’un processus de tests bien rodé. Si ces conditions constituent une barrière, on peut toujours

sous -traiter les tests à des experts. Tout dépend à combien on évalue le coût d’une erreur rapportée aux

clients… ou même, la réputation du prestataire!




ANNEXES




Glossaire Abstraction Faculté des humains de se concentrer sur l’essentiel et d’oublier les détails.

Parfois employé comme synonyme de classe.

Abstraite Se dit d’une classe qui ne peut pas être instanciée directement.

Acteur Classe de personnes ou de systèmes qui interagissent avec un système. Objet

toujours à l’origine d’une interaction.

Action Opération élémentaire et instantanée, utilisée pour décrire le comportement

d’un classe.

Agent Objet qui peut être origine et destination d’un interaction.

Algorithme Enchaînement des actions nécessaires à une tâche.

Analyse Activité qui consiste à spécifier ce que devra faire le système. Elle précède

l’activité de conception.

Attribut Type d’information élémentaire faisant partie de la structure d’une classe.

Cahier des charges Doc ument qui fixe les obligations réciproques du client et de son fournisseur et

qui contient les caractéristiques que doit présenter un produit en cours d’étude

ou de réalisation.

Classe Description abstraite d’un ensemble d’objets ; réalisation d’un type.

Classification Action d’ordonner dans le but de comprendre.




Clé Tuple d’attributs qui réalisent la restriction d’une association.

Client Objet à l’origine d’une requête.

Collection Terme générique désignant tous les regroupements d’objets sans préciser la

nature de regroupement.

Couche Segmentation horizontale des modèles.

Cycle de vie Etapes du développement et ordonnancement des étapes.

Dépendance Relation d’obsolescence entre deux éléments de modélisation.

Domaine Champ d’application.

Encapsulation Technique consistant à réunir dans le même objet des informations et des

actions de transformation de ces information.

Entité Ensemble d’objets informationnels sur lesquels on peut reconnaître la même

structure et qui sont gérés de même façon. Une entité correspond à un concept

global d’information qui a une sens dans le domaine considéré.

Flot de données Description des données qui transitent d’un objet vers un autre objet.

Gestion de version Enregistrement de l’histoire d’un élément.

Héritage Relation entre classes qui permet le partage de propriétés définies dans une

classe ; principale technique de réalisation de la généralisation.

Instance Une entité créée à partir d’un classificateur.




Itération Action de traverser une collection d’objets.

Modèle Représentation simplifiée d’un système, mettant l’accent sur un ou plusieurs

aspects essentiels.

Objet Entité atomique constituée d’un état, d’un comportement et d’une identité ; un

objet est une instance d’un classe.

Paquetage Elément d’organisation des modèles.

Persistance Qualité d’un objet à transcender dans le temps ou l’espace.

Phase Ensemble des activités entre deux points de contrôle d’un processus de

développement.

Polymorphisme Concept de la théorie des types, selon lequel un nom peut référencer des objets

instances de plusieurs classes regroupées dans une hiérarchie de généralisation.

Processus Suite d’étapes, plus ou moins ordonnées, visant à satisfaire un objectif.

Prototype Résultat d’un itération ; version partielle d’un système.

Récursivité Application d’un règle à ces propres résultats pour générer une séquence infinie

de résultats.

Risque Elément susceptible de perturber le bon déroulement du développement.

Stéréotype Concept qui permet de définir des types d’éléments ayant des propriétés

particulières.




Temps réel Caractéristique d’un logiciel dont le temps de réponse est compatible avec la

dynamique du système physique.

Test Ensemble des mesures et des activités qui visent à garantir le fonctionnement

satisfaisant du logiciel.

UML Ensemble de modèles permettant de représenter un système informatique et son

utilisation prévue dans l’entreprise.

Workflow Ensemble d’activités organisées de l’entreprise mettant en oeuvre des

communications, des collaboration et des coordinations.

Tests de non régression Pour détecter les erreurs liées à l’intégration d’un nouvel objet et s’assurer que l’application tourne comme avant et donne les mêmes résultats.

Tests des instructions Isoler l’objet ou programme afin de tester et valider les instructions. Tests des conditions Vérifications de tous les cas possibles Tests de revue de code Cela a pour objectif le respect de la sémantique du programme et le respect de

la qualité base sur le respect des normes et standards (cartouches, commentaires, optimisation…).

Tests aux limites Ces tests ont pour objectif de détecter les anomalies du logiciel lors de

l’utilisation de valeurs aux extrêmes. Tests grandeur réelle Mise en charge du système, consiste à détecter les problèmes de

fonctionnement du logiciel dans son environnement d’exécution. Tests d’exploitation Mesure de la fiabilité du système sur une longue période Tests de performance Il s’agit notamment des problèmes liés aux performances (temps de réponses,

débit, …) Tests de surcharge Dégradation des performances par la surcharge Tests négatifs Réaction du système face à des erreurs de manipulation




Tests d’ergonomie Cohérence des Interfaces Homme Machine Tests de recette utilisateur Fait par l’utilisateur pour si le système répond à ses besoins Axiome Proposition admise sans démonstration. Proposition évidente résultant des

principes d’identité et de non-contradiction.

CEI Commission électrotechnique internationale.

Complétude C’est le taux de couverture ou mesure de complétude qui exprime d’une

manière quantitative le degré de satisfaction du critère testé. Elle est calculé en

divisant le nombre des objets couverts par le nombre total des objets que le

critère de test nous impose (que l’on évalue par simple analyse du code source)

ISO Organisation internationale de normalisation.




Bibiliographie

Les ouvrages :

• Le test des logiciels ; écrit par Spyros XANTHAKIS, Pascal REGNIER, Constantin

KARAPOULIOS ; aux éditions Hermes.

• Le Génie Logiciel et ses Applications ; ecrit par I.SOMMERVILLE ; aux éditions

Interéditions.

• Modélisation objet avec UML ; ecrit par Pierre-Alain MULLER et Nathalie GAERTNER ;

aux éditions Eyrolles

Les sites web:

• http://www.essi.fr/~hugues/ Anne -Marie Hugues

• http://www.weblmi.com/ Le monde informatique

• http://www.learningtree.fr/courses/fr313out.htm

• http://phortail.org/webntic/Methodologie_de_test-11.html

• http://www -ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/node7.html

• http://projet-enoch.net/xml/memoire/generated-html/memoire-




PLANNIFICATION




COMPTES RENDU DE REUNIONS




Bordereau de livraison Détail de la livraison :

Fichier(s) Description(s)

Dossier_Projet.doc

Dossier projet de l’étude des methodes de test, réalisé durant l’année scolaire 2003 – 2004, au Concervatoire National des Arts et Métiers de Lille, pour le cours de Travaux Pratique de méthodologie.

Exemplaire manuscrit Version papier du précédant livrable.

Emetteur(s) Réception

Nom(s) Signature(s) Kamel KAOUANE Cornel CRISAN Philippe FIRMIN Olivier VEREMME Date : 14 Janvier 2004

Nom(s) Signature(s) C.RAYNAL G.MOREL Date : 19 Janvier 2004

Réserves éventuelles :

Dossier Projet - caron.nicolas.free.frcaron.nicolas.free.fr/cnam/Projet Methodologie/Methodes de...

Documents

Transcript of Dossier Projet - caron.nicolas.free.frcaron.nicolas.free.fr/cnam/Projet Methodologie/Methodes de...