Introduction à l’ingénierie des tests

Un test informatique est une activité permettant de vérifier l’adéquation d’un système informatique à un fonctionnement attendu. Dans l’ingénierie logiciel, cette activité est déterminante. Selon les équipes et les organisations, elle peut être plus ou moins formalisée et plus ou moins automatisée (exécution de programmes de test). Mais elle demeure incontournable pour donner une appréciation de la qualité du produit. L’activité de test permet de détecter un défaut, c’est-à-dire un écart entre le fonctionnement attendu et le fonctionnement constaté.

Par extension, on appelle test, la procédure décrivant les activités à réaliser. On parle également de test pour désigner l’activité de développement pour la production de programmes de test (on parle de tests automatisés). L’ingénierie des tests impliquent donc des activités et des spécialités différentes :

  • Le testeur en charge de réaliser les tests

  • La personne en charge de définir les procédures à réaliser (les scénarios de test). Il ne s’agit pas nécessairement du testeur.

  • Le développeur en charge de réaliser le ou les programmes d’automatisation des tests

À cela s’ajoute, les personnes impliquées dans l’organisation et la gestion des activités de tests et toutes les personnes impliquées dans la conception et la définition du système (comme les experts fonctionnels). L’ingénierie des tests impliquent donc des aspects fonctionnels, techniques et organisationnels.

Note

La méthode formelle est une autre approche pour valider des algorithmes. Elle se base sur la démonstration mathématiques. Cette approche est difficile à réaliser (et pas toujours possible selon la complexité des systèmes) et coûteuse. Elle est donc réservée à des contextes à haut risque pour les système exigeant un haut niveau de fiabilité. Elle n’est donc pas appliquée dans le domaine du génie logiciel.

Stratégie de test et types de test

En informatique, les tests sont conditionnés par la stratégie de test que l’on souhaite mettre en place. Cette stratégie est dépendante du budget mais également des types de défauts contre lesquels on souhaite se prémunir. Un test permet de fournir un certain degré de confiance sur le fait qu’un système fonctionne correctement. Mais que signifie fonctionner correctement ? Comme il est possible d’envisager le fonctionnement d’un système sous divers aspects, il existe divers types de test. Chacun de ces types servent à adresser un des aspects du fonctionnement du système.

Parmi les types de test, on distingue généralement :

  • Les tests unitaires : testent une partie (une unité) d’un système afin de s’assurer qu’il s’exécute sans erreur (build the system right)

  • Les tests d’acceptation : testent le système afin de s’assurer qu’il est conforme aux attentes de l’utilisateur (build the right system)

  • Les tests d’intégration : testent le système sur une plate-forme proche de la plate-forme cible afin de s’assurer que les différents composants s’intègrent correctement les uns avec les autres.

  • Les tests de performance : testent les performances du système afin de s’assurer qu’il répond à certains critères de réactivité. Par exemple, pour un service en ligne, il peut s’agir du temps de réponse moyen en seconde.

  • Les tests de sécurité : testent que l’application ne contient pas de failles de sécurité connues (injection de code, attaque XSS, …)

  • Les tests de robustesse (ou stress tests) : testent le comportement de l’application aux limites des ressources disponibles (mémoire, CPU, …).

Cette liste n’est pas exhaustive et ne peut pas l’être. Pour le développement d’un système donné, il est tout à fait possible d’envisager un type de tests permettant d’identifier des défauts spécifiques à ce système.

Comme nous le rappelle les grands principes des tests (Cf. ci-dessous), il est impossible d’envisager une activité de test qui soit exhaustive, la stratégie de test sert donc à préciser quels types de test doivent être réalisés et les conditions opérationnelles de réalisation de ces tests.

Les tests de non régression

Les tests de non régression ne sont pas un type particulier de tests. Tous les types de tests peuvent servir de tests de non régression.

Suite à une modification apportée à un système, un test de non régression permet de s’assurer que le système continue de fonctionner comme précédemment pour les parties qui ne devraient pas être impactées par cette modification. Un test de non-régression suppose donc une modification limitée du système et s’applique aux parties du système qui n’ont pas subies cette modification.

Les tests de non régression sont fondamentaux pour garantir la stabilité d’un système dans le temps. Cela suppose que l’activité de test est une activité périodique : on teste le système régulièrement et pas simplement une fois. C’est une des raisons majeures qui conduit les équipes à automatiser certains tests, c’est-à-dire à concevoir et développer des programmes capables de valider le fonctionnement d’un système. Ces programmes peuvent alors être exécutés aussi souvent que nécessaire. Par contre, ils doivent être en partie adaptés, au même titre que le système lui-même, lorsqu’une modification est apportée.

Les 7 principes des tests

Les 7 principes des tests ont été formalisés par le comité ISTQB.

Les tests montrent la présence d’un défaut

Les tests mettent en valeur la présence de défauts (bugs). Cependant les tests ne permettent pas de prouver l’absence de défaut. Les tests nous permettent de réduire la probabilité qu’il subsiste des défauts dans le système. Les tests ne servent donc qu’à nous rassurer en nous donnant confiance sur la capacité du système à fonctionner avec un minimum de défaut.

Les tests exhaustifs sont impossibles

Sauf pour des systèmes extrêmement simples, il n’est pas possible d’envisager la totalité des combinaisons impliquées par les entrées fournies au système et les conditions d’exécution du système. Ce principe implique la nécessité de réfléchir à une stratégie de test, c’est-à-dire aux types de test que l’on souhaite réaliser et les conditions de réalisation de ces tests.

Tester au plus tôt

Les tests doivent être réalisés au plus tôt après la production du système (ou d’une partie du système). Ce principe se base sur l’idée qu’une correction tardive sera plus complexe et plus coûteuse.

Regroupement des défauts

Les défauts d’un système tendent à être regroupés sur des composants ou des fonctionnalités particulières (par exemple en raison d’une complexité technique ou fonctionnelle plus élevée). Une stratégie de test devraient prendre en compte ce principe pour faire porter l’effort de test de manière significative sur ces composants ou ces fonctionnalités.

Le paradoxe du pesticide

Si les tests ne trouvent pas de défaut, cela peut signifier que les tests tendent à mettre en valeur une catégorie particulière de défauts ignorant ainsi les autres. On prend l’image du pesticide qui élimine un ensemble d’insectes jugés nuisibles mais laisse indemnes d’autres populations d’insectes qui vont proliférer et devenir nuisibles à leur tour. Il est important de faire varier la nature des tests en produisant de nouveaux cas ou en enrichissant les données en entrée.

La stratégie de test dépend du contexte

Il n’est pas possible de prévoir une procédure unique de tests applicable quel que soit le système car la stratégie de test dépend du contexte. Un site Web grand public n’aura pas les mêmes exigences de fiabilité que des applications Web internes à une entreprise. De même sur un site Web de e-commerce, les pages de consultation des produits n’auront sans doute pas la même exigence de sécurité que les pages de paiement des commandes.

L’illusion d’absence d’erreur

Une stratégie de test ne permet pas de garantir le zéro défaut. L’absence d’identification de défaut ne signifie pas que le système en est exempt. Il faut toujours assumer que le système contient des défauts cachés, c’est-à-dire non mis en valeur par les tests réalisés.