Non-régression

Pour les articles homonymes, voir Régression.

Cet article est une ébauche concernant l’informatique. Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

La non-régression consiste à ce que des corrections de bogues ou ajout de fonctionnalités nouvelles dans un logiciel ne provoquent pas une perturbation de fonctions existantes par effet secondaire. On effectue à cette fin des tests de non régression.

Ces tests sont utiles aussi quand on modifie 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.

Définition

Test de non 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é. 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.

Difficulté

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 à retester 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 en fait un de ses chevaux de bataille pour améliorer la qualité du logiciel.

Stratégie de test de non régression

Automatiser les tests de régressions 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 baser sa stratégie sur des faits.

Pour disposer de ces faits, l’analyse de l’application (code, ….) 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 test de non-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 à jouer est limité au strict nécessaire.

Logiciels pour les tests de non régression

• sYnopsis (KALIOS)
• Squish
• Visual Studio Team Tester Edition
• LDRA TBrun
• TestPartner de Compuware
• Rational Functional Tester (IBM)
• Valgrind (libre et gratuit)
• QF-test (payant)
• 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 (editeur SMARTBEAR, voir smartbear.com)

Voir aussi

• Test
• Cycle en V