Département Génie Informatique

Test Logiciel
Pr. Aimad QAZDAR
a.qazdar@uiz.ac.ma

28 novembre 2022
Pourquoi tester un logiciel ?
● Le test est une activité importante dont le but est d’arriver à un produit « zéro défaut ».
● C'est la limite idéaliste vers laquelle on tend pour la qualité du logiciel.
● Généralement 40% du budget global est consacrée à l’effort de test.

2
Pourquoi tester un logiciel ?
● Spatial - Juin 1996 :
− En 4 juin 1996, la fusée Ariane 5 s’explose après 37s de vol :
− Erreur de conversion entre données numériques!
− $370 Millions de dégâts!
● Transport — septembre 1998 :
− La ville de Dublin connaît un embouteillage monstrueux parce que la mise à jour du système
de feux tricolores a abouti à la déconnexion de 140 carrefours.
● Défense — mars 2002
− 3 soldats américains sont tués et 20 autres sont grièvement blessés parce qu’un tir a été mal
positionné par un système d’arme
● Médical - avril 2008
− Au Royaume Unis, le National Program for IT (NPfIT) révèle que, depuis 2005, environ 300
incidents ont mis des patients en danger lors d'utilisation d’appareils médicaux informatisés.

3
Pourquoi tester un logiciel ?
● Banque - juillet 2009
− Démantèlement d’un réseau international de fraude à la carte bancaire ayant réalisé plus de
35.000 transactions frauduleuses d'un montant total d'environ 6,5 millions d'euros.
● Informatique — il n'y à pas très longtemps
− Le PC que l’on doit rebouter parce qu’une application l’a bloqué ou que le système
d'exploitation a un bug.
● Télécommunications — hier ou avant-hier
− L’appel que l’on doit recommencer parce que la conversation a été interrompue inopinément

4
Plan

Introduction

Processus de test

Types de test

Activité tests

Jeu de tests

Principes de test

Outils de test

5
Introduction
Introduction
● L’erreur est humaine, presque tous les programmes contiennent des erreurs
● Les erreurs sont difficiles à identifier:
− Grande complexité des logiciels
− Invisibilité du système développé
− Pas de principe de continuité
− La différence entre l’environnement de développement et de production...
● L’activité de test est essentielle au développement de logiciels de qualité
● lorsque les tests sont correctement réalisés et utilisés, ils permettent de découvrir des
erreurs.
● Ainsi, il est possible de mesurer la qualité des logiciels en termes de défauts trouvés.

7
Introduction
● Les tests représentent une partie
importante du développement:
− Jusqu’à 33% du budget
− Jusqu’à 27% du temps de
développement

8
Quelque definitions
● Le test est « l’exécution ou l’évaluation d’un système ou d’un composant par des moyens
automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les
différences entre les résultats attendus et les résultats obtenus »
IEEE (Standard Glossary of Software Engineering Terminology)
● Le test est « une technique de contrôle consistant à s'assurer, au moyen de son
exécution, que le comportement d'un programme est conforme à des données
préétablies ».
AFCIQ : Association Française pour le Contrôle Industriel et la Qualité
● Tester, « c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des
défauts »,
G. Myers (The Art of Software testing)

9
La chaîne de l’erreur
● Les défauts présents dans les logiciels
proviennent d’erreurs humaines qui sont
le fait de méprises sur la compréhension
ou l’interprétation des spécifications ou
encore d’erreurs de réalisation lors du
codage ou également d’oublis lors des
phases de conception.
● Un défaut ne conduit pas
systématiquement à une défaillance, au
contraire, il est fréquent qu’un logiciel se
comporte correctement alors qu’il contient
un grand nombre de défauts mais qui ne
sont jamais exercés en fonctionnement .

10
La chaîne de l’erreur
● Une défaillance provient d’un défaut de
réalisation ou de conception du logiciel,
qui suite à une exécution du code impliqué
engendre un comportement fautif.
● Une suite de défaillances peut entraîner
une panne du logiciel ou du système.

11
La chaîne de l’erreur
● Défaillance vs une panne.
● Une défaillance se caractérise par des
résultats inattendus (calculs erronés,
fenêtre mal placée, message non affiché,
etc.) ou un service non rendu (données non
stockées dans une base, fenêtre non
ouverte, etc.); cependant le logiciel peut
continuer malgré son fonctionnement
anormal.
● Une panne se caractérise par un arrêt
total ou partiel du logiciel qui conduit à
un fonctionnement en mode (très) dégradé.
La seule manière de sortir de ce mode est
de redémarrer le logiciel ou le système
avec toutes les conséquences que cela
peut avoir.

12
La chaîne de l’erreur
● Les erreurs peuvent être de divers ordres.
● Il peut s'agir d'erreurs :
− de calcul
− de logique
− d'entrée / sortie
− de traitement des données (dépassement de tableau)
− d'interface (communication entre les programmes)
− de définition des données
● Ces erreurs représentent 90% des cas décelés.

13
La chaîne de l’erreur
1. Erreur – mauvaise configuration des rails
2. Défaut – le chauffeur du train constate le problème et signale une alarme
3. Défaillance – les passagers du train n’arrivent pas à leur destination (ou pire, sont
blessés ou sont morts!)

14
Processus de test
Processus de test
● Un module n'est pas un programme isolé.
● Il sera souvent nécessaire de mettre en place (simuler) un environnement pour tester
unitairement un composant.
● Ceci représente une charge supplémentaire de développement, qui doit être planifiée, car
l'environnement mis en place pour chacun des composants à tester unitairement ne fait
pas partie de la livraison.

16
Processus de test

Données de test Pilote Résultats

Interface
Oracle

Module à tester

Souche Souche Souche

17
Processus de test
● Le rôle du pilote est de :
− Lire les données de test
− Les passer au module à tester
− On compare le résultat obtenu à la prédiction de l’Oracle (verdict)
● Les souches simuleront la logique de comportement. En général elles se contenteront de
retourner une valeur fixe conforme aux paramètres passés.
● Le rôle de l’oracle est de présenter les résultats attendus de l’exécution (verdict)

18
Processus de test
● Spécification: Trier un tableau par ordre croissant sans doublon
● Choisir un scénario à exécuter (cas de test)
− S1: Un tableau est vide
− S2: Un tableau contient des doublons
− S3: Un tableau ne contient pas de doublons
● Estimer le résultat attendu (oracle)
− O1: le résultat est un tableau vide
− O2: le résultat est un tableau trié par ordre croissant sans doublon
− O3: le résultat est un tableau trié par ordre croissant sans doublon

19
Processus de test
− Interface : int[] mon_tri(int[] vec)
● Etape 1 : On choisit un cas test (CT) à exécuter (un tableau non vide de N entiers sans
doublons)
● Etape 2 : On concrétise le cas test en lui fournissant des données
de test (DT): Le tableau [1,0,12,4,43,5,21]
● Etape 3 : On indique le résultat que l’on attend pour ce CT (prédiction de l’Oracle):
[1,0,12,4,43,5,21]  [0,1,4,5,12,21,43]
● Etape 4 : On exécute le pilote (script de test testant le CT sur les DT)
● Etape 5 : On compare le résultat obtenu à la prédiction de l’Oracle (verdict)
● Etape 6 : On rapporte le résultat du test : succès / échec

20
Processus de test

succès / échec Oracle

verdict [0,1,4,5,12,21,43]

Pilote
DT:[1,0,12,4,43,5,21]
(Script de test) Résultats

int[] mon_tri(int[] vec)

Trier_tableau
Cas de test: trier un tableau de 7 entiers

21
Processus de test
public class Produit { import static org.junit.Assert.*;
/* Methode produit. */ import org.junit.Test;
public double produit(double a, double b){
double p = a*b; public class TestProduit {
return p;
} @Test
public void test() {
} double a=5;
double b=2;
double expected=10;
Produit p=new Produit();
double res = p.produit(a,b);
assertEquals(expected,res,0.0001);
}
}

22
Types & Classes de test
Classification des tests
● Il existe différentes façons de classifier les tests.
● Il est possible de les regrouper selon
− Mode d’exécution,
− Modalités,
− Méthodes,
− Niveaux,
− Caractéristiques.

24
Classification des tests : Mode d’Execution
● Test Manuel
− Les tests sont exécutés par le testeur.
− Il saisie les données en entrée, vérifie les traitements et compare les résultats obtenus avec
ceux attendus.
− Ces tests sont fastidieux et offrent une plus grande possibilité d’erreurs humaines.
− Ces tests sont très vite ingérables dans le cas des applications de grandes tailles.
● Test Automatique
− L’automatisation des tests est « l’utilisation de logiciels pour exécuter ou supporter des
activités de tests, par exemple ; gestion des tests, conception des tests, exécution des tests
ou vérification des résultats.».
− JUnit par exemple dans le monde Java.

25
Classification des tests : Modalités de Test
● Statiques : Les tests sont réalisés par lecture du code dans le but de trouver des erreurs
(par l'humain ou par machine, ).
− Inspection ou d’une revue de code;
− Un travail de collaboration lors d’une réunion (le programmeur, le concepteur, un
programmeur expérimenté, un testeur expérimenté, un modérateur…)
● Dynamiques : On exécute le système de manière à tester l’ensemble des
caractéristiques. Chaque résultat est comparé aux résultats attendus.

26
Classification des tests : Méthodes de Test
● Structurels (Boîte blanche) : Les tests structurels reposent sur des analyses du code
source. Il est possible d’analyser la structure du programme.
● Fonctionnels (Boîte noire) : Les tests fonctionnels reposent sur une spécification du
programme. Le code source du programme n’est pas utilisé.
● Il est parfois utile de combiner ces deux méthodes  « Boite grise »

27
Classification des tests : Niveau de Test

Béta-Tests

Tests de régression

Tests d’acceptation
Tests du système et de
fonctionnement
Tests d’intégration

Tests unitaires

28
Tests unitaires
● Les tests unitaires sont des tests en boîte blanche
● Les tests unitaires sont composé d’un ensemble de classes appelées « classes de test »
● Ces classes valident que des portions de code répondent à un certain besoin
● Les tests unitaires sont importants car ils permettent de détecter le maximum de
défaillance avant les tests en boîte noire et qu’ils peuvent s’exécuter d’une manière
automatique
Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

29
Tests unitaires
● Les tests unitaires ont deux objectifs : « couverture de code » et « couverture de
données »
● La couverture du code stipule de tester chaque ligne de code écrite (appel de fonction,
boucles, décisions, décisions multiples,…)
● La couverture des données oriente les tests vers les données (données valides,
données invalides, peu de données, trop de données, etc.)

Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

30
Tests d’intégration
● Exécuté en boîte noire ou boîte blanche
● Les tests d’intégration vérifient que les composants s’intègrent bien avec d’autres
composants ou systèmes
● Les tests d’intégration vérifient aussi que le produit est compatible avec l’environnement
logiciel et matériel du client

Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

31
Tests fonctionnels
● S’exécute en boîte noire
● Vérifie que le produit assure les fonctionnalités spécifiées dans les spécifications
fonctionnelles

Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

32
Tests d’acceptation
● S’exécute en boîte noire
● Les tests d’acceptation sont des tests formalisés par le client, ils sont exigés par le client
pour qu’il accepte le produit

Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

33
Tests système
● S’exécute en boîte noire, s’oriente vers les spécifications non fonctionnelles
● Composé de plusieurs tests :
− Tests de stress : tester le produit au-delà des attentes non fonctionnelles du client.
Par exemple, un système de sauvegarde qui doit tout sauvegarder deux fois par jour,
le tester en mode trois fois par jour.
− Tests de performance : évaluation par rapport à des exigences de performances
données. Par exemple, un moteur de recherche doit renvoyer des résultats en moins
de 30 millisecondes.
− Tests d’utilisabilité : vérifier les exigences d’apprentissage demandées à un
utilisateur normal pour pouvoir utiliser le produit
Béta-Tests
− etc. Tests de régression

Tests d’acceptation
Tests du système et de
fonctionnement
Tests d’intégration

Tests unitaires

34
Tests de non-régression
● Les tests de non-régression sont un sous-ensemble des tests originaux
● Les tests de non-régression vérifient qu’une modification n’a pas eu d’effets de bord sur
le produit
● Les tests de régression sont utiles parce que la réexécution de tous les tests est très
coûteuse

Béta-Tests

Tests de régression

Tests d’acceptation
Tests du système et de
fonctionnement
Tests d’intégration

Tests unitaires

35
Béta-Tests
● Quand un produit est quasiment terminé, il est distribué gratuitement à certains de ses
utilisateurs
● Ces utilisateurs sont appelés testeurs béta
● Ces utilisateurs vont utiliser le produit et reporter tout éventuel disfonctionnement de celui-
ci

Béta-Tests

Tests de régression

Tests d’acceptation

Tests du système et de
fonctionnement

Tests d’intégration

Tests unitaires

36
Positionnement des types de tests

37
Positionnement des types de tests

38
Activité tests
Activité Test
● L’activité tests est un projet à part entière.
● C’est la raison pour laquelle nous retrouvons l’ensemble des caractéristiques d’un projet :
− Planification et contrôle : planification, estimation des charges, définition des métriques,
définition des environnements matériels et logiciels, définition de la campagne, du plan et des
livrables.
− Analyse et conception : organisation du référentiel, identification des conditions de tests,
traçabilité, cas de tests, données de tests, procédures de tests, scénarios.
− Implémentation, suivi, exécution et reporting
− Gestion des configurations, évaluation des risques et gestion des incidents
− Bilan projet et Clôture (recette ou arrêt des tests) et Amélioration des processus

40
Stratégie de test
● Une technique de tests adaptée et puissante restera sans effet si elle ne fait pas partie
d’une stratégie de tests.
● La stratégie de tests vise à rendre l’effort de test efficace en :
− Maximisant les chances de détecter les erreurs.
− Tentant de trouver le plus d’erreurs possibles, le plus rapidement possible.
− Facilitant le diagnostique.
● Une stratégie consiste à définir :
− Les ressources mises en œuvre (équipes, testeurs, outils, etc.)
− Les mécanismes du processus de test (gestion de la configuration, évaluation du processus
de test, etc.)
● La stratégie de tests tient compte :
− Des méthodes de spécification, de conception …
− Du langage de programmation et du type d’application (temps réel, base de données…)
− Des ressources humaines, les délais et budget
− De la criticité du logiciel et du coût de développement
− Etc.
41
Plan Qualité Projet (PQP)
● L’ensemble de la stratégie de tests est détaillé dans le Plan Qualité Projet (PQP).
● Le plan qualité projet est très important.
● Il va notamment :
− Définir l’organisation à mettre en place (équipe de tests).
− Définir les responsabilités et relations entre les différents intervenants.
− Définir les types et les objectifs de tests pour chacun des niveaux (tests unitaires, tests
d’intégration, tests de validation).
− Définir les outils qui seront utilisés.
− Définir les moyens et les délais à investir dans l’activité de tests.

42
Plan de Test
● Le plan de tests est un document obligatoire déterminant le déroulement des tests
durant le projet
● C’est ainsi qu’il existe autant de plan de tests que de phases de qualification du produit.
● De manière générale, les tests se déroulent du général au particulier (détail).
● L’objectif de chaque plan de tests est de fournir un programme pour vérifier que le logiciel
produit satisfait les spécifications et la conception du logiciel.

43
Plan de Test
1. Définir les éléments à tester et l’ordre dans lequel ils doivent être testés.
2. Décrire l’environnement de tests.
3. Définir la façon dont les tests vont être menés : processus exacts à mener, l’historisation,
la traçabilité, le reporting, le suivi, le contrôle...
4. Décrire et constituer les fiches de tests (définir les actions à réaliser, les jeux de
données à utiliser, les valeurs et les comportements attendus). L’ensemble des fiches de
tests constitue le dossier de tests.
5. Fixer les critères d’arrêt des tests : selon la couverture définie, selon le nombre d’erreurs
trouvés, selon le temps imparti, …

44
Plan de tests
● Le plan de tests détermine la priorisation des défaillances
● La priorisation facilite la communication entre développeurs et testeurs ainsi que
l’affectation et la planification des tâches
● Par exemple, une priorisation de 1 à 6 est souvent adoptée:
Priorité Description
1. Fatal Impossible de continuer les tests à cause de la sévérité des défaillances
2. Critique Les tests peuvent continuer mais l’application ne peut passer en mode production
3. Majeur L’application peut passer en mode production mais des exigences fonctionnelles
importantes ne sont pas satisfaites
4. Medium L’application peut passer en mode production mais des exigences fonctionnelles sans
très grand impact ne sont pas satisfaites
5. Mineur L’application peut passer en mode production, la défaillance doit être corrigée mais elle
est sans impact sur les exigences métier

6. Cosmétique Défaillances mineures relatives à l’interface (couleurs, police, …) mais n’ayant pas une
relation avec les exigences du client

45
Rapport de Test
● Pour chaque phase de test l’équipe doit élaborer un rapport de tests.
● Ce rapport est la synthèse des actions menées :
− Exécution des fiches de tests (effectuer les actions décrites).
− Analyser les résultats obtenus : comparer les résultats attendus avec les résultats obtenus.
Les éléments de mesure sont très importants !
− Emettre des fiches de non-conformité si nécessaire (ces fiches sont aussi appelées fiches
d’anomalie, fiches de bug). Il s’agit de coupler intelligemment la gestion des tests et la gestion
des corrections (incidents).
− Consigner tous les résultats d’exécution de tests.
− Rédiger des comptes rendus de tests.
• La somme de ces comptes rendus constituera le rapport de tests.

46
Jeu de test
Tests exhaustifs

● Programme de 50-100 lignes do

if (…) then
− 1boucles(1-20 itérations), 4
if (…) then
conditions imbriquées à l’intérieur
if (…) then
de la boucle else …
− 1014 chemins d’exécution else …
possibles if (…) then
− pour tester tous les chemins à else …
else
raison d’un chemin par
while (i < 20)
milliseconde! ~3170 ans

48
Tests exhaustifs
● L’objet principal est d’analyser le comportement d’un logiciel dans un
environnement donné :
● il ne sert a priori à rien de tester le bon fonctionnement de la gestion du système
de freinage d’une automobile pour une vitesse de 1000 km/h.

49
Tests exhaustifs
● En général, tester un programme de façon exhaustive est impossible
● Il faut choisir un sous-ensemble des tests qui maximise la probabilité de détecter
les erreurs
● Il est possible d’utiliser des tests aléatoires, mais leur efficacité est faible pour
tester le comportement attendu.
● Une meilleure approche: déterminer un ensemble de tests fonctionnels qui seront
complémentés par des tests structurels.

50
Approches des jeux de test
Approches de Test structurel:
− Couverture des instructions, des enchaînements
− Couverture des conditions
− Couverture des conditions multiples
− Couverture des dépendances de données

51
Approches des jeux de test
● Exemple :
− PGCD de 2 nombres
− Précondition: p et q entiers naturels
positifs

-Tester tous les nœuds (les instructions):

(E, B1, P1 , P2, B2, P1 , B4, S)
(E, B1, P1 , P2, B3, P1 , B4, S)
-Tester tous les branches(les décisions):
(E, B1, P1 , P2, B2, P1 , B4, S)
(E, B1, P1 , P2, B3, P1 , B4, S)
-Tester 1-chemin élémentaire:
(E, B1, P1 , B4, S)
-Tester deux chemins élémentaires:
(E, B1, P1 , P2, B2, P1 , P2, B2, P1 , B4, S)
(E, B1, P1 , P2, B2, P1 , P2, B3, P1 , B4, S)
(E, B1, P1 , P2, B3, P1 , P2, B2, P1 , B4, S)
(E, B1, P1 , P2, B3, P1 , P2, B3, P1 , B4, S)
etc.
52
Approches des jeux de test
Approches de Test fonctionnel:
− Couverture de scénarios d’utilisation
− Couverture des partitions des domaines d’entrée
− Couverture des cas limites

53
Approches du jeu de test
● Exemples de Couverture des partitions des domaines d’entrée
● Les entrées est partitionnée en deux groupes :
− Classes d’équivalence valides
− Classes d’équivalence invalides
● Plage de valeurs (ex:1..100)
− Classes d’équivalence valides: 1..100
− Classes d’équivalence invalides:<1, >100
● Nombre de valeurs (ex:3 ou 4 arguments spécifiés)
− Classes d’équivalence valides : {3,4} arguments spécifiés
− Classes d’équivalence invalides: <3 arguments, >4 arguments spécifiés

54
Approches du jeu de test
● Exemples de Couverture des partitions des domaines d’entrée
● Ensemble de valeurs prédéfinies (ex: «auto», «maison», «bateau»)
− Classes d’équivalence valides : chaque valeur est sa propre classe d’équivalence
− Classes d’équivalence invalides : une pour chaque valeur (ex: « moto »
pour « auto »)
● «Doit être» (ex: le 1er caractère doit être une lettre)
− Classes d’équivalence valides : le 1er caractère est une lettre
− Classes d’équivalence invalides : le 1er caractère n‘est pas une lettre

55
Approches du jeu de test
● Exemples de Couverture des cas limites (valeur de marge)
● En pratique, il est souvent bénéfique de tester les conditions de marge
● Plage de valeurs : Écrire un test valide pour la valeur de début et celle de fin, et des tests
invalides pour les conditions juste en dehors de la plage valide
− ex: [-1..1]: tester -1, 1, -1.001, 1.001
● Nombre de valeurs: Écrire un test pour le nombre minimum, le nombre maximum, un de
moins que le nombre minimum et un de plus que la nombre maximum
− ex:1..255 enregistrements: tester pour 0, 1, 255, 256

56
Approches du jeu de test
● 14 cas de test –GJ Myers –«The Art of Software Testing»- 1979
1. Cas scalène valide (1,2,3 et 2,5,10 ne sont pas valides)
2. Cas équilatéral valide
3. Cas isocèle valide (2,2,4 n’est pas valide)
4. Cas isocèle valide avec les trois permutations (e.g. 3,3,4; 3,4,3; 4,3,3)
5. Cas avec une valeur à 0
6. Cas avec une valeur négative
7. Cas ou la somme de deux entrées est égale à la troisième entrée
8. Cas pour le test 7 avec les trois permutations
9. Cas ou la somme de deux entrées est inférieur à la troisième entrée
10. 3 cas pour le test 9 avec les trois permutations
11. Cas avec les trois entrées à 0
12. Cas avec une entrée non entière
13. Cas avec un nombre erroné de valeur (e.g. 2 entrées, ou 4)
14. Pour chaque cas de test, avez-vous défini le résultat attendu ?
http://www.51testing.com/N_download/lib/TestingTechDL/ArtofSoftwareTesting.pdf
57
Approches du jeu de test
● Chacun de ces 14 tests correspond à un défaut constaté dans des implantations de cet
exemple triangle
● La moyenne des résultats obtenus par un ensemble de développeurs expérimentés est
de 7.8 sur 14.
● La conception de tests est une activité complexe, a fortiori sur de grandes
applications

58
Les 7 Principes de test
Les 7 principes généraux des tests
● Un nombre de principes de test ont été suggérés au cours des 40 dernières années et
offrent des indications communes à tous les tests.

60
Les 7 principes généraux des tests
● Principe 1 – Les tests montrent la présence de défauts
Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en
prouver l’absence. Les tests réduisent la probabilité que des défauts restent
cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas
une preuve d’exactitude.
● Principe 2 – Les tests exhaustifs sont impossibles
Tout tester (toutes les combinaisons d’entrées et de préconditions) n’est pas
faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons
l’analyse des risques et des priorités pour focaliser les efforts de tests.
● Principe 3 – Tester tôt
Pour trouver des défauts tôt, les activités de tests devraient commencer aussi tôt
que possible dans le cycle de développement du logiciel ou du système, et
devraient être focalisées vers des objectifs définis.

61
Les 7 principes généraux des tests
● Principe 4 – Regroupement des défauts
L’effort de test devrait être fixé proportionnellement à la densité des défauts prévus
et constatés dans les différents modules. Un petit nombre de modules contiennent
généralement la majorité des défauts détectés lors des tests pré-livraison, ou
affichent le plus de défaillances en opération.
● Principe 5 – Paradoxe du pesticide
Si les mêmes tests sont répétés de nombreuses fois, il arrivera que le même
ensemble de cas de tests ne trouvera plus de nouveaux défauts. Pour prévenir ce
“paradoxe du pesticide”, les cas de tests doivent être régulièrement revus et
révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d’autres
chemins dans le logiciel ou le système de façon à permettre la découverte de
nouveaux défauts.

62
Les 7 principes généraux des tests
● Principe 6 – Les tests dépendent du contexte
Les tests sont effectués différemment dans des contextes différents. Par exemple, les
logiciels de sécurité critique seront testés différemment d’un site de commerce
électronique.
● Principe 7 – L’illusion de l’absence d’erreurs
Trouver et corriger des défauts n’aide pas si le système conçu est inutilisable et ne
comble pas les besoins et les attentes des utilisateurs.

63
Les outils de test
Réalisation des tests
● Capture et réexécution des scripts réalisés via une IHM.
● Sauvegarde des tests et des résultats associés.
● Génération de scripts de tests en fonction des langages et des plateformes
● Outils
− Mercury WinRunner et Quicktest Pro de Mercury Quality Center
− QARUN de MicroFocus
− ABBOT (open source)
− Rational robot de IBM
− Irise studio de Irise

65
Campagne de tests
● Les outils de gestion des plans et campagnes de test servent à définir, organiser
et conduire les campagnes de tests. Ils doivent donc s'interfacer avec tous les
outils qui interviennent dans les tests.
● Les outils:
− Testdirector de Mercury Quality Center
− Salomé TMF (open source)
− Test Manager de SoftEdition.Net
− QaDirector de MicroFocus

66
Tests fonctionnels (boite noire).
● Les tests concernent l'analyse des spécifications du logiciel, sans tenir compte du
code source. Le périmètre des contrôles englobe les interfaces utilisateurs, les
API, la gestion des bases de données, la sécurité et le réseau. Il vérifie la
conformité du fonctionnement d’un système vis-à-vis des exigences de l’utilisateur
(se réfère au cahier des charges).
● Les outils
− LEIRIOS Test Generator de LEIROS − Rational Robot d'IBM
− Conformiq Test Generator de Conformiq Software − iRise Application Simulator de iRise
− Mercury Functional Testing et Mercury Service Test − Mercury Business Process Testing de Mercury
Interactive
− Test Vector Generation de T-VEC
− TestView, WebFT de Radview
− AutoTester ONE de AutoTester
− Seapine SQA de Seapine
− QACenter Enterprise Edition de Compuware
− SilkTest de Segue
− Quality Forge de TestSmith
− Visual WebTester de Softbees
− Selenium (open source)
− eValid de Software Research

67
Tests structurels (boite blanche)
● Ces outils permettent de valider ce que fait le logiciel testé. Ils sont donc
complémentaires aux outils de tests fonctionnels qui vérifient, eux, ce que doit
faire le logiciel. Ces pourquoi des éditeurs ont créé des suites comprenant ces
deux types de tests.
● Les outils:
− C++TEST, .TEST, JTEST, SOATEST et INSURE++ de PARASOFT
− RATIONAL TEST REALTIME de IBM
− XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC

68
Performance des logiciels développés
● Le test de montée en charge.
● La simulation d'un environnement spécifique.
● L’évolution agressive de l'accès aux ressources
● Les outils:
− Wapt de Softlogica (test de charge)
− LoadRunner de Mercury quality center – (test de stress et de charge)
− Siege (open source) (test de charge)
− jMeter (open source) du groupe apache (test de performance)
− QaLoad de MicroFocus (test de charge)
− Performance Center de EMBARCADERO (test de performance)
− Web Performance Load Tester de WebPerformance, inc (test de charge)

69
Conclusion
● Les applications sont de plus en plus complexes, les volumes de données sont de
plus en plus grands...
● les tests sont aujourd’hui au centre de tous les intérêts : de nombreux progiciels
ont vu le jour pour tester, gérer les versions…
● Des sociétés ont investi dans la création d’un service interne, véritable structure
de tests. Rien ne peut être mis en production sans être validé par ce service.
● L’Internet mobile, nouveau mode d’information et nouveau challenge pour les
entreprises, est un support graphique différent nécessitant une programmation
adaptée et donc des tests complémentaires.

70
Référeces
● Les Tests : L’état de l’Art : CNAM 2008/2009, CENTRE REGIONAL DE LILLE, NFE209 –
AUDIT ET GOUVERNANCE DES SYSTEMES D’INFORMATION

71