📘 Concepts généraux

Le test logiciel est une approche de vérification dynamique qui repose sur l'exécution d’un logiciel − ou d’une partie d’un logiciel − afin d’en observer différents comportements. Par de telles observations il est possible de détecter des défaillances, et donc d’en déduire la présence de défauts − autrement dit un non respect de la spécification.

Étant donné qu’un logiciel peut avoir un très grand nombre de comportements possibles − notamment en fonction de ses données d’entrée ou de la complexité de son code − le test logiciel repose sur l’exécution d’un même logiciel un grand nombre de fois afin d’en observer tous les comportements estimés significatifs.

Par la suite, on dénommera logiciel testé le logiciel (ou la partie du logiciel) que nous souhaitons tester.

1. Définitions et concepts essentiels

1.1. Environnement d’exécution d’un logiciel

Un logiciel s’exécute toujours dans un environnement donné, que l’on peut définir comme tout ce qui peut affecter le comportement du logiciel lors de son exécution.

Figure 1. Environnement d’exécution d’un logiciel

L’environnement d’exécution d’un logiciel (ou s’une partie d’un logiciel) va notamment comprendre :

L’espace mémoire alloué au logiciel, dans lequel ce dernier va lire et/ou écrire :
- son état (valeurs des variables, contenu des objets, état de la pile d’exécution, etc),
- les arguments confiés au logiciel lors de son lancement,
- les valeurs de retour produites par son exécution.
Le système d’exploitation, dans lequel le logiciel pourra interagir notamment avec :
- l’ensembles des fichiers et dossiers,
- d’autres logiciels en cours d’exécution (processus worker, base de données, etc.).
Le monde physique, dans lequel le logiciel pourra interagir notamment avec :
- des périphériques d’entrée (claviers, souris, manettes, microphones, capteurs),
- des périphériques de sortie (écran, haut-parleurs, moteurs, actuateurs),
- des réseaux informatiques, permettant de contacter à distances d’autres logiciels en exécution

Un logiciel en exécution va accéder à une partie de son environnement afin de récupérer un ensemble de données que nous appellerons données d’entrée. Ces données permettent au logiciel de se configurer et de fonctionner, et font lui amener à exprimer un comportement particulier.

De même, un logiciel en exécution va produire un effet qui va affecter une partie de son environnement. On appellera données de sorties l’ensemble des changements et effets produits par un comportement du logiciel.

1.2. Scénario de test

Ainsi, pour vérifier qu’un comportement d’un logiciel est bien celui attendu par sa spécification, on peut procéder de la manière suivante :

On prépare un ensemble de données d’entrée,
On exécute le logiciel avec les données d’entrée préparées,
On observe et analyser les données de sorties produits par le comportement résultant.

Puisqu’il est nécessaire de vérifier possiblement un grand nombre de comportements chez un logiciel, il est nécessaire de pouvoir rigoureusement reproduire ce processus un grand nombre de fois. C’est le principe du scénario de test (aussi appelé cas de test ou simplement test), à savoir une séquence d’actions claire et reproductible visant à vérifier un comportement spécifique d’un logiciel. Un scénario de test est généralement composé des éléments suivants :

Un ensemble de données d’entrées qui seront confiées au logiciel (ex. arguments, fichiers, entrées dans une base de donnée, état, séquence d’évènements dans une interface graphique), qui définissent l’ensemble de l’environnement nécessaire pour étudier un comportement.
Une procédure d’exécution du logiciel avec les données d’entrée, qui devra également nous permettre de capturer les données de sortie que nous souhaitons observer.
Un oracle, qui est une procédure capable d’analyser les données de sortie, et de décider si oui ou non une défaillance est apparue dans le comportement observé.

On appelle suite de tests un ensemble de scénarios de test pour un logiciel testé.

Exemple 1. Premier scénario de test pour PALINDROME

On reprend le cas du logiciel PALINDROME présenté précédemment. Pour rappel, sa spécification nous indique que le logiciel s’exécute en ligne de commande, prend une chaîne de caractères en paramètre, et doit afficher "Oui" si la chaîne est un palindrome, et "Non" dans le cas contraire.

Pour vérifier une partie de cette spécification, on propose le scénario de test suivant :

Donnée d’entrée : "anna"
Procédure d’exécution du logiciel : java -jar palindrome.jar "anna"
Oracle : Lecture de la sortie console, le message "Oui" doit être présent.

Enfin, l’exécution d’un scénario de test suit le processus suivant :

À l’aide des données de test et de la procédure d’exécution, on exécute le logiciel testé (ou une partie du logiciel). Deux possibilités peuvent suivre :
1. Si cette exécution n’arrive pas jusqu’au bout, le test est considéré comme étant en erreur, ce qui correspond presque toujours au non-respect d’une contrainte du type "le logiciel ne doit pas planter".
2. Si cette exécution arrive au bout, elle produit un comportement observable, que ce soit par la production de nouvelles données, le changement de certaines variables, ou des effets de bord sur le système (fichiers modifiés, base de donnée altérée, etc.). On capture ces observations dans ce qu’on appelle les sorties.
Enfin, si le comportement a pu être observé et qu’il n’y a pas eu d’erreur, on fournit les sorties à l'oracle, qui va les analyser et prendre une décision :
1. Si le comportement observé correspond à la spécification, alors le test est considéré comme une réussite. On dit aussi que le teste "passe".
2. Sinon, le test est un échec.

En Java, une erreur sera typiquement provoquée par une exception de type RuntimeException, les plus connues étant NullPointerException et IndexOutOfBoundsException. Pour rappel, en Java, une RuntimeException est un type particulier d’exception qui peut se produire même si la méthode qui l’émet ne la déclare pas dans sa signature à l’aide du mot-clé throws.

Des exemples d’exécution de scénario de test sont donnés dans la section qui suit.

1.3. Test manuel, test automatisé

L’exécution d’un scénario de test se réalise généralement soit de manière manuelle soit de manière automatisée.

Le test manuel fait intervenir une personne responsable de l’application de chaque étape (saisir une valeur au clavier, cliquer quelque part, attendre un certain temps, suivre l’oracle, etc.) du scénario de test. Dans cette situation, chaque scénario de test est simplement décrit en langue naturelle, parfois à l’aide de tableaux ou de listes. Le test manuel correspond également ce qu’on développeur fait quotidiennement pour s’assurer que le logiciel qu’il réalise correspond bien à ses attentes : il le lance, effectue des manipulations choisies, et observe que tout se passe comme prévu.

Cependant, le test manuel possède ces principaux défauts :

Il nécessite à des personnes (ex. des développeurs) de prendre du temps pour exécuter les scénarios de test, ce qui représente un coût considérable.
Il est pénible et laborieux pour une personne de ré-exécuter un scénario de test à de nombreuses reprises, alors que c’est une tâche nécessaire tout au long du développement et de la vérification (voir schéma au début de ce chapitre).
Certains logiciels ou certaines parties de logiciels sont destiné(e)s uniquement à d’autres logiciels − ce qu’on appelle couramment des bibliothèques logicielles − et ne sont pas directement utilisables et donc difficilement testables à la main par des humains.

Exemple 2. Exécution manuelle du scénario de test précédent

Pour le même logiciel d’analyse de palindrome, on exécute manuellement le scénario de test vu dans l’exemple précédent :

On ouvre un terminal textuel et on se rend dans le répertoire avec le programme compilé,
On saisit au clavier java -jar palindrome.jar "anna" et on valide,
On applique l’oracle en regardant l’écran : "Oui" est bien affiché, c’est donc une réussite.

À l’inverse, le test automatisé consiste à faire exécuter le scénario de test par une machine et non par une personne. Il s’effectue en deux étapes :

Chaque scénario de test est implémenté sous la forme d’un script qui se charge de chacune des étapes sans intervention humaine (initialisation, exécution, oracle). Un tel script est un logiciel dont le but est d’exécuter et d’observer un autre logiciel.
Ensuite, tous les scripts de test sont exécutés et les résultats obtenus sont rassemblés.

Le test automatisé a pour inconvénient la nécessité de programmer les scénarios de test, ce qui prend du temps et ce qui n’est pas toujours trivial (ex. simuler les interactions avec une interface graphique est parfois difficile.). Cependant, le test automatisé répond à tous les problèmes du test manuel : l’exécution des tests ne demande pas de temps humain ; la ré-exécution des scénarios de test est facile ; on peut tester des bibliothèques logicielles beaucoup plus facilement.

Exemple 3. Exécution automatisée du scénario de test précédent

Pour le même logiciel d’analyse de palindrome, on implémente le scénario de test vu précédemment sous la forme du script de test suivant, écrit avec le langage Bash :

# Exécution du logiciel avec donnée d'entrée
RESULT=$(java -jar palindrome.jar "anna")

# Oracle
if [[ "$RESULT" == "Oui" ]]; then
  echo "Test [\"anna\", Oui] réussi"
else
  echo "Test [\"anna\", Oui] échoué"
fi

Puis on exécute le script de test de la sorte :

$ bash ./test-case.sh
Test ["anna", Oui] réussi

On constate que le test est bien là aussi une réussite.

Dans le reste de ce cours on s’intéressera uniquement aux tests automatisés.

1.4. Domaines d’entrée et de sortie d’un logiciel

Concevoir un scénario de test requiert une bonne compréhension des données d’entrée et de sortie du logiciel testé. Cette compréhension peut s’obtenir en identifiant les domaines d’entrée et de sortie d’un logiciel à l’aide d’une lecture attentive de la spécification. Un domaine d’entrée ou de sortie prend la forme d’un ensemble de variables, chaque variable possédant un domaine de valeurs et pouvant posséder un nom. Ainsi :

Un domaine d’entrée se définit par un ensemble de variables d’entrées (souvent appelés paramètres d’entrée). Conceptuellement, c’est le scénario de test qui affecte des valeurs (aussi appelées des arguments) à ces variables pour influencer l’exécution du logiciel et l’amener à produire un certain comportement.
Un domaine de sortie se définit par un ensemble de variables de sortie. Conceptuellement, c’est le logiciel qui modifie ou affecte les valeurs de ces variables, qui pourront ensuite être analysées par l’oracle du scénario de test.

Le mot variable ici ne désigne pas uniquement une variable au sens "programmation". En effet, une variable d’entrée peut très bien être un fichier ou une table de base de données, tandis qu’une variable de sortie peut très bien être un envoi d’exception ou le contenu visuel d’une page web.

Exemple 4. Domaines d’entrée et de sortie d’un logiciel de recherche dans un fichier

On considère un logiciel permettant de chercher une chaîne de caractères au sein d’un fichier texte. Il existe une option pour indiquer au logiciel si on souhaite ignorer ou non la casse des caractères lors de la recherche. Une fois terminé, le logiciel peut soit nous indiquer que le mot est bien présent, soit que le mot est bien absent, soit qu’il y a une erreur dans la lecture du fichier (ex. fichier absent).

On représente le domaine d’entrée de ce logiciel prend à l’aide de trois paramètres d’entrée :

: le fichier à analyser – le domaine de ce paramètre d’entrée est "l’ensemble des fichiers",
: la chaîne de caractères à rechercher dans le fichier – le domaine de ce paramètre d’entrée est "l’ensemble des chaînes de caractères",
: le choix d’ignorer la casse des caractères ou non – le domaine de ce paramètre d’entrée est l’ensemble des booléens, donc {vrai, faux}.

L’ensemble des valeurs possible de ce domaine d’entrée est le produit cartésien des domaines des différentes variables, à savoir .

Cet ensemble de valeurs est conceptuellement infini, puisqu’il existe une infinité de fichiers possibles, ainsi qu’une infinite de chaînes de caractères possibles. En pratique, ce domaine est simplement extrèmement grand, puisque, sur un ordinateur donné et dans un environnement logiciel donné, un fichier possède une taille maximale, de même qu’une chaîne de caractères.

Un exemple de données d’entrées conforme à ce domaine d’entrée serait :

: fichier contenant "Bonjour à tous"
: la chaîne "tous"
: faux

Enfin, on représente le domaine de sortie avec une unique variable de sortie :

: le résultat de la recherche – le domaine est l’ensemble {présente, absente, erreur fichier}.

Signatures de fonctions typées

Si un logiciel testé est une fonction (aussi appelée procédure) développé à l’aide d’un langage de programmation typé, il est possible d’identifier une partie des domaines d’entrée et de sortie en s’intéressant à la signature de la fonction :

la liste des paramètres nous indique un ensemble de variables d’entrée, et le type d’un paramètre nous indique le domaine de la variable d’entrée,
le type de retour nous indique le domaine d’une variable de retour.

Par exemple si on regarde la signature de fonction suivante en TypeScript :

function areEqual(x: number, y: number): boolean { … }

On peut en déduire :

une variable d’entrée x avec pour domaine l’ensemble des flottants,
une variable d’entrée y avec pour domaine l’ensemble des flottants,
une variable de sortie avec pour domaine l’ensemble {true, false}.

Cependant une signature ne permet pas de déterminer l’intégralité des domaines, car une fonction peut également lire ou écrire d’autres données dans son environnement (ex. des fichiers), qui font alors par définition également partie du domaine. Une lecture attentive de la spécification de la fonction reste donc nécessaire !

Le cas d’une méthode en orienté objet est un peu différent d’une fonction, voir la section dédiée.

Exemple 5. Domaines d’entrée et de sortie de PALINDROME

On considère le même logiciel PALINDROME que dans les chapitres précédents, à savoir un logiciel en Java qui s’exécute en ligne de commande et qui peut détecter si un mot est un palindrome ou non. Plus précisément, on s’intéressera ici directement au service Java principal requis dans le logiciel. Selon la spécification, ce service doit implémenter l’interface Java suivante :

package app;

interface Palindrome {
    /**
     * Verifies that a word is a palindrome.
     * Ignores the character case.
     * 
     * @return true if word is a palindrome, false otherwise.
     * @throws NullPointerException if word is null
     * @throws IllegalArgumentException if word is empty 
     *                                  or contains a digit, 
     *                                  or contains a special character.
     **/
    boolean isPalindrome(String word) throws IllegalArgumentException, NullPointerException;
}

Concernant le domaine d’entrée :

On constate dans la spécification et dans la signature un paramètre word avec pour type String.
On sait qu’en Java qu’une variable avec pour type String peut également prendre pour valeur null.
On en déduit que le domaine d’entrée est composé d’une unique variable d’entrée qu’on nomme word avec pour domaine String ∪ { null }

Concernant le domaine de sortie :

On constate dans la spécification et dans la signature un type de retour boolean.
On constate dans la spécification et dans la signature qu’un envoi d’exception soit de type NullPointerException, soit de type IllegalArgumentException est possible.
On en déduit que le domaine de sortie est composé d’une unique variable de sortie qu’on nomme result avec pour domaine {true, false, IllegalArgumentException, NullPointerException}

On peut aussi représenter le domaine de sortie sous la forme de deux variables :

return_value avec pour domaine { true, false, − }
exception avec pour domaine { IllegalArgumentException, NullPointerException, − }

avec '−' une valeur qui dénote l’absence de valeur.

1.5. Domaines d’entrée et sortie en orienté objet

En cas de programmation orientée objet, lorsque l’on teste une méthode, il ne faut pas oublier de considérer l’objet appelant comme faisant partie des paramètres d’entrée ! En effet, les valeurs des différents attributs de l’objet peuvent être accédées par la méthode et peuvent donc influencer son comportement.

Domaine d’entrée d’une méthode avec un seul objet

Soit une interface java IntegerList et la méthode add :

public interface IntegerList {
    boolean add(Integer element);
}

La méthode add n’étant pas statique, son domaine d’entrée est IntegerList Integer

Et si on effectue un appel de cette méthode sur une IntegerList nommée l1 :

l1.add(-5);

les données d’entrées confiées à add sont ici bien {l1, -5}

Ajoutons à cela deux constats importants :

Chaque attribut d’un objet peut être considéré comme un possible paramètre d’entrée de la méthode testée.
Tout objet accessible directement (l’objet appelant ou bien un objet passé en paramètre) ou indirectement (au travers des attributs des autres objets accessibles) est un possible paramètre d’entrée, ainsi que chacun de ses attributs.
Si les objets sont manipulés par des pointeurs (comme en Java), tout objet ou attribut peut également être une variable de sortie ! En effet, les objets d’entrée (l’objet appelant ainsi que les objets passés en paramètre) peuvent tous être modifiés par la méthode, ce qui contribue à changer l’état du système testé.

Domaines d’entrée et de sortie d’une méthode avec plusieurs objets

Soit le programme objet suivant :

Le domaine d’entrée de la méthode do est possiblement composé des paramètres d’entrée suivants :

mode int
this.x int
this.b B {null}
this.b.y bool {_}
this.b.c C {null, _}
this.b.c.z string {null, _}

où la valeur null représente l’absence d’un objet sur un pointeur (par exemple l’absence d’une instance B dans this.b) et où la valeur vide _ dénote le cas où un élément est inaccessible (par exemple y n’est pas accessible sans objet B dans this.b).

Seuls les attributs qui influencent vraiment le comportement de la méthode doivent être identifiés comme des paramètres d’entrée.

Et le domaine de sortie de la méthode do est possiblement composé des variables de sortie suivantes :

result bool
this.x int
this.b B {null}
this.b.y bool {_}
this.b.c C {null, _}
this.b.c.z string {null, _}

Malheureusement, le principe de l’encapsulation fait qu’il est courant de manipuler un objet uniquement au travers d’une interface, et donc de ne pas connaître ses attributs.

Dans ce cas, toute méthode permettant d’observer des données encapsulées (getters notamment, mais pas uniquement) pourra possiblement être considérée comme une variable d’entrée ou de sortie, de manière similaire à un attribut. La documentation de l’interface sera une bonne source d’informations pour bien comprendre un contexte donné.

Domaines d’entrée et de sortie d’une méthode avec plusieurs objets avec getters

Le domaine d’entrée de la méthode do est possiblement composé des paramètres d’entrée suivants :

mode int
this.getX() int
this.getB() B {null}
this.getB().getY() bool {_}
this.getB().getC() C {null, _}
this.getB().getC().getZ() string {null, _}

Et le domaine de sortie de la méthode do est possiblement composé des variables de sortie suivantes :

result bool
this.getX() int
this.getB() B {null}
this.getB().getY() bool {_}
this.getB().getC() C {null, _}
this.getB().getC().getZ() string {null, _}

1.6. Tableau de scénarios

Dans ce cours, on représentera souvent une suite de tests sous la forme d’un tableau de scénarios, dont les colonnes représentent les données d’entrée et l’oracle, et dont les lignes représentent les scénarios de test que comporte la suite de tests.

Pour présenter cette notation, supposons une méthode avec la signature de la forme suivante :

public int foo(int x, boolean y, String z) throws SpecificException

On suppose ici que les seules données d’entrée pertinentes sont x, y et z, et que les seules données de sortie pertinentes sont la valeur de retour (de type int), l’exception (de type SpecificException) et l’objet appelant (this).

Un tableau de scénarios pour cette méthode prend alors la forme suivante :

Tableau 1. Structure d’un tableau des scénarios
	Données d’entrée			Oracle
	`x` : int	`y` : bool	`z` : string	`result`	`SpecificException`	`this.contains(4)`
1	`2`	`false`	`"message"`	`45`		`true`
2	`-1`	`false`	`"message"`	-	×	-
3	`2`	`true`	`"message"`	`9`		`false`

dans lequel :

Chaque colonne représente soit une variable d’entrée, soit une variable de sortie.
Chaque ligne représente un scénario de test (qui portera le même nom que la combinaison correspondante). Dans chaque ligne, on inscrira les valeurs concrètes choisies pour chaque paramètre d’entrée (de manière à satisfaire les choix réalisés pour cette combinaison), et on inscrira quelles valeurs sont attendues pour les différentes données de sortie possibles.
Pour les données de sortie, une colonne pourra notamment indiquer :
- une valeur attendue pour une donnée de sortie − par exemple result, qui par convention sera la valeur retournée par une méthode,
- l’absence ou la présence d’une sortie particulière − par exemple une exception, dont la présence pourra être indiquée par une simple croix,
- la satisfaction d’une expression booléenne donnée.

Exemple 6. Premier tableau de scénarios pour isPalindrome

On prépare une première suite de tests pour isPalindrome sous la forme du tableau suivant :

Paramètres d’entrée Oracle

	Paramètres d’entrée	Oracle
	`word` : string	`return_value`	`exception`
1	`"bonjour!"`	−	`IllegalArgumentException`
2	`"john"`	`false`	−
3	`"anna"`	`true`	−

word : string

return_value

exception

"bonjour!"

−

IllegalArgumentException

"john"

false

−

"anna"

true

−

2. Processus général du test logiciel

De manière générale, une activité de test logiciel revient à suivre le processus suivant :

Figure 2. Processus général d’une activité de test logiciel

Supposons la réalisation d’un logiciel, à savoir le logiciel testé. Cette réalisation nécessite des changements du code du logiciel, à savoir des ajouts ou des modifications de parties existantes.
Comme tout changement de code est susceptible d’introduire un défaut dans le logiciel testé, on entreprend de tester le logiciel et ses changements à l’aide de scénarios de test.
- Si aucun scénario de test n’existe, on débute une conception de scénarios de test à l’aide d’une approche de test. En outre, si on souhaite faire du test automatisé, alors s’ajoute à cela une étape de développement, où on implémente les scénarios de test sous forme de scripts de tests.
- Sinon, on se saisit simplement des scénarios de test existants.
Puis on lance une exécution de l’ensemble des scénarios de tests (anciens comme nouveaux) sur le logiciel testé.
- Si l’un des scénarios de test ne passe pas (échec ou erreur), cela peut signifier qu’une défaillance a été observée. On doit alors réaliser un débogage pour découvrir le défaut qui cause de la défaillance, pour ensuite le corriger, et repartir au point de départ du processus.
- Si tous les scénarios de test passent (réussites), il ne reste qu’à effectuer une mesure de la qualité de la suite de tests, afin de déterminer si des tests additionnels sont nécessaires. Cette mesure dépend de l’approche de test employée, et consiste à mesurer la proportion de cibles atteintes par les tests (combinaisons, lignes de code, défauts potentiels, etc).
  - Si la qualité est considérée insuffisante pour les objectifs fixés, alors on repart en conception de scénarios de test.
  - Si la qualité est estimée suffisante, l’activité de test est terminée (pour le moment !).

Différentes approches de test seront présentées dans de futurs chapitres du cours.

Il est possible (et même recommandé) d’utiliser conjointement différentes approches de test, que ce soit lors de la conception ou de la mesure de la qualité des tests.

3. Classification du test logiciel

Il existe dans la littérature un grand nombre d’adjectifs associés au mot test permettant de catégoriser les différentes activités du test logiciel et/ou les différents types de scénarios de test en test logiciel. Dans cette section nous passons non exhaustivement en revue cette dense classification, en se concentrant sur quelques manières courantes de catégoriser le test logiciel.

3.1. Selon l’accès au code source

En fonction du contexte ou de l’objectif, la personne responsable de l’écriture des tests (testeur ou testeuse) peut reposer sur différentes sources d’information pour la conception de scénarios de test. Le code source du logiciel testé fait partir des possibles sources d’informations que l’on peut (ou non) utiliser, et on distingue communément trois cas :

On parle de test boîte blanche lorsqu'on utilise principalement le code source de ce qui est testé lors de la conception des scénarios de test. En analysant la structure du code et des composants internes, on peut par exemple en déduire quels scénarios de test sont nécessaires pour que chaque composant interne soit testé.

Tester en boîte blanche nécessite tout de même de lire et de considérer la spécification du logiciel testé, notamment afin de concevoir l'oracle de chaque scénario de test.

L’approche structurelle et l’approche par mutation, présentées dans de prochains chapitres, sont deux approches de conception de tests de type boîte blanche.
On parle de test boîte noire lorsqu'on n’utilise pas le code source de ce qui est testé lors de la conception des scénarios de test. Ce terme est souvent utiliser pour qualifier les approches qui reposent principalement sur la spécification du logiciel testé pour déterminer quels scénarios de test concevoir.

L’approche combinatoire, présentée dans un prochain chapitre, est une approche de conception de tests de type boîte noire.

3.2. Selon la propriété vérifiée

La spécification du logiciel testé définit l’ensemble des propriétés (ou contraintes) que doit satisfaire le logiciel. On distingue communément deux activités de test en fonction du type de propriétés testées :

On parle de test fonctionnel lorsqu’on cherche à vérifier qu’une fonctionnalité attendue (ex. faire un calcul, réagir à une action, produire un résultat, afficher un élément) du logiciel testé correspond bien aux attentes, ce qui impliquer vérifier que les comportements du logiciel permettent bien d’accomplir les tâches prévues. Le test fonctionnel représente généralement l’essentiel de l’activité de test logiciel.

Généralement le test fonctionnel est réalisé en boite noire

On parle de test non-fonctionnel lorsqu’on cherche à vérifier ce qui n’est pas directement lié aux fonctionnalités. Dans cette grande catégorie on peut citer le test de robustesse (est-ce que le logiciel peut gérer des cas peu prévus ?), le test de performance (est-ce que le logiciel utilise beaucoup de CPU ? de mémoire ? est-ce que les calculs sont rapides ?), le test de charge (est-ce que le logiciel peut endurer de très nombreuses sollicitations ?), le test de compatibilité (est-ce que le logiciel peut fonctionner sur des plateformes différentes ?), le test de sécurité (est-ce que le logiciel possède des failles de sécurité ? peut résister à certaines attaques ?)

Généralement le test non-fonctionnel est réalisé en boite blanche

La frontière entre fonctionnel et non-fonctionnel n’est pas toujours clairement définie. Par exemple il est difficile de classer certaines contraintes liés à la sécurité ou à l'ergonomie dans une seule des deux catégories.

Dans ce cours on ne s’intéressera que au test fonctionnel.

3.3. Selon l’usage des tests

Une autre catégorisation repose sur l’usage qui est fait des scénarios de test.

On parle de test de régression (aussi appelé test de non-regression) lorsque l’exécution des scénarios de test vise à détecter l’apparition de régressions, à savoir de nouveaux défauts apparus suite à des changements réalisé dans un logiciel. Cela nécessite l’exécution des tests à chaque changement réalisé, ou à chaque version produite, ce qui peut être automatisé à l’aide d’un gestionnaire de version (comme Git) couplé à un exécution des tests au sein d’une intégration continue (comme Gitlab CI).
On parle de test d’acceptation (aussi appelé test de recette) lorsque l’exécution des tests vise à valider que l’entièreté du logiciel testé est conforme aux attentes du client. Ce type de test ne concerne que les scénarios de test conçus directement sur la base des besoins du clients établis dans le cahier des charges initial.

Généralement le test d’acceptation prend la forme de test système (voir plus bas).
Un peu à part, on parle de développement dirigé par les tests lorsque les scénarios de test sont conçus progressivement avant le développement de chaque nouvelle fonctionnalité, puis sont exécutés lorsque la dite fonctionnalité est implémentée. Cette approche permet non seulement de garantir que toute fonctionnalité est toujours testée, mais permet aussi d’aider dans la conception des interfaces des composants d’un logiciel.

3.4. Selon le niveau de test

Une importante classification du test logiciel se fait en fonction de l’échelle, ou de la dimension, d’un scénario de test vis à vis du logiciel testé. Dit autrement, un scénario de test sera forcément spécifique à une partie, plus ou moins large, d’un logiciel. C’est ce qu’on appelle les niveaux du test logiciel.

Considérons d’abord la situation habituelle : nous souhaitons tester un système logiciel, et ce dernier est censé respecter une spécification. Cette spécification déclare quelles sont les entrées possibles pour ce système logiciel et quelles sorties ce système est censé produire en conséquence . Schématiquement :

Figure 3. Système logiciel et sa spécification

Mais un logiciel n’est que rarement constitué d’un bloc monolithique de code. En pratique, il est toujours décomposable en un ensemble d'unités (aussi appelées modules ou composants) qui sont intégrées ensemble afin de permettre au système de produire les comportements attendus. De telles unités peuvent être des fonctions, des méthodes, des classes ou encore des packages, en fonction de la granularité considérée. Pour un langage procédural comme C, l’unité communément considérée est la fonction, tandis que pour un langage orienté objet comme Java ce sera la plus souvent la méthode (ou éventuellement la classe).

Lors de la conception d’un logiciel, une des étapes consiste à décider de comment décomposer le système en unités, et quels seront les services rendus par ces différentes unités. En d’autres termes, on établit pour chaque unité une spécification qui lui est propre au sein des documents de conceptions. Ces spécifications peuvent prendre par exemple la forme de modèles UML (diagrammes des classes, de séquence, d’états-transitions) ou encore directement de code commenté en détail définissant des interfaces logicielles (par exemple une interface Java).

Si on étend le schéma précédent, on obtient alors :

Figure 4. Système logiciel et unités

La spécification d’une unité est rarement réalisée avec le client du logiciel produit, mais principalement par les concepteurs et les développeurs du logiciel. Pour autant, la spécification d’une unité ne doit pas entrer en contradiction avec la spécification système, qui est elle bien basée sur les besoins du client !

On peut dès lors avoir l’intuition suivante : si chaque unité se trouve être bien conforme à sa propre petite spécification − et si de telles petites spécifications sont cohérentes avec la spécifiation globale du système − alors les chances augmentent que le système dans son ensemble soit conforme à sa spécification ! Il en découle qu’il apparait très pertinent de vérifier chaque unité, par exemple à l’aide d’une approche de test logiciel qui est alors appelée test unitaire.

Sur cette base on peut alors distinguer plusieurs niveaux de test, avec au moins :

Le test système, qui consiste à tester le système dans son ensemble.
Le test unitaire, qui consiste à tester chaque unité séparément, et si possible isolée des autres.
Le test d’intégration, qui consiste à tester des groupes d’unités et leurs interactions.

Le test unitaire est en nature complètement identique au test système (chaque unité est un "petit système"), et diffère uniquement en terme d’échelle.

Si on ajoute au schéma précédent la notion de scénario de test, à la fois au niveau système et au niveau unitaire, on obtient alors :

Figure 5. Test système, test unitaire

Zoom sur le test unitaire

Le test unitaire est une approche très populaire et répandue, qui a pour particularité d’être principalement pratiquée par les développeurs eux-mêmes pour vérifier leur code. Elle possède de nombreux avantages, notamment :

Facilite la réutilisation d’une unité, car la qualité de chaque unité aura tendance à augmenter à l’aide des tests unitaires.
Facilite la localisation des défauts, car si une défaillance est observée lors du test d’une unité, alors il y a de grandes chances que le défaut soit localisé dans l’unité en question.

En revanche le test unitaire fait face à des obstacles de testabilité, notamment :

Les oracles doivent pouvoir accéder à l’état interne de l’unité, ce qui peut nécessité des accesseurs dédiés (ex. des getters).
Les unités qui ne sont pas suffisament accessibles (par exemple avec une visibilité package en Java) ne sont pas faciles à tester.

La testabilité fera l’objet d’une partie dédiée du cours.

Dans ce cours on ne verra que le test unitaire.

3.5. Selon l’approche de conception de scénarios

Enfin, une dernière manière de catégoriser le test logiciel se repose simplement sur l’approche de test utilisée pour concevoir des scénarios de test. Par exemple :

On parle de test combinatoire lorsqu’on utilise une approche combinatoire pour concevoir des scénarios de test.
On parle de test structurel lorsqu’on utilise une approche structurelle pour concevoir des scénarios de test.
On parle de test par mutation lorsqu’on utilise une approche pa mutation pour concevoir des scénarios de test.

La suite du cours comportera différentes chapitres pour expliquer ce qu’est une approche de test, et pour présenter les trois approches sus-mentionnées.

4. Conclusion

Ce chapitre a présenté toutes les définitions essentielles et générales du test logiciel, le processus général à appliquer pour faire du test logiciel, ainsi que certaines catégorisations existantes du test logiciel. On notera que deux questions importantes subsistent, à savoir comment développer des scripts de test, et comment concevoir des scénario de test.

Pour la suite du cours, on notera que nous nous concentrerons sur du test fonctionnel et unitaire, à la fois en boîte noire (approche combinatoire) et en boîte blanche (approche structurelle et approche par mutation).