TECHNIQUES DE TEST
ET
VALIDATION DU LOGICIEL
PRESENTATIONS
Informations pratiques
Outils à utiliser :
Selenium IDE ( Firefox plugin)
[Link]
Test link (open source test management)
[Link]
Firefox
Wampserver (un serveur web et un SGBD mysql )
[Link]
Mantis
[Link]
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