Test de régression

Une régression est un défaut introduit dans un logiciel à l'occasion de corrections de bogues ou n'importe quel changement établi dans un logiciel : ajout de nouvelles fonctionnalités, modification de fonctionnalités existantes ou modification d'un composant externe au logiciel lui-même : nouvelle version du système, de l'interface graphique, d'un compilateur ou d'une bibliothèque tierce qui interviennent dans son fonctionnement. La régression fonctionnelle est donc un bug informatique qui entraîne un retour en arrière non désiré et préjudiciable sur une fonctionnalité qui marchait avant. Elle menace le bon fonctionnement du logiciel, ce qu'il est important d'éviter ; on effectue à cette fin des tests de régression. Il est également courant de parler de tests de non-régression, ou TNR[1].

Pour les articles homonymes, voir Régression.

Définition

Un test de régression est un ensemble de tests d’un programme préalablement testé, après une modification, pour s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non modifiées du logiciel. Ces tests sont effectués quand le logiciel ou son environnement est modifié[2],[3].

L'intérêt principal de ces tests est de limiter les anomalies relevées lors de la recette de l'application, voire, ce qui est pire, une fois l'application déployée. Ils viennent compléter les tests unitaires et les tests d'intégration en amont des tests de recette.

L'expression non-régression est parfois employée dans un sens différent pour les logiciels dont le mécanisme d'installation garantit que l'on n'écrasera pas involontairement une version plus récente déjà installée ; c'est le cas entre autres de Python, VLC et Java[réf. souhaitée].

Difficultés

Les tests de régression sont longs à exécuter

Même si le changement effectué sur le système est mineur, il est prudent de couvrir le plus de cas possibles, afin d'assurer que le reste du logiciel fonctionne toujours de la même manière. Les tests de régression représentent de nombreux scénarios et peuvent donc être fastidieux à rejouer[4].

Aucun test ne garantit l'absence de défauts

Comme l'a rappelé Edsger Dijkstra,

Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

— Edsger W. Dijkstra , The Humble Programmer (1972)[5]

« Tester des programmes peut révéler des bugs très efficacement, mais cela ne permet pas d’en démontrer l’absence. »

— The Humble Programmer (1972)[6]

Solutions

Automatisation des tests

Des programmes spécialisés permettent d'automatiser ces tests. Nommés robots de tests, ils simulent généralement l'activité d'un utilisateur en rejouant un scénario prédéfini, parfois enregistré depuis des sessions réelles, et contrôlent que le résultat nouvellement obtenu est conforme au résultat de la version antérieure. Parfois, ce programme est directement inclus dans le logiciel lui-même, comme Simpletests pour Drupal depuis sa version 7.

Sélection réfléchie des cas de test à exécuter

Automatiser les tests de régression n’est pas toujours possible, ou pas toujours économiquement valable au regard des coûts de maintenance des tests automatisés. Une autre possibilité consiste à limiter le nombre de tests à réaliser à la suite d'une modification :

  • soit en se basant sur des statistiques ;
  • soit en limitant les tests à certaines catégories de fonctionnalités, en fonction de leur criticité, ou de leur interaction probable avec les fonctionnalités testées ;
  • soit en définissant une stratégie de test de régression basée sur les risques.

L'enjeu est donc d’identifier les tests pertinents à jouer manuellement pour minimiser l'effort de test tout en maximisant la couverture des risques de régressions. Cependant pour éviter de laisser passer des régressions il faut établir sa stratégie sur des faits.

Pour disposer de ces faits, l’analyse de l’application, des impacts de chaque modification faite et la comparaison de chaque version permettent d’identifier tous les changements et les risques associés. La difficulté est d’obtenir une vision de ces risques qui soit exploitable pour des tests fonctionnels : au-delà du fichier modifié il faut évaluer son impact sur les fonctionnalités.

Pour améliorer cette analyse, une solution consiste à prendre l’ « empreinte » de chaque test sur l’application (ce qui est exécuté dans l’application lors d’un test). Cette prise d’empreinte fait le lien entre code, modules fonctionnels et scénarios de tests. Une fois ce lien établi, il est possible de savoir exactement ce que couvre un test en particulier.

Ainsi, lors d’une nouvelle version, il est possible d’identifier quels tests vont couvrir l’intégralité des risques de régression en fonction des modifications apportées à l’application. Définir une stratégie de tests de régression plus efficace devient possible.

Grâce à cette méthode, l’automatisation des tests n’est plus la seule solution car le nombre de tests à dérouler est limité au strict nécessaire.

[réf. souhaitée]

Même si les tests de non-régression ne sont pas une nouveauté, la méthode extreme programming (XP) en fait un de ses chevaux de bataille pour améliorer la qualité du logiciel[réf. souhaitée].

Notes et références
  1. Bernard Homès, Les tests logiciels : fondamentaux, Paris, Hermes Science Publications, , 382 p. (ISBN 978-2-7462-3155-9, lire en ligne), p. 91
  2. CFTL (Comité Français des Tests Logiciels) + ISTQB.
  3. (en) Standard IEEE 610.12:1990.
  4. « Test de régression | Visual Studio .NET 2003 », Microsoft Developer Network.
  5. [PDF] Communications of the ACM, The Humble Programmer, 15 (10), octobre 1972: pp. 859–866.
  6. [PDF] Communications of the ACM, The Humble Programmer, 15 (10), octobre 1972: pp. 859–866.

Voir aussi

Articles connexes
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.