Vous êtes sur la page 1sur 43
Processus de Test Info inspirée de la documentation présentée par International Software Testing Qualifications Board
Processus de Test
Info inspirée de la documentation présentée par
International Software Testing Qualifications Board
Les organisations: CFTL, ISTQB, REQB  La qualité du logiciel est devenu un enjeu majeur
Les organisations: CFTL, ISTQB, REQB
 La
qualité
du
logiciel
est
devenu
un
enjeu
majeur
de
tout
développement informatique.
 Depuis 2004, des experts en tests de logiciels en France se sont
réunis au sein du Comité Français des Tests Logiciels (CFTL) pour
développer, définir ou faire la promotion de contenus standards
pour les formations en tests de logiciels, en ingénierie des exigences
et pour promouvoir les échanges autour des bonnes pratiques dans
ces deux domaines.
 Comité Français des tests Logiciels, l'International Software Testing
Qualifications Board (ISTQB), et le Requirements Engineering
Qualification Board (REQB) – organisations sans but lucratif,
indépendantes et reconnues internationalement pour les
compétences certifiées.
Le programme de certification ISTQB Certified Tester fourni des connaissances permettant de vérifier et tester

Le programme de certification ISTQB Certified Tester fourni des connaissances permettant de vérifier et tester efficacement des logiciels. A l'heure actuelle, il y a deux niveaux de certification:

le niveau Fondation et le niveau Avancé. Le niveau Avancé de ISTQB Certified Tester s'appuye sur le niveau Fondation et comporte trois parties :

Test Manager

Analyste de tests

Analyste technique de tests Ceci permet de choisir soit d'acquérir la certification soit dans une spécialité particulière, soit de prendre les trois examens et recevoir le certificat de testeur ISTQB, niveau avancé complet.

L’ingénierie des exigences

L’ingénierie des exigences  est l’un des principaux facteurs clé de succès des projets;  nécessite

est l’un des principaux facteurs clé de succès des projets;

nécessite la mise en œuvre de standards, d’outils, et de compétences particuliers;

est étroitement liée aux processus de test logiciel.

« Le Comité Français des Tests Logiciels contribue à professionnaliser l’ingénierie des exigences en France, en s’appuyant sur le schéma de certification REQB qui vise à identifier, décrire, diffuser et certifier les compétences nécessaires »

Comité Français des Tests Logiciels Le Comité Français des Tests Logiciels (CFTL) est une association

Comité Français des Tests Logiciels

Le Comité Français des Tests Logiciels (CFTL) est une association à but non lucratif fondée en 2004 pour faire la promotion du métier de testeur de logiciels. Le bureau du CFTL détermine le contenu des formations et les questions d'examen associées. Ces personnes travaillent toutes bénévolement pour le CFTL. Elles ont:

soit une expérience dans des comités nationaux d'autres pays comme ceux de l'ISTQB,

soit sont des spécialistes dans le domaine des tests logiciels,

soit ont travaillé sur les standards internationaux de tests de logiciels,

soit ont ou vont publier des ouvrages sur les tests de logiciels.

Objectifs d’Apprentissage pour Processus de Test (1)

1.2 Gestion, Pilotage et Contrôle des Tests Analyser les besoins de test pour un système afin de planifier les activités de test et les livrables permettant d’atteindre les objectifs de test. 1.3 Analyse des Tests

Utiliser cohérence

la

traçabilité

pour

regarder

test

la

complétude

par

et

la

des

conditions

de

définies

rapport

aux

objectifs de test, à la stratégie de test, et au plan de test.

Expliquer

les

facteurs

les

pouvant

affecter

test

le

et

niveau

les

de

avantages

détail

et

possible pour

désavantages à spécifier les conditions de test à un niveau détaillé.

conditions

de

Objectifs d’Apprentissage pour Processus de Test (2)

1.4 Conception des Tests

Utiliser la traçabilité pour vérifier la complétude et la cohérence des cas de test conçus par rapport aux conditions de test définies.

1.5 Implémentation des Tests

Utiliser les risques, établir les priorités, l’environnement de test, les données associées et les contraintes pour développer un planning d’exécution des tests qui soit complet et consistent par rapport aux objectifs de test, à la stratégie de test et au plan de test.

1.6 Exécution des Tests

Utiliser la traçabilité pour piloter l’avancement du test par rapport à la complétude et la cohérence par rapport aux objectifs de test, à la stratégie de test et au plan de test.

Objectifs d’Apprentissage pour Processus de Test (3)

1.7 Évaluation des Critères de Sortie et Reporting

et

processus de test afin de

façon

évaluations par rapport aux critères de sortie. 1.8 Activités de Clôture des Tests Résumer les quatre groupes d’activités de clôture des tests. Effectuer un bilan de projet pour évaluer les processus et identifier des axes d’amélioration.

Expliquer

l’importance

d’un

recueil

d’information

précis

effectué au bon moment dans le

permettre de réaliser

de

précise

les

rapports

et

les

1.2 Planification, Suivi et Contrôle des Tests

1.2.1 Planification des Tests

Pour chaque niveau de test, la planification des tests commence au début du processus de test pour ce niveau et continue tout au long du projet, jusqu’à l’achèvement des activités de clôture pour ce niveau. La planification des tests inclut aussi l’identification des méthodes pour collecter et suivre les métriques utilisées pour guider le projet, déterminer le respect du plan et mesurer l’atteinte des objectifs. Les informations sur les risques peuvent être utilisées pour déterminer les priorités des diverses activités de test. Par exemple, lorsque la performance du système est un risque élevé, les tests de performances peuvent être mis en place dès que du code intégré est disponible.

1.2.1 Planification des Tests

L’étape de planification des tests est là où l’approche de test est clairement définie par le Test Manager, incluant les niveaux de test qui seront mis en œuvre, les buts et objectifs de chaque niveau, et les techniques de tests à utiliser à chaque niveau de test.

Le plan de test peut aussi lister les caractéristiques spécifiques du logiciel faisant partie de son périmètre (sur la base de l’analyse des risques, si nécessaire), de même qu’identifier précisément les caractéristiques qui sont hors de son périmètre.

Dans

un cycle

de

vie

Agile, des

sessions

informelles

de

transfert

d’information peuvent être utilisées pour transférer les informations entre les équipes avant le démarrage du test.

1.2.2 Pilotage et Contrôle des Tests

Il est très important de lier le statut des livrables et des activités de test à la base de test d’une façon compréhensible et utile pour les parties prenantes techniques et métier du projet. Le contrôle des tests est une activité récurrente.

Cela implique la comparaison de l’avancement réel par rapport à l’avancement prévu et la mise en œuvre d’actions correctives si besoin.

Le contrôle des tests oriente le test vers l’accomplissement de la mission, de la stratégies et des objectifs, incluant la réorientation des activités de test selon les besoins.

Les réactions appropriées aux informations du contrôle dépendront des informations détaillées de planification des tests.

Le contenu des documents de planification des tests et les activités de contrôle des tests sont couverts dans le Chapitre 2 du Syllabus Niveau Avancé;Test Manager.

1.3 Analyse des Tests

L’analyse des tests est l’activité qui définit “ce qu’il faut” tester, sous la forme de conditions de test. Spécifier les conditions de test de façon détaillée aboutira à un nombre plus important de conditions de test.

Ex. Vous pouvez par exemple avoir une unique condition de test générale, “Tester le paiement”, pour une application de commerce électronique. Cependant, dans un document détaillé de condition de test, cela pourrait être scindé en de nombreuses conditions de test, avec une condition par méthode de paiement acceptée, une condition par pays destinataire possible, et ainsi de suite.

1.3 Analyse des Tests (2)

Facteurs à considérer quand l’on décide du niveau de détail avec lequel spécifier les conditions de test, dont :

Le niveau de test;

La complexité du système ou du logiciel;

Les risques projet et produit;

Les relations entre les bases de test, ce qui doit être testé et comment cela doit être testé;

Le cycle de développement logiciel utilisé ;

L’outil de Gestion des Tests utilisé ;

Le niveau de spécification et de documentation requis pour la conception des tests et des autres livrables de test ;

Les compétences et connaissances des Analystes de Test ;

Le niveau de maturité du processus de test et de l’organisation dans son ensemble;

La disponibilité d’autres parties prenantes du projet pour répondre à des demandes.

1.3 Analyse des Tests (3)

Certains des avantages de spécifier les conditions de test de façon détaillée

incluent:

Offrir plus de flexibilité pour relier d’autres livrables (par ex. cas de test) aux bases et objectifs de test, et ainsi offrir un suivi meilleur et plus détaillé pour un Test Manager;

Contribuer à la prévention des défauts, dès que la base de test est définie et éventuellement avant que l’architecture et la conception détaillée ne soient disponibles;

Lier les livrables de test aux parties prenantes en des termes qu’elles peuvent comprendre;

Aider à influencer et orienter non seulement les autres activités de test mais aussi les autres activités du développement;

Permettre d’optimiser la conception, l’implémentation et l’exécution des tests, ainsi que leurs livrables correspondant, par une meilleure couverture de mesures et cibles détaillées;

Permettre la base d’une traçabilité horizontale plus claire au sein d’un niveau de test.

1.3 Analyse des Tests (4)

Certains inconvénients liés à une spécification détaillée des conditions de test incluent :

Une consommation potentiellement importante en temps;

La maintenabilité sera plus difficile dans un environnement changeant;

La nécessité de définir et mettre en œuvre le niveau de formalité au sein de l’équipe.

Les conditions de test peuvent être spécifiées avec moins de détails quand la base de test peut être facilement et directement reliée aux livrables de développement. Ceci sera plus probablement le cas pour:

Les tests au niveau des composants;

Des projets moins complexes où des relations hiérarchiques simples existent entre ce qui doit être testé et comment le tester ;

Des tests d’acceptation où des cas d’utilisation peuvent être utilisés pour aider à définir les tests.

1.4 Conception des Tests

La Conception des tests est l’activité qui définit “comment” quelque chose doit être testé.

Cela implique l’identification de cas de tests par une élaboration pas à pas des conditions ou de la base de test en utilisant les techniques identifiées dans la stratégie de test et/ou le plan de test.

Dépendant des approches utilisées pour mesurer, contrôler les tests, et en assurer la traçabilité, les cas de tests peuvent être directement (ou indirectement via les conditions de test) liés à la base de test et aux objectifs définis. Ces objectifs incluent les objectifs stratégiques, les objectifs de test et d’autres critères de succès définis pour le projet ou par les parties prenantes.

http://www.cftl.fr/index.php?id=94

Des définitions complémentaires

Plan de tests: un document décrivant l’étendue, l’approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d’indépendance des testeurs, l’environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser, et tout risque nécessitant des plans de contingence. C’est un document reprenant les processus de planification des tests [IEEE 829].

Scénarios de tests: une technique de conception de tests boîte noire dans laquelle les cas de tests sont conçus pour exécuter des scénarios de cas d’utilisation.

Types de tests

Fonctionnels:

-

est-ce que le logiciel est conforme a la spécification ?

-

liés a la spécification, a la qualité, a la performance, a l'interfaçage,

-

Non-Fonctionnels:

est-ce que son usage est conforme ?

lies a la configuration, la compatibilité, a la documentation, au stress,

-

-

-

la compatibilité, a la documentation, au stress, - - -  Structurels: - est-ce que le

Structurels:

- est-ce que le codage est correct ?

- fautes d'implémentation, ou fonctions non prévues.

Y-a-t-il des alternatives ?

Méthodes formelles:

model-checking, SAT,

méthode par raffinements (B)

,

Interprétation abstraite (estimation d'erreur, runtime-error, Ces méthodes sont de plus en plus employées. Problème: adéquation modele réalité, passage a l'echelle .

Relecture de code: détection d'erreurs statiques, mais pas dynamiques.

)

C'est lourd, mais ca favorise la connaissance du code.

Les règles de codage sont importantes, et peuvent être vérifiées par des outils.

Analyse de sécurité: validation d'une architecture. C'est l'identification en amont de tous les problèmes potentiels.

Etapes et hiérarchisation des tests

Test

structurel

Tests unitaires

Tests d ’intégration

Test

fonctionnel

Tests système

Génération de test Le test dynamique processus

Donnée de test

Programme P

Génération de données de test

Problèmes

Exécution

Résultat

Spécification S

Oracle

Oracle

non vérifié

Verdict

vrai

faux

Critère d’arrêt

Localisation / Mise au point

Diagnostique

Le test dynamique de logiciel

Soit D le domaine d’entrée d’un programme P spécifié par S, on voudrait pouvoir dire:

Soit D le domaine de P: xD, P(x) = S(x).

Test exhaustif impossible dans la plupart des cas

Domaine D trop grand, voire infini;

Trop long et coûteux.

On cherche alors un ensemble de données de test T tel que

T D;

si xT, P(x) = S(x) alors xD, P(x) = S(x).

Critère d’arrêt pour la génération de données de test

{données de test} = T.

22
22

La génération de test

Test fonctionnel (test boîte noire)

Utilise la description des fonctionnalités du programme

I

I 2

I 3

1

description des fonctionnalités du programme I I 2 I 3 1 O O 1 2 

O

O

1

2

Test structurel (test boîte blanche)

Utilise la structure interne du programme

I

I 2

I 3

1

O

O

1

2

Test fonctionnel

Spécification formelle:

Modèle B, Z.

Automate, système de transitions.

Description en langage naturel.

UML:

Use cases

Diagramme de classes (+ contrats).

Machines à états / diagramme de séquence.

24
24

Test structurel

A partir d’un modèle du code

modèle de contrôle (conditionnelles, boucles );

modèle de données;

modèle de flot de données (définition, utilisation

).

Utilisation importante des parcours de graphes

critères basés sur la couverture du code.

25
25

Génération de test

Génération déterministe

« à la main ».

Génération automatique aléatoire;

Génération automatique aléatoire contrainte:

mutation;

test statistique.

Génération automatique guidée par les contraintes.

26
26

Génération de test

Reste à savoir quand on a suffisamment testé:

critères de test structurels, fonctionnels;

analyse de mutation.

Choisir le bon niveau pour le test.

27
27

Exemple de test unitaire structurel

PGCD (plus grand commun diviseur) de 2 nombres:

Précondition: p et q entiers naturels positifs

pgcd: integer is local p,q : integer; do

read(p, q) while p<> q do if p > q

P1

then p := p-qB2 else q:= q-p

end -- if end -- while result:=p end-- pgcd
28

B1

P2

B3

B4

p=q

B4

S

E

B1

P1

p<>q

p>q

B2

P2

p<q

B3

Exemple de test unitaire structurel

p=q

B4

S

E

B1

P1

p<>q

p>q

B2

P2

p<=q

B3

Tous les noeuds:

(E, B1, P1, P2, B2, P1, B4, S) (E, B1, P1, P2, B3, P1, B4, S)

Tous les arcs : idem

Tous les chemins élémentaires (1-chemin) :

idem + (E, B1, P1, B4, S)

Tous les 2-chemins :

idem + (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)

Techniques de test fonctionnel

Test « boite noire »

N’utilise que la description fonctionnelle du programme

c’est la spécification

Plusieurs informations

domaine d’entrée

scénarios

use cases

30
30

Domaine d’entrée

Plusieurs niveaux

type des paramètres d’une méthode

pré-condition sur une méthode

ensemble de commandes sur un système

grammaire d’un langage

On ne peut pas tout explorer, il faut délimiter

31
31

Génération aléatoire

Analyse partitionnelle

Test aux limites

Graphe causes - effets

Technique 1: Analyse partitionnelle

A partir de la spécification

déterminer le domaine d’entrée du programme

Partitionner le domaine d’entrée en classes d’équivalences

identifier des classes d’équivalence pour chaque donnée

les classes d’équivalence forment une partition du domaine de chaque donnée en entrée

choisir une donnée dans chacune

32
32

Technique 2 : Test aux limites

Intuition:

de nombreuses erreurs se produisent dans les cas limites

Pour chaque donnée en entrée

déterminer les bornes du domaine

prendre des valeurs sur les bornes et juste un peu autour

Exemple

pour un intervalle [1, 100]

1, 100, 2, 99, 0, 101

33
33

Technique 2 : Test aux limites

Le programme lit trois nombres réels qui correspondent à la longueur des côtés d’un triangle. Si ces trois nombres ne correspondent pas à un triangle, imprimer un message d’erreur. S’il s’agit d’un triangle, le programme détermine s’il est isocèle, équilatéral ou scalène et si son plus grand angle est aigue, droit ou obtus.

34
34

Structurel/fonctionnel: conclusion

Les critères structurels et fonctionnels sont complémentaires

une erreur d’omission ne peut pas être détectée par le test structurel

du code mort ne peut pas être détecté par le test fonctionnel

Au niveau unitaire

on commence par le test fonctionnel

on complète par du test structurel

35
35

Oracle

Fonction qui évalue le résultat d’un cas de test

Plus formellement

soit un programme P: Dom(P) Ran(P)

une spécification S: Dom(P) Ran(P)

une donnée de test X Dom(P)

oracle O: Dom(P) × Ran(P) bool O(X, P(X)) = true if P(X) = S(X)

Problème : comment comparer P(X) et S(X)

plus S est formalisé plus on peut automatiser

36
36

Oracle

Oracle manuel: on « regarde » le résultat et un humain évalue s’il est bon

Construire le résultat attendu

Assertions

dans le code (programmation défensive)

aux interfaces (design by contract)

set_current_node (cnode: Node)

pre

: cnode != null

post : currentNode = cnode

dans les cas de test (par ex. JUnit)

37
37

Quelques notions importantes pour conclure

La relecture >> au test dynamique

La non-régression est fondamentale et implique la capacité à mémoriser les tests

On verra aussi que les contrats/assertions peuvent servir d’oracle embarqués

38
38

Un métier à part entière

Seule activité dans le cycle de développement ou l'on peut voir toutes les fonctionnalités d'un produit.

Différent des développeurs spécialisés,

C'est une activité créatrice:

- il faut imaginer les scenarii pouvant mettre le logiciel en defaut;

- il faut imaginer les bancs de tests, les environnements de simulations (logiciel de conduite de train, de contrôle des commandes de vol ) => comment faire ?)

- demande rigueur et compétence.

Mais c'est une activité mal perçue:

- le testeur est en fin de chaîne => retards

- certains tests sont répétitifs

- mal considérés par les développeurs

C'est pourtant une activité essentielle de R&D (research and development ).

Quelques principes de base

P1: Independence - un programmeur ne doit pas tester ses propres programmes. Mais il vaut mieux faire ses tests avant de délivrer, et aussi les conserver !

P2: Paranoïa - Ne pas faire de tests avec l'hypothèse qu'il n'y a pas

d'erreur (code trivial, déjà vu,

Conseil: un test doit retourner erreur par defaut. Le retour ok doit être force.

)

=> bug assure !

P3: Prediction - La définition des sorties/résultats attendus doit être effectuée avant l'exécution des tests. C'est un produit de la spécification.

c'est nécessaire pour des développements certifies

les données sont fournies parfois au niveau système (ex: Matlab), mais les résultats seront différents a l'implémentation.

parfois les données sont trop complexes a fournir directement

(éléments de compilation, environnement complexe

)

Quelques principes de base (2)

P4: Verification

Il faut inspecter minutieusement les résultats de chaque test.

Mais aussi la pertinence des tests .

(DO-178B): le processus assure un "tuyau" propre, mais il faut quand même des filtres = verification.

C'est la séparation de l'exécution et de l'analyse. P5: Robustesse Les jeux de tests doivent être écrits avec des jeux valides, mais aussi invalides ou incohérentes: on ne sait jamais ce qui peut arriver. P6: Complétude Vérifier un logiciel pour vérifier qu'il ne réalise pas ce qu'il est suppose faire n'est que la moitie du travail. Il faut aussi vérifier ce que fait le programme lorsqu'il n'est pas suppose le faire.

En cas de bug ?

Vérifier que le test est bien correct (P4);

Vérifier que le problème n'est pas déjà répertorie (base de bugs par exemple);

Etablir un rapport de bug;

- donner un synopsis succinct et précis;

- donner une description claire, avec tous les détails de reproduction du bug;

- si possible, essayer de réduire l'exemple.

Renvoyer un "tas" en disant "ca marche pas"

ne marche pas.

Conclusion

Le test est une activité importante;

Demande compétence, rigueur, créativité;

Le test ne s'improvise pas: il faut le penser des le début;

C'est une activité structurée, dans le cadre du projet:

C'est un travail collectif entre le développent et la validation; Une bonne base de tests, avec une régression simple a mettre en œuvre est aussi très appréciée du dev !