diff --git a/content/conduite_projet/4_tests/imgs/pyramides_tests.svg b/content/conduite_projet/4_tests/imgs/pyramides_tests.svg new file mode 100644 index 0000000..28ffa19 --- /dev/null +++ b/content/conduite_projet/4_tests/imgs/pyramides_tests.svg @@ -0,0 +1,230 @@ + + + + + Pyramide des tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Pyramide des tests + 2024.10.13 + + + ephase + + + + + CC BY-SA + + + Français + Schéma représantant la pyramide des tests + + + + + + + + + + + + diff --git a/content/conduite_projet/4_tests/index.md b/content/conduite_projet/4_tests/index.md new file mode 100644 index 0000000..39399d9 --- /dev/null +++ b/content/conduite_projet/4_tests/index.md @@ -0,0 +1,75 @@ +--- +title: "Conduite de projet: les tests" +date: 2024-09-30 +tags: ["tests", agile"] +categories: ["Conduite de projet", "Cours"] +mathjax: true +--- + +Il existe plusieurs granularités et niveaux de tests. au plus haut niveau nous +avons l'adéquation entre ce que l'utilisateur veut et ce qui est proposé. + +![Pyramides des tests](./imgs/pyramides_tests.svg) + +Les niveaux de tests peuvent être représentés sous la forme d'une pyramide, plus +on monte: + +* plus les tests coûtent cher; +* plus ils sont nombreux; +* plus ils sont fragiles. + +Chaque unité de test dépends du contexte: procédure, fonction, méthode, classe. +Chaque développeur a sa façon d'écrire des tests. + +Les tests ne doivent pas faire parti des éléments à tester, ils doivent seulement +interagir avec eux. + +Nous avons: + + * Les **tests unitaires ou de composants** qui servent à tester les bouts de codes; + * les **tests d'intégration** pour tester les intégrations de composants entre + eux. + * les **tests systèmes** au niveau le plus haut. permet de tester l'absence de bug au niveau de l'utilisateur + + +## Les tests unitaires + +Ils doivent permettre d'améliorer la confiance accordée au code et agir comme +garde-fou. Il permettent aussi de trouver les fautes le plus tôt possible. Les +tests doivent être le plus léger possible, facile à lancer. Ainsi ils seront +exécutés le plus souvent possible. + +De facto, ils deviennent des **test de non régressions**. Ainsi tout travail de +refactorisation du code sera plus simple et plus confortable. + +### Tester quoi? + +En général, les fautes viennent des cas limites, nous voulons que **les +résultats obtenus** soient égaut **aux résultats attendus** + +### Anomalies et bugs + +Une anomalie dans le code fait que notre programme ne fonctionne pas comme il le +devrait, elle déclenche un bug. + +Un bon développeur ne doit pas avoir peur des anomalies et il doit pouvoir les +fixer. Un **bon testeur** doit trouver ces anomalies. Comme nous l'avons vu, si +`RO != RA` alors nous avond un bug. Pour le testeur, il faut préciser *l'état +initial*, la *suite de traitement*, et *le résultat attendu*. + +### Les oracles + +Parfois, il n'est pas possible de définir les **cas aux limites**. Dans ce cas +il est possible de passer par une **oracle**: une fonction test qui vérifie les +sorties pour un ensemble de valeurs en entrée. Dans le cadre d'une fonction de +tri, il est par exemple possible de créer une fonction qui définira une suite de +nombres choisi aléatoirement en entrée et vérifiera la sortie. + + +## Test d'intégration + +Ici nous testons les appels necessaires, il faut alors vérifier que nous n'avons pas d'erreurs et les valeurs qui nous sont retournées (validités du JSON par exemple). + +## Tests de validation + +Il faut "*scripter*" un scénario d'utilisation, définir le résultat attendu et le lancer et jouer notre scénario. Des outils spécialisés existent comme *Scelenium* pour tester les application web.