Software Test and Analysis in a Nutshell - IGL601

Transcription

IGL601 – Hiver 2015
Révision
Brève révision
Jonathan Guay
Département d’informatique
Faculté des sciences
[email protected]
http://igl601-jg.espaceweb.usherbrooke.ca/
Pourquoi la vérification
validation du logiciel?
 Validation
 Construisons-nous le bon produit?
 Choisissons-nous les bonnes propriétés?
 Vérification
 Construisons-nous le produit correctement?
 Traduisons-nous correctement ces propriétés?
 Plus une erreur est découverte tardivement plus elle
coûte cher à réparer.
Copyright 2015 Jonathan Guay
Pourquoi la gestion des
configurations?
 Les logiciels:
 sont de plus en plus gros
 sont de plus en plus complexes
 sont de plus en plus variés
 possèdent de plus en plus d’artéfacts
 doivent s’exécuter sur les plateformes variées
 La durée de vie des logiciels est de plus en plus
longue
Cycle de vie du logiciel vs
vérification/validation
Source: Luc Lavoie IGL601
Procédés de
développement logiciel
 Trois familles importantes de procédés
1.
Prédictifs
 Réactifs
 Cascade
 V
 …
 Itératifs
 Cascade itératif
 RUP
 …
2. Synthétiques
 XP, Scrum, Kaban, …
3. Rétro-ingénierie
Introduction à la vérification
et validation
 Nécessité des tests pour vérifier et valider le logiciel
 Propriétés et critères
 Validité
 Fiabilité
 Robustesse
 Tolérance aux pannes
 Disponibilité
 Performance
 Coût de traitement
 Sécurité
 Sureté
 Etc…
et validation (suite)
 Qu’est-ce qu’un test?
 Définitions
 Anomalie
 Défaillance
 Erreur
 Défaut
 Essai (Test suite)
 Type de défauts
 Calcul, Logique, Traitement de données, Définition des
données, Interface (interne et externe)
et validation (suite 2)
 Classification des essais
 Essai unitaire
 Essai d’intégration
 Essai de système
 Essai contractuel (livraison, acceptation, qualification,
certification)
 Essai de mise en exploitation
 Essai de non-régression
 Classification des tests
 Unitaire, intégration, système, non-régression, …
 Peu utile: le même test peut être utilisés dans plus d’un essai
 Selon l’objet testé
 Spécification, code source, code exécutable
 Selon la technique utilisée
 Fonctionnelle vs structurelle
 Statique vs dynamique
 Vérification vs validation
 Que faut-il pour faire un essai?
 Banc d’essai
 Un jeu de données d’essai
 Une procédure d’essai
 Un cahier d’essai
 Un guide d’interprétation des résultats
 … un oracle
Techniques de tests
 Tests fonctionnels dynamiques
 Analyse axiomatique (types abstraits algébriques)
 Analyse partitionnelle
 Tests aux limites
 Tests syntaxiques
 Tests aléatoires
 Graphes fonctionnels
 Graphes de causes à effets
 Analyse transactionnelle
 Algorithmique qualitative
 Analyse combinatoire
 Tests structurels dynamique
 Analyse de flot
 Flot de données
 Flot de contrôle
Techniques de tests (suite)
Source: Pezzè and Young
Techniques de tests (suite 2)
 Tests structurels dynamique
 Avantages:
 Augmentation du niveau de confiance de la complétude
de notre jeu de tests
 Permet de tester des cas qu’on ne pourraient déduire
uniquement à l’aide des spécifications.
Exemple d’un
flot de contrôle:
Source image: Pezzè and Young
Techniques de tests (suite 3)
 Tests structurels dynamiques
 Type de tests structurels dynamiques
 Ligne de code
 Branche d’exécution
 Condition
 Branche et condition combiné
 Branche et condition modifié (MC/DC)
 Chemins
 Chemins intérieurs
 Linéaire et saut (LCSAJ)
 Cyclique
 Appel de fonctions
 Exemple de calcul du critère de couverture par ligne de
code:
# de ligne de code exécuté / # de ligne de code total
Types abstraits algébriques
 Il est nécessaire de définir
de manière non
ambigüe le
comportement d’une
routine.
 Composer d’une
signature et d’un système
d’axiomes
 Composer à l’aide de
règles d’écritures
 Le développement d’un
TA rend la
programmation plus
facile.
Inadéquation
 Vocabulaire
 Spécification de test
 Obligation de test
 Cas de test
 Essai
 Séance d’essai
 Critères d’inadéquation
 Pourquoi l’adéquation est inatteignable?
 Problème de la programmation défensive
Z = 10;
if (z < 0) { throw new ErreurInterne( “z aurait dû être positif !”) }
 Pourcentage de couverture
 Dominance des critères de couverture
Gestion des versions
 Objectifs:
 Conservation
 Maîtrise de l’évolution
 Traçabilité
 Service
 Centralisé
 Décentralisé
 Gestion des conflits
 Verrouillage
 Fusion
 Hybride
Revues logicielles
 Vocabulaire:
 Revue
 Inspection (contrôle)
 Audit
 À quel moment doit-on faire la revue?
 Qui sont les réviseurs?
 Comment élaborer une bonne grille de revues?
 Revue de code oui, mais aussi, de tous les types
d’artéfacts
Gestion des essais
 Le plan d’essai
 Techniques de test
 Procédures de tests
 Critères de tests
 Ressources requises
 Compétences requises
 Facteurs qui influenceront le plan de tests
 Gestion des risques généraux et spécifiques
 Suivi
 ODC, RCA
 Gestion des équipes
 Gestion des réunions
 Gestion des résultats
 Gestion des suites à donner
 Amélioration des processus
 Gestion des anomalies
 Gestion des configurations
 Cahier des essaies
Gestion des anomalies
 Procédé typique de gestion des anomalies entres les
différents intervenants
 Chargé de projet,
 programmeur,
 testeur,
 utilisateur,
 l’administrateur).
 Normes IEEE 1044 et ITIL
Gestion des anomalies
(suite)
Cycle de vie d’une
anomalie:
Gestion des configurations
 Objectif de la gestion des configurations
 Nécessité de la gestion des configurations
 Tout au long du cycle de vie du logiciel
 Gestions des configurations
 Gestion des sources
 Gestion des versions
 Gestion matériel
 Gestion de la documentation
 Définition d’une configuration
 Normes IEEE, DoD et ITIL
 Composante élémentaire
 Configuration de référence
 Besoins de la gestion des configuration
 Difficultés
Procédés de verification et
validation
 Tests unitaires
 Tests d’intégration
 Tests de système
 Tests de non-régression
 Procédé prédictif simple
 Normes IEEE
 Procédés de développement logiciels et la VV
Procédés de verification et
validation (suite)
 Procédé
prédictif simple
Amélioration des processus
 Aperçu des différents processus d’amélioration des
processus
 PSP, TSP, CMMI, SPICE (RCA)
 TPI
 Niveau de maturité et de compétence
 du CMMI et du PSP
Techniques de flux de
données
 Objectifs
 Détecter automatiquement et systématiquement
 Anomalies
 Incohérences
 Notion de dominance
 Notion de dépendance (def-use pairs)
 Notation en fonction des nœuds immédiats
 Reach(E) = ReachOut(D) …
 Notion Avail (disponibilité d’une variable)
 Notion Live (durée de vie d’une variable)
 Classification des analyses
 Avant/Arrière
 Any-Path vs All-Path
 Notion de sensibilité du flux
données (suite)
 Notion de dépendance (def-use pairs)
données (suite 2 )
 Graphe de dépendance directe de données
Tests combinatoires
 But de l’analyse combinatoire
 Approches
 Tests partionnels basés sur la catégorie
 Tests par paires
 Tests basés sur un catalogue
Bonne chance!

Software Test and Analysis in a Nutshell - IGL601

Transcription

Documents pareils

Fiche d`activité - Le corps humain

grillesRicha13rangs

Sortie à Lyon

Protection juridique des logiciels au sein de l`Union Européenne

igl601_td3_test_fonct_dyn_ap-gce_ap-trans - IGL601

Site "cuisine-virtuelle.com"

Un petit film, sur le handicap

Etre ou ne pas être, telle est la question

Ecole Normale de Musique de Paris - Ecole Roux