Processus de Test

Info inspirée de la documentation présentée parInternational Software Testing Qualifications Board

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) pourdévelopper, définir ou faire la promotion de contenus standardspour les formations en tests de logiciels, en ingénierie des exigenceset pour promouvoir les échanges autour des bonnes pratiques dansces deux domaines.

Comité Français des tests Logiciels, l'International Software TestingQualifications Board (ISTQB), et le Requirements EngineeringQualification Board (REQB) – organisations sans but lucratif,indépendantes et reconnues internationalement pour lescompétences certifiées.

Le programme de certification ISTQB Certified Tester fourni desconnaissances permettant de vérifier et tester efficacement deslogiciels. 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 niveauFondation 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 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 »

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.

Comité Français des Tests 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 la traçabilité pour regarder la complétude et la

cohérence des conditions de test définies par rapport auxobjectifs de test, à la stratégie de test, et au plan de test.

Expliquer les facteurs pouvant affecter le niveau de détailpossible pour les conditions de test et les avantages etdésavantages à spécifier les conditions de test à un niveau détaillé.

Objectifs d’Apprentissage pour Processus de Test (2)

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

1.5 Implémentation desTestsUtiliser les risques, établir les priorités, l’environnement de test, lesdonnées associées et les contraintes pour développer un planningd’exécution des tests qui soit complet et consistent par rapport auxobjectifs de test, à la stratégie de test et au plan de test.

1.6 Exécution desTestsUtiliser la traçabilité pour piloter l’avancement du test par rapport à lacomplétude et la cohérence par rapport aux objectifs de test, à lastraté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 ReportingExpliquer l’importance d’un recueil d’information précis eteffectué au bon moment dans le processus de test afin depermettre de réaliser de façon précise les rapports et lesévaluations par rapport aux critères de sortie.

1.8 Activités de Clôture desTests 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.

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 longdu projet, jusqu’à l’achèvement des activités de clôture pour ceniveau.

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 logicielfaisant partie de son périmètre (sur la base de l’analyse des risques, sinécessaire), de même qu’identifier précisément les caractéristiques quisont hors de son périmètre.

Dans un cycle de vie Agile, des sessions informelles de transfertd’information peuvent être utilisées pour transférer les informationsentre 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 partiesprenantes 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 sibesoin.

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

Les réactions appropriées aux informations du contrôle dépendrontdes 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 testgénérale, “Tester le paiement”, pour une application de commerceélectronique. Cependant, dans un document détaillé de conditionde test, cela pourrait être scindé en de nombreuses conditions detest, avec une condition par méthode de paiement acceptée, unecondition 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 unTest 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 soientdisponibles;

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

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

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

Permettre la base d’une traçabilité horizontale plus claire au sein d’unniveau 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 techniquesidentifié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, eten assurer la traçabilité, les cas de tests peuvent être directement (ouindirectement via les conditions de test) liés à la base de test et auxobjectifs définis. Ces objectifs incluent les objectifs stratégiques, lesobjectifs de test et d’autres critères de succès définis pour le projet oupar 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, lesressources et le planning des activités de test prévues. Il identifieentre autres les éléments et caractéristiques à tester, qui fera chaquetâche, le degré d’indépendance des testeurs, l’environnement detest, les techniques de conception des tests et les techniques demesure des tests à utiliser, et tout risque nécessitant des plans decontingence. C’est un document reprenant les processus deplanification des tests [IEEE 829].

Scénarios de tests: une technique de conception de tests boîte noiredans laquelle les cas de tests sont conçus pour exécuter des scénariosde 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,- ...

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équationmodele 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

20

Tests unitaires

Tests d ’intégration

Tests système

Test structurel

Test fonctionnel

Génération de test Le test dynamique processus

21

Donnée de test Programme P

Exécution

Oracle

Résultat Spécification S

Verdict

Critère d’arrêt

vrai

Localisation / Mise au point

faux

non vérifié

Problèmes

Génération de données de test

Oracle

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

La génération de test Test fonctionnel (test boîte noire) Utilise la description des fonctionnalités du programme

Test structurel (test boîte blanche) Utilise la structure interne du programme

23

I1I2I3

O1

O2

I1I2I3

O1

O2

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

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

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

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

Exemple de test unitaire structurel

28

Précondition: p et q entiers naturels positifs

pgcd: integer islocal p,q : integer;do

read(p, q) B1while p<> q do P1

if p > q P2then p := p-qB2

else q:= q-p B3

end -- ifend -- whileresult:=p B4

end-- pgcd

E

B1

P1

P2

B2 B3

S

B4

p<>qp=q

p>q p<q

PGCD (plus grand commun diviseur) de 2 nombres:

Exemple de test unitaire structurel

29

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)

E

B1

P1

P2

B2 B3

S

B4

p<>qp=q

p>q p<=q

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

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 Génération aléatoire Analyse partitionnelle Test aux limites Graphe causes - effets

31

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

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

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 necorrespondent pas à un triangle, imprimer un messaged’erreur. S’il s’agit d’un triangle, le programme détermines’il est isocèle, équilatéral ou scalène et si son plus grandangle est aigue, droit ou obtus.

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

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

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 != nullpost : currentNode = cnode

dans les cas de test (par ex. JUnit) ...

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

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 baseP1: 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, ...) => bug assure !Conseil: un test doit retourner erreur par defaut. Le retour ok doit être force.

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 ceque 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 !