| Prochaine révision | Révision précédente |
| d5:c01 [2025/09/18 08:36] – créée dthevenot | d5:c01 [2025/09/26 08:26] (Version actuelle) – [Les différents types de tests] dthevenot |
|---|
| ~~SLIDESHOW~~ | ~~SLIDESHOW~~ |
| | ====== Tests logiciels et cybersécurité ====== |
| | * Une application de paiement en ligne qui n’a pas testé correctement la validation des entrées -> un pirate injecte du code SQL et accède aux données bancaires. |
| | * Une messagerie qui ne vérifie pas les mots de passe trop faibles, et qui se fait pirater. |
| | “Est-ce que c’est juste un bug ? Ou est-ce une faille de sécurité ?” -> “Un logiciel non testé, ce n’est pas seulement un logiciel qui bug, c’est un logiciel qui met en danger les données et les utilisateurs.” |
| | |
| | Tester, ce n’est pas seulement vérifier que ça marche (“le programme renvoie le bon résultat”), c’est aussi vérifier que ça ne peut pas être détourné par un usage malveillant. |
| | |
| | ===== Enjeux pour la cybersécurité ===== |
| | * Prévenir les vulnérabilités connues : injections, buffer overflow, failles XSS… |
| | * Réduire le coût des failles : corriger un bug après mise en production coûte 10 à 100 fois plus cher qu’avant. |
| | * Conformité réglementaire : RGPD, normes ISO, critères ANSSI. |
| ====== Les différents types de tests logiciels ====== | ====== Les différents types de tests logiciels ====== |
| |
| Il existe différents types de tests logiciels, tels que les tests unitaires, les tests d'intégration, les tests fonctionnels, les tests d'acceptation, et plus encore ! | Il existe différents types de tests logiciels, tels que les tests unitaires, les tests d'intégration, les tests fonctionnels, les tests d'acceptation, ... |
| |
| Vous pouvez utiliser de nombreuses techniques de tests logiciels différentes pour vous assurer que les changements apportés à votre code fonctionnent comme prévu. Cependant, tous les tests ne sont pas égaux, et nous allons voir comment les principales pratiques de test diffèrent les unes des autres. | Vous pouvez utiliser de nombreuses techniques de tests logiciels différentes pour vous assurer que les changements apportés à votre code fonctionnent comme prévu. Cependant, tous les tests ne sont pas égaux, et nous allons voir comment les principales pratiques de test diffèrent les unes des autres. |
| ===== Tests manuels ou automatisés ? ===== | ===== Tests manuels ou automatisés ? ===== |
| |
| À un niveau supérieur, nous devons faire la distinction entre les tests manuels et les tests automatisés. Les tests manuels sont effectués en personne, en cliquant dans l'application, ou en interagissant avec le logiciel et les API avec les outils appropriés. Cette méthode est très coûteuse, car il faut quelqu'un pour configurer un environnement et exécuter les tests, et elle peut être sujette à l'erreur humaine, car le testeur peut faire des fautes de frappe ou omettre des étapes dans le script de test. | Les tests peuvent être **manuels et/ou automatisés**. Les tests manuels sont effectués en personne, en cliquant dans l'application, ou en interagissant avec le logiciel et les API avec les outils appropriés. Cette méthode est très coûteuse, car il faut quelqu'un pour configurer un environnement et exécuter les tests, et elle peut être sujette à l'erreur humaine, car le testeur peut faire des fautes de frappe ou omettre des étapes dans le script de test. |
| ===== ===== | ===== ===== |
| Les tests automatisés, d'autre part, sont effectués par une machine qui exécute un script de test programmé à l'avance. Ces tests peuvent énormément varier en termes de complexité, de la vérification d'une seule méthode dans une classe jusqu'à s'assurer que l'exécution d'une séquence d'actions complexes dans l'interface utilisateur mène aux mêmes résultats. Cette méthode est beaucoup plus robuste et fiable que les tests manuels, mais la qualité de vos tests automatisés dépend de la qualité de vos scripts de test. | Les tests automatisés, d'autre part, sont effectués par une machine qui exécute un script de test programmé à l'avance. Ces tests peuvent énormément varier en termes de complexité, de la vérification d'une seule méthode dans une classe jusqu'à s'assurer que l'exécution d'une séquence d'actions complexes dans l'interface utilisateur mène aux mêmes résultats. Cette méthode est beaucoup plus robuste et fiable que les tests manuels, mais la qualité de vos tests automatisés dépend de la qualité de vos scripts de test. |
| ===== ===== | ===== ===== |
| Les tests automatisés sont un élément clé de l'intégration continue et de la livraison continue. Ils constituent un excellent moyen d'adapter votre processus de qualité à mesure que vous ajoutez de nouvelles fonctionnalités à votre application. Mais il est toujours utile de lancer des tests manuels avec ce qu'on appelle des tests exploratoires, comme nous le verrons dans ce guide. | Les tests automatisés sont un élément clé de **l'intégration continue** et de **la livraison continue**. Ils constituent un excellent moyen d'adapter votre processus de qualité à mesure que vous ajoutez de nouvelles fonctionnalités à votre application. Mais il est toujours utile de lancer des tests manuels avec ce qu'on appelle des **tests exploratoires**. |
| |
| ===== Les différents types de tests ===== | ===== Les différents types de tests ===== |
| === 1. Tests unitaires === | === 1. Tests unitaires === |
| <bootnote>vu en 1ère année</bootnote> | <bootnote>vu en 1ère année</bootnote> |
| | Testent une partie (une unité) d’un système afin de s’assurer qu’il fonctionne correctement. |
| |
| Les tests unitaires sont de très bas niveau, près de la source de votre application. Ils consistent à tester les méthodes et fonctions individuelles des classes, des composants ou des modules utilisés par votre logiciel. Les tests unitaires sont en général assez bon marché à automatiser et peuvent être exécutés très rapidement par un serveur d'intégration continue. | Les tests unitaires sont de très bas niveau, près de la source de votre application. Ils consistent à **tester les méthodes et fonctions individuelles des classes, des composants ou des modules utilisés** par votre logiciel. Les tests unitaires sont en général assez bon marché à automatiser et peuvent être exécutés très rapidement par un serveur d'intégration continue. |
| ===== ===== | ===== ===== |
| === 2. Tests d'intégration === | === 2. Tests d'intégration === |
| | Testent le système sur une plate-forme proche de la plate-forme cible. |
| |
| Les tests d'intégration vérifient que les différents modules ou services utilisés par votre application fonctionnent bien ensemble. Par exemple, ils peuvent tester l'interaction avec la base de données ou s'assurer que les microservices fonctionnent ensemble comme prévu. Ces types de tests sont plus coûteux à exécuter, car ils nécessitent que plusieurs parties de l'application soient fonctionnelles. | Les tests d'intégration vérifient que **les différents modules ou services utilisés par votre application fonctionnent bien ensemble**. Par exemple, ils peuvent tester l'interaction avec la base de données ou s'assurer que les microservices fonctionnent ensemble comme prévu. Ces types de tests sont plus coûteux à exécuter, car ils nécessitent que plusieurs parties de l'application soient fonctionnelles. |
| ===== ===== | ===== ===== |
| === 3. Tests fonctionnels === | === 3. Tests fonctionnels === |
| | Les tests fonctionnels se concentrent sur **les exigences métier d'une application**. Ils vérifient uniquement la sortie d'une action et non les états intermédiaires du système lors de l'exécution de cette action. |
| Les tests fonctionnels se concentrent sur les exigences métier d'une application. Ils vérifient uniquement la sortie d'une action et non les états intermédiaires du système lors de l'exécution de cette action. | |
| |
| Il y a parfois une certaine confusion entre les tests d'intégration et les tests fonctionnels, car ils nécessitent tous les deux plusieurs composants pour interagir. La différence réside dans le fait qu'un test d'intégration peut simplement vérifier que vous pouvez interroger la base de données, tandis qu'un test fonctionnel s'attend à obtenir une valeur spécifique de la base de données, telle que définie par les exigences du produit. | Il y a parfois une certaine confusion entre les tests d'intégration et les tests fonctionnels, car ils nécessitent tous les deux plusieurs composants pour interagir. La différence réside dans le fait qu'un test d'intégration peut simplement vérifier que vous pouvez interroger la base de données, tandis qu'un test fonctionnel s'attend à obtenir une valeur spécifique de la base de données, telle que définie par les exigences du produit. |
| ===== ===== | ===== ===== |
| === 4. Tests de bout en bout === | === 4. Tests de bout en bout === |
| | Les tests de bout en bout reproduisent **le comportement d'un utilisateur avec le logiciel** dans un **environnement applicatif complet**. Ils vérifient que les différents flux d'utilisateurs fonctionnent comme prévu et peuvent être aussi simples que le chargement d'une page Web ou la connexion. Des scénarios beaucoup plus complexes peuvent aussi vérifier les notifications par e-mail, les paiements en ligne, etc. |
| Les tests de bout en bout reproduisent le comportement d'un utilisateur avec le logiciel dans un environnement applicatif complet. Ils vérifient que les différents flux d'utilisateurs fonctionnent comme prévu et peuvent être aussi simples que le chargement d'une page Web ou la connexion. Des scénarios beaucoup plus complexes peuvent aussi vérifier les notifications par e-mail, les paiements en ligne, etc. | |
| ===== ===== | ===== ===== |
| Les tests de bout en bout sont très utiles, mais ils sont coûteux à réaliser et peuvent être difficiles à gérer lorsqu'ils sont automatisés. Il est recommandé d'avoir quelques tests clés de bout en bout et de s'appuyer davantage sur des tests de niveau inférieur (tests unitaires et d'intégration) pour être en mesure d'identifier rapidement les changements de dernière minute. | Les tests de bout en bout sont très utiles, mais ils sont coûteux à réaliser et peuvent être difficiles à gérer lorsqu'ils sont automatisés. Il est recommandé d'avoir quelques tests clés de bout en bout et de s'appuyer davantage sur des tests de niveau inférieur (tests unitaires et d'intégration) pour être en mesure d'identifier rapidement les changements de dernière minute. |
| ===== ===== | ===== ===== |
| === 5. Tests d'acceptation === | === 5. Tests d'acceptation === |
| | Testent le système afin de s’assurer qu’il est conforme aux besoins. |
| |
| Les tests d'acceptation sont des tests formels exécutés pour vérifier si un système répond à ses exigences métier. Ils nécessitent que l'application soit entièrement opérationnelle et se concentrent sur la simulation du comportement des utilisateurs. Ils peuvent aussi aller plus loin, et mesurer la performance du système et rejeter les changements si certains objectifs ne sont pas atteints. | Les tests d'acceptation sont des **tests formels exécutés pour vérifier si un système répond à ses exigences métier**. Ils nécessitent que l'application soit entièrement opérationnelle et se concentrent sur la simulation du comportement des utilisateurs. Ils peuvent aussi aller plus loin, et mesurer la performance du système et rejeter les changements si certains objectifs ne sont pas atteints. |
| ===== ===== | ===== ===== |
| === 6. Tests de performance === | === 6. Tests de performance / de robustesse === |
| | Testent le comportement de l’application au limite des ressources disponibles (mémoire, CPU, …) sur la plate-forme. |
| |
| Les tests de performance évaluent les performances d'un système sous une charge de travail spécifique. Ces tests permettent de mesurer la fiabilité, la vitesse, l'évolutivité et la réactivité d'une application. Par exemple, un test de performance peut observer les temps de réponse lors de l'exécution d'un nombre important de demandes ou déterminer le comportement du système face à une quantité élevée de données. Il peut déterminer si une application répond aux exigences de performances, localiser les goulots d'étranglement, mesurer la stabilité pendant les pics de trafic, et plus encore. | Les tests de performance évaluent **les performances d'un système sous une charge de travail spécifique**. Ces tests permettent de mesurer la fiabilité, la vitesse, l'évolutivité et la réactivité d'une application. Par exemple, un test de performance peut observer les temps de réponse lors de l'exécution d'un nombre important de demandes ou déterminer le comportement du système face à une quantité élevée de données. Il peut déterminer si une application répond aux exigences de performances, localiser les goulots d'étranglement, mesurer la stabilité pendant les pics de trafic, et plus encore. |
| ===== ===== | ===== ===== |
| === 7. Smoke tests === | === 7. Smoke tests === |
| | Les smoke tests (tests "vitaux") sont des tests simples qui vérifient le fonctionnement de base d'une application. Ils sont conçus pour être rapides à exécuter, et leur but est de vous donner l'assurance que les caractéristiques principales de votre système fonctionnent comme prévu. |
| |
| Les smoke tests sont des tests simples qui vérifient le fonctionnement de base d'une application. Ils sont conçus pour être rapides à exécuter, et leur but est de vous donner l'assurance que les caractéristiques principales de votre système fonctionnent comme prévu. | Ils peuvent être utiles juste après la création d'un build afin de décider si vous pouvez exécuter des tests plus coûteux. Ils peuvent également être utiles après un déploiement afin de vous assurer que l'application s'exécute correctement dans l'environnement nouvellement déployé. |
| |
| Les « smoke tests » peuvent être utiles juste après la création d'un build afin de décider si vous pouvez exécuter des tests plus coûteux. Ils peuvent également être utiles après un déploiement afin de vous assurer que l'application s'exécute correctement dans l'environnement nouvellement déployé. | === 8. Tests de sécurité === |
| ===== ===== | |
| ==== Comment automatiser vos tests ==== | Testent que l’application ne contient pas de failles de sécurité connues (injection de code, attaque XSS, …) |
| |
| Pour automatiser vos tests, vous devrez d'abord les programmer en utilisant un framework de test adapté à votre application. **PHPUnit, Mocha, RSpec** sont des exemples de frameworks de test que vous pouvez utiliser pour PHP, Javascript et Ruby respectivement. Il existe de nombreuses options pour chaque langue. Vous devrez donc peut-être faire des recherches et échanger avec les communautés de développeurs pour déterminer le meilleur framework pour vous. | |
| ===== ===== | ===== ===== |
| Si vos tests peuvent être exécutés via un script depuis votre terminal, vous pouvez les faire exécuter automatiquement par un serveur d'intégration continue comme Bamboo ou utiliser un service cloud comme Bitbucket Pipelines. Ces outils surveilleront vos dépôts et exécuteront votre suite de tests chaque fois que de nouveaux changements seront apportés au dépôt principal. | [[d5:A02]] |