Test de régression
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Pour les articles homonymes, voir Régression.
Un test de régression, ou test de non-régression[1], est un test ayant pour but de détecter les régressions introduites dans un logiciel après un changement effectué dans celui-ci.
Une régression est un défaut qui se produit après une modification d'un logiciel lorsque des fonctionnalités existantes ne sont plus réalisées aussi bien qu'avant. Les régressions peuvent apparaitre à l'occasion de n'importe quel changement établi dans un logiciel : corrections de bogues, 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). Il est donc intéressant d'être en mesure de repérer les régressions, par le biais de tests automatisés ou non, avant la mise à disposition de la nouvelle version du logiciel auprès des utilisateurs.
Définition
[modifier | modifier le code]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'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].
Intérêt
[modifier | modifier le code]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 mise à disposition des utilisateurs. Ils viennent compléter les tests unitaires et les tests d'intégration en amont des tests de recette.
Difficultés
[modifier | modifier le code]Les tests de régression sont longs à exécuter
[modifier | modifier le code]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
[modifier | modifier le code]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. »
« Tester des programmes peut révéler des bugs très efficacement, mais cela ne permet pas d’en démontrer l’absence. »
Solutions
[modifier | modifier le code]Automatisation des tests
[modifier | modifier le code]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[réf. nécessaire].
Sélection réfléchie des cas de test à exécuter
[modifier | modifier le code]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.
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
[modifier | modifier le code]- Bernard Homès, Les tests logiciels : fondamentaux, Paris, Hermes Science Publications, , 382 p. (ISBN 978-2-7462-3155-9, lire en ligne), p. 91
- CFTL (Comité Français des Tests Logiciels) + ISTQB.
- (en) Standard IEEE 610.12:1990.
- « Test de régression | Visual Studio .NET 2003 », Microsoft Developer Network.
- [PDF] Communications of the ACM, The Humble Programmer, 15 (10), octobre 1972: pp. 859–866.
