SlideShare une entreprise Scribd logo
1  sur  68
Télécharger pour lire hors ligne
Enseignant-chercheur
y.boukouchi@uiz.ac.ma
L E S F O N D A M E N T A U X D U
TEST LOGICIEL
Version 1.1 (Décembre 2017)
Plan
 Introduction
 Processus de test
 Types de test
 Activité tests
 Jeu de tests
 Principes de test
 Outils de test
2
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Introduction
3Prof. Youness BOUKOUCHI - ENSA d'Agadir
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é
 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.
 les tests mettent en avant des défaillances du logiciel, c’est-à-dire des
fonctionnements anormaux aux vues de ses spécifications.
4
Définitions
 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)
5
 Erreur: commise par un développeur(Erreur de programmation ou Erreur de logique)
 Défaut: état interne invalide d’un logiciel après l’activation d’une erreur
 Défaillance ou anomalie: manifestation externe d’une faute, le comportement observé est
différent du comportement attendu ou spécifié
La chaîne de l’erreur
6
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!)
La chaîne de l’erreur
8
Tester vs Déboguer
 Tester et déboguer, ce n’est pas la même activité et les
responsables sont différents:
 Les testeurs testent
 Les développeurs déboguent (Déboguer est une activité de
développement permettant d’analyser, trouver et supprimer les causes
de la défaillances)
9
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Processus de test
10Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
11
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Processus de test
Pilote
Module à tester
SoucheSouche Souche
Données de test Résultats
Interface
Oracle
12
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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)
13
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
14
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
15
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Cas de test: trier un tableau de 7 entiers
Processus de test
Pilote
(Script de test)
Trier_tableau
DT:[1,0,12,4,43,5,21] Résultats
int[] mon_tri(int[] vec)
Oracle
[0,1,4,5,12,21,43]verdictverdict
succès / échec
16
Processus de test
public class Calculator {
public int add(int x, int y)
{ return x + y; }
public int multi(int x, int y)
{return x*y;}
}
import static org.junit.Assert.*;
import org.junit.Test;
import ma.ensa.metier.Calculator;
public class CalculatorTest {
@Test
public void addTest() // tester l’addition
{ int a = 15; int b = 18; // données de test
Calculator calc = new Calculator();
int c = calc.add(a,b);
// 33 résultat attendu (Oracle) et c résultat actuel
assertEquals(33, c); // rapport de test
}
@Test
public void multiTest() // tester l’addition
{ int a = 5; int b = 5; // données de test
Calculator calc = new Calculator();
int c = calc.multi(a,b);
assertEquals(25, c);
}}
17
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Types & Classes de test
18Prof. Youness BOUKOUCHI - ENSA d'Agadir
CLASSIFICATION DES TESTS
 Il existe différentes façons de classifier les tests.
 Il est possible de les regrouper selon
 leur mode d’exécution,
 leurs modalités,
 leurs méthodes,
 leurs niveaux,
 leurs caractéristiques.
19
Prof. Youness BOUKOUCHI - ENSA d'Agadir
CLASSIFICATION DES TESTS
 LE MODE D’EXECUTION
 Le 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 d’applications de grandes tailles.
 Le 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).
20
Prof. Youness BOUKOUCHI - ENSA d'Agadir
CLASSIFICATION DES TESTS
 LES MODALITES DE TEST
 Statiques : Les tests sont réalisés «par l'humain» (testeur), sans
machine, par lecture du code dans le but de trouver des erreurs.
Il peut s’agir :
 de l’inspection ou d’une revue de code;
 d’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.
21
Prof. Youness BOUKOUCHI - ENSA d'Agadir
CLASSIFICATION DES TESTS
 LES METHODES 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é. Les tests fonctionnels permettent d’écrire les tests bien
avant le «codage ».
 Il est parfois utile de combiner ces deux méthodes.
22
CLASSIFICATION DES TESTS
Tests unitairesTests unitaires Tests
d’intégration
Tests
d’intégration
Tests du
système et de
fonctionnement
Tests du
système et de
fonctionnement
Tests
d’acceptation
Tests
d’acceptation
Tests de
régression
Tests de
régression Béta-TestsBéta-Tests
 LES NIVEAUX DE TEST
23
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
24
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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)
25
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
26
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
27
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
28
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
 etc.
29
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Tests de régression
 Les tests de régression sont un sous-ensemble des tests originaux
 Les tests de 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
 Test de non-régression : vérifier que la correction des erreurs n'a
pas affecté les parties déjà développées et testées. Cela consiste à
jouer et exécuter des nouveaux tests.
30
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
31
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Positionnement des types de tests
32
Prof. Youness BOUKOUCHI - ENSA d'Agadir
34
Activité tests
35Prof. Youness BOUKOUCHI - ENSA d'Agadir
L’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, Evaluation des risques et Gestion des incidents
 Bilan projet et Clôture (recette ou arrêt des tests) et Amélioration des processus
36
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES ACTIVISTES LIÉES AUX TESTS
37
1. Planifier les tests : c’est-à-dire prévoir où et en quelle quantité porter les efforts en
personne et en temps ; il s’agit également de prévoir et de réserver l’utilisation de plates-
formes de tests et les outils nécessaires ;
2. Spécifier les tests : c’est-à-dire préciser ce que l’on attend des tests en termes de
détection d’erreurs (fonctionnel ou non fonctionnel par exemple), les techniques et les
outils à utiliser ou à ne pas utiliser, les parties du logiciel sur lesquelles porteront les tests ;
3. Concevoir les tests : c’est-à-dire définir les scénarios de tests, appelés aussi cas de test,
permettant de mettre en évidence des défauts recherchés par les tests, en fonction de
leurs spécifications ; il s’agit aussi de préciser les environnements d’exécution de ces tests ;
4. Établir les conditions de tests : c’est-à-dire prévoir pour chaque scénario de tests les jeux
de valeurs à fournir au logiciel pour réaliser ce scénario ;
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES ACTIVISTES LIÉES AUX TESTS
38
5. Définir les conditions d’arrêt d’une campagne de tests : c’est-à-dire définir, en relation
avec la phase de planification, ce qui permettra de décider l’arrêt ou la poursuite des
tests ;
6. Contrôler les résultats : c’est-à-dire comparer les données fournies par l’exécution des
tests par rapport aux données attendues ou constatées lors de phases précédentes de
tests ;
7. Tracer les tests vis-à-vis des exigences grâce à une matrice de traçabilité : c’est-à-dire
analyser en quoi les tests fournissent une exhaustivité de la recherche d’erreurs dans les
attendus du logiciel. Cette matrice permet de vérifier qu’à toute exigence correspond au
moins un scénario de test (mesure de la complétude des tests) et, à l’opposé, elle permet
également de vérifier qu’un scénario de test sert à valiser au moins une exigence (mesure
de l’efficacité des tests).
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LA STRATEGIE DE TESTS
 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.
 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
 …
39
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
40
Prof. Youness BOUKOUCHI - ENSA d'Agadir
PLAN DE TESTS
 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.
41
Prof. Youness BOUKOUCHI - ENSA d'Agadir
PLAN DE TESTS
 Un plan de test doit :
1. Définir les éléments à tester et l’ordre dans lequel ils doivent être testés
(planifier les tests).
2. Décrire l’environnement de tests.
3. Définir la façon dont les tests vont être menés (procédures) : 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… (Appliquer la stratégie de tests aux
tests).
42
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Le 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
43
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 suivantes :
 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.
44
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Jeu de test
45Prof. Youness BOUKOUCHI - ENSA d'Agadir
Tests exhaustifs
 Programme de 50-100 lignes
 1boucles(1-20 itérations), 4
conditions imbriquées à
l’intérieur de la boucle
 1014 chemins d’exécution
possibles
 pour tester tous les chemins à
raison d’un chemin par
milliseconde! ~3174 ans
do
if (…) then
if (…) then
if (…) then
else …
else …
if (…) then
else …
else
while (i < 20)
46
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Tests exhaustifs
47
 L’objet principal est d’analyser le
comportement d’un logiciel dans un
environnement donné : ainsi, 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.
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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 de tests structurels.
48
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Approches des jeux de test
 1- Approches de Test structurel:
 couverture des instructions, des enchaînements
 couverture des conditions
 Couverture des conditions multiples
 couverture des dépendances de données
49
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
50
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
51
Prof. Youness BOUKOUCHI - ENSA d'Agadir
 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
Approches du jeu de test
52
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Approches du jeu de test
 Exemples de Couverture des cas limites
 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
53
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Approches des jeux de test
 Soit la spécification suivante :
 Un programme prend en entrée trois entiers. Ces trois entiers sont
interprétés comme représentant les longueurs des cotés d’un triangle. Le
programme rend un résultat précisant si il s’agit d’un triangle scalène,
isocèle ou équilatéral.
 Produire une suite de cas de tests pour ce programme
54
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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 ?
55
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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
56
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Les 7 Principes de test
57Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
58
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
59
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
60
Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
61
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Les outils de test
62Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES OUTILS DE TEST
 Le premier groupe concerne les outils d’aide à la 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
63
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES OUTILS DE TEST
 Le second groupe concerne les outils de 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
64
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES OUTILS DE TEST
 Le troisième groupe concerne les 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
 Conformiq Test Generator de Conformiq Software
 Mercury Functional Testing et Mercury Service Test
 Test Vector Generation de T-VEC
 AutoTester ONE de AutoTester
 QACenter Enterprise Edition de Compuware
 Quality Forge de TestSmith
 Selenium (open source)
 Rational Robot d'IBM
 iRise Application Simulator de iRise
 Mercury Business Process Testing de Mercury Interactive
 TestView, WebFT de Radview
 Seapine SQA de Seapine
 SilkTest de Segue
 Visual WebTester de Softbees -
 eValid de Software Research
65
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES OUTILS DE TEST
 Le quatrième groupe concerne les 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
66
Prof. Youness BOUKOUCHI - ENSA d'Agadir
LES OUTILS DE TEST
 Le cinquième groupe concerne la performance des logiciels développés, quelque soit
l’environnement.
 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)
67
Prof. Youness BOUKOUCHI - ENSA d'Agadir
Conclusion
68Prof. Youness BOUKOUCHI - ENSA d'Agadir
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.
69
Prof. Youness BOUKOUCHI - ENSA d'Agadir
MERCI DE VOTRE ATTENTION
70Prof. Youness BOUKOUCHI - ENSA d'Agadir

Contenu connexe

Tendances

Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualitéSpikeeLabs
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de testsSabrine MASTOURA
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1Christophe Rochefolle
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielleYouness Boukouchi
 
Stratégie de tests type
Stratégie de tests typeStratégie de tests type
Stratégie de tests typemadspock
 
Intégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec JenkinsIntégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec JenkinsKokou Gaglo
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logicielRabia AZIZA
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdfmido04
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnelscvcby
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringneuros
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieMohammed Amine Mostefai
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-CorrectionLilia Sfaxi
 
Intro sur les tests unitaires
Intro sur les tests unitairesIntro sur les tests unitaires
Intro sur les tests unitairesPHPPRO
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfslimyaich3
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceLilia Sfaxi
 
Correction de td poo n2
Correction de td poo n2Correction de td poo n2
Correction de td poo n2yassine kchiri
 

Tendances (20)

Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualité
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielle
 
Stratégie de tests type
Stratégie de tests typeStratégie de tests type
Stratégie de tests type
 
Intégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec JenkinsIntégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec Jenkins
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
Intro sur les tests unitaires
Intro sur les tests unitairesIntro sur les tests unitaires
Intro sur les tests unitaires
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdf
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de Séquence
 
Correction de td poo n2
Correction de td poo n2Correction de td poo n2
Correction de td poo n2
 

Similaire à Test logiciel

test_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxtest_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxEnochBidima3
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciellauraty3204
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel Esaie88
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsCloudNetCare
 
testUnitaire (1).pptx
testUnitaire (1).pptxtestUnitaire (1).pptx
testUnitaire (1).pptxManalAg
 
Toolbox du designer : Useberry
Toolbox du designer : UseberryToolbox du designer : Useberry
Toolbox du designer : UseberryLudivine Dobigny
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application javaAntoine Rey
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxNicolas Fédou
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingGeeks Anonymes
 

Similaire à Test logiciel (20)

Cours1.pptx
Cours1.pptxCours1.pptx
Cours1.pptx
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
 
test_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxtest_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptx
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
J Unit
J UnitJ Unit
J Unit
 
Et4 4 testinformel
Et4 4 testinformelEt4 4 testinformel
Et4 4 testinformel
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel
 
chap6_GL.pptx
chap6_GL.pptxchap6_GL.pptx
chap6_GL.pptx
 
Final
FinalFinal
Final
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests Logiciels
 
Conformiq
ConformiqConformiq
Conformiq
 
testUnitaire (1).pptx
testUnitaire (1).pptxtestUnitaire (1).pptx
testUnitaire (1).pptx
 
Toolbox du designer : Useberry
Toolbox du designer : UseberryToolbox du designer : Useberry
Toolbox du designer : Useberry
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application java
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Présentation banc_ test
Présentation banc_ testPrésentation banc_ test
Présentation banc_ test
 

Plus de Youness Boukouchi

Les fondamentaux de langage C#
Les fondamentaux de langage C#Les fondamentaux de langage C#
Les fondamentaux de langage C#Youness Boukouchi
 
Appalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSPAppalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSPYouness Boukouchi
 
La persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateLa persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateYouness Boukouchi
 
JDBC: Gestion des bases de données en Java
JDBC: Gestion des bases de données en Java JDBC: Gestion des bases de données en Java
JDBC: Gestion des bases de données en Java Youness Boukouchi
 
Modélisation des processus métiers BPMN
Modélisation des processus métiers BPMNModélisation des processus métiers BPMN
Modélisation des processus métiers BPMNYouness Boukouchi
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPYouness Boukouchi
 
Mindmaps الخريطة الذهنية
Mindmaps الخريطة الذهنيةMindmaps الخريطة الذهنية
Mindmaps الخريطة الذهنيةYouness Boukouchi
 
التفكير الإيجابي 2015
التفكير الإيجابي 2015التفكير الإيجابي 2015
التفكير الإيجابي 2015Youness Boukouchi
 
فن التواصل مع الاخرين 2015
فن التواصل مع الاخرين 2015فن التواصل مع الاخرين 2015
فن التواصل مع الاخرين 2015Youness Boukouchi
 

Plus de Youness Boukouchi (10)

Les fondamentaux de langage C#
Les fondamentaux de langage C#Les fondamentaux de langage C#
Les fondamentaux de langage C#
 
Appalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSPAppalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSP
 
La persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateLa persistance des données : ORM et hibernate
La persistance des données : ORM et hibernate
 
Programmation en C
Programmation en CProgrammation en C
Programmation en C
 
JDBC: Gestion des bases de données en Java
JDBC: Gestion des bases de données en Java JDBC: Gestion des bases de données en Java
JDBC: Gestion des bases de données en Java
 
Modélisation des processus métiers BPMN
Modélisation des processus métiers BPMNModélisation des processus métiers BPMN
Modélisation des processus métiers BPMN
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
 
Mindmaps الخريطة الذهنية
Mindmaps الخريطة الذهنيةMindmaps الخريطة الذهنية
Mindmaps الخريطة الذهنية
 
التفكير الإيجابي 2015
التفكير الإيجابي 2015التفكير الإيجابي 2015
التفكير الإيجابي 2015
 
فن التواصل مع الاخرين 2015
فن التواصل مع الاخرين 2015فن التواصل مع الاخرين 2015
فن التواصل مع الاخرين 2015
 

Test logiciel

  • 1. Enseignant-chercheur y.boukouchi@uiz.ac.ma L E S F O N D A M E N T A U X D U TEST LOGICIEL Version 1.1 (Décembre 2017)
  • 2. Plan  Introduction  Processus de test  Types de test  Activité tests  Jeu de tests  Principes de test  Outils de test 2 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 4. 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é  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.  les tests mettent en avant des défaillances du logiciel, c’est-à-dire des fonctionnements anormaux aux vues de ses spécifications. 4
  • 5. Définitions  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) 5
  • 6.  Erreur: commise par un développeur(Erreur de programmation ou Erreur de logique)  Défaut: état interne invalide d’un logiciel après l’activation d’une erreur  Défaillance ou anomalie: manifestation externe d’une faute, le comportement observé est différent du comportement attendu ou spécifié La chaîne de l’erreur 6
  • 7. 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!) La chaîne de l’erreur 8
  • 8. Tester vs Déboguer  Tester et déboguer, ce n’est pas la même activité et les responsables sont différents:  Les testeurs testent  Les développeurs déboguent (Déboguer est une activité de développement permettant d’analyser, trouver et supprimer les causes de la défaillances) 9 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 9. Processus de test 10Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 10. 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. 11 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 11. Processus de test Pilote Module à tester SoucheSouche Souche Données de test Résultats Interface Oracle 12 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 12. 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) 13
  • 13. 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 14 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 14. 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 15 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 15. Cas de test: trier un tableau de 7 entiers Processus de test Pilote (Script de test) Trier_tableau DT:[1,0,12,4,43,5,21] Résultats int[] mon_tri(int[] vec) Oracle [0,1,4,5,12,21,43]verdictverdict succès / échec 16
  • 16. Processus de test public class Calculator { public int add(int x, int y) { return x + y; } public int multi(int x, int y) {return x*y;} } import static org.junit.Assert.*; import org.junit.Test; import ma.ensa.metier.Calculator; public class CalculatorTest { @Test public void addTest() // tester l’addition { int a = 15; int b = 18; // données de test Calculator calc = new Calculator(); int c = calc.add(a,b); // 33 résultat attendu (Oracle) et c résultat actuel assertEquals(33, c); // rapport de test } @Test public void multiTest() // tester l’addition { int a = 5; int b = 5; // données de test Calculator calc = new Calculator(); int c = calc.multi(a,b); assertEquals(25, c); }} 17 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 17. Types & Classes de test 18Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 18. CLASSIFICATION DES TESTS  Il existe différentes façons de classifier les tests.  Il est possible de les regrouper selon  leur mode d’exécution,  leurs modalités,  leurs méthodes,  leurs niveaux,  leurs caractéristiques. 19 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 19. CLASSIFICATION DES TESTS  LE MODE D’EXECUTION  Le 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 d’applications de grandes tailles.  Le 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). 20 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 20. CLASSIFICATION DES TESTS  LES MODALITES DE TEST  Statiques : Les tests sont réalisés «par l'humain» (testeur), sans machine, par lecture du code dans le but de trouver des erreurs. Il peut s’agir :  de l’inspection ou d’une revue de code;  d’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. 21 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 21. CLASSIFICATION DES TESTS  LES METHODES 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é. Les tests fonctionnels permettent d’écrire les tests bien avant le «codage ».  Il est parfois utile de combiner ces deux méthodes. 22
  • 22. CLASSIFICATION DES TESTS Tests unitairesTests unitaires Tests d’intégration Tests d’intégration Tests du système et de fonctionnement Tests du système et de fonctionnement Tests d’acceptation Tests d’acceptation Tests de régression Tests de régression Béta-TestsBéta-Tests  LES NIVEAUX DE TEST 23 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 23. 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 24 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 24. 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) 25 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 25. 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 26 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 26. 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 27 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 27. 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 28 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 28. 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  etc. 29 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 29. Tests de régression  Les tests de régression sont un sous-ensemble des tests originaux  Les tests de 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  Test de non-régression : vérifier que la correction des erreurs n'a pas affecté les parties déjà développées et testées. Cela consiste à jouer et exécuter des nouveaux tests. 30 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 30. 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 31 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 31. Positionnement des types de tests 32 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 32. 34
  • 33. Activité tests 35Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 34. L’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, Evaluation des risques et Gestion des incidents  Bilan projet et Clôture (recette ou arrêt des tests) et Amélioration des processus 36 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 35. LES ACTIVISTES LIÉES AUX TESTS 37 1. Planifier les tests : c’est-à-dire prévoir où et en quelle quantité porter les efforts en personne et en temps ; il s’agit également de prévoir et de réserver l’utilisation de plates- formes de tests et les outils nécessaires ; 2. Spécifier les tests : c’est-à-dire préciser ce que l’on attend des tests en termes de détection d’erreurs (fonctionnel ou non fonctionnel par exemple), les techniques et les outils à utiliser ou à ne pas utiliser, les parties du logiciel sur lesquelles porteront les tests ; 3. Concevoir les tests : c’est-à-dire définir les scénarios de tests, appelés aussi cas de test, permettant de mettre en évidence des défauts recherchés par les tests, en fonction de leurs spécifications ; il s’agit aussi de préciser les environnements d’exécution de ces tests ; 4. Établir les conditions de tests : c’est-à-dire prévoir pour chaque scénario de tests les jeux de valeurs à fournir au logiciel pour réaliser ce scénario ; Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 36. LES ACTIVISTES LIÉES AUX TESTS 38 5. Définir les conditions d’arrêt d’une campagne de tests : c’est-à-dire définir, en relation avec la phase de planification, ce qui permettra de décider l’arrêt ou la poursuite des tests ; 6. Contrôler les résultats : c’est-à-dire comparer les données fournies par l’exécution des tests par rapport aux données attendues ou constatées lors de phases précédentes de tests ; 7. Tracer les tests vis-à-vis des exigences grâce à une matrice de traçabilité : c’est-à-dire analyser en quoi les tests fournissent une exhaustivité de la recherche d’erreurs dans les attendus du logiciel. Cette matrice permet de vérifier qu’à toute exigence correspond au moins un scénario de test (mesure de la complétude des tests) et, à l’opposé, elle permet également de vérifier qu’un scénario de test sert à valiser au moins une exigence (mesure de l’efficacité des tests). Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 37. LA STRATEGIE DE TESTS  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.  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  … 39 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 38. 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. 40 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 39. PLAN DE TESTS  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. 41 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 40. PLAN DE TESTS  Un plan de test doit : 1. Définir les éléments à tester et l’ordre dans lequel ils doivent être testés (planifier les tests). 2. Décrire l’environnement de tests. 3. Définir la façon dont les tests vont être menés (procédures) : 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… (Appliquer la stratégie de tests aux tests). 42 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 41. Le 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 43
  • 42. 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 suivantes :  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. 44 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 43. Jeu de test 45Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 44. Tests exhaustifs  Programme de 50-100 lignes  1boucles(1-20 itérations), 4 conditions imbriquées à l’intérieur de la boucle  1014 chemins d’exécution possibles  pour tester tous les chemins à raison d’un chemin par milliseconde! ~3174 ans do if (…) then if (…) then if (…) then else … else … if (…) then else … else while (i < 20) 46 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 45. Tests exhaustifs 47  L’objet principal est d’analyser le comportement d’un logiciel dans un environnement donné : ainsi, 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. Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 46. 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 de tests structurels. 48 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 47. Approches des jeux de test  1- Approches de Test structurel:  couverture des instructions, des enchaînements  couverture des conditions  Couverture des conditions multiples  couverture des dépendances de données 49 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 48. 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. 50
  • 49. 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 51 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 50.  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 Approches du jeu de test 52 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 51. Approches du jeu de test  Exemples de Couverture des cas limites  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 53 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 52. Approches des jeux de test  Soit la spécification suivante :  Un programme prend en entrée trois entiers. Ces trois entiers sont interprétés comme représentant les longueurs des cotés d’un triangle. Le programme rend un résultat précisant si il s’agit d’un triangle scalène, isocèle ou équilatéral.  Produire une suite de cas de tests pour ce programme 54 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 53. 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 ? 55 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 54. 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 56 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 55. Les 7 Principes de test 57Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 56. 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. 58 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 57. 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. 59 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 58. 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. 60 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 59. 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. 61 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 60. Les outils de test 62Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 61. LES OUTILS DE TEST  Le premier groupe concerne les outils d’aide à la 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 63 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 62. LES OUTILS DE TEST  Le second groupe concerne les outils de 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 64 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 63. LES OUTILS DE TEST  Le troisième groupe concerne les 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  Conformiq Test Generator de Conformiq Software  Mercury Functional Testing et Mercury Service Test  Test Vector Generation de T-VEC  AutoTester ONE de AutoTester  QACenter Enterprise Edition de Compuware  Quality Forge de TestSmith  Selenium (open source)  Rational Robot d'IBM  iRise Application Simulator de iRise  Mercury Business Process Testing de Mercury Interactive  TestView, WebFT de Radview  Seapine SQA de Seapine  SilkTest de Segue  Visual WebTester de Softbees -  eValid de Software Research 65 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 64. LES OUTILS DE TEST  Le quatrième groupe concerne les 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 66 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 65. LES OUTILS DE TEST  Le cinquième groupe concerne la performance des logiciels développés, quelque soit l’environnement.  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) 67 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 67. 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. 69 Prof. Youness BOUKOUCHI - ENSA d'Agadir
  • 68. MERCI DE VOTRE ATTENTION 70Prof. Youness BOUKOUCHI - ENSA d'Agadir