Le document traite des tests en génie logiciel, soulignant leur rôle essentiel dans l'assurance qualité en vérifiant la conformité des produits aux intentions prévues. Il aborde divers aspects des tests, y compris la testabilité, les types de tests (unitaires, d'intégration, fonctionnels), et les aspects liés à l'organisation et à la planification des activités de test. Enfin, il met l'accent sur l'analyse des erreurs et les stratégies à adopter pour optimiser la détection des défauts dans un logiciel.

1. Génie Logiciel
TEST

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

19. Taux de découverte de bogues
et arrêt des tests

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
 ...

26. Couverture des branches
[branch coverage ou decision coverage]
 Toute branche est exécutée au
moins une fois

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

28. Couverture des chemins
[path coverage]
 Tout chemin est exécuté au moins
une fois

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

30. MERCI