Test logiciel

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

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

Processus de test
Pilote
Module à tester
SoucheSouche Souche
Données de test Résultats
Interface
Oracle
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

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

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

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

Types & Classes de test

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

 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

 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

 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

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

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

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

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

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

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

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

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

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

Positionnement des types de tests
32

Activité tests

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

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 ;

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

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

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

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

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

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

Jeu de test

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

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.

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

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

 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 de Test fonctionnel:
 couverture de scénarios d’utilisation
 couverture des partitions des domaines d’entrée
 couverture des cas limites
51

 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

 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

 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

 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

 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

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

 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

 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

 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

Les outils de test

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

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

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

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

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

Conclusion

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

MERCI DE VOTRE ATTENTION

Test logiciel

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Test logiciel

Similaire à Test logiciel (20)

Plus de Youness Boukouchi

Plus de Youness Boukouchi (11)

Test logiciel