Dans le syllabus ISTQB distingue 5 types de test :
- Les tests fonctionnels
- Les tests non-fonctionnels
- Les tests structurels
- Les tests liés aux changements : qui se composent des tests de confirmation et les tests de régression
Le logiciel à tester peut-être modélisé et représenté sous la forme d’un diagramme.
Cette représentation permet aux développeurs de mieux comprendre ce qu’ils doivent fabriquer, et aide les testeurs à concevoir les tests de s’assurer qu’ils couvrent tous les cas de figure importants.
Par exemple :
- Diagramme de transition d’état :
- Diagramme de flux de processus
- Diagramme de contrôle de flux
- La structure de menu
- Modèle de menace de sécurité
- Spécification en langage naturel : en français le moins technique possible
On verra dans le chapitre 4 quelques-unes de ces techniques de modélisation.
1. Tests fonctionnels
Les fonctions sont ce que « fait » le logiciel.
Par exemple pour une application d’une banque :
- Créer un compte bancaire
- Modifier un compte bancaire
- Faire un virement
- Imprimer le RIB
- Commander une carte bancaire
- …etc
Les tests qui vérifient ces fonctionnalités sont appelés « Les tests fonctionnels ».
Le test fonctionnel est de loin le plus populaire parmi les types de test.
Ces tests sont conçus à partir des livrables non techniques qui décrivent le fonctionnement attendu de l’application, comme :
- les spécifications fonctionnelles
- les spécifications d’exigences
- Les cas d’utilisation
- Le fonctionnement attendu de l’application peut ne pas être décrit noir sur blanc dans un document mais il peut être extrait à partir des échanges avec le client ou les utilisateurs.
Les fonctions sont ce que « fait » un composant, un ensemble de composant, un système ou un système de systèmes.
Les tests fonctionnels peuvent donc être réalisé à tous les niveaux de test : test composant, test d’intégration, tests système et tests d’acceptation (ou éventuellement tests d’intégration système).
Les tests fonctionnels exécuté dans chaque niveau se base sur le livrable du niveau de développement correspondant dans le cycle en V.
Comment Dériver des conditions de tests fonctionnelles de ces livrables et les techniques de conception des cas de tests seront couverts dans le chapitre 4 du syllabus.
Les tests fonctionnels vérifient le comportement extérieur d’une entité logicielle, ce comportement est l’ensembles des fonctionnalités que le logiciel fournit indépendamment des choix techniques qui sont fait pour fabriquer ce logiciel.
Ces tests sont donc des tests boite noire car ils ne s’intéressent pas au code et à la structure technique du produit logiciel.
Les tests de sécurité et les tests d’interopérabilité
Les tests de sécurité et les tests d’interopérabilité sont des tests fonctionnels.
Les tests de sécurité examinent les vulnérabilités du système et les tests d’interopérabilité vérifie la capacité du système à interagir avec d’autres systèmes.
Il y a souvent confusion entre intégration et interopérabilité.
L’intégration s’assure de la communication entre des composants ou des systèmes qui sont fabriqué ensemble. L’intégration est définitive.
L’interopérabilité s’assure de la communication entre des systèmes développés par des éditeurs différents. L’interopérabilité est temporaire et est remise en question à chaque mise à jour d’un des systèmes communicants.
2. Tests non-fonctionnels
Les tests non-fonctionnels n’évaluent ce que « fait » le produit logiciel mais « comment » il le fait.
Est-ce qu’il est rapide ? fiable ? facile d’utilisation ? maintenable ? portable sur des supports différents ? …etc
Des exemples de tests non fonctionnel :
- Test de performances : vérifient que le logiciel est suffisamment rapide en temps d’exécution et en débit.
- Test de charge : déterminent la charge maximale supportée par l’application
- Test de stress : vérifie comment réagit l’application quand elle fait face à sa charge maximale
- Les tests d’utilisabilité : vérifie que l’application est facile d’utilisation et de prise en main.
- Les tests de maintenabilité : vérifient la facilité d’adaptation de l’application à des modification de code ou à des évolutions des environnements extérieurs sans que cela génère des régressions.
- Les tests de fiabilité : vérifient Le degré avec lequel l’application reste disponible malgré les interruptions.
- Les tests de portabilité : vérifient la facilité de transfert de l’application d’un environnement à un autre.
Ces tests non-fonctionnels peuvent être réalisé au niveau des tests composant, au niveau Intégration, au niveau système et par le client au niveau d’acceptation.
Mais la grande différence avec les tests fonctionnels qui sont soit OK soit KO. Les résultats des tests non-fonctionnels sont des valeurs sur une échelle.
Comme le temps de réponse en millisecondes quand on effectue des tests de performance.
Le nombre d’utilisateurs en connexion simultanés quand on effectue des tests de charge.
L’ISO9126 décrit les caractéristiques qualité qui peuvent faire l’objet des tests non fonctionnels.
Les tests non fonctionnels comme les tests fonctionnels vérifient le comportement du logiciel sans s’intéresser au code. Ce sont donc des tests « boite noire ».
3. Tests structurels
On dit que les tests structurels sont des tests « boite blanche » parce qu’elles se basent sur le code de l’application ou avec des mots plus compliqués : la structure logicielle du système.
Quand le testeur fait des tests boite noire, il ne s’intéresse pas à la structure du code, au langage de programmation, ou aux technologies impliquées. Le testeur conçoit les tests à partir des spécifications et vérifie que le logiciel fournit les services qui ont été prévus dans les spécifications, indépendamment de la technologie utilisée pour le fabriquer.
Quand un testeur fait des tests boite blanche, cela veut dire qu’il peut voir le code et qu’il peut concevoir des tests selon la structure de ce code, pour couvrir et vérifier ses chemins d’exécution possibles.
Comme les autres types de tests, les tests structurels peuvent être réalisés pendant le niveau des tests composants, le niveau d’intégration, ou le niveau des tests système et rarement pendant les tests d’acceptation qui sont généralement effectués par des profils peu techniques comme les utilisateurs.
Le code source d’un logiciel peut être modélisé sous forme d’un graphe composé d’étapes et des transitions qui représentent les instructions du code.
Chaque test déclenche l’exécution d’une partie du code.
Quand les testeurs ont une visibilité sur le code ils peuvent mesurer les chemins et les parties du code couverts par leurs tests. Ce que ne permettent pas les tests boite noire basées sur les spécifications.
Exemple de code :
Lire (Age*) ; * une valeur sur le clavier
Si Age < 18 Alors
Afficher (« Mineur »)
Sinon
Afficher (« Majeur »)
A est une instruction simple.
B est une condition qui crée une bifurcation dans la structure du code. Quand la condition est vrai cela déclenche un traitement c. si la condition est fausse, cela déclenche un traitement d.
Supposant qu’on crée un test 1 avec une valeur à taper sur le clavier de 15.
Test 1 : Age = 15
L’exécution de ce test parcourra le chemin abc. Et l’instruction d ne sera pas exécutée.
Si la campagne de test ne contient que le Test 1 alors la couverture des tests est de 50% parce que le test a couvert la moitié des chemins possibles du code.
Pour augmenter la couverture, on peut concevoir un deuxième test qui va orienter l’exécution vers le chemin qui parcourt l’instruction « d ».
Test 2 : Age = 40
En exécutant la suite de ces deux tests, on a couvert 100% de la structure du code.
Les techniques de couverture sont traitées plus en détail dans le chapitre 4.
Mesurer la couverture du code eut vite devenir un cauchemar si on le fait manuellement, mais heureusement il existe des outils qui le fait à notre place en parcourant les instructions ou les décisions comme les conditions si-alors et les boucles.
Les tests qui se basent sur la structure du code sont surtout les tests sur les premiers niveaux du cycle projet comme le niveau des tests composant et le niveau des tests d’intégration. Ils peuvent être réalisés lors des tests du niveau système et au niveau des tests d’acceptation mais c’est beaucoup moins fréquent
4. Les tests de confirmation et de régression
Les tests de confirmation
Les tests de confirmation sont des tests exécutés une deuxième fois pour confirmer la correction d’une anomalie qui a été détectée lors de la première exécution du test.
C’est compliqué ?
Voici comment cela se produit dans le temps.
Pendant la phase d’exécution. Le testeur exécute des cas de tests.
Lorsque le testeur détecte un incident lors de l’exécution d’un cas de test, le testeur crée un rapport d’incident et l’envoie au développeur.
Le développeur cherche le défaut à l’origine de l’incident grâce au débogage.
Quand le développeur trouve le défaut, il corrige et livre la nouvelle version corrigée du logiciel au testeur.
C’est à ce moment là que le testeur réalise un test de confirmation en vérifiant que l’incident ne se produit plus.
Les tests de régression
Quand on modifie le code d’un logiciel pour ajouter de nouvelles fonctionnalités ou pour réaliser des corrections, on risque de toucher à des parties du logiciel qui fonctionnait correctement, et qui après modification, ne fonctionnent plus comme avant.
C’est ce qu’on appelle des régressions.
Les tests de régression ont pour objectifs de s’assurer que les modifications apportées au logiciel n’apportent pas des régressions dans ce même logiciel ou sa compatibilité avec les autres systèmes avec lesquels il communique.
Plus la modification apportée au logiciel impacte des parties importantes de ses composants, plus le risque de régression est grand, plus le périmètre des tests de régression doit être étendue.
Les tests de confirmation et les tests de régression sont censés être exécutés plusieurs fois, il doit donc être possible de les répéter grâce à des pas de test claires et bien définies.
Tous les types de test vus précédemment peuvent devenir des tests de régression s’ils concernent des caractéristiques ou des parties existantes du logiciel qui ne sont pas censés changer.
Les tests de régression peuvent être réalisés quelques soit le niveau de test.
L’automatisation permet de programmer un test une seule fois et de l’exécuter automatiquement autant de fois qu’on le souhaite de jour ou de nuit.
L’automatisation est un investissement qui a un coût, il faut donc bien choisir les tests à automatiser.
Pour automatiser un test, il est préférable que le test concerne une partie importante du logiciel qu’il faut donc vérifier de façon récurrente, et qui ne subit pas beaucoup d’évolution (pour ne pas avoir à constamment mettre à jour le test).
Les tests de régression étant des tests à exécuter régulièrement, et qui ne changent pas souvent. Ce sont de bons tests à automatiser.
