INTRODUCTION

 Les logiciels deviennent de plus en plus complexes et

important

 Pas de programme sans bug !!!

 Important de tester avant de distribuer sans code

1
EXERCICE
 Soit le programme suivant :

‣ (E1) Lecture de trois entiers entrés par l’utilisateur sur la console

‣ (E2) Les trois entiers représentent la longueur des cotés d’un
triangle
‣ (E3) Le programme affiche si le triangle est :

 (E3.1) scalène (cotés différents)

 (E3.2) isocèle

 (E3.3) équilatéral 5

Combien faut-il de tests pour tester correctement ce programme ? 2

RÉPONSE

3
QU’EST CE QU’UN TEST

« Le test est l’exécution ou l’évaluation d’un système ou

d’un composant du système, par des moyens automatiques
ou manuels
1. pour vérifier qu’il répond à ses spécifications, ou
2. pour identifier les différences entre les résultats attendus et
les résultats obtenus »

IEEE STD 729 - Standard glossary of software engineering

L’art et la manière de
trouver les bogues 4
 Pourquoi
QU’EST CE QU’UN TEST

Condition de test

 Que cherche-t-on à évaluer ?

 (raison, objectif du test)

 Que faut-il examiner pour cela ?

 (quel est l’objet sous test ?)

 Par rapport à quoi ?

5
 (quelle est la référence ?)
QU’EST CE QU’UN TEST Quoi

Cas de test

 Une instance détaillée de la condition de test qui

définit :
 Les données d’entrées

 Les préconditions (conditions préalables

nécessaires au démarrage du test)

 Les postconditions (conditions assurées après

l’exécution du test)
6
 Comment
QU’EST CE QU’UN TEST

Procédure de test

 Une réalisation pratique du cas de test

 Automatique (scripts) ou
 Manuelle (actions humaines)

7
QU’EST CE QU’UN TEST
Avec quoi

Outils et environnements de test

Exécution
 Machines dédiées au test, machines virtuelles
 Framework de tests : CPPUNIT, GOOGLE TEST
 Outils d’analyse statique : CPPDEPEND, UNDERSTAND,
 Outils d’analyse dynamique : VALGRIND, GPROF

Conception
 Gestionnaires de tests et d’exigences : CALIBER, ...
 Gestionnaire de revues
 Outils de modélisation

Implémentation
 Créateur 8
automatique de test
 Oracles, comparateurs
PRINCIPE DE BASE DE TEST

  Indépendance Tester au plus tôt et au plus près

testeurs / développeurs des causes d’erreur

Harmonie avec le
Résultats prouvés et
développement
reproductibles

Effort conforme aux risques Automatisation

acceptés sur le projet

9
TYPES DE TESTS

10
TI : PRÉSENTATION

 les tests d’intégration représentent la partie “technique”

des tests métier. Ainsi, les tests d’intégration se
focaliseront sur le fonctionnement et les aspects
techniques de l’assemblage des différents composants ;
ils n’entreront pas dans le détail du fonctionnel.

11
TI : OBJECTIFS
 4 objectifs :

 La construction progressive du logiciel à partir des

composants déjà testés de manière unitaire.

 La vérification que le composant intégré fonctionne bien avec

les autres ( tests fonctionnels)

 L’intégration de l’application avec les autres applications du

Système d’Information
12
 La vérification des choix techniques (tests techniques)
TESTS D’INTÉGRATION

 Objets sous test

 Selon la granularité du test :
 plusieurs composants : fonctions ,méthodes , ,classes , modules,
 un composant et son environnement : système de fichiers, autres systèmes,

matériel, ...
 Tous types
 Référence
 Spécifications et document de conception générale ou d’architecture du
système

13
TESTS D’INTÉGRATION

Pré-conditions
 Composants disponibles, compilés et exécutables dans l’environnement de test
 succès les tests unitaires

 Références sont disponibles et suffisamment stables

Posts-conditions
 Composants intégrés les un aux autres
 Défauts dans les interfaces et/ou les échanges identifiés, tracés et priorisés

 Corrections vérifiées

 Impacts des défauts non corrigés évalués

 Couverture recherchée atteinte

 Traçabilité des résultats avec le référentiel assurée 14

 TESTS D’INTÉGRATION

Conception et implémentation

 Intégration des composants dépendante de l’architecture du système

 Différentes méthodes d’intégration : bottom-up, top-down,

 Isolation

 Préparation des données

Testeurs

 les développeurs fournissent les composants aux testeurs qui réalisent l’intégration
 Conçoivent, implémentent et exécutent les tests sur une plateforme d’intégration

 S’appuient sur une infrastructure d’intégration 15

ARCHITECTURE DES DÉPENDANCES

16
TI : APPROCHES CLASSIQUES

 Big-Bang : non recommandé

 De haut en bas (top-down)

 De bas en haut (bottom-up)

 Mixte

17
APPROCHE BIG-BANG

(+)Intégration de tous les composants à tester en une seule

étape. (intégration massive)

(+)Intégration rapide, utilisation privilégiée dans les petits

projets.

(-)Inadapté pour les projets importants : risque de se perdre

suite à un nombre important de modules à intégrer. Perte
d’efficacité.
18
APPROCHE DESCENDANTE

19
APPROCHE DESCENDANTE

20
APPROCHE DESCENDANTE

21
APPROCHE DESCENDANTE

22
APPROCHE DESCENDANTE

 Création de bouchons
 Test tardif des couches basses

 Détection précoce des défauts d'architecture

 Effort important de simulation des composants absents et

multiplie le risque d’erreurs lors du remplacement des
bouchons.
 La simulation par « couches » n’est pas obligatoire

23
APPROCHE ASCENDANTE

24
APPROCHE ASCENDANTE

25
BOTTOM-UP

26
APPROCHE ASCENDANTE
 Avantages
 Faible effort de simulation
 Construction progressive de l'application s'appuie sur les modules
réels. Pas de version provisoire du logiciel
 Les composants de bas niveau sont les plus testés,
 Définition des jeux d'essais plus aisée
 Démarche est naturelle.

 Inconvénients
 Détection tardive des erreurs majeures
 Planification dépendante de la disponibilité des composants

27
 La simulation par « couches » n’est pas obligatoire
APPROCHE MIXTE
 Combinaison des approches descendante et ascendante.

 Avantages :
 Suivre le planning de développement
 Prise en compte du risque lié à un composant

 La principale difficulté d’une intégration mixte réside

dans sa complexité car il faut alors gérer intelligemment
sa stratégie de test afin de concilier les deux modes
d’intégration : ascendante et descendante
28
APPROCHE MIXTE

29
EXEMPLE
 On peut effectuer des testes d’integration avec Maven et
Junit sur du code en JAVA.

 On doit séparer ces tests du service interne de

l'application. Cette séparation dans JUnit Test, est
appelée "catégorisation", en utilisant l'annotation
@Category.

30
31
32


33
CONCLUSION

34