Wikipédia

Régression logicielle

bug logiciel

Une régression logicielle est un type de bug dans lequel une fonctionnalité qui fonctionnait auparavant cesse de fonctionner. Cela peut se produire après la modification du code source du logiciel, notamment l'ajout de nouvelles fonctionnalités et de corrections de bugs. La régression peut aussi se produire à la suite d'une modification de l'environnement d'exécution du logiciel, comme une mise à jour du système d'exploitation, des dépendances, ou simplement un changement de configuration.

Une régression des performances d'un logiciel est une situation dans laquelle le logiciel fonctionne toujours correctement, mais s'exécute plus lentement ou utilise plus de ressources qu'auparavant.

Typologie modifier

Différents types de régressions logicielles ont été identifiés dans la pratique, notamment les suivants :

  • Locale – une modification introduit un nouveau bug dans le composant modifié.
  • Distante – une modification dans une partie du logiciel casse un autre composant.
  • Révélation (unmasking) – une modification révèle un bug déjà existant qui n’avait aucun effet auparavant.

Les régressions sont souvent causées par corrections "hotfix" incluses dans des patches. Une méthode pour éviter ce problème consiste à effectuer des tests de régression à l'aide d'un plan de test préalablement conçu[1]. Des tests automatisés et des cas de test bien rédigés peuvent réduire le risque de régression.

Prévention et détection modifier

Plusieurs techniques ont été proposées pour éviter l'introduction de régressions dans les logiciels à différents stades de développement.

Avant la publication modifier

Afin d'éviter que l'utilisateur final ne subisse des régressions après la sortie du logiciel, les développeurs exécutent régulièrement des tests de régression après l'introduction de modifications dans le logiciel. Ces tests peuvent inclure des tests unitaires pour détecter les régressions locales ainsi que des tests d'intégration pour détecter les régressions distantes[2]. Les tests de régression exploitent souvent les cas de test existants pour le développement, cependant il est souvent nécessaire de sélectionner un sous-ensemble représentatif, en utilisant la priorisation des cas de tests.

Pour détecter les régressions de performance, des tests de performance sont exécutés régulièrement afin de surveiller les temps de réponse et l'utilisation des ressources (mémoire, bande passante, charge CPU) du logiciel après les modifications[3]. Contrairement aux tests de régression fonctionnelle, les résultats des tests de performance sont sujets à une variance, c'est-à-dire que les résultats peuvent différer d'un test à l'autre en raison de la variation des mesures. Par conséquent, il faut décider si un changement de la mesure est significatif et constitue réellement une régression. Des approches de tests statistiques et de détection de ruptures sont parfois utilisées pour faciliter cette décision[4].

Avant le commit modifier

Étant donné que la localisation de la cause d'une régression logicielle peut être coûteuse[5],[6] il existe également des méthodes qui tentent d'empêcher la validation des régressions dans le dépôt de code en premier lieu. Par exemple, les hooks Git permettent aux développeurs d'exécuter des scripts de test avant que les modifications de code (commits) ne soient validées ou transmises au dépôt[7]. Des outils d'analyse statique comme lint sont également souvent ajoutés aux hooks de validation pour garantir un style de code cohérent, minimisant ainsi les problèmes stylistiques qui peuvent accentuer le risque de régressions[8].

Localisation des régressions modifier

De nombreuses techniques utilisées pour trouver la cause première des bogues logiciels de non-régression peuvent également être utilisées pour déboguer les régressions logicielles, notamment le débogage par point d'arrêt, le débogage par affichage et le découpage (slicing). Les techniques décrites ci-dessous sont souvent utilisées spécifiquement pour trouver la cause des régressions logicielles.

Régression fonctionnelle modifier

Une technique courante utilisée est la localisation par dichotomie, qui prend en entrée à la fois un commit bogué et un commit précédent fonctionnel, et tente de trouver la cause initiale en effectuant une recherche dichotomique sur les commits intermédiaires[9]. Les systèmes de gestion de versions tels que Git et Mercurial fournissent des moyens intégrés pour effectuer une telle recherche[10],[11].

D'autres options incluent l'association directe du résultat d'un test de régression aux modifications de code[12], la définition de points d'arrêt de divergence[13], ou une analyse du flot de contrôle, qui identifie les cas de test - y compris ceux qui échouent - pertinents pour un ensemble de modifications de code[14].

Régressions de performance modifier

Le profilage mesure les performances et les ressources utilisées par différentes parties d'un programme et fournit des données utiles au débogage des problèmes de performances. Dans le contexte des régressions de performances, les développeurs comparent souvent les piles d'éxécution (ou arbres d'appel) générés par les profileurs à la fois pour la version boguée et pour la version précédemment fonctionnelle. Des mécanismes existent pour automatiser cette comparaison[15]. Les outils développeurs (devtools) des navigateurs offrent généralement la possibilité d'enregistrer ces profils de performances[16],[17].

La journalisation (logging) facilite également la localisation des régressions de performances et, à l'instar des arbres d'appels, les développeurs peuvent comparer les journaux de performances de plusieurs versions du même logiciel[18]. Il existe un compromis lors du paramétrage d'un log de performance, car un journal plus détaillé permet d'atteindre une granularité plus fine, tandis qu'un journal moins détaillé réduira la surcharge lors de l'exécution du programme[19].

D'autres méthodes incluent l'écriture de tests unitaires sensibles aux performances[20] et le classement des sous-systèmes en fonction des écarts des mesures de performances[21]. La recherche dichotomique peut également être réutilisée pour les régressions de performances en définissant une valeur seuil de mesure d'exécution (durée par exemple).

Voir également modifier

Notes et références modifier

  1. ↑ Jared Richardson et Gwaltney, William Jr, Ship It! A Practical Guide to Successful Software Projects, Raleigh, NC, The Pragmatic Bookshelf, , 32, 193 (ISBN 978-0-9745140-4-8, lire en ligne)
  2. ↑ Hareton K.N. Leung et Lee White, Proceedings of the International Conference on Software Maintenance, San Diego, CA, USA, IEEE, (ISBN 0-8186-2091-9, DOI 10.1109/ICSM.1990.131377, S2CID 62583582, lire en ligne), « A study of integration testing and software regression at the integration level »
  3. ↑ Weyuker et Vokolos, « Experience with performance testing of software systems: issues, an approach, and case study », IEEE Transactions on Software Engineering, vol. 26, no 12,‎ , p. 1147–1156 (ISSN 1939-3520, DOI 10.1109/32.888628, lire en ligne)
  4. ↑ David Daly, William Brown, Henrik Ingo, Jim O'Leary et Bradford, Proceedings of the International Conference on Performance Engineering, Association for Computing Machinery, , 67–75 p. (ISBN 978-1-4503-6991-6, DOI 10.1145/3358960.3375791, S2CID 211677818, lire en ligne), « The Use of Change Point Detection to Identify Software Performance Regressions in a Continuous Integration System »
  5. ↑ Adrian Nistor, Tian Jiang et Lin Tan, Proceedings of the Working Conference on Mining Software Repositories (MSR), , 237–246 p. (ISBN 978-1-4673-2936-1, DOI 10.1109/MSR.2013.6624035, S2CID 12773088, lire en ligne), « Discovering, reporting, and fixing performance bugs »
  6. ↑ Agarwal et Agrawal, « Fault-localization techniques for software systems: a literature review », ACM SIGSOFT Software Engineering Notes, vol. 39, no 5,‎ , p. 1–8 (ISSN 0163-5948, DOI 10.1145/2659118.2659125, S2CID 12101263, lire en ligne)
  7. ↑ « Git - Git Hooks », git-scm.com (consulté le )
  8. ↑ Kristín Fjóla Tómasdóttir, Mauricio Aniche et Arie van Deursen, Proceedings of the International Conference on Automated Software Engineering, , 578–589 p. (ISBN 978-1-5386-2684-9, DOI 10.1109/ASE.2017.8115668, S2CID 215750004, lire en ligne), « Why and how JavaScript developers use linters »
  9. ↑ (en) Thomas Gross, Proceedings of the International Workshop on Automatic Debugging, Linkøping University Electronic Press, , 185–191 p. (lire en ligne), « Bisection Debugging »
  10. ↑ « Git - git-bisect Documentation », git-scm.com (consulté le )
  11. ↑ « hg - bisect », www.selenic.com, Mercurial (consulté le )
  12. ↑ « Reading 11: Debugging », web.mit.edu, MIT
  13. ↑ Ben Buhse, Thomas Wei, Zhiqiang Zang, Aleksandar Milicevic et Gligoric, Proceedings of the International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), , 15–18 p. (ISBN 978-1-7281-1764-5, DOI 10.1109/ICSE-Companion.2019.00027, S2CID 174799830, lire en ligne), « VeDebug: Regression Debugging Tool for Java »
  14. ↑ A.-B. Taha, S.M. Thebaut et S.-S. Liu, Proceedings of the Annual International Computer Software & Applications Conference, IEEE, , 527–534 p. (ISBN 0-8186-1964-3, DOI 10.1109/CMPSAC.1989.65142, S2CID 41978046, lire en ligne), « An approach to software fault localization and revalidation based on incremental data flow analysis »
  15. ↑ (en) Ocariza et Zhao, « Localizing software performance regressions in web applications by comparing execution timelines », Software Testing, Verification and Reliability, vol. 31, no 5,‎ , e1750 (ISSN 1099-1689, DOI 10.1002/stvr.1750, S2CID 225416138, lire en ligne)
  16. ↑ (en) « Analyze runtime performance », Chrome Developers, Google (consulté le )
  17. ↑ (en-US) « Performance analysis reference - Microsoft Edge Development », docs.microsoft.com, Microsoft (consulté le )
  18. ↑ Kundi Yao, Guilherme B. de Pádua, Weiyi Shang, Steve Sporea, Toma et Sajedi, Proceedings of the International Conference on Performance Engineering, Association for Computing Machinery, , 127–138 p. (ISBN 978-1-4503-5095-2, DOI 10.1145/3184407.3184416, S2CID 4557038, lire en ligne), « Log4Perf: Suggesting Logging Locations for Web-based Systems' Performance Monitoring »
  19. ↑ Li, Shang, Adams et Sayagh, « A Qualitative Study of the Benefits and Costs of Logging from Developers' Perspectives », IEEE Transactions on Software Engineering, vol. 47, no 12,‎ , p. 2858–2873 (DOI 10.1109/TSE.2020.2970422, S2CID 213679706, lire en ligne)
  20. ↑ Christoph Heger, Jens Happe et Roozbeh Farahbod, Proceedings of the International Conference on Performance Engineering, Association for Computing Machinery, , 27–38 p. (ISBN 978-1-4503-1636-1, DOI 10.1145/2479871.2479879, S2CID 2593603, lire en ligne), « Automated root cause isolation of performance regressions during software development »
  21. ↑ Haroon Malik, Bram Adams et Ahmed E. Hassan, Proceedings of the International Symposium on Software Reliability Engineering, , 201–210 p. (ISBN 978-1-4244-9056-1, DOI 10.1109/ISSRE.2010.43, S2CID 17306870, lire en ligne), « Pinpointing the Subsystems Responsible for the Performance Deviations in a Load Test »
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Régression_logicielle&oldid=214600401 ».