Les travaux effectués dans de cadre de cette thèse s'intéressent à la problématique du test de sécurité des applications, en considérant la validation des mécanismes de sécurité interne à un système d'une part, puis la sécurité des interfaces web d'autre part. Pour la partie interne, nous avons comparé, dans un premier temps, l'utilisation du test fonctionnel et des tests de sécurité pour valider les mécanismes implémentant une politique de contrôle d'accès. Dans ce cadre, l'analyse de mutation a été adaptée pour qualifier et évaluer les tests. Nous avons ensuite proposé trois méthodologies pour tester les mécanismes de contrôle d'accès: - utilisation du pair-wise pour générer les tests de sécurité, - sélection et transformation des tests fonctionnels en tests de sécurité - détection de mécanismes de sécurité cachés qui nuisent à la flexibilité et l'évolutivivité du système. Concernant le test des interfaces web, visant non seulement à tester le code validant les entrées de l'utilisateur mais aussi protéger les applications web, nous avons proposé une nouvelle approche qui tire profit du test par contournement (bypass-testing) et qui permet de protéger les applications web contre ce type d'attaques. Cette approche a été concrétisée dans un outil permettant à la fois l'audit et la sécurisation des applications web. L'ensemble de ces travaux a conduit à réfléchir à de nouvelles méthodologies de développement garantissant une meilleure qualité et une meilleure testabilité des mécanismes de contrôle d'accès. L'ingénierie des modèles (IDM) a été exploitée pour automatiser la spécification et le déploiement semi-automatisé des politiques de contrôle d'accès, et offrir par analyse de mutation un moyen de certification générique des tests de sécurité. Enfin, la composition de modèles permet d'automatiser l'intégration des mécanismes de sécurité, et surtout la reconfiguration automatique du système en cas d'évolution de la politique de sécurité.

Réutiliser les tests unitaires automatiquement est une solution pour faciliter le travail de certains développeurs. Dans notre recherche, nous proposons une ébauche de solution en utilisant le raisonnement à base de cas (Case Based reasoning - CBR) issu du domaine de l’intelligence artificielle. Cette technique tente de trouver le cas le plus similaire dans une base de cas pour ensuite, après modifications, le réutiliser pour résoudre un nouveau problème. Nos travaux de recherche se concentrent sur l’analyse de la similarité du code dans l’optique de réutiliser des tests unitaires. Nous porterons donc une attention particulière à l’élaboration d’une technique de comparaison des classes adaptées au contexte des tests. Plus précisément, dans ce mémoire, nous aborderons les questions suivantes: 1. Trouver la classe la plus similaire dans le but de réutiliser ses tests unitaires (travaux principaux); 2. Trouver les méthodes similaires entre les deux classes similaires; 3. Chercher les tests réutilisables en fonction de la similarité des méthodes de ces deux classes. Pour ce faire, nous mènerons des expérimentations afin de trouver les meilleures attributs (caractéristiques) permettant de comparer deux classes. Ces attributs doivent être choisis en considérant le contexte particulier des tests qui ne sont pas les mêmes que pour, par exemple, détecter du code dupliqué. Cette recherche nous permet de proposer un premier algorithme d’analyse de la similarité des classes qui fonctionne assez bien dans le contexte de notre expérimentation. Nous avons également étendu le processus à la sélection et la réutilisation de tests à l’aide d’une technique simple permettant de vérifier que l’algorithme d’analyse de similarité des classes peut potentiellement fonctionner et s’intégrer à un processus complet. Nos travaux montrent qu’il est possible de réutiliser des tests unitaires, bien que l’algorithme reste à être améliorer. Nous proposons d’ailleurs plusieurs pistes à ce sujet. / Automatically reusing unit tests is a possible solution to help developers with their daily work. Our research proposes preliminary solutions using case base reasoning (CBR), an approach coming from artificial intelligence. This technique try to find the most similar case in a case base to reuse it after some modifications against some new problems to solve. Our works focus on the similarity analysis of a program code with the goal of reusing unit tests. Our main focus will be on the elaboration of a technique to compare classes in the test context. To be more precise, in the thesis, we will discuss: 1. How to find the most similar class for which it will be possible to reuse its tests (main focus); 2. How to find similar methods between the new class and the most similar one; 3. Find which test could be reused considering the similarity of the methods. To achieve this, we will run some experiments to find the bests attributes (characteristics) to compare two classes. Those attributes must be chosen considering the specific context of testing. For example, those characteristics are not the same as for finding duplicated code. This research propose an algorithm to analyze the similarity of classes. Our experiment shows that this algorithm works quite well in the context of the experiment. We also extended the experiment to see if it could possibly work within the whole process of selection and reuse of unit tests. We did this by using some simple techniques that could certainly be refined. In fact, our works demonstrate that it is possible to reuse unit tests despite the fact that our algorithm could be perfected and we suggest some improvements about it.

Bien que l’AOP soit présent dans le paysage informatique depuis quelques années, son adoption industrielle reste relativement timide malgré les bénéfices architecturaux promis et espérés. L’objectif principal de nos travaux est de favoriser l’adoption de l’AOP auprès des développeurs oeuvrant dans l’industrie. Nous voulons proposer des solutions adaptées qui permettent à ces professionnels d’embrasser l’AOP sans avoir à sacrifier leur processus, méthodologie et outils actuels qui leur permettent d’atteindre des objectifs de performance, de qualité, de déploiement et de maintenabilité. Afin de nous permettre d’identifier des besoins réels, nous avons centré nos travaux sur des équipes employant un processus Agile. En effet, les processus Agiles préconisent généralement diverses pratiques et principes qui risquent d’être affectés par un changement de paradigme de programmation. C’est notamment le cas des tests qui tiennent une place très importante au sein des méthodes agiles, car ils permettent l’acceptation du changement sur le long terme. Dans un premier temps, nous avons mené une étude exploratoire dont l’objectif était de mieux définir quels seraient les irritants pour des développeurs débutants avec l’AOP et qui travaillent dans un environnement Agile. À la lumière des résultats de cette étude, nous avons amorcé la partie maîtresse de nos travaux qui consistent à élaborer une solution pour faciliter les tests unitaires d’aspects. Pour ce faire, nous avons conçu et rendu disponible un cadre d’applications (framework) permettant la création et le tissage de Mocks avec des aspects, facilitant ainsi l’isolation des aspects. Ce cadre a été développé de manière à s’arrimer avec les pratiques et outils répandus en industrie pour des équipes Agiles. / Although the fact that AOP has been proposed since quite a few years, the industrial adoption of this paradigm is not widespread in spite of the benefits hoped and promised for software architectures. The main goal of our work is to promote the adoption of AOP by industrial developers. We want to provide adapted solutions allowing those professionals to embrace AOP without having to sacrifice their processes, practices and tools. We seek practical solutions to allow them to reach their performance, quality, deployment and maintainability goals. To better identify and understand the real needs of teams using Agile processes, our work is focus on Agile environments. In fact, Agile processes encourage numerous practices and principles that could be affected by the usage of AOP in such projects. For instance, this is the case for software testing who is largely embraced the Agile community as a way of sustaining the acceptation of change over time. Our first step was to conduct an exploratory study to identify what could be the irritants for Agile teams who want to use AOP for the first time. Considering those results, we undertook our main contribution consisting to produce a solution to help unit testing of aspects. To do so, we developed and made available a framework to create and weave Mocks with aspects to help isolate aspects for testing purposes. The framework was designed to integrate easily with practices and tools commonly used in the industry by Agile teams.

Les logiciels actuels sont de grandes tailles, complexes et critiques. Le besoin de qualité exige beaucoup de tests, ce qui consomme de grandes quantités de ressources durant le développement et la maintenance de ces systèmes. Différentes techniques permettent de réduire les coûts liés aux activités de test. Notre travail s’inscrit dans ce cadre, est a pour objectif d’orienter l’effort de test vers les composants logiciels les plus à risque à l’aide de certains attributs du code source. À travers plusieurs démarches empiriques menées sur de grands logiciels open source, développés avec la technologie orientée objet, nous avons identifié et étudié les métriques qui caractérisent l’effort de test unitaire sous certains angles. Nous avons aussi étudié les liens entre cet effort de test et les métriques des classes logicielles en incluant les indicateurs de qualité. Les indicateurs de qualité sont une métrique synthétique, que nous avons introduite dans nos travaux antérieurs, qui capture le flux de contrôle ainsi que différentes caractéristiques du logiciel. Nous avons exploré plusieurs techniques permettant d’orienter l’effort de test vers des composants à risque à partir de ces attributs de code source, en utilisant des algorithmes d’apprentissage automatique. En regroupant les métriques logicielles en familles, nous avons proposé une approche basée sur l’analyse du risque des classes logicielles. Les résultats que nous avons obtenus montrent les liens entre l’effort de test unitaire et les attributs de code source incluant les indicateurs de qualité, et suggèrent la possibilité d’orienter l’effort de test à l’aide des métriques. / Current software systems are large, complex and critical. The need for quality requires a lot of tests that consume a large amount of resources during the development and the maintenance of systems. Different techniques are used to reduce the costs of testing activities. Our work is in this context. It aims to guide the unit testing effort distribution on the riskiest software components using the source code attributes. We conducted several empirical analyses on different large object-oriented open source software systems. We identified and studied several metrics that characterize the unit testing effort according to different perspectives. We also studied their relationships with the software class metrics including quality indicators. The quality indicators are a synthetic metric that we introduced in our previous work. It captures control flow and different software attributes. We explored different approaches for unit testing effort orientation using source code attributes and machine learning algorithms. By grouping software metrics, we proposed an effort orientation approach based on software class risk analysis. In addition to the significant relationships between testing metrics and source code attributes, the results we obtained suggest the possibility of using source code metrics for unit testing effort orientation.

Les travaux présentés dans ce mémoire concernent la modélisation des comportements erronés du logiciel et la validation des tests. L'absence d'un modèle des fautes logicielles pose le problème de la confiance que l'on peut accorder aux tests par rapport à l'élimination des fautes dans un programme. Cette confiance serait accrue si on pouvait mesurer la capacité de jeux de tests à révéler des fautes injectées dans un programme. Cependant, les méthodes d'injection de fautes, telles que l'analyse de mutation, suscitent des critiques liées à la représentativité des fautes injectées vis-à-vis de fautes réelles (c'est-à-dire effectivement introduites au cours du développement du logiciel). S'il paraît illusoire de démontrer la représentativité des fautes artificielles, étant donné l'absence d'un modèle de fautes complet et parfait, il nous paraît intéressant d'évaluer la représentativité des erreurs générées par des fautes artificielles vis-à-vis des erreurs dues à des fautes réelles. Les études expérimentales que nous avons menées, portent sur deux programmes séquentiels (appelés ETUD et LOCALES), issus d'applications critiques du nucléaire. Elles ont eu pour objet d'analyser les erreurs générées au cours de l'exécution du logiciel. Nous avons ainsi pu comparer, pour chacun de ces deux programmes, les erreurs et les comportements erronés générés, d'une part par des fautes réelles et, d'autre part par des fautes artificielles (de type mutations). Nos résultats expérimentaux permettent de montrer que les erreurs et les comportements erronés produits par des mutations peuvent être représentatifs de ceux générés par de fautes réelles. La première série d'expériences, sur le programme ETUD, a permis de définir un modèle des comportements erronés, à partir d'une représentation de l'état interne d'un programme en cours d'exécution. Ce modèle permet d'expliquer, par l'analyse des dépendances du programme, les mécanismes de création, d'annulation et de masquage d'erreurs. La deuxième série d'expériences, sur le programme LOCALES, permet d'expliquer les similitudes observées entre divers comportements erronés en appliquant le modèle proposé. En conclusion, la bonne représentativité des erreurs générées par les mutations nous permet de réhabiliter l'analyse de mutation en tant que technique de validation des tests du logiciel et d'en proposer des applications à des fins industrielles.