Titre de l'invention : Système de test de fonctionnalités d’une application informatique

[0001 ] [L'invention concerne les développements informatiques, et en particulier les outils permettant de détecter des dysfonctionnements d'une application informatique en cours de développement.

[0002] En vue d'anticiper des problèmes de développement, il est connu de réaliser des tests unitaires d'une application informatique. A cet effet, des valeurs de paramètres sont injectées comme données d'entrée dans des fonctions de l'application informatique. On détermine alors si l'exécution de l'application ou les valeurs renvoyées posent des problèmes.

[0003] En pratique, et en particulier pour des applications informatiques complexes et développées en équipe, les tests unitaires ne peuvent porter que sur une partie de l'application et que sur un jeu limité de valeurs de paramètres. En effet, il s'avère irréaliste de réaliser des tests unitaires pour l'ensemble de l'application et pour des valeurs exhaustives de paramètres. Par conséquent, les développeurs réalisent des tests unitaires sur des échantillons vraiment limités de l'application et de paramètres. De plus, le choix des fonctions testées et des valeurs de paramètres de test s'avère vraiment empirique. Les tests unitaires ne sont donc pas optimaux à la fois en termes de fiabilité et en termes de temps de mise en œuvre.

[0004] Par ailleurs, les évolutions d'une application informatique sont parfois faites en partant d'une application saine, avec de nouveaux interlocuteurs qui peuvent introduire des mutations néfastes de l'application. L'anticipation de telles mutations et de leur conséquence est délicate.

[0005] L'invention vise à résoudre un ou plusieurs de ces inconvénients. L'invention porte ainsi sur un système de teste de fonctionnalités d’une application informatique tel que défini à la revendication 1 .

[0006] L’invention porte également sur les variantes des revendications dépendantes. L’homme du métier comprendra que chacune des caractéristiques des revendications dépendantes ou de la description peut être combinée indépendamment aux caractéristiques ci-dessus, sans pour autant constituer une généralisation intermédiaire.

[0007] D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence aux dessins annexés, dans lesquels :

[0008] [Fig.1 ] est une représentation schématique d’un exemple de système pour la mise en œuvre de l’invention ;

[0009] [Fig.2] est une représentation schématique de grandes catégories d’étapes mises en œuvre dans un système pour la mise en œuvre de l’invention ;

[0010] [Fig.3] est un exemple de graphe , le graphe de la figure 3 représente un graphe d’appels pour un service d’enregistrement d’un email d’identification et d’un mot de passe.

[0011 ] La figure 1 illustre de façon schématique un système de test de fonctionnalités d’une application informatique 1 , selon un exemple de mise en œuvre de l'invention. Le système de test 1 est configuré pour la mise en œuvre de tests unitaires d’une application informatique, en cours de développement ou avant sa mise en service.

[0012] Le système de test 1 comporte ici un dispositif de traitement 2 et une base de données 20. Le dispositif de traitement 2 typiquement être mis en œuvre sous la forme d'un serveur informatique accessible par un réseau informatique 3, typiquement Internet. La base de données 20 est accessible par le dispositif de traitement 2. Des exemples de contenu de la base de données 20 seront détaillés par la suite.

[0013] Le dispositif de traitement 2 peut être mis en œuvre sous la forme d'un serveur informatique accessible par le réseau 3. À cet effet, l'utilisateur dispose ici d'un terminal 4 connecté au dispositif de traitement 2 par l'intermédiaire du réseau informatique 3. Le terminal 4 est configuré pour afficher un certain nombre d'informations sur un écran de l'utilisateur. Le terminal 4 peut par exemple disposer d'un navigateur Internet communiquant avec le dispositif de traitement 2 et affichant une interface utilisateur 6. L'utilisateur peut disposer d'une interface de saisie telle qu'une souris 5, en vue de fournir des réponses au navigateur Internet, ensuite transmises au dispositif de traitement 2. Le terminal 4 dispose par ailleurs d’un accès à une application informatique en cours de développement ou devant être testée, mémorisée sur un support de stockage 7. Le support de stockage 7 peut être un stockage local du terminal 4 ou un stockage distant, par exemple sur des serveurs de stockage accessibles en ligne. Le dispositif de traitement 2 peut être configuré pour envoyer des informations d'affichage au terminal 4, par exemple sous la forme de contenus HTML.

[0014] Le dispositif de traitement numérique 2 est configuré pour récupérer le code source d’une application informatique. Le code source de l’application informatique peut également être stocké dans la base de données 20, de sorte que le dispositif 2 peut être configuré pour à la fois donner un accès au code source et mettre en œuvre des tests unitaires.

[0015] La figure 2 illustre des grandes catégories d’étapes pouvant être mises en œuvre par le dispositif de traitement 2 lors de tests ou de préparations de tests du code source de l’application informatique. La catégorie 100 correspond à des processus de génération d’une liste de fonctions à tester. La catégorie 200 correspond à des processus de génération d’une liste de valeurs de test pour les fonctions listées. La catégorie 300 correspond aux processus de test du code source lui-même.

[0016] Le dispositif de traitement numérique 2 est configuré pour analyser le code source de l’application informatique à tester dans le but de définir une liste appropriée de fonctions à tester, ce qui correspond à la catégorie 100 mentionnée précédemment. Une liste de fonctions appropriée correspond à une sélection de fonctions du code source à tester, c’est-à-dire un nombre restreint de fonctions parmi l’ensemble des fonctions du code source. A cet effet, selon l’invention, le dispositif de traitement 2 réalise les opérations suivantes pour générer la liste des fonctions à tester :

[0017] -générer un score de probabilité d’appel de chaque fonction ;

[0018] -générer un score d’impact de défaillance de chaque fonction ;

[0019] -générer un score d’imbrication pour chaque fonction ; [0020] -générer un score d’atypicité.

[0021 ] La génération du score de probabilité d’appel de chaque fonction peut être réalisée comme suit :

[0022] -définir un graphe d’appels de l’ensemble des fonctions de l’application informatique et génération d’une base de données de la fréquence d’appel de chacune des fonctions du graphe d’appels. Pour chaque fonction ‘fonction’, on pourra associer la fréquence d’appel ‘fafonction’ dans une telle base de données. La base de données des fréquences d’appel peut être stockée dans la base de données 20 ;

[0023] -générer un score de probabilité d’appel de chaque fonction, le score dépendant du graphe d’appels et de la fréquence d’appel mémorisée dans la base de données pour cette fonction. Un score de probabilité d’appel d’une fonction ‘fonction’ sera référencé ‘pafonction’ par la suite. Un exemple correspondant est illustré par référence à la figure 3. Dans l’exemple, le graphe de la figure 3 représente un graphe d’appels pour un service d’enregistrement d’un email d’identification et d’un mot de passe. La fonction 101 correspond à une lecture de données d’entrée d’un utilisateur. La fonction 102 est une fonction de vérification de la validité d’un email saisi. La fonction 103 est une fonction de validation de la robustesse du mot de passe. La fonction 104 est une fonction de validation de conformité des données d’entrée. La fonction 105 est une fonction d’inscription dans une base de données d’identifiants. Les fonctions 102 et 103 ne sont exécutées que si la fonction de lecture des données d’entrée 101 s’est effectuée correctement. Pour une fréquence donnée ‘fa10T d’appel de la fonction 101 , les probabilités d’appel respectives ‘pa102’ et ‘pa103’ des fonctions 102 et 103 est inférieure à ‘fa10T. La fonction de validation de conformité 104 n’est exécutée que si les fonctions 102 et 103 se sont effectuées correctement. Par conséquent, la probabilité d’appel ‘pa104’ est inférieure aux probabilités d’appel ‘pa102’ et ‘pa103’ des fonctions 102 et 103. La fonction d’inscription 105 n’est exécutée que si la fonction 104 s’est effectuée correctement. Par conséquent, la probabilité d’appel ‘pa105’ est inférieure à la probabilité d’appel ‘pa104’ ; [0024] La génération du score d’impact de défaillance de chaque fonction peut être réalisée comme suit : chaque fonction est classée par thème sémantique. A cet effet, on met en œuvre une analyse sémantique de chaque fonction, pour générer un score d’impact de défaillance de cette fonction en fonction de son thème sémantique. Par exemple, une fonction dont l’analyse sémantique fait apparaître des thèmes sémantiques d’authentification, de gestion de certificats ou de chiffrement sera considérée comme ayant un score d’impact de défaillance très élevée pour une application informatique de traitement de paiements bancaires. Pour un autre exemple, pour une application informatique d’un fournisseur de service, l’analyse sémantique du code source peut faire ressortir pour chaque fonction, un contexte lié au service, un contexte lié à la facturation, un contexte lié au support et un contexte d’affichage. En fonction d’une criticité qui peut être définie par le développeur ou l’utilisateur pour chaque contexte, l’analyse sémantique peut générer un score de criticité pour chacune des fonctions en fonction des contextes sémantiques identifiés.

[0025] La génération du score d’imbrication pour chaque fonction est réalisée pour chaque fonction en fonction de la portée ou du niveau d’imbrication de cette fonction (nesting level en langue anglaise). Un exemple de calcul de score d’imbrication pour une fonction de référence est détaillé à l’adresse "https://gist.github.com/avmnu-sng/790f995091 d209c00dcf2170352bebbd". Le score est détaillé ici comme un score de complexité cognitive du code source. Le score d’imbrication est représentatif de la difficulté de compréhension d’une fonction du fait de son niveau d’imbrication.

[0026] La génération du score d’atypicité permet de prendre la difficulté du débuggage pour des fonctions qui sortent du contexte usuel de l’application. La génération du score d’atypicité peut être mise en œuvre comme suit. On détermine une liste de mots les plus utilisés dans l’ensemble du code source, puis on génère une liste de mots utilisés pour chacune des fonctions. Un score d’atypicité est généré, dépendant du décalage sémantique entre les mots de la liste de mots d’une fonction par rapport à liste des mots les plus utilisés dans l’ensemble du code source. Par exemple, dans une application de gestion de 3D, le vocabulaire majoritaire est lié au graphisme (formes, lumière, angle de la caméra, etc.). Cependant, de telles applications incluent le plus souvent un module lié aux lois de la physique afin de pouvoir générer une animation réaliste. Un tel module peut inclure beaucoup de vocabulaire lié à de la thématique de la mécanique, ce qui est représente un décalage important par rapport à la thématique de la 3D.

[0027] Pour pouvoir effectuer simplement et objectivement une sélection à tester parmi l’ensemble des fonctions du code source, le dispositif de traitement 2 génère un score combiné pour chaque fonction du code source. Le score combiné combine notamment le score de probabilité d’appel, le score d’impact de défaillance, le score d’imbrication et le score d’atypicité, par exemple par simple ajout de ces scores ou par application de pondérations.

[0028] Ainsi, on génère numériquement un score pour chaque fonction, permettant à un système de traitement numérique d’établir une hiérarchie des fonctions à tester, et ainsi une liste réduite de fonctions à tester.

[0029] L’invention permet d’optimiser l’efficacité des tests unitaires réalisés, c’est-à- dire que pour un nombre donné de tests unitaires réalisés, le niveau de criticité des erreurs détectées sera optimal. Avec des ressources de test limitées, une fiabilité optimale des tests pourra ainsi être obtenue.

[0030] Avantageusement, le dispositif de traitement 2 est configuré pour générer la liste de fonctions à tester, en :

-identifiant la présence d’une documentation de chaque fonction dans le code source et en générant un score de documentation de la fonction basé sur l’identification de la présence d’une telle documentation. La présence d’une documentation d’une fonction est en effet un facteur favorisant la reprise de l’application informatique par un autre développeur ou par le développeur initial lui-même ;

-en générant le score combiné de chaque fonction du code source en tenant compte de score de documentation.

[0031] Avantageusement, la génération du score d’atypicité est mise en œuvre comme suit. La sélection de noms de mots les plus utilisés dans le code source comprend le listage de l’ensemble des mots du code source et l’élimination des noms d’opérateurs usuels d’un langage informatique. Les opérateurs usuels ne sont donc pas pris en compte pour calculer un décalage sémantique avec les mots des différentes fonctions.

[0032] Le dispositif de traitement 2 est en outre configuré pour générer une liste de valeurs de tests des fonctions listées. La génération de la liste de valeurs de test correspond à la catégorie 200 mentionnée précédemment. La génération d’une liste de valeurs de test selon l’invention peut être mise en œuvre comme suit :

[0033] -les opérations réalisées sur les paramètres des fonctions du code source sont analysées, en identifiant des structures de paramètres compatibles avec ces opérations, et en construisant des exemples de valeurs de paramètres correspondant aux structures identifiées.

[0034] - des exemples de valeurs des paramètres du code source sont listées;

[0035] - d’autres valeurs des paramètres sont extrapolées en appliquant des variations aux exemples de valeurs de paramètres dans le code source.

[0036] Par exemple, pour la fonction suivante:

[0037] def check(email):

[0038] if(re.match(regex, email)):

[0039] print("Valid Email")

[0040] else:

[0041 ] print("lnvalid Email")

[0042] La fonction re. match ne s’applique qu’à des chaînes de caractère et donc on en déduit que le paramètre ‘email’ est une chaîne de caractère. On a donc identifié une structure de paramètre compatible avec le paramètre ‘email’.

[0043] Par une analyse sémantique, on détermine également que ‘email’ est sans doute une information sous la forme d’un email. Ensuite, d’autres valeurs des paramètres sont extrapolées en appliquant des variations aux exemples de valeurs de paramètres dans le code source. Par exemple, les valeurs suivantes peuvent être extrapolées pour le paramètre ‘email’ : user@domain.com, user123@domain.com, User@domain.com, user@domain.co.uk, @domain.com, ou user.domain.com [0044] Des structures de paramètres compatibles les plus courantes et les plus utilisées peuvent par exemple être des entiers, des nombres réels, des chaines de caractères, des dates, des tableaux, des dictionnaires ou des instances de classes.

[0045] Avantageusement, l’identification de structures de paramètres compatibles comprend l’association d’une pondération à chaque structure de paramètre compatible. Le nombre de valeurs pour chaque structure compatible dans la liste de valeurs est ainsi déterminé en fonction de cette pondération, pour que les valeurs de test correspondent statistiquement à des structures de données les plus probables.

[0046] Avantageusement, l’identification de structures de paramètres compatibles est basée sur une analyse sémantique des termes à proximité de chaque appel d’une fonction. Des structures des paramètres compatibles sont ainsi déterminées en tenant compte des termes utilisés à proximité des appels de chaque fonction dans le code source.

[0047] Préalablement à la génération des valeurs, on peut détecter grâce à la sémantique des appels internes qui doivent faire l’objet de mocks et on peut ensuite les traiter comme des entrées. En programmation orientée objet, les mocks (simulacres ou mock object) sont des objets simulés qui reproduisent le comportement d'objets réels de manière contrôlée. Un programmeur crée un mock dans le but de tester le comportement d'autres objets, réels, mais liés à un objet inaccessible ou non implémenté. Ce dernier est alors remplacé par un mock.

[0048] Dans un test unitaire, les mocks peuvent simuler le comportement d'objets réels et complexes et sont utiles à ce titre quand ces objets réels sont impossibles à utiliser. On peut citer les cas suivants :

-Remplacer un comportement non déterministe (l'heure ou la température ambiante) ;

-Si l'objet a des états difficiles à reproduire (une erreur de réseau par exemple) ; -Si l'initialisation de l'objet est longue (par exemple. : création d'une base de données) ;

-Si l'objet n'existe pas ou si son comportement peut encore changer ; -S'il est nécessaire d'inclure des attributs et des méthodes uniquement à des fins de test.

[0049] Le dispositif de traitement 2 est en outre configuré pour mettre en œuvre un processus de test du code source lui-même. La mise en œuvre des tests correspond à la catégorie 300 mentionnée précédemment. Les tests de l’application informatique sont mis en œuvre avec exécution du code source pour tester la liste de fonctions générées, avec la liste de valeurs de paramètres générée, et ainsi bénéficier des sélections effectuées pour avoir un maximum d’efficacité de ces tests. Le dispositif de traitement 2 est avantageusement configuré pour mémoriser les valeurs de sortie des fonctions listées pour les valeurs d’entrée listées et pour mémoriser les appels internes. Une telle mémorisation permet de réaliser une analyse a posteriori de l’exécution de l’application informatique.

[0050] Avantageusement, le processus de test du code source comprend un module de mutation. Le module de mutation est configuré pour générer des mutations du code source à tester. Le dispositif de traitement 2 est alors configuré pour exécuter le code source muté pour la liste de fonctions et la liste de valeurs listées. Le dispositif de traitement 2 est en outre configuré pour comparer les valeurs de sortie des fonctions listées du code source d’origine et du code source muté. Un tel test de mutation permet de constater l’influence de mutations du code sur son exécution, son fonctionnement et sur ses résultats.

[0051 ] Avantageusement, on peut mettre en place un filtrage des assertions et des tests en fin de processus avant de réaliser les tests unitaires. On peut par exemple garder le sous-ensemble minimal des cas de tests et d’assertions qui couvrent toutes les lignes de code et éliminent tous les mutants générés. Ce filtrage permet d’optimiser les coûts d'exécution des tests et la lisibilité des tests unitaires.