FR 3097665 A1 20201225 FR 1906638 A 20190620 Description Titre de l'invention : Procédé de validation automatique de COTS et dispositif pour la mise en oeuvre du procédé [0001] L'invention se situe dans le domaine général des systèmes d'information. Elle se rapporte plus particulièrement à la validation de composants, d'équipements, de produits, de systèmes d'information, et des applications logicielles utilisant des produits logiciels sur étagères ou des logiciels libres. [0002] Un produit informatique standard (logiciel ou matériel), aussi nommé 'produit in- formatique COTS' (sigle emprunté à l'expression d'origine anglaise "commercial offthe-shelr) désigne tout produit informatique fabriqué en série et vendu en grande distribution pour répondre à des besoins spécifiques de plusieurs utilisateurs qui peuvent l'utiliser de façon autonome. Les produits informatiques standards sont de plus en plus utilisés dans les systèmes industriels en raison de leurs faibles coûts de conception, de fabrication, et de maintenance. [0003] Un logiciel standard (aussi nommé 'logiciel commercial sur étagère') est un logiciel conçu par le titulaire du marché ou un éditeur tiers, existant en de multiples copies, dont le code source peut être disponible, vendu, loué, fourni gratuitement par un vendeur (par exemple les logiciels libres), ou inconnu. Les logiciels standards sont destinés à être incorporés en tant que pièces détachées dans des systèmes hôtes tels que les systèmes d'informations et les applications logicielles. Des exemples de logiciels standards comprennent les composants d'extension (par exemples les plugins, les codecs, les pilotes, etc.), les bibliothèques logicielles, les exécutables, les fichiers, les composants de données (par exemples les bases de données et les ontologies), et les éléments de configuration tels que les paramètres, les scripts, et les fichiers de commandes. [0004] L'intégration de logiciels standards permet de bénéficier dc logiciels récents et évolutifs à faible coût, opérationnels dans les meilleurs délais, et réutilisables sur d'autres systèmes spécifiques. [0005] En informatique, un test de validation désigne un test informatique qui permet de vérifier si un logiciel respecte toutes les exigences client décrites dans le document de spécifications du logiciel. L'objectif principal d'un test de validation est de rechercher des informations quant à la qualité du système et d'identifier un nombre de comportements problématiques du logiciel testé afin de permettre la prise de décisions. [0006] Les tests de validation sont réalisés en plusieurs phases, en validation fonctionnelle, validation solution, et validation de performance et de robustesse. Les tests fonctionnels assurent que les divers modules ou composants implémentent correctement les 2 exigences client. Les tests de validation solution assurent que les exigences client sont respectées d'un point de vue « cas d'utilisation ». Les tests de performances vérifient la conformité de la solution par rapport à des exigences de performance, et les tests de robustesse permettent d'identifier des éventuels problèmes de stabilité et de fiabilité dans le temps. [0007] La classification des tests informatiques peut se baser sur la nature de l'objet à tester, ou sur l'accessibilité de la structure de l'objet, ou encore sur la propriété de l'objet. Selon la nature de l'objet testé, quatre niveaux de tests existent: des tests de composants (ou tests unitaires), des tests d'intégration, des tests systèmes, et des tests d'acceptation. Selon l'accessibilité de la structure de l'objet, trois techniques de tests de validation existent: les tests en mode 'boîte blanche', les tests en mode 'boîte grise', et les tests en mode 'boîte noire'. [0008] Les tests en mode boîte blanche, qui sont en général des tests fonctionnels, permettent de vérifier la structure interne d'un composant ou d'un système. L'objet testé répond à un besoin exprimé. Ses interfaces sont spécifiées et son contenu devient la propriété de l'intégrateur de l'objet dans le système hôte. L'objet testé devient partie intégrante du système hôte avec la possibilité d'adapter ses stratégies de validation, le transfert d'une partie du savoir-faire du développeur (ou fournisseur) vers l'intégrateur, et l'adaptation de l'objet au besoin du système spécifique. Pour certains types de logiciels, des techniques de conception de tests en mode boîte blanche sont prescrites par des normes (par exemple les normes RTCA/D0-178C/D0-278C ou EUCOCAE ED-12C/ED-109A pour le secteur aéronautique). [0009] Les tests en mode boîte grise permettent de tester un objet qui répond à un besoin exprimé, dont les interfaces sont spécifiées et le contenu est partiellement connu. Certaines données de développement deviennent la propriété de l'intégrateur du système hôte avec la visibilité du code source et de certaines documentations techniques (spécifications) et des tests du fournisseur. [0010] Les tests en mode boîte noire, fonctionnels ou non-fonctionnels, permettent de vérifier la définition de l'objet testé en vérifiant que les sorties obtenues sont bien celles prévues pour des entrées données, l'objet testé ayant des interfaces spécifiées mais un contenu inconnu. [0011] La validation des logiciels standards et des logiciels libres se base souvent sur des techniques de tests en mode boîte noire à cause de l'effet boîte noire qui les caractérise vu l'absence ou l'obsolescence de leur spécification, de documents d'architecture et de conception, et de preuves formalisées de test. Les stratégies de validation des logiciels standards et des logiciels libres dépendent aussi de la maîtrise des interactions entre les logiciels intégrés et le système hôte et sont influencées par le domaine d'application, les défaillances des éléments matériels et logiciels du système hôte, de la validation du 3 système hôte, ainsi que de l'évolution des logiciels testés. [0012] Les techniques de validation et de qualification des logiciels standards et des logiciels libres dépendent de l'accès de l'intégrateur (propriétaire du système hôte) aux spécifications de ces logiciels. Dans le cas où la spécification existe et est suffisamment précise, l'intégrateur teste et valide le logiciel dans son contexte d'utilisation en exécutant un ou plusieurs tests préalablement élaborés pour vérifier le respect d'une ou plusieurs exigences spécifiques et envoie les défauts constatés à l'éditeur du logiciel testé. Dans le cas où la spécification est inconnue ou très incomplète ou obsolète, la validation du logiciel doit se faire en mode boîte noire, ce qui peut être contraire à certaines contraintes de certification qui exigent de vérifier la conception interne du composant logiciel testé. [0013] A cet effet, l'invention a pour objet un procédé de test et validation automatique de logiciels standards et de logiciels libres permettant de tester, valider, vérifier, et qualifier, de manière automatique, le fonctionnement d'un logiciel standard ou d'un logiciel libre. Plus précisément, l'invention fournit un procédé pour tester un composant logiciel implémenté dans un système hôte à partir d'une ou plusieurs campagnes de test, une campagne de test comprenant des cas de tests informatiques et étant associée à des données de test d'entrée. Le procédé est caractérisé en cc qu'il comprend les étapes consistant à: - exécuter les cas de tests informatiques de chaque campagne de tests pendant une période de fonctionnement du composant logiciel, ce qui fournit des données de test de sortie associées à chaque campagne de tests; - déterminer un modèle de fonctionnement de référence et une partition de données à partir des données de test d'entrée et de sortie associées à chaque campagne de test, un modèle de fonctionnement de référence étant déterminé en appliquant un algorithme d'apprentissage machine aux données de test d'entrée et de sortie, une partition de données étant déterminée en appliquant un algorithme de partitionnement de données aux données de test d'entrée et de sortie; - fonctionner le composant logiciel en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie; - déterminer une caractéristique de fonctionnement du composant logiciel à partir des modèles de fonctionnement de référence en fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données associées à la une ou plusieurs campagnes de test. [0014] Selon certains modes de réalisation, algorithme d'apprentissage machine peut être un algorithme d'apprentissage machine choisi dans un groupe comprenant des algorithmes d'apprentissage machine de type clustering non-supervisés. [0015] Selon certains modes de réalisation, l'algorithme d'apprentissage machine peut être un réseau de neurones profond. [0016] Selon certains modes de réalisation, l'algorithme de partitionnement de données peut être choisi dans un groupe comprenant, sans limitation, l'algorithme des k-moyennes, des algorithmes de regroupement hiérarchique, et des algorithmes de maximisation de l'espérance. [0017] Selon certains modes de réalisation, l'ensemble des partitions de données associées à la une ou plusieurs campagnes de test peut correspondre à un domaine d'usage du composant logiciel, les données de mise en production d'entrée et les données de mise en production de sortie étant représentées par un point de fonctionnement du composant logiciel. L'étape de détermination d'une caractéristique de fonctionnement du composant logiciel peut, selon ces modes de réalisation, comprendre la détermination si ledit point de fonctionnement appartient au domaine d'usage et à une partition de donnée. [0018] Selon certains modes de réalisation, le domaine d'usage peut comprendre au moins une zone de défaillance, la caractéristique de fonctionnement pouvant être une anomalie de fonctionnement du composant logiciel si le point de fonctionnement est compris dans l'au moins une zone de défaillance ou si le point de fonctionnement n'appartient pas au domaine d'usage du composant logiciel. [0019] Selon certains modes de réalisation, la caractéristique de fonctionnement peut être une nouvelle fonctionnalité du composant logiciel si le point de fonctionnement appartient au domaine d'usage et n'appartient à aucune des une ou plusieurs partitions de données et à aucune de l'au moins une zone de défaillance. [0020] Selon certains modes de réalisation, chaque partition de données et chaque modèle de fonctionnement associés à chaque campagne de test peuvent correspondre à une fonctionnalité donnée du composant logiciel, la caractéristique de fonctionnement étant la fonctionnalité donnée si le point de fonctionnement appartient à la partition de données correspondant à la fonctionnalité donnée. [0021] Selon certains modes de réalisation, les cas de tests informatiques peuvent être définis en fonction de l'application du système hôte. [0022] L'invention fournit en outre un dispositif pour tester un composant logiciel im- plémenté dans un système hôte à partir d'une ou plusieurs campagnes de tests, une campagne de test comprenant des cas de tests informatiques et étant associée à des données de test d'entrée. Le dispositif est caractérisé en ce qu'il comprend : - une unité de traitement configurée pour : exécuter les cas de tests informatiques de chaque campagne de tests pendant une période de fonctionnement du composant logiciel, ce qui fournit des données de test de sortie associées à chaque campagne de tests, et déterminer un modèle de fonctionnement de référence et une partition de données à partir des données de test d'entrée et de sortie associées à chaque campagne de test, un modèle de fonctionnement de référence étant déterminé en appliquant un algorithme d'apprentissage machine aux données de test d'entrée et de sortie, une partition de données étant déterminée en appliquant un algorithme de partitionnement de données aux données de test d'entrée et de sortie; - une unité de test configurée pour : * fonctionner le composant logiciel en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie; * déterminer une caractéristique de fonctionnement du composant logiciel à partir des modèles de fonctionnement de référence en fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données associées à la une ou plusieurs campagnes de test. [0023] Avantageusement, les modes de réalisation de l'invention permettent de teste d'une manière automatique le fonctionnement d'un composant logiciel. [0024] Avantageusement, les modes de réalisation de l'invention permettent de détecter si le composant logiciel testé sort du domaine d'usage qualifié et de détecter des éventuelles anomalies. [0025] Avantageusement, les modes de réalisation de l'invention fournissent des tests auto- matiques de composants logiciels basés sur des techniques d'intelligence artificielle et d'analyse de données pour des tests en mode boîte noire. [0026] Les dessins annexes illustrent l'invention: [0027] [fig.1] représente une vue schématique d'un système hôte implémentant un dispositif de test de composant logiciel, selon certaines modes de réalisation de l'invention. [0028] [fig.2] représente un organigramme illustrant un procédé pour tester un composant logiciel implémenté dans un système hôte, selon certains modes de réalisation de l'invention. [0029] [fig.3] représente un organigramme illustrant une étape de détermination d'une carac- téristique de fonctionnement d'un composant logiciel, selon certains modes de réalisation de l'invention. [0030] [fig.4] représente des points de fonctionnement d'un composant logiciel dans un domaine d'usage, selon certains modes de réalisation de l'invention. [0031] [fig.5] représente une vue schématique d'un système hôte exemplaire pour l'implémentation de dispositif de test de composant logiciel, selon certains modes de réalisation de l'invention. [0032] Les modes de réalisation de l'invention fournissent un procédé et un dispositif pour tester, d'une manière automatique, un composant logiciel implémenté dans un système hôte à partir d'une ou plusieurs campagnes de tests. [0033] Le procédé et le dispositif selon l'invention peuvent être utilisés pour la validation de 6 tout type de composants, d'équipements, de produits, de systèmes informatiques, systèmes d'information, et d'applications logicielles implémentant un composant logiciel à tester, le composant logiciel pouvant être un produit logiciel sur étagère (aussi nommé 'logiciel standard') ou un logiciel libre. [0034] En référence à la figure 1, un environnement exemplaire d'un système hôte 1000 im- plémentant un composant logiciel à tester est illustré, selon certains modes de réalisation de l'invention. [0035] Le système hôte 1000 pour représenter tout type de système d'information dédié à la collecte, le stockage, la structuration, la modélisation, la gestion, l'analyse, le traitement, et la distribution de données (textes, images, sons, vidéo). [0036] Selon certains modes de réalisation, le système hôte 1000 peut comprendre des ressources informatiques telles que les fichiers de données, les bases de données et systèmes de gestion de bases de données, les progiciels de gestion intégrés, les outils de gestion des clients, des outils de gestion de la chaîne logistique, des outils de travail collaboratif, des applications métier, des serveurs d'application ou de présentation (Web), des architectures d'intégration, et les infrastructures réseaux. [0037] Selon certains modes de réalisation, le système hôte 1000 peut être un dispositif in- formatique personnel, une tablette informatique, un terminal client, un téléphone portable, ou tout dispositif informatique de cc type implémentant un composant Le système hôte 1000 peut être utilisé dans divers systèmes ou dispositifs industriels embarqués tels que les satellites et les dispositifs médicaux. [0038] Référant à la figure 1, le système hôte 1000 peut échanger ou communiquer ou diffuser des données à un système 109 via un réseau de communication 107. [0039] Dans certains modes de réalisation, le système 109 peut être un autre système d'information échangeant des données avec le système hôte 1000 à travers une ou plusieurs interfaces de programmation applicatives. [0040] Dans certains modes de réalisation utilisant une architecture client/serveur, le système hôte 1000 peut représenter un dispositif informatique client échangeant des données avec un système informatique de serveur 109 fournisseur de données, via le réseau de communication 107. [0041] Dans certains modes de réalisation, le système 109 peut être un serveur fournisseur de services informatiques en nuage ('cloud computing' en anglais) à au moins un système hôte 1000. Selon ces modes de réalisation, les services informatiques peuvent être de type 'logiciels en tant que service' ('software as a service' en anglais), 'plate-forme en tant que service' (.`platform as a service' en anglais), ou 'infrastructure en tant que service' ('infrastructure as a service' en anglais). [0042] Selon les services informatiques de type logiciel en tant que service, les logiciels exploités par le système hôte 1000 peuvent être installés sur le serveur distant 109. Ces 7 logiciels peuvent comprendre, à titre d'exemples, des applications de gestion de la relation client, des applications de visioconférence, des applications de messagerie et de logiciels collaboratifs, et des applications de création de site e-commerce. [0043] Selon les services informatiques de type plate-forme en tant que service, le système hôte 1000 peut être configure pour maintenir les applications et le serveur 109 peut être configure pour maintenir la plate-forme d'exécution de ces applications. La plate-forme d'exécution des applications clients peut comprendre, sans limitation, du matériel ou des serveurs de stockage (par exemple la carte mère et sa mémoire vive), les logiciels de base comprenant le(s) système(s) d'exploitation et le(s) moteur(s) de base de données, et l'infrastructure de connexion au réseau, de stockage et de sauvegarde. [0044] Selon les services informatiques de type infrastructure en tant que service, le système hôte 1000 peut être configure pour gérer les logiciels applicatifs (par exemples les exécutables, les paramétrages, et les bases de données) et le serveur 109 peut être configure pour gérer le matériel serveur, les couches de virtualisation ou de conteneurisation, le stockage, et les réseaux. [0045] Selon certains modes de réalisation, le réseau de communication 107 peut inclure un ou plusieurs réseaux privés et/ou publics qui permettent au système hôte 1000 d'échanger des données avec le système 109, tels qu'interna, un réseau local (LAN), un réseau étendu (WAN) un réseau de voix/données cellulaire, une ou plusieurs connexions de bus à grande vitesse et/ou d'autres types de réseaux de communications (filaires, sans fil, radio). [0046] Les modes de réalisation de l'invention fournissent un dispositif et un procédé pour le test d'un composant logiciel de type logiciel standard ou logiciel libre implémenté dans le système hôte 1000 à partir d'une ou plusieurs campagnes de test. [0047] Selon certains modes de réalisation, le composant logiciel testé peut être, à titre d'exemple et sans limitation, un composant logiciel choisi parmi un groupe comprenant des composants d'extension (par exemples les plugins, les codecs, et les pilotes), des bibliothèques logicielles, des exécutables, des fichiers, des composants de données (par exemples des bases de données et des ontologies), et des éléments de configuration tels que les paramètres, les scripts, et les fichiers de commandes. [0048] Une campagne de test comprend un ensemble de cas de tests informatiques à exécuter sur une période de temps donnée pour répondre à un besoin spécifique. Un cas de test informatique est un test qui sert à vérifier si certaines données de test d'entrée pour une exécution donnée produisent le résultat attendu. Le besoin peut être de vérifier que le comportement du composant logiciel testé est toujours le même après des mises à jour logicielles, de vérifier le comportement d'une nouvelle fonctionnalité à implémenter, de s'assurer que l'ajout de nouvelles fonctionnalités n'a pas introduit 8 de régression sur les anciennes, ou de s'assurer que le changement de serveur ou de base de données n'a pas impacté le service. [0049] Selon certains modes de réalisation, la période de temps donnée pour exécuter les cas de tests d'une campagne de test peut être quelques minutes ou dizaines de minutes, quelques jours, ou parfois quelques semaines. [0050] Selon certains modes de réalisation, une campagne de test peut être une campagne de test de validation visant à vérifier que le composant logiciel a bien le comportement attendu, ou une campagne de régression visant à vérifier que l'implémentation de nouvelles fonctionnalités n'a pas impacté le comportement des fonctionnalités déjà présentes dans le composant, ou bien une campagne de test vitaux visant à s'assurer que l'intégration du composant logiciel dans le système hôte 1000 n'a pas engendré de régression critique sur l'application. [0051] En référence à la figure 1, un dispositif 100 pour tester un composant logiciel im- plémenté dans le système hôte 1000 à partir d'une ou plusieurs campagnes de test, est illustré. Chaque campagne de test désignée Ci est associée à un ensemble de données de test d'entrée notées El, Ein E1,,, l'ensemble de données de test d'entrée comprenant N valeurs de test d'entrée et l'indice i variant de 1 au nombre total Nt°, de campagnes de test considérées, au moins égal à 1. Le test du composant logiciel se base sur la détermination d'un ou plusieurs modèles de fonctionnement de référence du composant logiciel pendant une phase d'apprentissage suivie d'une phase de mise en production pendant laquelle le fonctionnement du composant logiciel en mode opérationnel est comparé aux différents modèles de fonctionnement de référence, ce qui permet de déterminer une caractéristique de fonctionnement du composant logiciel et de détecter toutes anomalies et nouvelles fonctionnalités du composant logiciel. [0052] Selon certains mode de réalisation, le dispositif 100 peut comprendre une unité de traitement 101 configurée pour exécuter les cas de test informatiques de chaque campagne de test Ci pendant une période de fonctionnement du composant logiciel. La période de fonctionnement peut correspondre à l'ensemble des périodes de temps données nécessaires pour exécuter les cas de tests de chacune des campagnes de test considérées. L'exécution des cas de tests informatiques de chaque campagne de test C1 fournit des données de test de sortie notées Sl,, Si2,...,51, associées à chaque campagne de test Ci. [0053] L'unité de traitement 101 peut être configurée pour analyser et traiter les données de test d'entrée El, E12,...,E1N et les données de test de sortie associées S11, 512,...,51N à chaque campagne de test Cipour i variant del à N0 pourdéterminer un modèle de fonctionnement de référence du composant logiciel et une partition de donnée, à partir des données de test d'entrée et des données de test de sortie associées à chaque campagne de test. 9 [0054] Plus précisément, l'unité de traitement 101 peut être configurée pour déterminer un modèle de fonctionnement de référence noté RTEMi en association avec chaque campagne de test Cien appliquant un algorithme d'apprentissage machine aux données de test d'entrée -Eh et données de test de sortie 5,1, 512,...,5i, associées à la campagne de test C. Les données de test d'entrée RI, EL RN et les données de test de sortie Si' Si2StN sont données comme couples à l'algorithme d'apprentissage machine qui va converger vers un état où ces paramètres internes permettent de reproduire et généraliser ces couples, en prenant les précautions de rigueur pour éviter les phénomènes d'under-fitting et ovcr-fitting. [0055] Selon certains modes de réalisation, l'algorithme d'apprentissage machine peut être un algorithme d'apprentissage machine choisi dans un groupe comprenant des algorithmes d'apprentissage machine de type clustering non-supervisés. [0056] Dans un mode de réalisation préféré, l'algorithme d'apprentissage machine peut être un réseau de neurones profond. [0057] L'unité de traitement 101 peut être configurée pour déterminer une partition de données notée Pi en association avec chaque campagne de test Ci en appliquant un algorithme de partitionnement de données (aussi nommé 'algorithme de groupement de données' ou encore 'clustering algorithm' en anglais) aux données de test d'entrée Eil, On UN et données dc test de sortie Sil, S'n Sisi associées à la campagne de test Ci. Les données de test d'entrée El. El2,...,Ely et les données de test de sortie Sil, 512,...,51N associées à chaque campagne de test Ci, pour i variant de 1 à N10 peuvent ainsi être représentées par des points de fonctionnement dans un espace multidimensionnel et peuvent être séparées ou groupées en différentes partitions (aussi nommées 'groupements' ou 'clusters' en anglais). [0058] Selon certains modes de réalisation, l'algorithme de partitionnement de données peut être choisi dans un groupe comprenant, sans limitation, l'algorithme des k-moyennes, des algorithmes de regroupement hiérarchique, et des algorithmes de maximisation de l'espérance. [0059] Dans certains modes de réalisation, le dispositif 100 peut comprendre une unité de stockage configurée pour sauvegarder les modèles de fonctionnement de référence RTEM et les partitions de données Pi déterminés par l'unité de traitement 101 pendant la phase d'apprentissage. Chaque partition de données Pl et chaque modèle de fonctionnement de référence RTEM déterminés pour chaque campagne de test Ci correspondent à une fonctionnalité donnée du composant logiciel testé. L'ensemble des partitions de données Pi associées aux campagnes de test Ci correspondent à un domaine d'usage D du composant logiciel aussi nommé domaine de qualification. Le domaine d'usage D représente le périmètre normal de fonctionnement du composant logiciel. [0060] Dans certains modes de réalisation, le domaine d'usage D peut comprendre au moins une zone de défaillance. [0061] Dans certains modes de réalisation, le nombre total de campagnes de test peut être choisi pour produire autant de modèles de fonctionnement de référence que nécessaires pour couvrir toutes les applications du composant logiciel testé. Les modèles de fonctionnement de référence constituent le comportement de référence désiré. [0062] Dans certains modes de réalisation, le dispositif 100 peut comprendre une unité de test 103 configurée pour déterminer une caractéristique de fonctionnement du composant logiciel testé pendant une phase de mise en production, aussi nommée phase opérationnelle. [0063] Plus précisément, l'unité de test 103 peut être configurée pour fonctionner ou mettre en production le composant logiciel testé en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie. Les données de mise en production d'entrée et les données de mise en production de sortie peuvent être représentées par un point de fonctionnement du composant logiciel. [0064] Une fois les données de mise en production d'entrée et les données de mise en production de sortie collectées, l'unité de test 103 peut être configurée pour déterminer une caractéristique de fonctionnement du composant logiciel à partir des modèles de fonctionnement de référence RTEMl, pour i variant de 1 à Moten fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données Pi associées aux campagnes de test C. La comparaison du fonctionnement du composant logiciel dans le système en production par rapport aux modèles de fonctionnement de référence basés sur l'apprentissage permet, en production, de caractériser le fonctionnement du composant logiciel et de détecter tout fonctionnement nouveau ou anormal. [0065] Selon certains mode de réalisation, l'unité de test 103 peut être configurée pour dé- terminer une caractéristique de fonctionnement du composant logiciel en déterminant si le point de fonctionnement représentant les données de mise en production d'entrée et les données de mise en production de sortie appartient au domaine d'usage D et à une partition de donnée Pi pour j pouvant varier entre 1 et Mo,. [0066] Plus précisément, l'unité de test 103 peut être configurée pour déterminer que la ca- ractéristique de fonctionnement du composant logiciel est une anomalie de fonctionnement du composant logiciel, si le point de fonctionnement représentant les données de mise en production d'entrée et les données de mise en production de sortie est compris dans au moins une zone de défaillance comprise dans le domaine d'usage D ou si le point de fonctionnement n'appartient pas au domaine d'usage du composant logiciel. La détection d'une anomalie de fonctionnement permet d'initier une procédure de maintenance ou de réparation. 11 [0067] Dans certains modes de réalisation, l'unité de test 103 peut être configure° pour dé- terminer que la caractéristique de fonctionnement du composant logiciel est une nouvelle fonctionnalité du composant logiciel, si le point de fonctionnement représentant les données de mise en production d'entrée et les données de mise en production de sortie appartient domaine d'usage et n'appartient à aucune des partitions de données Pi pour i allant de 1 à NUL, et n'appartient à aucune zone de défaillance du domaine d'usage D. La nouvelle fonctionnalité, qui n'a pas été prise pendant la phase d'apprentissage, fait partie du fonctionnement normal du composant logiciel testé. Il est possible, lors de la détection de nouvelles fonctionnalités, de déclencher une nouvelle phase d'apprentissage visant à enrichir les modèles de fonctionnement de référence du composant logiciel. Des méthodes rapides dites 'active learning' peuvent être mise en oeuvre pour cette mise à jour. [0068] Dans certains modes de réalisation, l'unité de test 103 peut être configure° pour dé- terminer que la caractéristique de fonctionnement du composant logiciel est une fonctionnalité donnée (connue) du composant logiciel si le point de fonctionnement représentant les données de mise en production d'entrée et les données de mise en production de sortie appartient à la partition de données associée à la fonctionnalité donnée. [0069] En référence à la figure 2, un procédé de test d'un composant logiciel est illustré, selon certains modes de réalisation de l'invention. [0070] Dans certains modes de réalisation, le composant logiciel testé peut être un logiciel standard ou un logiciel libre, implémenté dans un système hôte 1000. Un logiciel standard peut être, à titre d'exemple et sans limitation, un logiciel standard choisi parmi un groupe comprenant des composants d'extension (par exemples les plugins, les codecs, et les pilotes), des bibliothèques logicielles, des exécutables, des fichiers, des composants de données (par exemples des bases de données et des ontologies), et des éléments de configuration (tels que les paramètres, les scripts, et les fichiers de commandes). [0071] Dans certains modes de réalisation, le composant logiciel peut être testé afin de vérifier que le comportement du composant logiciel est toujours le même après des mises à jour logicielles, ou de vérifier le comportement d'une nouvelle fonctionnalité à implémenter, de s'assurer que l'ajout de nouvelles fonctionnalités n'a pas introduit de régression sur les anciennes, ou de s'assurer que le changement de serveur ou de base de données n'a pas impacté le service. [0072] Le procédé peut comprendre deux phases : une phase d'apprentissage qui comprend les étapes 201 à 205, et une phase de mise en production qui comprend les étapes 207 et 209. [0073] La phase d'apprentissage correspond à une phase de détermination d'un ou plusieurs 12 modèles de fonctionnement de référence du composant logiciel testé, pendant une période de fonctionnement hors ligne, à partir d'une ou plusieurs campagnes de test. Une campagne de test comprend un ensemble de cas de tests informatiques à exécuter sur une période de temps donnée pour répondre à un besoin particulier. Une campagne de test peut être une campagne de test de validation visant à vérifier que le composant logiciel a bien le comportement attendu, ou une campagne de régression visant à vérifier que l'implémentation de nouvelles fonctionnalités n'a pas impacté le comportement des fonctionnalités déjà présentes dans le composant, ou bien une campagne de test vitaux visant à s'assurer que l'intégration du composant logiciel dans le système hôte 1000 n'a pas engendré de régression critique sur l'application. [0074] Un cas de test informatique est un test qui sert à vérifier si certaines données de test d'entrée pour une exécution donnée produisent le résultat attendu. [0075] La phase de mise en production correspond à une phase de caractérisation du fonc- tionnement du composant testé pendant une période opérationnelle ou fonctionnelle en comparant le fonctionnement en ligne du composant logiciel aux modèles de fonctionnement de référence déterminés pendant la phase d'apprentissage. La caractérisation du fonctionnement du composant logiciel testé permet de détecter toutes anomalies et nouvelles fonctionnalités du composant logiciel. [0076] A l'étape 201, un ou plusieurs cas de tests informatiques peuvent être déterminés pour au moins une campagne de test C1 afin de tester un composant logiciel. Chaque campagne de test Ci est associée à un ensemble de données de test d'entrée notées E1, l'ensemble de données de test d'entrée comprenant N valeurs de test d'entrée et l'indice i variant de 1 au nombre total Nt°, de campagnes de test considérées, au moins égal à I. [0077] Selon certains modes de réalisation, les cas de tests informatiques peuvent être dé- terminés ou définis en fonction de l'application du système hôte implémentant le composant logiciel testé. [0078] A l'étape 203, les cas de tests informatiques de chaque campagne de test Ci peuvent être exécutés pendant une période de fonctionnement du composant logiciel. La période de fonctionnement peut correspondre à l'ensemble des périodes de temps données nécessaires pour exécuter les cas de tests de chacune des campagnes de test considérées. L'exécution des cas de tests informatiques de chaque campagne de test C1 fournit des données de test de sortie notées 5i, Sl2,...,Sl, associées à chaque campagne de tests Ci. [0079] A l'étape 205, un modèle de fonctionnement de référence RTEMi du composant logiciel et une partition de données Pi peuvent être déterminés à partir des données de test d'entrée El, Eo,...,EN et des données de test de sortie Sii, associées à chaque campagne de test Ci, pour i variant de 1 à Rot. 13 [0080] Plus précisément, un modèle de fonctionnement de référence RTEM, du composant logiciel peut être déterminé, en association avec chaque campagne de test Ci, en appliquant un algorithme d'apprentissage machine aux données de test d'entrée Eih Et, UNet aux données de test de sortie Sil, Si, Si, associées à la campagne de test C; . Les données de test d'entrée et les données de test de sortie Sil, 5i, ,,5t sont données comme couples à l'algorithme d'apprentissage machine qui va converger vers un état où ces paramètres internes permettent de reproduire et généraliser ces couples, en prenant les précautions de rigueur pour éviter les phénomènes d'under-fitting et over-fitting. [0081] Selon certains modes de réalisation, l'algorithme d'apprentissage machine peut être un algorithme d'apprentissage machine choisi dans un groupe comprenant des algorithmes d'apprentissage machine de type clustering non-supervisés. [0082] Dans un mode de réalisation préféré, l'algorithme d'apprentissage machine peut être un réseau de neurones profond. [0083] Dans certains modes de réalisation, les données de test d'entrée E11, El2,...,Ei, ct les données de test de sortie 511, Si2,...,Sl, associées à chaque campagne de test C. pour i variant de 1 à N,o' peuvent être représentées par des points de fonctionnement dans un espace multidimensionnel et peuvent être séparées ou groupées en différentes partitions (aussi nommées 'groupements' ou 'clusters' en anglais). Une partition de données P1 peut être déterminée en association avec chaque campagne de test Ci en appliquant un algorithme de partitionnement de données (aussi nommé 'algorithme de groupement de (lonnées' ou encore 'clustering algorithm' en anglais) à partir des données de test d'entrée RI, E2,...,E1Net des données de test de sortie Sil, associées à chaque campagne de test Ci. Chaque partition de données Pi et chaque modèle de fonctionnement de référence RTEM déterminés pour chaque campagne de test C correspondent à une fonctionnalité donnée du composant logiciel. L'ensemble des partitions de données Pi associées aux campagnes de test C correspondent à un domaine d'usage D du composant logiciel aussi nommé domaine de qualification. Le domaine d'usage D représente le périmètre normal de fonctionnement du composant logiciel. [0084] Dans certains modes de réalisation, le domaine d'usage D peut comprendre au moins une zone de défaillance. [0085] Selon certains modes de réalisation, l'algorithme de partitionnement de données peut être choisi dans un groupe comprenant, sans limitation, l'algorithme des k-moyennes, des algorithmes de regroupement hiérarchique, et des algorithmes de maximisation de l'espérance. [0086] Selon certains modes de réalisation, le nombre total de campagnes de test peut être choisi pour produire autant de modèles de fonctionnement de référence que nécessaires 14 pour couvrir toutes les applications du composant logiciel testé. Les modèles de fonctionnement de référence constituent le comportement de référence désiré. [0087] A l'étape 207, le composant logiciel peut être mis en production en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie. La mise en production du composant logiciel consiste à fonctionner le composant logiciel en lui fournissant en entrée des données de mise en production d'entrée. Les données de mise en production d'entrée et les données de mise en production de sortie peuvent être représentées par un point de fonctionnement du composant logiciel. [0088] A l'étape 209, une caractéristique de fonctionnement du composant logiciel peut être déterminée à partir des modèles fonctionnement de référence RTEMi,pour i variant de 1 à NI,o, en fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données Pi associées aux campagnes de test Ç. La comparaison du fonctionnement du composant logiciel dans le système en production par rapport aux modèles de fonctionnement de référence basés sur l'apprentissage permet, en production, de caractériser le fonctionnement du composant logiciel et de détecter tout fonctionnement nouveau ou anormal. [0089] Selon certains modes de réalisation, une caractéristique de fonctionnement du composant logiciel peut être déterminée en en déterminant si le point de fonctionnement représentant les données de mise en production d'entrée et les données de mise en production de sortie appartient au domaine d'usage D et à une partition de donnée Pi pour j pouvant varier entre 1 et Ntor. [0090] En référence à la figure 3, un organigramme illustrant l'étape de détermination d'une caractéristique du composant logiciel à l'étape 209 est présenté, selon certains modes de réalisation. [0091] A l'étape 301, les partitions de données Pl, le domaine d'usage D comprenant au moins une zone de défaillance, le point de fonctionnement représentant les données de mise en production d'entrée et de sortie, peuvent être reçues. [0092] A l'étape 303, il peut être déterminé si le point de fonctionnement est compris dans le domaine d'usage D. [0093] S'il est déterminé à l'étape 303 que le point de fonctionnement n'appartient pas au domaine d'usage D, une anomalie de fonctionnement du composant logiciel peut être déterminée comme caractéristique de fonctionnement à l'étape 313. [0094] S'il est déterminé à l'étape 303 que le point de fonctionnement appartient au domaine d'usage D, il peut être déterminé à l'étape 305 si le point de fonctionnement est compris dans une partition de données. [0095] S'il est déterminé à l'étape 305 que le point de fonctionnement est compris dans une partition de donnée Pi pour j variant entre 1 et Mot, la fonctionnalité donnée (connue) associée à la partition Pi à laquelle appartient le point de fonctionnement est déterminée comme caractéristique de fonctionnement à l'étape 307. [0096] S'il est déterminé à l'étape 305 que le point de fonctionnement n'appartient à aucune partition de données Pi pour i allant de 1 à NI',' alors l'étape 309 peut être exécutée pour déterminer si le point de fonctionnement est compris dans une zone de défaillance du domaine d'usage. S'il est déterminé à l'étape 309 que le point de fonctionnement est compris dans une zone de défaillance, alors une anomalie de fonctionnement du composant logiciel peut être déterminée comme caractéristique de fonctionnement à l'étape 313. S'il est déterminé à l'étape 309 que le point de fonctionnement n'appartient à aucune zone de défaillance, une nouvelle fonctionnalité du composant logiciel peut être déterminée comme caractéristique de fonctionnement à l'étape 311. [0097] En référence à la figure 4, un exemple de représentation de points de fonctionnement dans un domaine d'usage 400 est illustré, selon certains modes de réalisation de l'invention. Le domaine d'usage définit le périmètre des fonctionnements du composant logiciel. [0098] Comme illustré dans la figure 4, le domaine d'usage 400 comprend trois zones de dé- faillances 404, une première partition 401 (aussi nommée Partition 1), et une second partition 402 (aussi nommée Partition 2). Le point de fonctionnement Pl 403 appartient à une zone de défaillance et correspond à la détection d'une anomalie de fonctionnement. Les points de fonctionnement 405 sont compris dans le domaine d'usage D mais à l'extérieur des première et seconde partitions 401 et 402. Ces points de fonctionnement correspondent à la détection d'une nouvelle fonctionnalité du composant logiciel qui n'a pas été considérée pendant la phase d'apprentissage. [0099] L'invention fournit par ailleurs un produit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé lorsque ledit programme est exécuté sur un ordinateur. [0100] Le dispositif 100, le procédé et le produit programme d'ordinateur de test de composant logiciel selon les différents modes de réalisation de l'invention peuvent être mis en oeuvre sur un ou plusieurs dispositifs ou systèmes informatiques, désignés collectivement sous le nom d'ordinateur, tel que l'ordinateur 50 illustré à la Figure 5. L'ordinateur 50 peut inclure un processeur 50, une mémoire 53, une base de données 52 faisant partie d'un dispositif de mémoire de stockage de masse, une interface d'entrée/sonie (1/0) 54 et une interface Homme-Machine (IHM) 51. L'ordinateur 50 peut communiquer avec le système 109 via un réseau de communication 107 et avec le réseau de communication 107 via l'interface d'entrée/sortie (E/S) 54. Les ressources externes peuvent inclure, mais sans s'y limiter, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être 16 utilisée avec l'ordinateur 50. [0101] Le processeur 50 peut inclure un ou plusieurs dispositifs sélectionnés : des micropro- cesseurs, des microcontrôlcurs, des processeurs de signal numérique, des micro-ordinateurs, des unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basé sur des instructions de fonctionnement enregistrées dans la mémoire 53. La mémoire 53 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment mais sans s'y limiter, la mémoire à lecture seule (read-only mcmory (ROM), la mémoire à accès aléatoire (random access rnemory (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache mcmory)) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 52 peut inclure des dispositifs de stockage dc données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile ou tout autre dispositif capable de stocker des informations. Une base dc données peut résider sur le dispositif de stockage de mémoire de masse 52, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. [0102] Le processeur 50 peut fonctionner sous le contrôle d'un système d'exploitation 55 qui réside dans la mémoire 53. Le système d'exploitation 55 peut gérer les ressources informatiques de telle façon que le code de programme de l'ordinateur, intégré sous forme d'une ou de plusieurs applications logicielles, telles que l'application 56 qui réside dans la mémoire 53, puisse disposer d'instructions exécutées par le processeur 50. Dans un autre mode de réalisation, le processeur 50 peut exécuter directement l'application 56. [0103] En général les routines exécutées pour mettre en oeuvre les modes de réalisation de l'invention, qu'elles soient mises en oeuvre dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même d'un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme "code de programme informatique" ou simplement "code de programme». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans des dispositifs divers de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer les opérations nécessaires pour exécuter les opérations et/ou les éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un 17 programme, lisibles par ordinateur, pour réaliser les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation. 18 [Revendication 1] REVENDICATIONSProcédé pour tester un composant logiciel implémenté dans un système hôte à partir d'une ou plusieurs campagnes de test, une campagne de test comprenant des cas dc tests informatiques et étant associée à des données de test d'entrée, le procédé étant caractérisé en ce qu'il comprend les étapes consistant à: exécuter (203) les cas de tests informatiques de chaque campagne de tests pendant une période de fonctionnement dudit composant logiciel, ce qui fournit des données de test de sortie associées à chaque campagne de tests; déterminer (205) un modèle de fonctionnement de référence et une partition de données à partir des données de test d'entrée et de sortie associées à chaque campagne de test, un modèle de fonctionnement de référence étant déterminé en appliquant un algorithme d'apprentissage machine auxdites données de test d'entrée et de sortie, une partition de données étant déterminée en appliquant un algorithme de partitionnement de données auxdites données de test d'entrée et de sortie; fonctionner (207) ledit composant logiciel en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie; déterminer une caractéristique de fonctionnement dudit composant logiciel (209) à partir des modèles de fonctionnement de référence en fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données associées à ladite une ou plusieurs campagnes de test. [Revendication 2] Procédé pour tester un composant logiciel selon la revendication 1, ca- ractérisé en ce que ledit algorithme d'apprentissage machine est un algorithme d'apprentissage machine choisi dans un groupe comprenant des algorithmes d'apprentissage machine de type clustering non-supervisés. [Revendication 3] Procédé pour tester un composant logiciel selon la revendication 2, ca- ractérisé en ce que ledit algorithme d'apprentissage machine est un réseau de neurones profond. 19 [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] Procédé pour tester un composant logiciel selon la revendication 1, caractérisé en ce que ledit algorithme de partitionnemcnt de données est choisi dans un groupe comprenant l'algorithme des k-moyennes, des algorithmes de regroupement hiérarchique, et des algorithmes de maximisation de l'espérance. Procédé pour tester un composant logiciel selon la revendication 1, caractérisé en ce que l'ensemble des partitions de données associées à ladite une ou plusieurs campagnes de test correspond à un domaine d'usage dudit composant logiciel, les données de mise en production d'entrée et les données de mise en production de sortie étant représentées par un point de fonctionnement dudit composant logiciel, ladite étape (209) de détermination d'une caractéristique de fonctionnement dudit composant logiciel comprenant la détermination si ledit point de fonctionnement appartient audit domaine d'usage et à une partition de donnée. Procédé pour tester un composant logiciel selon la revendication 6, caractérisé en ce que ledit domaine d'usage comprend au moins une zone de défaillance, ladite caractéristique de fonctionnement étant une anomalie de fonctionnement dudit composant logiciel si ledit point de fonctionnement est compris dans ladite au moins une zone de défaillance ou si ledit point de fonctionnement n'appartient pas audit domaine d'usage. Procédé pour tester un composant logiciel selon la revendication 6, caractérisé en ce que ladite caractéristique de fonctionnement est une nouvelle fonctionnalité du composant logiciel si ledit point de fonctionnement appartient audit domaine d'usage et n'appartient à aucune desdites une ou plusieurs partitions de données et à aucune de ladite au moins une zone de défaillance. Procédé pour tester un composant logiciel selon la revendication 6, caractérisé en ce que chaque partition de données et chaque modèle de fonctionnement associés à chaque campagne de test correspond à une fonctionnalité donnée dudit composant logiciel, ladite caractéristique de fonctionnement étant ladite fonctionnalité donnée si ledit point de fonctionnement appartient à la partition de données correspondant à ladite fonctionnalité. Procédé pour tester un composant logiciel selon la revendication 1, caractérisé en ce que ledit composant logiciel est un logiciel libre ou un logiciel standard. 20 [Revendication 10] Procédé pour tester un composant logiciel selon la revendication 1, ca- ractérisé en ce que lesdits cas de tests informatiques sont définis en fonction d'une application dudit système hôte. [Revendication 11] Dispositif (100) pour tester un composant logiciel implémenté dans un système hôte (1000) à partir d'une ou plusieurs campagnes de tests, une campagne de test comprenant des cas dc tests informatiques et étant associée à des données dc test d'entrée, le dispositif étant caractérisé en ce qu'il comprend : une unité de traitement (101) configurée pour : exécuter les cas de tests informatiques de chaque campagne dc tests pendant une période de fonctionnement dudit composant logiciel, cc qui fournit des données de test de sortie associées à chaque campagne de tests, et déterminer un modèle dc fonctionnement de référence et une partition dc données à partir des données de test d'entrée et de sortie associées à chaque campagne dc test, un modèle de fonctionnement de référence étant déterminé en appliquant un algorithme d'apprentissage machine auxdites données dc test d'entrée et de sortie, une partition de données étant déterminée en appliquant un algorithme de partitionnement de données auxditcs données de test d'entrée et de sortie; une unité de test (103) configurée pour : fonctionner ledit composant logiciel en utilisant des données de mise en production d'entrée, ce qui fournit des données de mise en production de sortie; déterminer une caractéristique de fonctionnement dudit composant logiciel à partir des modèles de fonctionnement de référence en fonction d'une comparaison entre les données de mise en production d'entrée et de sortie et les données des partitions de données associées à ladite une ou plusieurs campagnes de test.