Seance5 Log3410

-- Séance 5 --
Test des exigences
Objectifs:
Comprendre l’importance des tests et leurs différents types
Comprendre les pratiques du Test Driven Development (TDD)
Être en mesure de réaliser des tests fonctionnels
Explorer les méthodes et outils désignés pour les tests fonctionnels
Découvrir une approche structurée pour un projet de test
1
© 2010 Exigences et spécifications du logiciel, N.Kerzazi
Sommaire
• Mise en contexte
• Concepts de la pratique Test Driven Development (TDD) et Test Driven
Requirement (TDR)
• Définition des exigences des tests
• Positionnement des exigences des tests dans le processus de test
• Organisation et décomposition des exigences des tests
• Mesure de la couverture des tests
2
Rappel: Validation & Vérification
• Qualité du logiciel = Conformité aux spécifications + Fiabilité + Robustesse
• Méthodes de V & V
Validation: Est-ce que le logiciel réalise les fonctions attendues?
Vérification: Est-ce que le logiciel fonctionne correctement?
• Concrètement
Test statique: Relecture du code, spécifications, design, etc;
Test dynamique: Exécution du code pour s’assurer de son bon
fonctionnement;
Vérification symbolique: Run-time checking, execution symbolique,etc;
Vérification formelle: Preuve ou model-checking d’un modèle formel,
raffinement et génération de code.
3
© 2010 Exigences et spécifications du logiciel, N.Kerzazi
Perspective du testeur: Vue traditionnelle
• Qu'est-ce que ce système est censé faire exactement et dans quel ordre?
• Quelles sont les choses qui risquent de ne pas fonctionner correctement et

comment le système doit se comporter?
• Comment créer et enregistrer un ensemble de scénarios de test pour mettre

à l’épreuve le système?
• Comment savoir si tout le système a été correctement testé?
• Y a-t-il autre chose que le système doit faire ou ne pas faire et qu’on doit
savoir?
• Est-ce qu’on peut commencer tôt les activités liées au test et éviter ainsi
de découvrir des erreurs trop tard???
© 2010 Exigences et spécifications du logiciel, N.Kerzazi 4

Perspective du testeur: Vue cas d’utilisation
• Ensemble de cas d’utilisation qui documente des séquences ordonnées
d’événements et la façon dont le système interagit avec l’utilisateur.
• Description des pré-conditions et des post-conditions.
• Cahier de spécification supplémentaire contenant les ENF (performance,
utilisabilité, fiabilité, etc.).
• Différence entre un cas d’utilisation et un cas de test?

Rappel du vocabulaire lié au test
Plan de Cas
• Plan de test test d’utilisation
Contient
• Cas de test
• Procédure de test
Cas de test
• Script de test
• Couverture du test Fournit des instruction pour
• Résultats du test Procédure

de test
Exécution automatique
Script de
test
Résultats
du test
Définition du test
• [ 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)
• Tester c’est réaliser l’exécution du programme
• Oracle: résultats attendus d’une exécution du logiciel
• Coût du test: 30 % à 60 % du coût de développement total
• Deux grandes familles de tests:
Test fonctionnel (ou test boîte noire)
Test structurel (ou test boîte blanche)

Difficultés du test
• Le test exhaustif est en général impossible à réaliser:
En test fonctionnel, l’ensemble des données d’entrée est en général

infini ou de très grande taille.
la qualité du test dépend de la pertinence du choix des données de

test.
• Difficultés d’ordre psychologique ou «culturel»
Le test est un processus destructif: un bon test est un test qui trouve
une erreur. Alors que l’activité de programmation est un processus
constructif.

Concepts de la pratique TTD
Exigences Spécifications
• Approche Test-Driven Development: TDD
1. Écrire un test et s’assurer qu’il échoue Tests Tests

d’acceptation fonctionnels
2. Écrire le minimum de code pour faire passer le test
3. Re-factoriser le code en s’assurant que le test continu de passer
• Caractéristiques:
S’inspire de l’organisation des chaînes de production «Lean-Thinking»
1. L’étape de codage ne produit que ce qui est demandé par l’étape de test
2. Pas de gâchis causé par des étapes intermédiaires
3. Tout est juste à temps (JIT)
Les tests unitaires (TU) dérivent directement de la spécification
L’équipe agile mise sur l’émergence de la conception donc les TU
permettent de vérifier la bonne adéquation du code à la conception
• Est-ce qu’on peut faire la même chose pour les tests fonctionnels?

Du TDD au TDR (Test-Driven Requirements)
• Avec les tests unitaires du TDD, les jeux de données sont peu représentatifs
sur le plan fonctionnel.
• Les mêmes principes du TDD peuvent être appliqués au niveau fonctionnel
TDR
• Caractéristiques du TDR
Tirer les tests fonctionnels des exigences sans avoir à attendre leur réalisation
pour faire les tests.
Déléguer les tests fonctionnels aux clients.
Intéressant pour des équipes réparties géographiquement.
Possibilité d’avoir dans le même wiki les exigences et les tests qui les vérifient.
Le codage devient la dernière activité avant la livraison du logiciel.
Supportée par des outils
- FIT (http://fit.c2.com)
- Fitnesse (http://www.fitnesse.org)
- Greenpepper (http://www.greenpeppersoftware.com/)
- Microsoft Test & Lab Manager
Bases de l’approche TDR
• Décrire des tests sous une forme tabulaire dans un Wiki ou une page Web
• Accompagner ce tableau d’un bout de code, appelé fixture, qui fait le lien
entre les tests et les API de l’application
• Le moteur FIT utilise la fixture pour lire le tableau et appeler les API de
l’application avec les paramètres adéquats
• Le moteur FIT retourne le résultat du test dans le même tableau en mettant
en couleur les cases du tableau selon le résultat du test
• Plusieurs catégories de tableaux sont disponibles:
ColumnFixture : pour spécifier des données en entrée et des résultats attendus.
ActionFixture : pour spécifier un enchainement d’actions (décrire des scénarios
de tests)
RowFixture : pour spécifier des lignes de résultats. Généralement utilisé pour
faire des initialisations ou pour vérifier des résultats de recherches
Tableau personnalisé: pour une adaptation spécifique

Exemple: très simple
• Ex. Tester le calcul de division pour voir s’il est acceptable

• Partie 1: la spécification
Nous voulons que la division fonctionne à la fois avec les nombres
positifs et négatifs.
Ex. Division
= numéra Dénomin quotient
1000 10 100.00
• Partie 2: les fixtures
-1000 10 -100.00
1000 9 111.11
1000 0.01 100000
72458 43568 1.66
• Exécution
c: java FileRunner input.html results.html
7 right, 0 wrong, 0 ignored, 0 exceptions
Approche MBT (Model-based Testing): alternative au TDR
Exigences
• Principe:
Élaborer un modèle à partir duquel on
dérive automatiquement les scripts des Modèle
tests
• La profondeur des tests que l’on peut
Générateur de
générer dépend de la précision du modèle Cas de test
• L’effort est considérable pour les activités
de modélisation Cas de test
• Exemple d’outil
Générateur de
Smartesting Script
(http://www.smartesting.com/)
Scripts de test
Adaptateur
Système

Qu’est ce que exactement les exigences des tests (ET) ?
Identifient quoi tester: (traditionnellement le plan de test)
qu'est-ce qui doit être testé et
qu'est-ce qui doit être validé?
• Comprend à la fois les situations normales et celles avec erreurs
• Couvre les règles de gestion, les fonctionnalités et les ENF
• NE dispose PAS de données pour les assigner aux cas de test
Ces données apparaissent dans les cas de test (le «comment» des
tests)

Exemple 1: Tester l’insertion d’un enregistrement dans une table
• Les exigences des tests identifiées (entre autres) :

• “Valider qu’il est possible d’insérer une nouvelle entrée”
• “Valider que l'insertion échoue si l'entrée existe déjà”
• “Valider que l'insertion échoue si la table atteint son maximum”
• “ Valider qu’il est possible d’insérer une entrée dans une table vide (initial)”
• “Valider que l’insertion échoue si la table est pleine”
o Ce sont des exigences de test et NON PAS des tests parce qu’ils ne
décrivent pas les données à insérer.
• Les données ne sont pas pertinentes à ce niveau, ils vont apparaitre
dans les cas de test.
• Valider que vous pouvez insérer ‘Mat Lavallée’ est un cas de test et
non une exigence de test.
15
Pourquoi identifier les exigences de tests?
L’équipe d’assurance qualité est propriétaire de ses besoins fonctionnels

de test
C’est la base pour établir des tests complets
Contribue à déterminer l'ampleur de l'effort de test
Justifie les types de ressources nécessaires
Sert à identifier les stratégies d’automatisation à utiliser
Sert de carte pour guider les efforts de test
Sert de base pour la communication entre les analystes et les testeurs
L’équipe de développement peut les adopter pour la vérification
16
D’où proviennent les exigences des tests
Traditionnellement : Exigences d’affaires, fonctionnelles, logique interne…
Specs marketing, specs fonctionnelles, specs techniques
En réalité :
“Entrevues d’analyse”, checklists des ENF, Use Cases (scenarios),
découverts pendant les tests, autres livrables (conception, etc.)
17
Comment les exigences des tests sont elles liées au plan de test?
Traditionnellement, le plan de test représente le «quoi» doit être testés, y
compris même les cas de test.
Un plan de test clarifie l’approche de test pour renforcer la confiance.
Un plan de test peut inclure les exigences des tests (ET). Toutefois, si les ET
sont trop longues, ils devraient être séparées: document nommé « Test
Requirements Hierarchy».
18
Progression vers le bas niveau
Exigences d’affaires
Exigences des tests

Génère M
1
M Execute
Cas de test/ M
scénario
Génère
M
1
Procédure de
test/Script
19
Naviguer vers le bas
Exigences d’affaires Premièrement, regardons

cette relation: Qu'est-ce
qui est au sein de notre
processus de tests
Exigences des tests
M
Cas de test/ scénario
Ensuite, nous allons examiner
cette relation:
Génération des exigences des tests
qui nourrit notre processus de tests
Procédure de
test/Script
20
Exemple de guichet automatique (GA) pour pratiquer les ET
• Exigences d’affaires • Groupe d’exercice !
• “Le GA doit permettre des • 1. Limiter le champ d'application à

retraits”. ces 3 exigences.
• “Les retraits sont entre 20$ et • 2. Qu’est ce qu’il faut valider ? (test
300 $”. de)?
• “Les retraits sont des multiple • 3. Existe- t- il des exigences

de 20 $”. implicites dont on a omis l’écriture?
21
Exemple 2: Tester les retraits d’un GA
o “Valider qu'une option de retrait est disponible”
o "Valider que le retrait se fait par multiple de 20 $, entre 20 $ - 300 $"
o "Valider qu’un retrait <$20 n’est pas permis"
o "Valider qu’un retrait >$300 n’est pas permis"
o “Valider que le retrait reçue est égale au montant demandé”
o "Valider le fait qu’ un montant de retrait valide ne doit pas dépasser le solde du
compte”
o Ce sont des exigences de test et NON des test pas parce qu'ils ne décrivent
pas les données à utiliser (comme 20 $, 40 $, 60 $, 1 $)
22
Exemple: Cas de test/scénario
• Valider qu’on peut faire un retrait d’argent entre 20$ et 300$ en billet de
20$
Cas # P/F $ entrée Résultat attendu Résultat actuel
Retrait 01 Pass 20 Retrait de 20$
Retrait 03 Pass 60 Retrait de 60 $
: : : :
23
Exemple de procédure de test
Procédure
Étape 1: Insérer la carte
Étape 2: Enter le PIN
Étape 3: Sélectionnez l'option Retirer
Étape 4: Entrez le montant en dollars
Étape 5: Valider le montant reçu
24
Positionnement des ET dans le processus de test
• Utiliser un verbe d’action

- “Valider que …”
- “Vérifier le …”
- “Tester que…”
• Utiliser la traçabilité vers les exigences d’affaires
• Rappelez-vous que différentes applications nécessitent # approches
- batch, web, GUI, etc.
• Garder votre document d’exigences des tests vivant

Suite …
• Maintenir un équilibre entre les niveaux d’abstraction (beaucoup vs peu)
Trop haut niveau: ne sera pas utile, trop vague pour générer des
scénarios de test.
Trop faible niveau: dépasse le processus et la documentation, il

n’assure pas la productivité.
Règle générale: 5-7 niveaux de profondeur pour chaque niveau
• Organiser le document des ET
Souligner un format hiérarchique
Voir comment les analystes découpent le projet
Voir comment les architectes découpent le projet
Organiser par fonctionnalité

26
Décomposition
Business
Function
Exigences d’affaires Tasks within the

Function
Transactions to
perform a task
Data Entry Types

for transactions
Exigences des tests Field Validation
Gardez la M
Cas de test/ scénario
perspective
fonctionnelle
en tête!
Procédure de
test/Script
27
Exemple: location de voiture
1. Valider qu'une location peut se produire.

1.4 Ouvrez un billet de location Task
1.4.1 Valider qu'une fiche client peut être entrée
1.4.1.1 Valider qu'un nouveau client peut être ajouté à la
table des clients
1.4.1.1.1 Valider que le nom est toujours alpha
1.4.1.1.2 Valider que l’âge est > 21.
1.4.1.1.3 Valider que le numéro de téléphone est
numérique
1.4.1.1.4 Valider que le code régional est un numéro
existant.
1.4.1.2 Valider qu’on peut modifier la fiche d’un client
existant
28
Exemple: location de voiture
1. Valider qu'une location peut se produire.

1.4 Ouvrez un billet de location
1.4.2 Valider que l'approbation de carte de crédit est obtenue
1.4.2.1 Valider que la date d’expiration est valide
1.4.2.2 Valider que la date d'expiration > 1 mois .
1.4.2.3 Valider que le CC est de 12 chiffres
1.4.2.4 Valider que la somme $ est <= solde de crédit
disponible
1.4.2.5 Valider que l'autorisation est reçue.
29
Mesures de la couverture des tests
• Les exigences des tests (ET) sont le «quoi» tester et sont à la base pour
l'établissement de la complétude des tests
• Les ET fournissent le point de mesure de la couverture des tests
• Chaque ET devrait avoir des attributs: priorité, risque, et poids
• Chaque ET devrait être suivie pour vérification ( ) et validation (%)
30
Distinguer entre les # types de test
Tests fonctionnels Tests de stress (mémoire, CPU)

Tests des Interfaces Usager Tests des ressource usager
Tests de sécurité Tests de la documentation
Tests de compatibility
Tests de l’ installation
Tests de récupération
Tests de configuration Tests de maintenabilité
Tests de performance (Temps de
Réponse) Autres …
Tests de charge (utilisateurs Communication avec les autres
simultanés, plusieurs petites systèmes
transactions)
Tests de volume (grandes
transactions)
31
Les trois dimension pour les tests
Cycle de vie
Système
Intégration
Module
unitaire
Caractéristiques
Boite blanche
Boite noire
Niveau

Complémentarité test fonctionnel -structurel
• Les techniques fonctionnelles et structurelles sont utilisées de façon

complémentaire.
• Exemple : Soit le programme suivant censé calculer la somme de deux
entiers:
Function sum(x,y : integer) : integer;
begin
if (x = 600) and (y = 500) then sum:= x-y
Else sum:= x+y;
End
• Une approche fonctionnelle détectera difficilement le défaut alors qu’une
approche par analyse de code pourra produire la DT : x = 600, y = 500
Les approches structurelles détectent plus facilement les erreurs commises.
Les approches fonctionnelles détectent plus facilement les erreurs d’omission et de spécification

Méthodes de test fonctionnel
• Le test fonctionnel vise à examiner le comportement fonctionnel du

logiciel et sa conformité avec la spécification du logiciel
Sélection des Données de Tests ( DT)
• Méthodes du test fonctionnel

1. Analyse partitionnelle des domaines des données d’entrée et test
aux limites (test déterministe)
2. Test combinatoire: Algorithmes Pairwise
3. Test aléatoire
4. Génération automatique de tests à partir d’une spécification (TDR).

1. Analyse partitionnelle des domaines des données d’entrée et test aux
limites (test déterministe)
• Une classe d’équivalence

correspond à un ensemble de
données de tests supposées
tester le même comportement,
c’est-à-dire activer le même
défaut.

Partitionnement de domaines : exemple
• Soit le programme suivant :

Un programme lit trois nombres réels qui correspondent à la longueur
des cotés d’un triangle. Si ces trois nombres ne correspondent pas à
un triangle, imprimer le message approprié. Dans le cas d’un triangle,
le programme examine s’il s’agit d ’un triangle isocèle, équilatéral ou
scalène et si son plus grand angle est aigu, droit ou obtus (< 90°, = 90°,
> 90 °) et renvoie la réponse correspondante.
• Classes d’équivalence et Données de Test

Analyse partitionnelle - Méthode
• Trois phases :
Pour chaque donnée d’entrée, calcul de classes d’équivalence sur les
domaines de valeurs,
Choix d’un représentant de chaque classe d’équivalence,
Composition par produit cartésien sur l’ensemble des données
d’entrée pour établir les DT.

Test aux limites
• Principe : on s’intéresse aux bornes des intervalles partitionnant les

domaines des variables d’entrées :
pour chaque intervalle, on garde les 2 valeurs correspondant aux 2
limites, et les 4 valeurs correspondant aux valeurs des limites ± le plus
petit delta possible
n ∈3 .. 15 ⇒v1 = 3, v2 = 15, v3 = 2, v4 = 4, v5 = 14, v6 = 16
si la variable appartient à un ensemble ordonnés de valeurs, on choisit
le premier, le second, l’avant dernier et le dernier
n ∈{-7, 2, 3, 157, 200} ⇒v1 = -7, v2 = 2, v3 = 157, v4 = 200
si une condition d’entrée spécifie un nombre de valeurs, définir les cas
de test à partir du nombre minimum et maximum de valeurs, et des
test pour des nombres de valeurs hors limites invalides.
• Un fichier d’entrée contient 1-255 records, produire un cas de test pour 0,
1, 255 et 256.

Test aux limites -Exemple
• Calcul des limites sur l’exemple du programme de classification des

triangles
1, 1, 2 Non triangle
0, 0, 0 Un seul point
4, 0, 3 Une des longueurs est nulle
1, 2, 3.00001 Presque un triangle sans en être un
0.001, 0.001, 0.001 Très petit triangle
99999, 99999, 99999 Très grand triangle
3.00001, 3, 3 Presque équilatéral
2.99999, 3, 4 Presque isocèle
3, 4, 5.00001 Presque droit
3, 4, 5, 6 Quatre données
3 Une seule donnée
Entrée vide
-3, -3, 5 Entrée négative

Test aux limites -Evaluation
• Méthode de test fonctionnel très productive :

le comportement du programme aux valeurs limites est souvent pas
ou insuffisamment examiné
• Couvre l’ensemble des phases de test (unitaires, d’intégration, de
conformité et de régression)
• Inconvénient : caractère parfois intuitif ou subjectif de la notion de limite
⇒Difficulté pour caractériser la couverture de test.

Méthodes de test fonctionnel -Exercice 1
• Supposons que nous élaborions un compilateur pour le langage BASIC. Un

extrait des spécifications précise :
«L’instruction FOR n’accepte qu’un seul paramètre en tant que
variable auxiliaire. Son nom ne doit pas dépasser deux caractères non
blancs; Après le signe = est précisée aussi une borne supérieure et une
borne inférieure. Les bornes sont des entiers positifs et on place entre
eux le mot-clé TO. »
• Déterminer par analyse partitionnelle des domaines des données
d’entrée les cas de test à produire pour l’instruction FOR.

Méthodes de test fonctionnel -Correction Exercice 1
• DT obtenues par analyse partitionnelle pour l’instruction FOR:

FOR A=1 TO 10 cas nominal
FOR A=10 TO 10 égalité des bornes
FOR AA=2 TO 7 deux caractères pour la variable
FOR A, B=1 TO 8 Erreur -deux variables
FOR ABC=1 TO 10 Erreur -trois caractères pour la variable
FOR I=10 TO 5 Erreur -Borne sup < Borne inf
FOR =1 TO 5 Erreur -variable manquante
FOR I=0.5 TO 2 Erreur -Borne inf décimale
FOR I=1 TO 10.5 Erreur -Borne sup décimale
FOR I=7 10 Erreur -TO manquant

Méthodes de test fonctionnel-Exercice 2
• Considérons les spécifications suivantes :
«Écrire un programme statistique analysant un fichier comprenant les

noms et les notes des étudiants d’une année universitaire. Ce fichier se
compose au maximum de 100 champs. Chaque champ comprend le
nom de l’étudiant (20 caractères), son sexe (1 caractère) et ses notes
dans 5 matières (entiers compris entre 0 et 20). Le but du programme
est de :
calculer la moyenne pour chaque étudiant,
calculer la moyenne générale (par sexe et par matière),
calculer le nombre d’étudiants qui ont réussi (moyenne supérieure à10)
• Déterminer par une approche aux limites les cas de test à produire pour
cette spécification

Méthodes de test fonctionnel -Correction Exercice 2
• DT obtenues par test aux limites pour l’exemple étudiants :

passage d’un fichier vide, puis comprenant 1 champ, 99, 100 et 101 ( 5
tests différents, la valeur -1 n’ayant pas de sens dans ce cas);
inclure un nom d’étudiant vide, un nom avec des caractères de
contrôle, un nom avec 19, puis 20, puis 21 caractères;
inclure un code sexe vide, puis avec un caractère faux (C par exemple);
avoir un étudiant sans aucune note et un avec plus de 5 notes;
pour certains champs, les notes ne doivent pas être des nombres
entiers, mais des caractères, des réels avec plusieurs décimales, des
nombres négatifs ou des nombres entiers supérieurs à20.
• Les DT aux limites doivent être passées indépendamment : les erreurs
peuvent se compenser.

2. Test combinatoire: Algorithmes Pairwise
• Les combinaisons de valeurs de domaines d’entrée donne lieu a une

explosion combinatoire
Exemple : Options d’une boite de dialogue MS Word
• 212 * 3 (nombre d’item dans le menu déroulant) = 12 288

Test combinatoire: Approche Pairwise
• Tester un fragment des combinaisons de valeurs qui garantissent que

chaque combinaison de 2 variables est testée
Exemple : 4 variables avec 3 valeurs possibles chacune

Pairwise
• 9 cas de test : chaque combinaison de 2 valeurs est testée
• La majorité des fautes sont détectées par des combinaisons de 2 valeurs

de variables

3. Test aléatoire ou statistique
• Principe : utilisation d’une fonction de calcul pour sélectionner les DT :
fonction aléatoire : choix aléatoire dans le domaine de la donnée

d’entrée,
utilisation d’une loi statistique sur le domaine.
• Exemples :
Échantillonnage de 5 en 5 pour une donnée d’entrée représentant une

distance,
Utilisation d’une distribution gaussienne pour une donnée

représentant la taille des individus.

Test combinatoire - Evaluation
• L’approche Pairwise se décline avec des triplets, des quadruplets, …. mais

le nombre de tests augmente exponentiellement
• Une dizaine d’outils permet de calculer les combinaisons en Pairwise (ou
n-valeurs) :
http://www.pairwise.org/default.html
Prise en charge des exclusions entre valeurs des domaines et des
combinaisons déjà testées.
Exemple : outil Pro Test
• Problème du Pairwise:
Le choix de la combinaison de valeurs n’est peut-être pas celui qui
détecte le bogue…
Les résultats attendus de chaque test doivent être fournis
manuellement

Conclusion
• Tout démarre d’une bonne spécification. Elle doit être testable
• Les approches TDD et TDR valorisent les activités de test.
• À long terme, les rôles Analyste et Testeur fusionneront, car il n’existera
plus de besoin d’avoir des ressources spécialisées sur les exigences et sur
les tests (pratiques: Exigences, TDD, TDR).
• Les exigences des tests sont la base pour établir des tests complets
• Quatre grandes méthodes pour les tests fonctionnels

Annexe: Microsoft Test & Lab Manager (MTLM)

Ajout d’un élément de travail pour un cas de test

Exécution d’un cas de test dans MTLM (Microsoft Test Runner)

Seance5 Log3410

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Seance5 Log3410

Transféré par

Droits d'auteur :

Formats disponibles

-- Séance 5 --

Test des exigences

Comprendre l’importance des tests et leurs différents types

Comprendre les pratiques du Test Driven Development (TDD)

Être en mesure de réaliser des tests fonctionnels

Explorer les méthodes et outils désignés pour les tests fonctionnels

Découvrir une approche structurée pour un projet de test

• Concepts de la pratique Test Driven Development (TDD) et Test Driven

• Définition des exigences des tests

• Positionnement des exigences des tests dans le processus de test

• Organisation et décomposition des exigences des tests

• Mesure de la couverture des tests

• Qualité du logiciel = Conformité aux spécifications + Fiabilité + Robustesse

• Quelles sont les choses qui risquent de ne pas fonctionner correctement et

• Comment créer et enregistrer un ensemble de scénarios de test pour mettre

• Comment savoir si tout le système a été correctement testé?

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 4

• Ensemble de cas d’utilisation qui documente des séquences ordonnées

d’événements et la façon dont le système interagit avec l’utilisateur.

• Description des pré-conditions et des post-conditions.

• Cahier de spécification supplémentaire contenant les ENF (performance,

utilisabilité, fiabilité, etc.).

• Différence entre un cas d’utilisation et un cas de test?

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 5

• Résultats du test Procédure

• [ 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

• Tester c’est réaliser l’exécution du programme

• Oracle: résultats attendus d’une exécution du logiciel

• Coût du test: 30 % à 60 % du coût de développement total

• Deux grandes familles de tests:

Test fonctionnel (ou test boîte noire)

Test structurel (ou test boîte blanche)

• Le test exhaustif est en général impossible à réaliser:

En test fonctionnel, l’ensemble des données d’entrée est en général

la qualité du test dépend de la pertinence du choix des données de

• Difficultés d’ordre psychologique ou «culturel»

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 8

• Approche Test-Driven Development: TDD

1. Écrire un test et s’assurer qu’il échoue Tests Tests

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 9

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 11

• Ex. Tester le calcul de division pour voir s’il est acceptable

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 13

Identifient quoi tester: (traditionnellement le plan de test)

qu'est-ce qui doit être testé et

qu'est-ce qui doit être validé?

• Comprend à la fois les situations normales et celles avec erreurs

• Couvre les règles de gestion, les fonctionnalités et les ENF

• NE dispose PAS de données pour les assigner aux cas de test

© 2010 Exigences et spécifications du logiciel, N.Kerzazi 14

• Les exigences des tests identifiées (entre autres) :

L’équipe d’assurance qualité est propriétaire de ses besoins fonctionnels

C’est la base pour établir des tests complets

Contribue à déterminer l'ampleur de l'effort de test

Justifie les types de ressources nécessaires

Sert à identifier les stratégies d’automatisation à utiliser

Sert de carte pour guider les efforts de test

Sert de base pour la communication entre les analystes et les testeurs

L’équipe de développement peut les adopter pour la vérification

Traditionnellement : Exigences d’affaires, fonctionnelles, logique interne…

Specs marketing, specs fonctionnelles, specs techniques