Fondamentaux des tests - thebear45.free.frthebear45.free.fr/miage/Master 1/MAC/Cours/ch5 - Cours Tests.pdf · Tester pendant le cycle de vie logiciel 20. 11 2. ... •Techniques avancées

1

1

Tests

Frédéric MOALUniversité d’Orléans

Master M1 MIAGE 2011/2012

Partie 1

Fondamentaux des tests

2

2

Fondamentaux des tests

� Qu’est-ce que le testing ?� Origine et coûts des défauts logiciels� Pour quelle réalité ?� Rôle des tests dans le développement et

la maintenance� Planification, contrôle, exécutions et

critères d'arrêt des tests � Aspects sociologiques du métier de

testeur

Défaillances

Qu’est-ce que le Testing ?

Le Testing est l’ensemble des méthodes, processuset outils permettant de détecter les défaillances d’unlogiciel.

Défauts Fonctionnels

g Une absence de fonction.g Une incohérence d’IHM.g …

Défauts Techniques

g Un défaut de traitement.g Un défaut de communication

inter-composants…

3

Origine des défauts logiciels

� L’être humain à cause� des échéanciers serrés� de la complexité fonctionnelle� de la complexité du code et des infrastructures � des modifications de technologies � de multiples interactions entre les systèmes� ...

� Les conditions d’environnement � radiations� magnétisme� champs électroniques � Pollution� …

Pour quelle réalité ?Un décalage entre injection des défauts et détectio n des défaillances

70%

60%

50%

40%

30%

20%

10%

Conception Fabrication Qualification Exploitation

70%

20%

10%

4%17%

60%

19%

Introduction des défaillances

Détection des défaillances70% des défaillancesproviennent de la conception

ou de l’expression des besoins.

60% des défaillances ne sont détectées qu’à

l’occasion des « tests systèmes » et des « tests d’acceptation utilisateur ».

Source « National Institute of Standards & Technologies »

4

Pour quelle réalité ?Un coût toujours croissant des tests de régression

Coût d’une campagne de tests d’une évolutionFonction de la taille (fonctionnelle et/ou technique) de l’évolution

Soit une évolution de 100 jours développement

100 * 0,3 = 30 jours

Coût de la campagne de tests de régression exhaustifs associéeFonction de la taille du Système d’information

Notre évolution de 100 jours au sein d’un SI pesant 5000 jours

(5000-100) * 0,3 * 0,45 = 661 jours

g Pilotage des tests par les risquesg Industrialisation

Bonification

g Traçabilitég Automatisation

Bonification

Répartition des défauts affectant les projets logic iels

� D’autres études révèlent des problèmes de même nature� 82 % des travaux de correction et de reprise sont liés aux

erreurs de définition des exigences

� Les problèmes de spécification des besoins représentent 44 % des causes d’annulation de projets

� Seulement 54 % des exigences initiales sont effectivement réalisées

� Seulement 45 % des exigences réalisées sont finalement utilisées

5

CMMi : Globally address Cost of Software Quality

Cost as % of Development

0

10

20

30

40

50

60

70

1 2 3 4 5

CMMi Levels

TCoSQ

Lab N. Conf

Field N. Conf.

Testing

Prevention

g CMMi est un cadre permettant d’industrialiser les tests et le QA procedures, dans un cycle de développement logiciel.

g Les stratégies de test doivent prendre en compte TOUS les composants du coût : pre-release and post-release non conformance, appraisal (testing), assurance (quality control), prevention both at development and organization level.

Cos

ts

Quality Level 100%

Failure Costs

Total Quality Costs

Costs forprevention

and detection

Minimum

Source: Juran, 1988

Rôle des tests dans le développement et la maintena nce

Les processus de test représente de 30% à 50% des budgets projet mais lesdéfauts « latents » générant des anomalies critiques coûtent cher

Schedule

Selon un rapport de la firme Coverity, les logiciels propriétaires affichentencore une densité de 20-30 défauts par 1,000 lignes de code (KLOC),

un nombre inchangé depuis les années ’60, malgré le QA. (2004)

Encore aujourd’hui (2003), alors que l’industrialisation de la production logicielle a permisd’améliorer la productivité, 50% des projets ne tiennent pas leurs objectifs de coût et qualité

� S’assurer que le logiciel répond aux

exigences – couverture fonctionnelle

� Maîtriser les risques opérationnels

� Contrôler le coût des mise en production

� Établir la confiance dans le système

� Aider à l’éradication des anomalies

� Construire la qualité – est-elle suffisante?

� Crédibilité, réputation et être fiable

6

Rôle des tests dans le développement, la maintenanc e

� Des tests rigoureux des systèmes et de la documentation� aide à réduire les risques d’occurrence de problèmes dans

l’environnement opérationnel

� contribuent à la qualité des systèmes logiciels

si les défauts découverts sont corrigés avant la livraison du système pour un usage opérationnel.

� Les tests de logiciels peuvent aussi être nécessaire� pour respecter des exigences légales ou contractuelles

� atteindre des normes industrielles spécifiques..

Planification, contrôle, exécution et critères d'ar rêt des tests

� Décider de combien de test est suffisant devrait prendre en compte� le niveau de risque, incluant les aspects

� techniques� commerciaux � projet� humain,

� Les contraintes telles le temps et le budget.

� Les tests doivent fournir suffisamment d’informations� pour que les responsables puissent prendre des décisions informées

concernant la mise en production du logiciel ou du système en cours de tests,

� pour l’étape de développement suivante ou la livraison aux clients.

7


� Un nombre de principes de tests ont été suggérés au cours des 40 dernières années et offrent des indications communes à tous les tests :� Principe 1 – Les tests montrent la présence de défauts

� Principe 2 – Les tests exhaustifs sont impossibles

� Principe 3 – Tester tôt

� Principe 4 – Regroupement des défauts

� Principe 5 – Paradoxe du pesticide

� Principe 6 – Les tests dépendent du contexte

� Principe 7 – L’illusion de l’absence d’erreurs


� La planification des tests se compose des tâches majeures suivantes:� Déterminer la portée et les risques, et identifier les objectifs des tests.� Déterminer les approches de tests

� techniques, � objets de tests, � couverture, � identification et interfaces avec les équipes concernées par les tests,� outils de tests

� Déterminer les ressources de tests requises� personnel, � environnement de tests et Infrastructures.

� Implémenter la politique de test et/ou la stratégie de tests.� Planifier les tâches d’analyse et de conception des tests.� Planifier l’implémentation, l’exécution et l’évaluation des tests.� Déterminer les critères de sortie des tests.

8


� Le contrôle des tests se compose des tâches majeures suivantes:�Mesurer et analyser les résultats�Mesurer et documenter l’avancement, la

couverture des tests et les critères de sortie� Initier des actions correctives�Décider


� Evaluer les critères de sortie contient les tâches majeures suivantes:�Vérifier les registres de tests en fonction des

critères de sortie spécifiés dans la planification des tests.

�Evaluer si des tests supplémentaires sont requis ou si les critères de sortie doivent être changés.

�Ecrire un rapport de synthèse des tests pour les responsables.

9

Aspects sociologiques du métier de testeur

� Plusieurs niveaux d’indépendance peuvent être définis avec des tests conçus par :� la (les) personne(s) qui a (ont) écrit le logiciel à

tester (niveau faible d’indépendance).�une (des) autre(s) personne(s) du groupe (p.ex.

de l’équipe de développement).�une (des) personne(s) d’un groupe différent au

sein de la même organisation (p.ex. équipe de test indépendante).

�une (des) personne(s) d’une organisation ou société différente (p.ex. sous-traitance ou certification par un organisme externe).


�L’identification de défaillances pendant les tests peut être perçue comme une critique contre le produit et contre son(ses) auteur(s). Les tests sont, de ce fait, souvent vus comme une activité destructrice

�Rechercher des défaillances dans un système requiert de la curiosité, du pessimisme professionnel, un oeil critique, une attention au détail, une bonne communication avec ses pairs en développement, et de l’expérience sur laquelle baser sa recherche d’erreurs

10


� Les relations entre le test et le développement nécessitent donc de :�Commencer par une collaboration plutôt que par

des conflits �Rappeler à chacun l’objectif commun de

systèmes de meilleure qualité.�Communiquer les découvertes sur le produit de

façon neutre et factuelle sans critiquer la personne responsable,.

�Essayer de comprendre ce que ressent une autre personne et pourquoi elle réagit comme elle le fait.

�Confirmer que l’autre personne a compris ce que l’on a dit et vice versa.

Partie 2

Tester pendant le cycle de vie logiciel

20

11

��

2. Tester pendant le cycle de vie logiciel

� Préambule� Tests et modèles en V (ISO/CEI 12207) - Tests et modèles

itératifs� Niveaux de tests

� tests unitaires� tests d’intégration locale� tests système� tests d’acceptation

� Cible des tests� tests fonctionnels, � tests non fonctionnels, � tests de l’architecture logicielle, � tests de non régression

� Tests de maintenance, spécificité et mise en oeuvre

Que fait-on ?• des tests fonctionnels• des tests structurels • des tests de robustesse/performances • des tests d'ordonnancement • des test unitaires • des tests boite noire, boite blanche • des tests aux limites• des tests « métiers »• des tests de réception• des test de non régression• débogage• Tests dynamique, statiques

EXB

CF

CT

Réalisation Tests unitaires

Intégration

Validation

Réception

Préambule : Les questions autour du test

Qui fait les tests ?• MOA• MOE• Développeur• Spécificateur• Client• Fournisseur• Utilisateurs finaux•…

Quels sont les éléments de références ?• Exigences MOA• Cahiers des charges• Dossiers de spécifications fonctionnels• Dossiers de conceptions détaillées• Normes• Règles de l’art (explicites/implicites) • Règles de « bon sens »• Exigences techniques particulières• ...

Quels sont les objectifs de tests ?Quand fait-on les tests ? Doit-on outiller les tests ?

12

��

2. Tester pendant le cycle de vie logiciel (2h)






V&V – Construire la qualité en amont Testing – Optimiser la stratégie et les approches

1. Définir•Audit d’exigence•Traçabilité des exigences de test•Préparer Risk Based Testing•Planifier Stratégie Dynamic Testing

2. Développer•Tests Statiques de code (artefacts)•Tests sous surveillance

3. Tester•Techniques avancées de qualification•Exécuter Risk Based Tests

4. Intégrer & Recetter•Gestion critères de recette•Tests de processus métier•Co-ordination des tests bout-à-bout

MeilleureQualité

Plus grandeFiabilité

MOA

MOE

Tests et cycles en V : Positionnement des activités

13

Stratégie de tests initialeProtocole de réception initial

Dossier des résultats de réception

Dossier des résultats d'intégration

Définition des exigences

Conception fonctionnelle

Conception technique

Tests unitaires

Intégration

Validation

Réalisation

Plan d'intégration

Stratégie de tests finaleProtocole de réception final

Plan de validation et de réception

Plan de tests unitairesDossier des résultats de tests unitaires

Réception

Dossier des résultats de validation

Livraison incrémentale

Construction incrémentale

Stratégie évolutive

PHASE 1Définition

des exigencespilote, système

PHASE 2Développement

de pilote

PHASE 3Mise en servicepilote / système

Stratégie de testsProtocole de réceptionPlan de validation et deréception

Plan de tests TU+TIDossier des résultats TU

Dossiers desrésultats TI + TV+ réception

Tests : Cycles en V et Modèles itératifs

Séquences de test devant être mises en œuvre dans l e cadre d’un

projet

TESTUNITAIRE

TESTD’INTEGRATION

LOCALE

TESTSYSTEME (qualification)

TEST DE RECETTEUTILISATEUR

TEST D’INTEGRATION GLOBALE&

PREPARATION MISE EN PRODUCTION

Ordonnancement des séquences d’exécution(1)

et d’analyse des résultats des tests

(1) Ne présage pas du calendrier de fabrication du patrimoine nécessaire à l’exécution de ces tests

Equipe

de développement

Equipede test

Equipe Utilisateurs

TESTDIRECTORNON PERTINENT

TESTDIRECTOREST UN PLUS

TESTDIRECTOR S’IMPOSEEventuellement transfert, voire partage

du référentiel TestDirector

La déclinaison « test » des spécifications détailléesLa déclinaison « test » de l’architecture du logiciel

La déclinaison « test » des spécifications internes

14

Principes de synchronisation des activités de développement et de qualification

EXECUTIONNON REGRESSION

Itération n-1, n-2, n-x

INTEGRATIONLOCALE

Itération n

PROGRAMMATIONTEST UNITAIRE

Itération n

CONCEPTIONItération n

EXECUTIONDES TESTSItération n

SPECIFICATIONDES TESTSItération n

ELABORATIONPLAN DE TEST

Itération n

ELABORATION PLANDE NON REGRESSION

Itération n-1

AUTOMATISATIONNON REGRESSION

Itération n-1

Temps

Equipe de développement

Equipe de test

SPECIFICATIONItération n+1

��







15

Les Tests Unitaires

� De niveau composants élémentaires� Assure les fondations de construction du logiciel pour

� limiter les écarts par rapport à TOUTES les spécifications techniques et détaillées du composant à tester

� assurer la fiabilité de la phase de codage� s’assurer que chaque composant élémentaire remplis entièrement et

complètement la fonction définie

� dans une certaine mesure, vérifier le respect des normes de développement et de mise en œuvre des composants élémentaires

� Les principaux tests :

� Vérification du format des champs

� Vérification du caractère obligatoire ou facultatif des champs

� Vérification de tous les contrôles croisés entre champs

� Vérification des contrôles effectués sur liste de valeur

� Vérification des valeurs aux limites

� Vérification des règles d’ergonomie

� Vérification que les structures de données sont correctement mises à

jour

� Vérification du fonctionnement structurel des composants un à un

(tests boite blanche)

� …

Les Tests Unitaires

16

Les Tests Unitaires

� Préparer à partir du DCT du composant

� Préciser (Valider) le périmètre de l’objet des tests � Qu’est-ce qui fait partie du composant, qu’est-ce qui n’en fait pas partie

� Identifier les cas de tests et préciser les résultats attendus� Rechercher les règles de gestion� Rechercher les éléments pouvant donner lieu à « bug »

� Identifier les jeux d’essais et données de tests� Données à fournir au composant� Données instanciées en bases

� Définir les pré-requis et outils complémentaires� environnement, � « bouchons », � version des socles techniques, � lanceurs � Moyens d’accès au données avant/après

� Valider la couverture de tests prévus/périmètre à couvrir

Les Tests Unitaires

� Exécuter � Installer dans l’environnement de test

� Le composant à tester� Les pré-requis� Les données nécessaire

� Exécuter scrupuleusement chacun des cas identifiés en préparation� Identifier les résultats OK / NOK� Tracer le déroulement du cas pour être en mesure de :

� Fournir la preuve du test� Rejouer à l’identique un test (non régression)

� Le Test Unitaire n’est à faire qu’une fois le composant complètement codé (*)

� CF exemple JUnit

17

��







Les Tests d’Intégration Locale

� S'assurer du bon fonctionnement lors de l'assemblage � logiciel / logiciel � logiciel / données reprises� logiciel / matériel� logiciel / reste du S.I

� Conforter le découpage effectué en conception

� Construire l’application à partir des composants élémentaires préalablement testés unitairement

18


� Vérifier l’enchaînement correct des composants

� Vérifier les IHM « aux limites » techniques :� Comment réagit l’IHM en cas de saisie de valeurs extrêmes, quelles soient numériques

ou alphanumériques ?

� Vérifier l’intégrité globale des données manipulées et mises à jour dans la base de données� Une donnée saisie par l’utilisateur doit être instanciée correctement en base� Une donnée de la base doit être restituée correctement à l’utilisateur

� Vérifier que les séquences d’arrêt prématuré, volontaire ou involontaire, sont correctement traitées

� Valider les règles d’habilitation (autorisation ou limite d’accès au composant ou à l’un de ses fonctions élémentaires)

Chacun des composants est vu comme une boite noire dont on ne cherche pas à connaître le fonctionnement interne mais le fonctionnement en relation avec les autres composants


� Préparer toujours à partir des DCT� Identifier les points d’interface entre les composants élémentaires

� Zones de communication entre deux composants IHM� Zones de communication entre services IHM et service métier� Echange de fichier� Echange de flux� Interface interne / externe au projet ou à l’application…

� Identifier les règles de dialogue au niveau de chaque interface� Données fournies� Données restituées� Gestions des codes retour� Mode de dialogue synchrone / asynchrone� Traitement de masse / Traitement unitaire� Fonctionnement TP – Batch TP/Batch

� Identifier les versions de comptabilité des composants

� En déduire les cas de test et scénarios

19


� Exécuter� Assembler les composants dans l’environnement ad hoc

� Débouchonner� Mettre en place les composants à tester dans les versions définies� Les prérequis� Les données nécessaire

� Exécuter scrupuleusement chacun des cas identifiés en préparation� Identifier les résultats OK / NOK� Tracer le déroulement du cas pour être en mesure de :

� Fournir la preuve du test� Rejouer à l’identique un test (non régression)

� Les tests d’Intégration Locale peuvent débuter dès que 2 composants ayant une relation entre eux sont testés Unitairement

��







20

Les Tests Système (qualification)

� Il est de type « boite noire » et s’appuie sur une exigence fonctionnelle

� Il vérifie qu’a une sollicitation métier, le ou les résultats obtenus sont bien ceux escomptés, mais aussi que les limites fonctionnelles du logiciel sont gérées� � On prouve que ça marche, que le logiciel tourne selon ses spécifications

� Il vérifie qu’aux « étourderies » de l’utilisateur, des parades efficaces sont actives� Ex : L’utilisateur peut saisir deux fois le même code article sur deux lignes de

commande différentes ; il convient donc d’envisager ce cas de test…� � On prouve la robustesse fonctionnelle du logiciel

� A contrario il n’a pas vocation à vérifier le fonctionnement des objets sur lesquels l’utilisateur n’interagit pas

� Bien sûr, il n’a pas pour but de palier aux insuffisances de tests unitaires et de tests d’intégration locale

��







21

Les Tests d’Acceptation

� S'assurer du bon fonctionnement du logiciel dans son ensemble par rapport aux :�attendus METIER �spécifications fonctionnelles�exigences MOA/utilisateurs

et en condition la plus proche possible de l’opérationnel

��







22

Cible de tests : tests fonctionnels

� Les tests fonctionnels sont axés sur des exigences fonctionnelles

� Une exigence fonctionnelle � décrit un objectif, une finalité du système en fixant clairement les

frontières.� est issue d’un besoin métier qu’elle décompose en un enchaînement

logique d’actions, compréhensibles par l’utilisateur, exploitables par les équipes de conception et de développement mais pouvant également être testées par l’équipe de qualification.

� décline le cas d’utilisation usuel (le besoin est satisfait dans son intégralité sans qu’aucun événement ne soit venu perturber le déroulement du processus).Associé à ce cas d’utilisation « standard » un certain nombre d’autres cas d’utilisation dits « alternatifs » seront documentés avec la même rigueur que le cas d’utilisation usuel ; leurs origines peuvent être :

� métier « produit non disponible en stock » � technique « liaison réseau interrompue »

��







23

Cible de tests : tests non-fonctionnels

� Les tests non-fonctionnels incluent, mais pas uniquement les � tests de performance, � tests de charge,� tests de stress, � tests d’utilisabilité, � tests d’interopérabilité, � tests de maintenabilité, � tests de fiabilité,� les tests de portabilité.

� Ce sont les tests de “comment” le système fonctionne.� Ils peuvent être effectués à tous les niveaux de test. � Le terme de tests non-fonctionnels décrit les tests requis

pour mesurer les caractéristiques des systèmes et logiciels qui peuvent être quantifiés sur une échelle variable, telles que les temps de réponse pour les tests de performances.

��





� Cible des tests� tests fonctionnels, � tests non fonctionnels, � tests de l’architecture logicielle,� tests de non régression


24

Cible de test : architecture logicielle (tests structurels)

� Les tests structurels (boîte blanche) peuvent être effectués à tous les niveaux de tests. Ils :� sont utilisés de façon optimale après les techniques basées sur les

spécifications, � aident à mesurer l’ampleur des tests via l’évaluation de la couverture

d’un type de structure.

� La couverture � indique à quel point une structure a été exercée par une suite de

tests, � est exprimée en pourcentage des éléments couverts. A tous les

niveaux de tests, mais spécialement dans les tests de composants et les tests d’intégration,

� des outils peuvent être utilisés pour mesurer la couverture

��







25

Cible de tests : les tests de non régression

� Quand un défaut est détecté et corrigé, le logiciel devrait être retesté pour confirmer que le défaut original a été correctement ôté.

� Le test de régression � est la répétition des tests sur un programme déjà testé, après des

modifications, pour mettre à jour tout défaut introduit ou découvert en résultat de ce(s) changement(s).

� sont exécutés quand le logiciel, ou son environnement, est modifié.

Cible de tests : les tests de non régression

� Leur étendue est basée sur le risque de ne pas trouver d’anomalie dans un logiciel fonctionnant auparavant.

� Les tests devraient être répétables pour pouvoir être utilisés pour des tests de régression.

� Les tests de régression� peuvent être exécutés à tous les niveaux de tests, et s’appliquent aux

tests fonctionnels, non-fonctionnels et structurels. � sont exécutées de nombreuses fois � généralement évoluent lentement, � donc sont de bons candidats à l’automatisation.

26

Partie 3

Les techniques de tests

51

3. Techniques de tests

� Techniques statiques et revues de code� Techniques « boites noires »� Techniques « boites blanches »� Impact du choix d’une technique de test

27

Techniques statiques et revues de code

� Objectif : trouver des défauts dans le code source et les modèles logiciels

� N’exécutent pas le logiciel testé. � Elles sont :

�manuelles (revues) �automatisées (analyse statique).

� Trouve des défauts plutôt que des défaillances

� Peut détecter des défauts difficiles à trouver par les tests


� Revues� Les revues varient de très informelles à très formelles

� Revue informelle� Walkthrough� Revue technique� Inspection

� Facteurs de succès des revues� un objectif prédéfini et clair� des personnes impliquées et adéquates� des défauts trouvés bien acceptés, et exprimés objectivement� des aspects personnels et psychologiques traités � des techniques de revue adaptées

� aux types et au niveau de livrable logiciel,

� aux types et niveau de réviseurs.� des check-lists ou rôles� Des formations sont données sur les techniques de revue, � L’encadrement supporte un bon processus de revue � L’ accent est mis sur l’apprentissage et l’amélioration du processus.

28


� Les phases d’une revue formelle�Planification�Lancement �Préparation individuelle�Réunion de revue�Correction�Suivi


� L’analyse statique outillée vérifie le code programme � complexité� flux de contrôle � flux de données, � sorties générées telles que HTML et/ou XML.

� Elle permet � la détection rapide d’erreurs avant l’exécution des tests.� une information avancée sur certains aspects louches du code ou de

la conception, par le calcul de métriques.� la détection de dépendances et d’inconsistances dans les modèles

logiciels tels que de liens.� l’amélioration de la maintenabilité du code et de la conception.� la prévention des défauts, si les leçons sont prises en compte lors du

développement.

29


� Les défauts typiques découverts par les outils d’analyse statique incluent� Référencement d’une variable avec une valeur indéfinie� Interface inconsistante entre modules et composants� Variables qui ne sont jamais utilisées� Code non accessible (code mort)� Violation des standards de programmation� Vulnérabilités de sécurité� Violation de syntaxe dans le code ou le modèle logiciel.

� Ils sont typiquement utilisés par des développeurs et par les concepteurs

Techniques « boites noires »

Boîte noire =

sans référence à la structure interne du composant ou du logiciel

30

Techniques « boites noires »

� Les techniques de conception de tests �Partitions d’équivalence�Analyse des valeurs limites�Tables de décision�Diagrammes de transition d’états�Cas d’emplois

Techniques « boites blanches »

boîte blanche=

analyse de la structure du composant ou du système

31

Techniques « boites blanches »

� Niveau composant : la structure est celle du code lui-même � instructions, � décisions � branches

� Niveau intégration : la structure peut être un arbre (ou graphe) d’appel c’est à dire un diagramme où des modules appellent d’autres modules.

� Niveau système : la structure peut être � une structure de menus, � des processus métiers (commerciaux, fabrication …)� une structure d’une page web

Techniques « boites blanches

� Test des instructions et couverture � Dans les tests de composants, la couverture des

instructions est l’évaluation du pourcentage d’instructions exécutables qui ont été exercées par une suite de cas de tests.

� Test des décisions et couverture� La couverture des décisions, liées aux tests de

branches, est l’évaluation des pourcentages de résultats de décisions (p.ex. les options Vrai et Faux d’une instruction IF) qui ont été traitées par une suite de cas de tests.

32

Impact du choix d’une technique de test

� Le choix des techniques de tests à utiliser dépend d’un nombre de facteurs, incluant :� le type de système, � les standards réglementaires, � les exigences client ou contractuelles, � le niveau de risque, � Le type de risques, � les objectifs de test, � la documentation disponible, � la connaissance des testeurs, � le temps disponible et le budget, � le cycle de vie de développement utilisé, � l’utilisation de cas d’utilisation� l’expérience sur les défauts découverts précédemment.

� Quelques techniques sont plus applicables que d’autres à certaines situations et niveaux de tests, d’autres sont applicables à tous les niveaux de tests.

Partie 4

Gestion des tests

64

33

4. Gestion des tests

� Tâches du responsable des tests � Tâches des testeurs� Estimation des tests� Planification des tests� Critères de sorties� Suivi et contrôle du déroulement des tests� Gestion de configuration� Gestion des anomalies

Tâches du responsable des tests� Coordonner la stratégie et le plan du test.

� Apporter le point de vue du test aux autres activités du projet.

� Planifier les tests (en considérant le contexte et les risques) � sélection des approches de test,� estimation du temps, de l’effort et des coûts du test,� acquisition des ressources, � définition des niveaux de test, les cycles, l’approche et les objectifs � planification de la gestion d’anomalies.

� Démarrer la spécification, la préparation, l’implémentation et l’exécution des tests

� Surveiller et contrôler l’exécution.

� Adapter le planning en fonction des résultats et de l’avancement du test

34

Tâches du responsable des tests� Entreprendre les actions nécessaires pour résoudre les problèmes

� Mettre en place une gestion de configuration adéquate du logiciel de test à des fins de traçabilité.

� Introduire des mesures appropriées pour mesurer l’avancement du test et évaluer la qualité du test et du produit.

� Décider ce qui devrait être automatisé, à quel degré et comment.

� Sélectionner les outils pour aider le test

� Organiser la formation des testeurs à l’usage des outils.

� Décider de la mise en oeuvre de l’environnement de test.

� Établir des rapports de synthèse du test

Tâches des testeurs� Passer en revue les plans du test et y contribuer.� Analyser, passer en revue et évaluer, quant à leur testabilité,

� les exigences utilisateurs, � les spécifications et les modèles.

� Créer des spécifications de test.� Mettre en place l’environnement de test� Préparer et obtenir les données de test.� Implémenter des tests à tous les niveaux,

� exécuter et consigner les tests, � évaluer les résultats� documenter les écarts vis-à-vis des résultats attendus.

� Employer � les outils d’administration ou de gestion des tests� les outils de surveillance des tests en fonction du besoin.

� Automatiser les tests � Mesurer les performances des composants et systèmes � Passer en revue les tests développés par d’autres.

35

Estimation des tests� Deux approches de l’estimation de l’effort de test :

� basé sur des mesures issues de projets antérieurs ou similaires ou basée sur des valeurs typiques.

� par le détenteur des tâches de tests ou par des experts.

� L’estimation de l’effort de test doit prendre en compte� les objectifs de l’entreprise. � les caractéristiques, nature complexité et taille du domaine, du produit, du

métier � la qualité des exigences, de la documentation et autres informations utilisées � les exigences de fiabilité et de sécurité� les caractéristiques du processus de développement � la stabilité de l’organisation et le savoir-faire des personnes impliquées � les outils employés et le processus de test� les contraintes de temps� les résultats du tests : nombre de défauts et volume des reprises exigées.� les aspects réglementés,

Planification des tests

� Définir et prendre des décisions quant à� l’approche générale du test (stratégie de test), � la définition des niveaux de test et ce qui doit être testé� comment évaluer les résultats des tests et quand arrêter les tests (critères de sortie)� quels rôles vont exercer quelles activités.

� Intégrer et coordonner des activités de test dans les activités du cycle de développement

� Assigner les ressources aux différentes tâches définies.� Définir la documentation du test pour permettre une préparation et une exécution

reproductibles des tests� volume, � niveau de détail des procédures de test � structure et modèles.

� Sélectionner les mesures pour � suivre et contrôler la préparation et l’exécution du test, � éliminer des défauts � Résoudre les problèmes relatifs aux risques..

36

Critères de sortie

� l’objectif des critères de sortie est de définir quand arrêter le test,

� les critères de sortie :� Des mesures d’exhaustivité, comme la couverture de code, de

fonctionnalités ou de risques.

� L’estimation de la densité des anomalies ou des mesures de fiabilité.

� Le coût.

� Les risques résiduels, � anomalies non corrigées � manque de couverture du test dans certaines parties� ...

� Un calendrier, par exemple, basé sur la date de mise sur le marché

� ...

Suivi et contrôle du déroulement des tests

objectif du suivi du test =

fournir un retour et une visibilité sur les activités de test.

37

Suivi et contrôle du déroulement des tests

� mesures de test habituelles :� pourcentage de préparation des cas de test (cas de test préparés /

planifiés /)� pourcentage de préparation de l’environnement de test.� pour l’exécution de cas de test

� nombre de cas de test exécutés ou non � nombre de cas de test réussis ou échoués.� couverture des exigences, des risques ou du code

� Les informations sur les défauts � densité des défauts, � défauts trouvés et corrigés, � taux des défaillances et résultats du retest.

� Confiance subjective des testeurs dans le produit� Dates des jalons du test� Coût du test, y compris le coût de l’avantage de trouver le prochain

défaut comparé à celui de l’exécution du test suivant.

Gestion de configuration

objectif =

établir et maintenir l’intégrité des produits

du logiciel ou du système durant le cycle de vie du projet et du produit.

(composants, données et documentation)

______________aider le testeur à

identifier de manière unique (et à reproduire) l’élément testé,

les documents de test, les tests.

38

Gestion de configuration

� éléments du matériel de test � identifiés, � sous contrôle de versions,

� changements � identifiés et retraçables, � reliés les uns aux autres � reliés aux éléments de développement (objets de

test),

= la traçabilité maintenue pendant tout le processus du test.

� documents identifiés et éléments du logiciel référencés de manière non ambiguë dans la documentation de test

Gestion des anomalies

� l’un des objectifs du test est de découvrir des défauts

� les différences entre les résultats attendus et les résultats effectifs doivent être consignées en tant qu’anomalies.

� les anomalies devraient être suivis depuis leur découverte et classification jusqu’à leur correction et la confirmation de leur résolution.

� pour pouvoir gérer tous les anomalies jusqu’à la fin d’un projet, une organisation devrait établir un processus et des règles pour leur classification.

39


� objectifs des rapports d’anomalies � fournir aux développeurs et aux autres parties

un retour sur le problème concerné et permettre l’identification, la localisation et la correction nécessaires.

�Fournir aux responsables du test le moyen de suivre la qualité d’un système sous test et l’avancement du test.

�Fournir des idées pour l’amélioration du processus de test.


� informations sur une anomalie (si elles sont disponibles)� Résultats attendus et effectifs.� Date de la découverte de l’anomalie.� Identification ou élément de configuration du logiciel ou système.� Processus du cycle de vie du logiciel ou du système au cours duquel

l’anomalie a été observé� Description de l’anomalie.� Degré de l’impact sur les intérêts des détenteurs d’enjeux� Sévérité de l’impact sur le système� Urgence ou priorité de la correction� Etat de l’anomalie (par exemple, ouvert, soumis, doublon, en attente de

correction, corrigé en attente de test de confirmation, clôturé).� Conclusions et recommandations� Problèmes globaux, comme d’autres parties pouvant être impactées par

une modification résultant de l’anomalie.� Historique des modifications, tels que la séquence des actions

entreprises par des membres de l’équipe du projet afin de localiser l’anomalie, de le corriger et d’en confirmer la correction.

40

Partie 5

Les outils de support aux tests

79

5. Outils de support aux tests

� Outils de support et de gestion des tests � Outils d’aide aux tests statiques � Outils d’aide à la spécification des tests � Outils d’aide à l’exécution et au suivi des

tests � Outils de support des performances et de

surveillance

A noter : Quelques types d’outils peuvent être intrusifs

41

Outils de support et de gestion des tests

� Les fonctionnalités� Assistance à la gestion des tests et des activités de test effectuées.� Interface avec les outils d’exécution, outils de gestion des défauts et

outils de gestion des exigences.� Contrôle de version indépendant ou interface avec un outil de gestion

de configuration externe.� Support pour la traçabilité des tests, des résultants de tests et

incidents vers les documents source, tels les spécifications d’exigences.

� Enregistrement des résultats de test et génération des rapports d’avancement.

� Analyse quantitative (métriques) liées aux tests

� 3 types d’outils� Outils de gestion des exigences� Outils de gestion d’incidents� Outils de gestion de configuration

Outils d’aide aux tests statiques

� Outils d’assistance au processus de revue� archiver des informations relatives aux processus de revue,

garder et diffuser les commentaires des revues,

� informer sur les efforts et défauts

� gérer les références vers les règles de revue et/ou les checklists

� assurer le traçabilité entre les documents et le code source

� fournir de l’aide aux revues en ligne

� Outils d’analyse statique � recherche de défauts avant l’analyse dynamique.

� respect des standards de codage.

� analyse des structures et de leurs dépendances

� aide à la compréhension du code.

� calculer des métriques à partir du code (p.ex. complexité)

42


� Outils de modélisation�valider des modèles du logiciel. �Par exemple,

� vérificateur de modèle de bases de données peut trouver des défauts ou inconsistances dans le modèle de données ;

� d’autres outils de modélisation peuvent découvrir des défauts dans un modèle d’états ou un modèle objet.

�peuvent souvent aider à générer quelques cas de test basés sur les modèles


principal avantage des outils d’analyse statique et des outils de modélisation

= Rentabilité (Retour sur Investissement) procurée en découvrant d’avantages de

défauts plus tôt dans le processus de

développement.

43

Outils d’aide à la spécification des tests

� Outil de conception des tests� génèrent des entrées de test ou des tests réels à partir des

exigences, d’une interface utilisateur graphique (GUI), de modèles de conception (états, données ou objets) ou à partir du code.

� peut aussi générer les résultats attendus (p.ex. utilisation d’un oracle de tests).

� peuvent faciliter la génération des tests en offrant des cadres structurés, parfois appelés “test frame”, qui génèrent des tests ou des bouchons.

� Les tests générés à partir d’un modèle d’état ou d’un modèle objet � utiles pour vérifier l’implémentation du modèle dans le logiciel, � rarement suffisants pour vérifier tous les aspects du logiciel ou

du système concerné. � peuvent faire gagner un temps précieux et fournir une

exhaustivité accrue des tests par la complétude des tests que l’outil peut générer.

Outils d’aide à la spécification des tests

� Outil de préparation des données�agissent sur des bases de données, fichiers

ou transferts de données afin d’élaborer des données de tests utilisables lors de l’exécution des tests.

�s’assurer que les données réelles transférées vers l’environnement de tests sont rendues anonymes de façon à protéger leur contenu.

44

Outils d’aide à l’exécution et au suivi des tests

� Outils d’exécution des tests� Outils de tests dans un cadre unitaire

Comparateurs de tests� Outils de mesure de couverture � Outils de sécurité informatique


� Outils d’exécution des tests� permettent l’exécution automatique, ou semi-automatique, des

tests

� utilise des entrées archivées et des résultats attendus, par le biais d’un langage de script.

� permet répéter les tests avec des données différentes

� permet de tester une partie différente du système avec des étapes similaires.

� peuvent aussi être utilisés pour enregistrer des tests et dans ce cas peuvent être référencés comme des outils de capture et de rejeu

� En général, ces outils comprennent � des possibilités de comparaison dynamique

� proposent des information de suivi de chaque exécution des tests.

45


� Outils de tests dans un cadre unitaire � peut faciliter le test des composants ou parties de

systèmes en simulant l’environnement où s’exécute l’objet en cours de test.

� peuvent aussi être utilisés pour fournir un cadre d’exécution où les langages, systèmes d’opération ou matériels doivent être testés ensemble.

� aident à l’exécution des tests de composants en parallèle avec la construction du code.


� Comparateurs de tests� déterminent les différences entre les fichiers, bases de données

ou résultats de tests.

� Outils de mesure de couverture � peuvent être soit intrusifs, soit non-intrusif selon la technique

demesure utilisée, ce qui est mesuré et le langage de développement.

� mesurent le pourcentage de types de structures de code exercés (p.ex. instructions, branches ou décisions, et d’appels de modules ou de fonctions).

� indiquent de quelle manière le type de structure analysé a été parcouru par un jeu de tests.

� Outils de sécurité informatique� recherchent des virus informatiques et des attaques de déni de

service (denial of service). � stressent le système en y cherchant des vulnérabilités

spécifiques.

46

Outils de support des performances et de surveillan ce

� Outils d’analyse dynamique � détectent des défauts qui ne se manifestent que lors de l’exécution du

logiciel, telles les dépendances temporelles ou les fuites de mémoire.

� Outils de tests de performances / outils de tests de stress� surveillent et indiquent le comportement du système soumis à une

variété de conditions d’utilisation simulées. � simulent une charge sur une application, une base de données, ou un

environnement système, tel qu’un serveur ou un réseau. � sont souvent basés sur une répétition automatisée de tests, contrôlée

par des paramètres.

� Outils de surveillance� ne sont pas strictement des outils de tests, � fournissent de l’information pouvant être utilisée à des fins de tests et

qui n’est pas disponible par d’autres moyens.� analysent continuellement, vérifient et informent sur l’utilisation de

ressources système spécifiques, et alertent en cas de problèmes de service potentiels.

Bénéfices potentiels et risques lies aux outils de tests

� Le simple achat, ou la location d’un outil ne garantit par le succès� chaque type d’outil nécessite des efforts supplémentaires pour

atteindre des bénéfices réels et durables. � Les bénéfices potentiels à l’utilisation d’outils

� réduction du travail répétitif � réintroduction des mêmes données de tests, � vérification du respect de standards de codage).� répétitivité et cohérence accrues � Evaluation objective � Facilité d’accès aux informations au sujet des tests ou de leur exécution

� Les risques liés à l’utilisation d’outils � Attentes irréalistes placées dans l’outil � Sous-estimation du temps, du coût et de l’effort pour l’introduction

initiale d’un outil� Sous-estimation du temps et de l’effort nécessaires pour obtenir de

l’outil des bénéfices significatifs et continus de l’outil � Sous-estimation de l’effort requis pour maintenir les acquis générés par

l’outil.� Confiance excessive dans l’outil

47

Tests unitaires :exemple de JUnit

JUnit

� un framework open source (junit.org) pour le test unitaire de programmes Java qui permet d’automatiser les tests

� Deux versions du framework :JUnit 3.X :

classes de tests héritent de TestCaseJUnit 4.X :

utilisation des annotations Java (5+)94

48

Classes de Junit 3Te

sts

unita

ires

Un exemple simple version Junit 3

49

Ecriture d’une classe de test

� Un exemple simple de Classe à tester :

Test

s un

itaire

s

Ecriture d’une classe de test� Classe de test :

� Création des objets qui vont interagir lors du test� Code qui agit sur les objets impliqués dans le test� Vérification que le résultat obtenu correspond bien

au résultat attendu

Test

s un

itaire

s

50


static void assertTrue(boolean test)

méthode JUnit : vérifie que test == true et dans le cas contraire lance une exception (en fait une Error) de typeAssertionFailedError

L’exécuteur de tests JUnit attrape ces objets Errors et indique les tests qui ont échoué

Exécution des tests

� Résultat d’une exécution sous Eclipse :

100

51


Exécution d’un test

� Pour exécuter un testTestResult result = (new

CounterTest("testIncrement")).run();

� Pour exécuter une suite de testsTestSuite suite = new TestSuite();suite.addTest(new CounterTest("testIncrement"));suite.addTest(new CounterTest("testDecrement"));TestResult result = suite.run();

� En utilisant l’introspectionTestSuite suite = new TestSuite(CounterTest.class);TestResult result = suite.run();

52

Résultats d’un test

� JUnit propose des outils pour exécuter suite de tests et afficher les résultats� junit.textui.TestRunner : affichage textuel� junit.swingui.TestRunner : affichage graphique

� Ajouter à la classe de test une methode statique suitepour rendre une suite accessible à un "exécuteur de test" (TestRunner) :

public static Test suite() {TestSuite suite = new TestSuite();suite.addTest(new CounterTest("testIncrement"));suite.addTest(new CounterTest("testDecrement"));return suite;}

� Autre solution (introsepection)junit.textui.TestRunner.run(CounterTest.class);

� De nombreux IDE intègrent JUnit : NetBeans, JBuilder, Eclipse

tous les tests d’un package� TestSuite contient des objets Test

� Des TestCase mais aussi des TestSuite

� Une classe AllTest� Teste toutes les suite de tests du package

public class AllTests {public static Test suite() {TestSuite suite =

new TestSuite("Test for default package");suite.addTest(new TestSuite(TokenizerTest.class));suite.addTest(new TestSuite(NodeTest.class));suite.addTest(new TestSuite(ParserTest.class));suite.addTest(new TestSuite(TreeTest.class));return suite;}

}

53

tous les tests de sous-package

� Dans chaque package définir une suite qui inclus les suites des sous packages

public class AllTests_{public static Test suite() {

TestSuite suite =new TestSuite("All helix.* and subpackages tests");

suite.addTest(helix.edb.AllTests_.suite());suite.addTest(helix.def.AllTests_.suite());

return suite;}

}

Les méthodes assert

� static void assertTrue(String message , boolean test )� Le message optionnel est inclus dans l’Error

� static void assertFalse(boolean test )� static void assertFalse(String message , boolean test )

� vérifie que test == true

� assertEquals(expected , actual )� assertEquals(String message , expected , actual )

� méthode largement surchargée: arg1 et arg2 doivent être tout deux des objets ou bien du même type primitif

� Pour les objets, utilise la méthode equals (public boolean equals(Object o) sinon utilise ==

54


� assertSame(Object expected , Object actual )� assertSame(String message , Object expected , Object

actual )� Vérifie que expected et actual référencent le même objet (==)

� assertNotSame(Object expected , Object actual )� assertNotSame(String message , Object expected , Object

actual )� Vérifie que expected et actual ne référencent pas le même objet

(==)


� assertNull(Object object )� assertNull(String message , Object object )

� Vérifie que objet est null

� assertNotNull(Object object )� assertNotNull(String message , Object object )

� Vérifie que objet n’est pas null

55


� fail()� fail(String message )

� Provoque l’échec du test et lance une AssertionFailedError� Utile lorsque les autres méthodes assert ne correspondent pas

exactement à vos besoins ou pour tester que certaines exceptions sont bien lancées

try {

// appel d’une méthode devant lancer une Exception

fail("Did not throw an ExpectedException");

}

catch (ExpectedException e) { }

Un exemple version Junit 4

56

Exemple de classepublic class Operations {

public static long additionner(final long...pNombres) {long lRetour = 0;for(final long lNombre : pNombres) {

lRetour += lNombre;}return lRetour;

}// Cette méthode ne fonctionne pas correctement public static long multiplier(final long...pNombres) {

long lRetour = 0;for(final long lNombre : pNombres) {

lRetour *= lNombre;}return lRetour;

}}

111

Exemple de classe de Testpublic class TestSimple {

@Testpublic void additionAvecDeuxNombres() {

final long lAddition = Operations.additionner(10, 20);Assert.assertEquals(30, lAddition);

}@Testpublic void additionAvecCinqNombres() {

final long lAddition = Operations.additionner(256, 512, 1024, 2048, 4096);Assert.assertEquals(7936, lAddition);

}@Testpublic void mutiplicationAvecDeuxNombres() {

final long lMultiplication = Operations.multiplier(10, 20);Assert.assertEquals(300, lMultiplication);

}public void testMutiplicationAvecCinqNombres() {

final long lMultiplication = Operations.additionner(256, 512, 1024, 2048, 4096);Assert.assertEquals(1125899906842624L, lMultiplication);

}}

112

57

Exécution des tests

� Résultat d’une exécution sous Eclipse :

113

Test d’exception

public static long diviser(final long...pNombres) {if(pNombres.length < 2) {

throw new IllegalArgumentException("Il faut au moins deux nombres en entrée");

}long lRetour = pNombres[0];for(int i=1;i<pNombres.length;i++) {

lRetour /= pNombres[i];}return lRetour;

}

114

58

Test d’exception

public class TestThrowable {

@Test(expected=IllegalArgumentException.class)public void divisionAvecUnNombre() {

Operations.diviser(1);}

@Test(expected=ArithmeticException.class)public void divisionAvecDeuxNombresDontUnZero() {

Operations.diviser(10, 0);}

@Test(expected=ArithmeticException.class)public void divisionAvecDeuxNombres() {

Operations.diviser(10, 5);}

}115

Test d’exception

� Run :

116

59

Test de durée d’exécution

public class TestDureeLimitee {

@Test(timeout=1000)

public void dureeRespectee() {

}

@Test(timeout=1000)

public void dureeNonRespectee() throws InterruptedException {

Thread.sleep(10000);

}

}

117

Ignorer un test

public class TestIndisponibilite {

@Test

public void nonIgnore1() {

}

@Test

public void nonIgnore2() {

Assert.fail("Echec");

}

@Ignore

@Test

public void ignore() {

Assert.fail("Echec ignoré");

}

} 118

60

Méthodes pré/post tests

public class TestAvantApres {@Beforepublic void avantTest() {

System.out.println("------------------------");System.out.println("Avant Test");

}@Afterpublic void apresTest() {

System.out.println("Après Test");System.out.println("------------------------");

}@Testpublic void premierTest() {

System.out.println("Premier Test");}

…}

119

Méthodes pré/post Classe de test

public class TestAvantApresEnsembleTests{@BeforeClasspublic void avantTests() {

System.out.println("------------------------");System.out.println("Avant tous les Tests");

}@AfterClasspublic void apresTests() {

System.out.println("Après tous les Tests");System.out.println("------------------------");

}@Testpublic void premierTest() {

System.out.println("Premier Test");}

…}

120

61

JUnit 4

� Introduit de nouveaux tests et une syntaxe par « contrats »

� Exemple :

121

JUnit 4

import java.io.Serializable;import org.hamcrest.core.IsInstanceOf;import org.junit.Assert;import org.junit.Test;

public class TestContratClasseInstance {@Testpublic void classeDeString() {

Assert.assertThat("texte", IsInstanceOf.instanceOf(String.class));}@Testpublic void classeDeSerializable() {

Assert.assertThat("texte", IsInstanceOf.instanceOf(Serializable.class));}

…}

122

62

JMock

� Les assertions par contrat sont désormais intégrées à JUnit, mais sont à l'origine développées par JMock.

� La librairie originale comprend des contrats supplémentaires

123

JMock

� Ces contrats sont séparés en 7 groupes : � core (contrats intégrés dans JUnit et déjà vus dans les chapitres

précédents) : contrats de base sur les objets et les valeurs, ainsi que les contrats composés.

� beans : contrats sur les beans Java et leurs valeurs.

� collection : contrats sur les tableaux et les collections.

� number : contrats de comparaison numérique.

� object : contrats de contrôle des objets et des classes.

� text : contrats de comparaison de textes.

� xml : contrats sur les documents XML.

� Pour pouvoir les utiliser, il faut rajouter les jar : "jmock-2.5.1.jar ", "hamcrest-core-1.1.jar " et "hamcrest-library-1.1.jar ".

124

63

Contrats de Bean

� Le contrats "HasProperty" vérifie qu'un bean possède bien les getter et setter correspondants à une propriété

� Le contrat "HasPropertyWithValue" vérifie que la valeur d'une propriété d'un bean respecte un contrat passé en paramètre.

125

Exemple de contrat de Bean

� Deux classes « Bean » :

public class BeanSansPropriete {}

public class BeanAvecPropriete {private Integer prop;public void setProp(Integer pProp){prop = pProp;}public Integer getProp(){return prop;}

}

126

64

Exemple de contrat de Beanpublic class TestContratBean {

@Test

public void beanSansPropriete() {assertThat(new BeanSansPropriete(), hasProperty("prop"));

}@Test

public void beanAvecPropriete() {assertThat(new BeanAvecPropriete(), hasProperty("prop"));

}@Test

public void beanAvecBonneValeur() {final BeanAvecPropriete lBean = new BeanAvecPropriete();lBean.setProp(10);assertThat(lBean, hasProperty("prop", equalTo(10)));

}@Test

public void beanAvecMauvaiseValeur() {final BeanAvecPropriete lBean = new BeanAvecPropriete();assertThat(lBean, hasProperty("prop", equalTo(10))); 127

Résultat contrats de Bean

128

65

Principes

� Integration continue – Pendant le développement, le programme marche toujours – peut être qu’il ne fait pas tout ce qui est requis mais ce qu’il fait, il le fait bien.

� TDD Test Driven Development :pratique qui se rattache à l’eXtreme Programming

“Any program feature without an automated test simply doesn’t exist.” from Extreme Programming Explained, Kent Beck

Test Tips

� Code a little, test a little, code a little, test a little . . .� Run your tests as often as possible, at least as often as

you run the compiler ☺� Begin by writing tests for the areas of the code that

you’re the most worried about . . .write tests that have the highest possible return on your testing investment

� When you need to add new functionality to the system, write the tests first

� If you find yourself debugging using System.out.println(), write a test case instead

� When a bug is reported, write a test case to expose the bug

� Don’t deliver code that doesn’t pass all the tests

Documents

Fondamentaux des tests - thebear45.free.frthebear45.free.fr/miage/Master 1/MAC/Cours/ch5 - Cours Tests.pdf · Tester pendant le cycle de vie logiciel 20. 11 2. ... •Techniques avancées