Dans ce mémoire nous visons à automatiser l’identification des problèmes fonctionnels dans les simulateurs de vol en répondant à trois objectifs qui sont : de modéliser le simulateur en utilisant l’apprentissage automatique, de détecter les écarts dans les métriques que l’on enregistre dans des nouvelles versions du simulateur et d’être en mesure de détecter auto- matiquement les déviations dans les cas où une nouvelle version du simulateur comporte des problèmes fonctionnels. Nous discutons dans cette section de la méthodologie et des résul- tats que nous avons obtenus pour rencontrer ces trois objectifs tout en nous référant à la littérature existante.
6.1 Objectifs 1 et 2 : modélisation du simulateur et détection des écarts dans les métriques
Dans la littérature, on utilise plusieurs techniques d’apprentissage automatique afin de mo- déliser un système logiciel à partir de données enregistrées. Parmi ces techniques, il y a la régression logistique, les réseaux de neurones, les modèles de Bayes, les règles associatives et les arbres de décision. Puisque nous visons à travailler avec des systèmes composés de boîtes noires, il est intéressant de choisir un modèle permettant un visuel graphique du comporte- ment du système. Nous optons donc pour des arbres de décisions qui sont des modèles qui offrent une abstraction visuelle en utilisant une représentation d’arbre composé de noeuds, de feuilles et de branches. D’autres travaux optent pour une modélisation utilisant des règles as- sociatives qui mettent en lien des observations sur les métriques sans les diviser entre entrées et sorties. Puisque nous cherchons à expliquer l’impact d’un stimulus (c.-à-.d, des entrées) sur le comportement (c.-à-.d, les sorties) du simulateur, nous sélectionnons avec l’aide d’ex- perts un ensemble de métriques de sortie et d’entrée, ce qui nous permet d’avoir un modèle représentant le système et de remplir notre premier objectif.
Les autres techniques d’apprentissage automatique, malgré une représentation plus fidèle du sytème modélisé dans certains cas, n’offrent pas une représentation graphique du comporte- ment du système. Même si nous cherchons à avoir un modèle représentant parfaitement notre système, il faut faire attention au sur-ajustement du modèle qui n’est pas préférable puisque l’on veut être tolérant aux variations normales dans les métriques enregistrées sous un même stimulus (la figure 4.3 montre ce phénomène). Nous voulons ainsi éviter de générer trop de fausses alarmes, ce qui rendrait l’adoption de notre approche de test inutile. En effet, un système considérant toute métrique comme étant déviante aurait un taux de rappel parfait
avec une précision très faible, ce qui alourdirait la tâche des testeurs qui devraient vérifier le système en entier. La calibration à la section 4.4.6 montre que l’écart des métriques par rap- port au modèle peut aller jusqu’à 41%. Cela confirme notre intuition qu’il faut adopter une approach de détection flexible et tolérante aux écarts tout en ne manquant pas les déviations lorsqu’elles sont présentes.
6.2 Objectif 3 : automatisation de la détection avec un niveau de seuil
Nous proposons une approche qui détecte automatiquement les déviations dans des métriques que nous enregistrons pendant le pilotage d’un simulateur de vol, permettant ainsi d’identifier ses problèmes fonctionnels. L’avantage de détecter les déviations au niveau des métriques est mis en valeur dans la littérature, permettant ainsi de mieux identifier la nature d’un problème. Les résultats de l’étape de calibration à la section 4.4.6 montrent que les écarts des métriques par rapport à leurs signatures peuvent être très disparates. Nous sélectionnons donc un premier niveau de seuil de détection juste au dessus de la médiane d’écart la plus haute afin d’éviter les fausses alarmes avec les versions ayant un comportement normal tout en maximisant le rappel des déviations dans les versions avec problème fonctionnel.
Un niveau de seuil optimisé pour un meilleur rappel réduit la précision de notre approche, nous obtenons donc initialement un taux de fausses alarmes de 60% et une précision aussi basse que 40%. Nous améliorons notre approche dans la discussion de la section 4.6.1 en proposant des niveaux de seuil sur les métriques adaptés à chacune des versions, obtenant ainsi un taux de fausses alarmes parfait pour les versions n’ayant pas de problèmes fonctionnels et, pour les versions ayant des problèmes fonctionnels, une précision minimale de 50% tout en ne manquant aucune déviation avec un taux de rappel de 100%.
La fluctuation de la précision et du rappel de notre approche en fonction des modifications apportées au simulateur se manifeste aussi dans l’approche développée par Foo et al. [10]. Les auteurs obtiennent une précision fluctuant entre 75% et 100% et un rappel fluctuant entre 54% et 67% en fonction de l’erreur qu’ils injectent dans le système testé. Dans notre cas, avec l’utilisation des seuils optimaux, nous obtenons un taux de rappel de 100% et une précision variant de 50% à 100%. En comparant les résultats, nous remarquons que Foo et al. mettent plus l’accent sur la précision de leur approche, tandis que nous préférons le rappel dans notre cas à cause du niveau critique du système que l’on test. L’orientation des résultats est donc en fonction du contexte dans lequel nous détectons les problèmes fonctionnels. Le dilemme suivant se pose donc, veut-on assurer la sécurité du système ou veut-on simplement mieux assister les testeurs en leurs donnant des diagnostics précis ?