2. Cour développé par
Akrouh Mohamed
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
Asrihi Yousra
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
Dans le cadre des projets de fin de semestre, nous sommes en tâche de préparer un cours sur les
tests unitaires. Ce travail est demandé par Madame LAMIAE notre enseignante du module Qualité
Logiciel.
2
Sabbani Anas
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
5. “Les tests logiciels est une activité
permettant de vérifier si les résultats
réels correspondent aux résultats
attendus et de s’assurer que le
système logiciel est sans défaut.
5
9. Les catégories de
tests logiciel
○ Les tests fonctionnels
○ Les tests non fonctionnels
○ Maintenance
Il faut noter que ces types ne sont pas applicables
à tous les projets. Cela dépend souvent de la
nature et de la portée de ce dernier.
9
10. Tests Fonctionnels
10
On parle de tests fonctionnels quand il s'agit de vérifier qu'une classe permet
bien de remplir avec succès l'objectif fixé par un cas d'utilisation donné. Un
test fonctionnel permet de répondre à la question « est-ce que le code permet
de faire ça ? » ou « est-ce que cette fonctionnalité attendue est bien
fonctionnelle ?
11. Tests Non-Fonctionnels
11
les tests non-fonctionnels vérifient des propriétés qui ne sont pas directement
liées à une utilisation du code. Il s'agit de vérifier des caractéristiques telle que
la sécurité ou la capacité à monter en charge. Les tests non-fonctionnels
permettent plutôt de répondre à des questions telles que « est-ce que cette
classe peut être utilisée par 1000 threads en même temps sans erreur ? ».
12. Maintenance
12
Selon la définition de l'AFNOR, la maintenance vise à maintenir ou à rétablir un bien dans un état
spécifié afin que celui-ci soit en mesure d'assurer un service déterminé .
La maintenance regroupe ainsi les actions de dépannage et de réparation, de réglage, de révision,
de contrôle et de vérification des logiciels.
Un service de maintenance peut également être amené à participer à des études d'amélioration du
processus industriel, et doit, comme d'autres services de l'entreprise, prendre en considération de
nombreuses contraintes comme la qualité, la sécurité, l'environnement, le coût, etc.
13. Les types de test
logiciel
13
Categories Type
Test
fonctionnels
Unit Testing - Integration Testing
Test non
fonctionnels
Performance - Endurance
Load - Volume
Maintenance
Regression - Maintenance
14. TESTS AUTOMATISÉS
14
Déf: Un test automatisé est un test dont l'exécution ne
nécessite pas l'intervention d'un humain.
L'exécution de tests automatisés requiert donc l'utilisation
de solutions informatiques dont le but est d'exécuter des
actions, soit spécifiquement dans un navigateur web, soit
plus généralement au niveau du système d'exploitation.
15. TESTS AUTOMATISÉS
15
Beaucoup de tests relativement basiques doivent être réalisés très régulièrement durant le cycle de
vie d'un logiciel, ce qui rend leur exécution manuelle fastidieuse pour un ROI faible. D'autre part,
dans certains contextes (projets web notamment), les tests doivent être réalisés sur différentes
plateformes, différents navigateurs de différentes versions, etc.
Avantage : ces scripts peuvent être réutilisés pour tester votre produit ultérieurement.
Inconvénient : cela implique un temps et un coût de création.
16. Tests Manuels
16
Lors de tests manuels, c’est une personne, un testeur expérimenté, qui va naviguer dans votre produit. Il l’utilise
comme le feront vos futurs utilisateurs. Les tests manuels peuvent se dérouler de deux façons différentes :
Test avec scénario - Le testeur suit des parcours définis au préalable pour contrôler la qualité de l’application sur
des problématiques bien précises.
Test exploratoire - Le testeur navigue librement dans l’application pour y déceler le maximum de bugs et de
problèmes.
17. Tests Manuels
17
Avantage : Contrairement au test automatisé, le test manuel vous permet de tester l’UI (user
interface) et UX (user experience) de votre produit : l’affichage correct du texte, les liens, les
images. Cela vous permet de déceler des bugs qui seraient visibles par vos utilisateurs mais
n’auraient pas pu être repérés par un robot.
Inconvénient : Les tests manuels ne peuvent pas être répliqués aussi facilement que les tests
automatisés.
19. “Un test unitaire est un procédé
permettant de s'assurer du bon
fonctionnement d'une unité de
programme.
19
20. Il s’agit simplement de vérifier, en fonction
de certaines données fournies en entrée
d’un module de code , que les données qui
en sortent ou les actions qui en découlent
sont conformes aux spécifications du
module.
Définition
20
21. Le test définit un critère d'arrêt (état ou
sorties à l'issue de l'exécution) et permet de
statuer sur le succès ou sur l'échec d'une
vérification. Grâce à la spécification, on est
en mesure de faire correspondre un état
d'entrée donné à un résultat ou à une sortie.
Le test permet de vérifier que la relation
d'entrée / sortie donnée par la spécification
est bel et bien réalisée.
utilité
21
22. utilité
22
● Trouver les erreurs rapidement
● Sécuriser la maintenance
● Documenter le code:
Il est possible que la documentation ne soit plus à jour, mais les
tests eux correspondent à la réalité de l'application.
24. Fonctionnement
24
On définit généralement 4 phases dans l'exécution d'un test unitaire :
1. Initialisation (fonction setUp) : définition d'un environnement de test complètement
reproductible (une fixture).
2. Exercice : le module à tester est exécuté.
3. Vérification (utilisation de fonctions assert) : comparaison des résultats obtenus
avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS
(SUCCÈS) ou ÉCHEC (FAILURE).
4. Désactivation (fonction tearDown) : désinstallation des fixtures pour retrouver l'état
initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests
doivent être indépendants et reproductibles unitairement (quand exécutés seuls).
25. Cycle de vie d’un test
25
Software Testing Life Cycle (STLC):
26. Utilisation des mocks
26
Les mocks sont des objets permettant de simuler un objet réel de façon contrôlée.
Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de couverture
de code, et de fiabilité des tests.
● pour simuler une base de données, un service web, etc., les interactions entre
l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs
fonctionnements peut être un gain de temps considérable ;
● certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici
de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de
code, par exemple le catch d'une exception ;
● sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code
qui est testé (par exemple une base de données).
27. Outils de Test
Unitaire
27
❖ AUnit11 pour Ada ;
❖ ASUnit12 pour ActionScript ;
❖ Cppunit13 pour C++ ;
❖ CUnit14 pour C ;
❖ DUnit pour Delphi ;
❖ FLEXunit pour Adobe Flex ;
❖ Google Test15 et Boost Test16 pour C++ ;
❖ HUnit17 pour Haskell ;
❖ JSUnit18, QUnit19 et Unit.js20 pour JavaScript
❖ Tape pour JavaScript ;
❖ Test::Unit pour Ruby ;
❖ Test::More pour Perl ;
❖ JUnit21 et TestNG22 pour Java ;
❖ NUnit23 pour .NET ;
❖ Microsoft Unit Test24 pour .NET ;
❖ xUnit25 pour .NET ;
❖ NUnitASP26 pour ASP.NET
❖ OUnit27 pour OCaml ;
❖ OCunit pour Objective C ;
❖ PBUnit pour PowerBuilder;
❖ PHPUnit28, SimpleTest29 et Atoum30 pour PHP ;
❖ utPLSQL 31 pour PL/SQL ;
❖ Unittest et PyUnit pour Python ;
28. JUnit
28
est un framework de test unitaire pour le langage de programmation Java.
Créé par Kent Beck et Erich Gamma, JUnit est certainement le projet de la série
des xUnitconnaissant le plus de succès.
JUnit définit deux types de fichiers de tests. Les TestCase (cas de test) sont
des classes contenant un certain nombre de méthodes de tests. Un TestCase
sert généralement à tester le bon fonctionnement d'une classe. Une TestSuite
permet d'exécuter un certain nombre de TestCase déjà définis.
Dans un TestCase il n'y a pas de main méthod, chaque test étant indépendant.
JUnit est intégré par défaut dans les environnements de développement intégré
Java tels que BlueJ, Eclipse et NetBeans.
30. Cppunit
30
CppUnit est un module d'infrastructure de
test unitaire pour le langage de
programmation C ++. Il permet des tests
unitaires des sources C ainsi que du C ++
avec une modification minimale de la
source
31. PHPUnit28
31
Créé par Sebastian Bergmann en
2004, il intègre les concepts communs
aux bibliothèques de tests unitaires
xUnit. le code source de PHPUnit est
hébergé sur GitHub
36. ○ Ils permettent notamment de documenter
automatiquement le code source. En effet, la
lecture des tests permet de comprendre le
comportement attendu du code, et donc le
fonctionnement de l’application, tant
technique que logique.
Avantage
36
37. ○ Les développeurs peuvent appréhender
toutes les fonctionnalités apporté par un
système.
○ Nous pouvons tester des parties du projet
sans attendre que d'autres soient terminées.
Avantage
37
38. ○ Les tests automatisés représentent
donc un formidable outil de
non-régression
Avantage
38
39. ○ Les tests unitaires ne détectent pas toutes les
erreurs.
○
Limite
39
40. ○ Les tests unitaires ne peuvent pas l'évaluer tous
les chemins d'exécution,
○
Limite
40
41. ○
○ Les tests unitaires sont centrés sur une unité de
code, il ne peuvent pas détecter les erreurs
d'intégration.
Limite
41
42. Best Practices
Les cas de tests unitaires doivent être
indépendants.
En cas d'amélioration ou de modification
des exigences, les tests élémentaires ne
doivent pas être affectés.
42
44. Best Practices
Suivez les conventions de dénomination
claires et cohérentes pour vos tests
unitaires
44
45. Best Practices
En cas de changement de code dans un
module, assurez-vous qu'il existe un
scénario de test d'unité correspondant pour
le module et que le module réussisse les
tests avant de modifier la mise en œuvre.
45
46. Best Practices
Plus vous écrivez de code sans avoir à
tester, plus vous aurez de chemins à vérifier
pour détecter les erreurs.
46
47. L'approche TDD(Test-Driven-Development)
Il existe trois approches concernant les tests unitaires :
1. Les développeurs n'en écrivent jamais (ne riez pas, c'est
malheureusement la majorité des cas) ;
2. Les développeurs écrivent les tests quand ils ont le temps et la
motivation (c'est à dire très rarement) ;
3. Les développeurs commencent par écrire les tests avant toute
ligne de code métier.
47
48. TDD
1. Cette dernière
approche porte un
nom : le TDD, pour
Test-Driven-Developme
nt. La règle est assez
simple : vous
commencez par écrire
les tests qui permettent
de valider les
différentes exigences
de votre application.
Ensuite, vous écrivez le
code de votre
application qui permet
de valider ces tests.
2. Cette méthode permet
d'éviter d'écrire trop de code. La
base de code est plus saine et
moins sujette aux erreurs. D'un
autre côté, il n'est pas toujours
évident d'avoir cette approche
avec des tests d'interface ou
lorsqu'une connectivité réseau
est présente. Car les paramètres
qui rentrent en compte sont
multiples.
3. Pour faire simple, cette
approche est intéressante pour
tester son modèle, et c'est ce que
nous allons voir dans les prochains
chapitres.
48