2. Le Test
Vérifie que le produit est conforme aux intentions
aspects surtout fonctionnels
Un des moyens de l'assurance qualité
le plus utilisé, aussi « vieux » que le développement
Méthode dynamique (en exécutant le logiciel)
vient après les méthodes statiques (analyses auto.)
dernier rempart contre les erreurs résiduelles
encore trop souvent empirique
3. Aspects psychologiques
Importance de l'intention
les tests sont élaborés en fonction de l'intention
vouloir démontrer que le programme marche = mauvaise approche car les
tests sont choisis en conséquence (ne trouvent rien de neuf)
Activité de test
processus « destructif »
objectif : mettre en évidence des erreurs
si on n'y aboutit pas, c'est un échec (!)
4. Aspects psychologiques
Plus facile de trouver les erreurs des autres que les siennes
on ne détruit pas bien ce qu'on a construit soi-même
à force de regarder, on ne voit plus rien
regard neuf : nouvelle interprétation des spécifications
→ Séparation des tâches
équipes de développement ≠ équipes d'intégration et de qualification
budget de qualification et de développement séparés
5. Testabilité
Facilité avec laquelle des tests peuvent être développés à partir des
documents de conception
faisabilité
coût
critères de décision de succès ou d'échec d'un test
couverture
Se prépare tout au long du cycle de vie
spécifications, conception globale et détaillée
(compréhensibles, précises, pertinentes, quantifiées...)
6. Facteurs de testabilité
Facteurs de bonne testabilité
précision, complétude, traçabilité des documents
architecture simple et modulaire
abstractions à travers des interfaces
politique claire des traitements d'erreur
Facteurs de mauvaise testabilité
forte contraintes d'espace mémoire et d'efficacité
intégration forte des traitements
longues chaînes de traitements
7. Limites théoriques
Notion d'indécidabilité
propriété indécidable = qu'on ne pourra jamais prouver dans le cas général
(pas de procédé systématique)
Exemples de propriétés indécidables
l'exécution d'un programme termine
deux programmes calculent la même chose
un programme n'a pas d'erreur
un paramètre du programme fait passer l'exécution
sur une instruction, une branche, un chemin donné
sur toutes les instruction, branches ou chemins
8. Terminologie : alpha- et bêta-test
Alpha-test (alpha testing)
test effectué en phase de développement, avant la distribution du produit (→
alpha-versions du produit)
Bêta-test (beta testing)
test effectué après l'alpha-test, en distribuant le produit (→ des bêta-versions)
à un groupe limité d'utilisateurs avertis
☛ dans la suite de ce cours : uniquement ∞test
9. Organisation de l'activité de test
Activité coûteuse → optimiser l'investissement
effort minimum / /probabilité max. de détection d'erreur
incrémentalité
Construction des tests
aussi organisée que celle d'un produit (!)
(☛ il y a des sociétés qui vendent des suites de test)
Gestion projet
planification suffisamment tôt (difficile d'accroître les ressources en fin de
développement)
10. Tâches
1. Définition des tests
2. Implémentation des jeux de tests
3. Soumission des jeux de tests
4. Dépouillement des résultats
5. Évaluation de la qualité des tests
6. Décision d'arrêter l'écriture de tests
7. Rejeu (maintenance, non régression)
11. Environnements (outils) de test
Mise en œuvre des jeux de test
construction de données et de contextes d'exécution
Diagnostic
définition de critères de réussite / échec
automatisable ou non (ex. test d'interface)
Synthèse des résultats
car les sorties des tests sont souvent très grosses
→ ne pas rater une erreur dans une masse de succès
Diffusion des résultats
12. Types de test
(éléments testés et phases)
Tests unitaires
test d'une fonction, une classe, un module
(pendant le développement)
Tests d'intégration
test de l'assemblage des modules
(pendant le développement)
Tests de validation
chez le fournisseur, par l'équipe de qualification, puis chez le client
Tests de suivi d'exploitation
13. Types de test
(nature des propriétés testées)
Tests fonctionnels
réaction à certaines entrées (sorties produites)
Tests de performance
vitesse, charge, ...
Tests de fiabilité
résistance aux pannes
Tests de sécurité, ...
☛ Tous types et étapes de test pas nécessairement présents : dépend de la criticité
du logiciel
14. Types de test
(selon les informations accédées)
Test boîte noire [black box testing]
évaluation de l'extérieur (sans regarder le code), uniquement en fonction des
entrées et des sorties
sur le logiciel ou un de ses composants
Test boîte blanche [white/glass box testing]
exploite le code (→ besoin du source/de l'architecture)
tests de portions de code : bloc, branche, etc.
15. Contenu d'un plan de test
Définition des cas de test
configuration matérielle et logicielle
préconditions
étapes du test
critères de réussite / échec
Chronologie et durée des étapes de test
pour chaque étape, chronologie et moyens de mise en œuvre des différents
jeux de test
modes d'intégration
16. Contenu d'un plan de test
Équipes concernées et responsabilités
Procédures de suivi
évaluation du degré de réalisation des tests
procédures de collecte de données statistiques
Actions à prendre en cas de découverte d'erreur
signalement aux développeurs
contrôle après corrections (suivi)
17. Contenu d'un plan de test
Délais et temps de calcul
Politique de passage des tests
(y compris les tests de non régression)
Normes
Outils et méthodes recommandés
Bibliothèques de tests
18. Critères d'arrêt des
développements de tests
Taux de couverture atteint (☛ critère a priori)
suffisamment d'aspects testés
Nombre ou taux d'erreurs découvertes
(☛ critère a posteriori)
courbe du nb d'erreurs en fonction de la durée
arrêt sous un certain seuil (→)
séparation des erreurs par catégorie
Épuisement des ressources dédiées au test (☹)
effort humain et/ou durée
20. Test fonctionnel
Ex: fonction qui attend un numéro de département (de métropole) entre 1
et 95 :
Ex: fonction qui attend une réponse oui/non :
21. Test fonctionnel :
Analyse aux bornes
L'expérience prouve que:
☛ Les erreurs se situent très souvent à frontières de comportements
différents
Par ex. :
indice de tableau tout juste trop grand ou trop petit
boucles avec une itération en trop ou en moins
comparaisons stricte au lieu de avec égalité, ou l'inverse
etc.
22. Test fonctionnel :
Analyse aux bornes
Sensibilité à la frontières de comportements
→ analyse précise aux bornes des classes
Plusieurs représentants par classe d'équivalence
une valeur « médiane » ordinaire
+ une ou plusieurs valeurs aux bornes
Aussi appelé « test aux limites »
23. Test fonctionnel :
Analyse aux bornes
fonction qui attend un numéro de département (de métropole) entre 1 et
95:
fonction qui attend une réponse oui/non :
24. Test boîte blanche
exploite le code
→ nécessite le source
+ graphe de flot de contrôle, graphe de flot de données, ...
tests de portions de code (bloc, branche, etc.)
éventuellement, marquage des portions de code
testées
effectivement parcourues
→ taux de couverture
25. Test fonctionnel :
Analyse de chemins
Basé sur le chemin d'exécution
boîte noire : d'après l'algorithme de la spécification
boîte blanche : d'après le graphe de flot de contrôle
Couverture
des branches (ou des instructions)
de séquences de branches
des chemins
...
27. Couverture des instructions
[instruction coverage]
Toute instruction est exécutée
au moins une fois
Idem couverture de branche
parcourir tous les nœuds~
parcourir tous les arcs
29. A retenir
Test = processus « destructif »
pas d'erreur trouvée (chez un autre) = échec
Notion de plan de test
poser le problème du compromis couverture/effort
Tests boîte noire / boîte blanche (code visible)
Tests fonctionnels :
partition des entrées, test aux limites, combinatoire
couverture des branches et chemins
Instrumentation, auto-test (assertion) et oracle