Tests Flashcards
Pourquoi des tests ?
Constat - La réalité des projets – Dérive dans le temps
! 51% des projets ne respectent pas leurs dates de
livraison
! 16.2% des projets sont livrés dans les temps et dans leur
budget prévu
– Surcoût du projet
! 43% des projets dépassent leur budget initial
! 53% des projets coûtent 189% du budget initialement
estimé
– Taux d’anomalies trop important
– Exigences oubliées, fausses ou mal-comprises
! 18% des solutions ne correspondent pas aux besoins des
utilisateurs
! 70% des défauts logiciels proviennent de l’expression
des besoins et de leurs spécifications
– Turnover des équipes
! Les logiciels deviennent de plus en
plus complexes et importants.
! les volumes de données sont de
plus en plus grands…
! Important de tester avant de
distribuer son code.
! Pas de programme sans erreur
(bug)!
Classes d’erreurs
! Les erreurs peuvent être de divers ordres.
Ø de calcul
Ø de logique
Ø d’entrée / sortie
Ø de traitement des données
Ø dépassement de tableau
Ø d’interface
Ø communication entre les programmes
Ø de définition des données
Ø etc.
Ces classes d’erreurs représentent 90%
des cas décelés.
Tests
! Les tests existent depuis toujours
(mauvaise perception).
! Prise de conscience actuelle de la
part des sociétés et notamment
des directions informatiques
(risque de dysfonctionnement,
perte financière, retard…).
! Les tests rassurent et permettent
de palier aux erreurs humaines.
Tests existent
depuis toujours
! De 1960 à 1980, il s’agissait
d’une mise au point.
! De 1980 à 1990, les tests
cherchaient uniquement à
trouver des erreurs.
! Depuis 1990, les tests se
veulent préventifs.
Objectifs des tests
! Quoi ? Objet à contrôler / fourniture / livrable
– un logiciel ou système informatique produit
– Spécification
Objectifs des tests
! Pourquoi ? Des tests pour contrôler.
– Le bon fonctionnement d’un système informatique en
identifiant les défauts.
– Contrôle des nouvelles fonctionnalités.
– Intégration réussie avec l’existant.
– Vérification que les besoins des utilisateurs sont couverts.
– Satisfaction client
Objectifs des tests
! A l’aide de ? Un référentiel d’exigences
– Règles de gestion
– Architecture système
Objectifs des tests
! Trouver des anomalies qui n’ont pas été détectées
! Valider la conformité d’un livrable avec les exigences fournies
! Vérifier la conformité de l’implémentation des exigences fournies
! Vérifier la conformité d’un produit par rapport aux Règles de
gestion
! Vérifier la conformité d’un produit par rapport aux spécifications
techniques
Validation VS Vérification
! Est-ce que le logiciel fonctionne comme prévu ? – Les définitions des test sont souvent associées avec les termes
vérification et validation.
! La validation est le moyen de confirmer le respect
d’exigences déterminées pour une utilisation
spécifique prévue.
– Validation : Faisons-nous le travail attendu ?
! La Vérification est l’action de confirmer la satisfaction
des exigences spécifiques via l’étude et la mise à
disposition de preuves objectives.
– Vérification : Faisons-nous le travail correctement ?
Difficultés liées aux tests
! Impossible de réaliser un test exhaustif
! Qualité des tests dépend des données utilisées
! Impossible de supprimer l’erreur humaine
! Difficultés d’ordre psychologique, culturel
! Manque d’intérêt pour les tests
! Taille et complexité des programmes
! Différence entre environnement de
développement et de production
! Perte d’information naturelle
Cycle de vie VS Tests
! Les phases de tests font parties du processus qualité d’un projet
! Quelque soit le processus de développement mis en place
– Cycle en cascade
– Cycle en V
– Cycle iteratif
– Le cycle UP (Unified Process)
– Extreme Programming (XP)
– …
! Besoin d’apporter la preuve du résultat
Cycle de vie VS Tests
Expression des besoins
Spécifications fonctionnelles
Analyse
Conception
Implementation
Tests du systeme
Validation
Livraison
Cycle de vie VS Tests
! Les mouvements Agile et le Test-Driven Development
(TDD) ont encouragé de nombreux programmeurs à
écrire des tests unitaires automatisés
! TDD nous impose de commencer par écrire les tests
unitaires, avant le code de production
– Un cycle qui peut durer une trentaine de secondes.
– Les tests et le code sont écrits ensemble, en commençant par
les tests.
! De cette manière, nous écrivons des dizaines de tests par jour, des
centaines de tests par mois et des milliers de tests par an.
! ces tests couvriront virtuellement tout le code de production.
Les trois lois du TDD
! Première loi.
– Vous ne devez pas écrire un code de
production tant que vous n’avez pas
écrit un test unitaire d’échec.
! Deuxième loi.
– Vous devez uniquement écrire le test
unitaire suffisant pour échouer ;
l’impossibilité de compiler est un
échec.
! Troisième loi.
– Vous devez uniquement écrire le code
de production suffisant pour réussir le
test d’échec courant.
Types VS Techniques de tests
! Types de tests
– Catégories de tests effectués tout au long du cycle devie du logiciel.
! Tests unitaires
– Vérifier que l’objet fournit les services décrits
! Tests d’intégration
– vérification du bon enchaînement des fonctions et des programmes afin de valider
l’architecture technique du logiciel
! Tests de validation du système ou vérification
– Vérifier que les fonctions fournissent les bons résultats et sont conformes aux exigences essentiellement fonctionnelles.
! Recette (ou acceptation) utilisateur
– Contrôle par des utilisateurs du logiciel pour s’assurer que le produit répond à leur besoins.
Types VS Techniques de tests
! Techniques de tests
– Techniques utilisées durant les phases de tests (types de tests)
– Techniques fonctionnelles, structurelles , dynamiques, statiques,
flots de données, graphes cause-effet, …
Processus de test
Définir la stratégie et plan de test
Élaborer les scénarios de test
Spécifier les cas de tests
Exécuter les cas de tests
Analyser les résultats des cas de tests
Stratégie VS Plan de test
! La stratégie de test ne couvre que les vues générales sur la
manière d’aborder le processus de test. Les détails, comme
qui effectue les tests et la manière dont les étapes doivent
être effectuées, sont laissés au plan de test.
Stratégie VS Plan de test
– Organiser les phases de tests
! Qui?
– Equipe de développement
– Equipe spécifique
– Client
