TECHNIQUES DE TEST

ET
VALIDATION DU LOGICIEL
PRESENTATIONS
Informations pratiques
Outils à utiliser :

 Selenium IDE ( Firefox plugin)

http://docs.seleniumhq.org/download/
 Test link (open source test management)

http://sourceforge.net/projects/testlink/
 Firefox

 Wampserver (un serveur web et un SGBD mysql )

http://www.wampserver.com/
 Mantis

http://www.mantisbt.org/download.php
Objectifs du cours
 Comprendre les enjeux des tests dans un projet informatique

 Avoir des connaissances sur les activités de tests et

l’industrialisation des tests

 Comprendre l’impact des évolutions du logiciel sur la

validation du logiciel et la gestion des non-regressions

 Avoir des exemples pratiques de contruction de plan de

tests, d’execution des tests et de reporting/communication
autour de la validation du logiciel.
 Mots clés
et
connaissances relatives aux tests
 Plan
PRESENTATION et INTRODUCTION
 Présentations
 Objectifs du cours
 Mots clés et connaissances relatives aux tests
 Présentation du plan du cours
 Métiers concernés par ce cours
 Risque projet et Stratégie de test

LE PROCESSUS DE TESTS DANS LES PROJETS DE CONCEPTION LOGICIEL

 Les phases de test
 Les différents acteurs
 Types de test
 Processus de gestion des régressions
 Tests – les couts, la durée
 Valeur ajoutée des tests
 Plan
PLANNIFICATION DES TESTS
 Définition d’un plan de test
 Construction d’un plan de test
 Définition des exigences, des processus métiers
 Définition des versions du logiciel et outil de versioning
 Définition des cas de test , des suites de tests
 Mise en place du test
 Documentation de la phase de tests

CAS PRATIQUE : CONSTRUIRE SON PLAN DE TESTS

 Les outils de planification et de gestion des tests
 Cas Pratique avec testlink
 Plan
EXECUTION DES TESTS ET GESTION DES BOGUES
 Principes d’exécution des tests
 La démarche et le processus de remontée des bogues
 Définition des priorités
 Allocation des ressources
 Gestion des environnements d’exécution
 Le cycle de vie d’un bogue

 Cas Pratique : avec Mantis et Testlink pour l’exécution

 Plan
EXECUTION DES TESTS ET L’INTEGRATION CONTINUE
 Les principes de l’intégration continue
 Test de Code : Junit, PhpUnit
 Présentation de selenium

 Cas pratique : Automatisation des tests avec Selenium

 Plan
VALIDATION DU LOGICIEL ET REPORTING
 Principes de validation du logiciel
 Définir et utiliser des métriques de tests. Points de validation? Les données, les traitements, les interfaces, la sécurité
 Définir les critères de sortie de la phase de tests
 Qualité des données
 Compte rendu et audit
 Construire et utiliser un compte rendu (les métriques, le contenu …)

VALIDATION DU LOGICIEL ET REPORTING

 Construire ses tableaux de bords
 Les indicateurs de validation
 Les activités de cloture de tests
 Les différents commités et l’arbitrage
 Améliorer le processus de tests avec TMMi, TPI Next, CTP, STEP
 DAY 1

LE COMMENCEMENT

Objectifs des tests

“Software testing is an extensive and critical activity for
providing quality and robust software”
Métiers concernés par ce cours

Chef de
projet MOE
Chef de Architecte
projet MOA

… Développeur Responsable
financier

Testeur Responsable
produit
Risques dans un projet informatique

Quels sont les risques dans un

projet informatique ?
Risques dans un projet informatique
Identifier les risques, c’est « jouer » l’anticipation

Types de risque
 Qualité produit
 Délais
 Conformité par rapport aux exigences
 Budget

Activités
 Identifier les risques du projet dès son démarrage
 Donner un score à chacun des risques
 Définir un plan d’actions permettant de les réduire
 Faire une évaluation périodique du score de chacun des risques
Stratégie de tests

 Il permet aux différents acteurs (chef de projet, testeurs, développeur …)

du projet de comprendre et d’être informés sur l’organisation des tests et
certains points clés nécessaires à la bonne exécution des tests.
 Ce document décrit:
 Les rôles et responsabilités des différents acteurs
 L’organisation des environnements pour l’exécution des tests
 Les différents niveaux de tests
 Les risques et les actions pour réduire ces risques
 Le planning de tests
 Les priorités
 Le processus de gestion des régressions
 Les outils utilisés
 Le reporting et la gouvernance
 La traçabilité d’exécution et de suivi des exigences du métier (requirements)
Les étapes d’un projet logiciel
• Etude préalable
EP

• Modélisation / mise à jour des processus métiers

BP

• Spécifications fonctionnelles
SF

• Spécifications techniques
ST

• Développement
DEV • Tests Unitaires

• Tests d’intégration
TI

• Test de bout en bout

ETE

• Recette utilisateur
UAT

• Mise en production
MP
Phases - test unitaire
 L’objectif des tests unitaires est d’être capable d’isoler le plus petit élément
du logiciel ou du composant logiciel et de valider qu’il fonctionne tel que
décrit dans les spécifications.
 La plus grande partie des anomalies doit etre identifiée et corrigée
pendant cette phase
 L’objectif est de réduire les tests élémentaires lors des phases suivantes
 L’investissement en temps nécessaire à la construction et la réalisation de
ces tests entraine souvent une négligence des équipes projets et à pour
conséquence l’accroissement des anomalies lors des phases suivantes.
 Plus une anomalie est identifiée tard dans le processus de développement
d’une application, plus elle coute chère à l’entreprise.
 Nous parlerons des frameworks d’automatisation des tests unitaires lors du
chapitre sur l’execution des tests
Phases - test d’integration (1to1)
 Les tests d’integration servent à valider que
l’ensemble des éléments et composants développés
séparément fonctionne bien ensemble.
 Pendant cette phase on teste essentiellement les
interfaces entre les composants assemblés
 Il est préférable de tester 2 composants entre eux
(1to1) que tous les composants ensemble.
 Les tests qui sont donc identifiés pendant cette
phase sont les tests de liaison entre composant
Phase - test de bout en bout (EtoE)
 Les tests de bout en bout permettent de valider
l’integration fonctionnelle des composants du
logiciel et donc que le système dans son ensemble
fonctionne correctement.
 Les processus métiers peuvent être exécutés
pendant cette phase afin d’augmenter les chances
de succès de la recette utilisateur.
Phase - Recette utilisateur (UAT)
 L’objectif des UAT est de valider fonctionnellement
le logiciel, c’est-à-dire s’assurer que le logiciel livré
fonctionne correctement et correspond bien aux
exigences exprimées.
 Ils sont considérés comme des « black-box testing »
signifiant qu’on ne regarde pas le code et l’aspect
technique du logiciel mais ses fonctionnalités, ses
réponses au besoin business
 A la fin de cette phase, un PV (procès verbal)
validant la conformité aux exigences
Les acteurs
Phase de test Acteur

Tests unitaires Développeur

Développeur
Tests d’integration
Testeur

Développeur

Testeur
Tests de bout en bout
AMOA

Utilisateur*

Développeur

Testeur
UAT
AMOA

Utilisateur

*Sur certains projets des utilisateurs peuvent être positionnés en avance de phase sur les tests de bout en bout afin d’augmenter les chances de succès
Type de test - Performance
 Le logiciel répond bien aux contraintes de
performance exprimées
 La performance peut se mesurer à partir de
 Accès concurrents
 Chargements

 Affichage des pages

 Traitements

 Les tests de performance peuvent inclure une phase

de « stress test »
Type de test - Données
 Objectifs : Valider la cohérence et la qualité des
données
 Ce type de test ne tient pas compte des traitements
et analyse uniquement les flux.
 Comparaison des inputs et des outputs de données
en entrée et sortie de composant
Type de test - Traitements
 Objectifs: Valider la conformité des différentes
fonctions de l’application
 On exécute le workflow de chacune des fonctions
testées
Type de test - IHM
 Objectifs: Valider la conformité des IHMs avec les
spécifications
 Avec la multiplication des tailles d ’écran les
équipes de tests doivent désormais être sensibilisées
à cette problématique
Type de tests - Sécurité
 Objectifs : identifier les failles du logiciel
 Ces tests comprennent le contrôle de
 Confidentialités

 Authentification

 Droits et accès des utilisateurs

Type de tests – smoke tests
 Les “smoke tests” sont des tests basics qui permettent
d’identifier les anomalies les plus simples.

 Les “smoke tests” repondent à des questions telles que

“Est-ce que le programme tourne?”, “reussi t’on à lancer
l’application?”

 Les “smoke tests” ne concernent que les fonctions clés

 Les "smoke tests" sont toujours réalisés avant de faire

les tests détaillés
Type de test – Non régression
 Toute modification d’un élément du programme, d’un module
d’un composant doit faire l’objet de test de non régression.
 Le correction d’une anomalie peut avoir des effets de bord
et entrainer d’autres anomalies
 L’objectif de ces tests est d’identifier des anomalies
inexistantes avant ce nouveau développement et qui
altérerait le fonctionnement actuel du logiciel
 La non régression peut être testée
 en exécutant de nouveau la « batterie » de tests
 En ajoutant des tests spécifiques qui ne testent pas ce qui vient
d’etre livré mais ce qui pourrait être impacté par cette livraison
 Le principal moyen de se prémunir des régressions est
l’automatisation et l’industrialisation d’une batterie de tests
Impact de coûts
 Impact au niveau du cout d’une détection tardive
d’anomalie

Exemple:
Is the error due to a defect in unit 1?
Is the error due to a defect in unit 2?
Is the error due to defects in both units?
Is the error due to a defect in the interface between the units?
Is the error due to a defect in the test?
Finding the error (or errors) in the integrated module is much more complicated than
first isolating the units, testing each, then integrating them and testing the whole.
Travaux Pratiques
Valeur ajoutée des tests

A vous de jouer