Test de régression

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir Régression.

Une régression est récurrente lors 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. Elle menace souvent le bon fonctionnement du logiciel ou de certaines de ses fonctionnalités majeures ou mineures, On effectue à cette fin des tests de régression

Définition[modifier | modifier le code]

Test de régression : 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é[1],[2]. L'intérêt principal de ces tests est de limiter les anomalies relevées lors de la recette de l'application. 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

Difficulté[modifier | modifier le code]

  1. Ces tests sont fastidieux, car devant être le plus exhaustifs possible, afin d'assurer que le logiciel fonctionne de la même manière. Or la nature même du phénomène de régression oblige à tester à nouveau toutes les fonctionnalités précédemment testées et validées, alors que les fonctionnalités récemment validées sont peu nombreuses. En particulier, quand il s'agit de corrections d'erreurs, le nombre de tests ne peut que rester identique ou augmenter, alors même que le nombre de modifications apportées diminue. Le rendement de la phase de test décroît donc rapidement.
  2. 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) [1], Communications of the ACM 15 (10), octobre 1972: pp. 859–866

« le test des programmes peut montrer la présence de bugs, mais jamais garantir leurs absence »

— The Humble Programmer (1972) [2], Communications of the ACM 15 (10), octobre 1972: pp. 859–866

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, ainsi Simpletests pour Drupal depuis sa version 7.

Une alternative consiste à limiter le nombre de tests à réaliser suite à 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.

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.

Stratégie de tests de régression[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.

Dans le cas de tests manuels l'enjeu est donc d’identifier les tests pertinents 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 (code, ….), 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.

Logiciels pour les tests de régression[modifier | modifier le code]

  • Ranorex
  • Smartesting, permet une conception et une maintenance rapide de scénarios de tests manuels ou automatisés
  • MaTeLo
  • sYnopsis (KALIOS)
  • Squish
  • Visual Studio Team Tester Edition
  • LDRA TBrun
  • TestPartner de Compuware
  • Rational Functional Tester (IBM)
  • Valgrind (libre et gratuit)
  • QF-Test (Quality First Software)
  • QuickTest Professional (HP-Mercury)
  • Selenium (libre et gratuit)
  • WebDriver (libre et gratuit)
  • DejaGnu : Framework de test de non-régression du projet GNU.
  • Kalistick (stratégie de test de non-régression)
  • TestComplete (SMARTBEAR)
  • Recital : logiciel de tests (EURAXIEL).

Voir aussi[modifier | modifier le code]

Notes et références[modifier | modifier le code]

  1. CFTL (Comité Français des Tests Logiciels) + ISTQB
  2. Standard IEEE 610.12:1990 (en anglais)