FR2958059A1 - Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs - Google Patents

Abstract

L'invention a notamment pour objet la validation d'exécution d'une tâche dans un environnement de test comprenant au moins un cluster ayant une pluralité de nœuds dont au moins un comprend un programme pour gérer l'exécution de tests. Après avoir transmis au moins une caractéristique desdits nœuds à un système de mémorisation d'éléments de tests, des données représentatives d'au moins un test permettant l'exécution de ladite tâche dans ledit cluster sont reçues (405) si ledit système de mémorisation d'éléments de tests comprend des données représentatives dudit au moins un test compatible avec ladite au moins une caractéristique. Si les ressources disponibles dudit cluster permettent l'exécution de ladite tâche selon lesdites données reçues représentatives dudit au moins un test, ladite tâche est exécutée (435) selon lesdites données reçues représentatives dudit au moins un test et au moins un résultat obtenu lors de ladite exécution est transmis (440).

Description

La présente invention concerne la validation d'exécution de routines logicielles et plus particulièrement un procédé, un programme d'ordinateur et un dispositif de validation d'exécution de tâches dans des systèmes informatiques évolutifs. Afin de faciliter la programmation des systèmes informatiques, des couches logicielles intermédiaires sont généralement utilisées entre la couche matérielle et la couche logicielle applicative. De telles couches intermédiaires permettent d'exécuter des tâches aussi génériques que possible, telles que des transferts et des traitements de données. En outre, l'utilisation de telles tâches permet souvent de décorréler les couches applicative et matérielle, autorisant ainsi une application logicielle à être exécutée par plusieurs couches matérielles différentes. Si ces couches intermédiaires comprennent typiquement le système d'exploitation utilisé, elles peuvent également comprendre des tâches particulières liées, notamment, à l'optimisation des ressources matérielles.

Ainsi, par exemple, dans le domaine des calculs à haute performance, certaines tâches peuvent être proposées, en marge du système d'exploitation, pour, notamment, choisir les algorithmes mathématiques les plus performants en fonction des applications visées. Naturellement, il convient de tester et valider l'exécution de ces tâches afin que les résultats produits répondent à des caractéristiques prédéterminées, quelque soit la couche matérielle utilisée, ou, à tout le moins, que les résultats produits soient caractérisés en fonction de la couche matérielle utilisée. Ainsi, le test et la validation de l'exécution de ces tâches représentent une phase essentielle du développement de systèmes informatiques comprenant une couche matérielle et une couche intermédiaire adaptée à exécuter ces tâches pour détecter des défaillances et garantir ainsi un niveau de fiabilité requis. Ces tests ont généralement pour objet d'observer le comportement du système exécutant ces tâches selon des séquences prédéterminées, c'est-à-dire selon des données de test particulières, afin de comparer les résultats obtenus avec des résultats attendus.

Les systèmes informatiques mettant en oeuvre ces tâches évoluent au cours du temps pour, d'une part, corriger d'éventuelles erreurs observées et, d'autre part, améliorer leurs performances ou intégrer de nouvelles fonctionnalités. De telles évolutions peuvent concerner des éléments matériels du système informatique, l'architecture matériel ou la configuration de ces éléments ainsi qu'une partie de la couche logicielle intermédiaire telle qu'un système d'exploitation. Toujours dans un souci de fiabilité, l'exécution de ces tâches sur ces systèmes modifiés doit à nouveau être vérifiée pour s'assurer que les performances n'ont pas été dégradées. Il s'agit alors d'un test de non régression. A ces fins, les tests visent à observer le comportement du système modifié exécutant les tâches considérées selon des données de test afin de comparer les résultats obtenus avec des résultats attendus ou des résultats antérieurs. Il existe de nombreuses stratégies de test et de validation. Cependant, un test est typiquement lié à un environnement, c'est-à-dire une configuration matérielle et logicielle, des données de test, c'est-à-dire des séquences d'appels aux tâches testées et leurs paramètres, et une méthode d'analyse ou d'obtention des résultats. Il en résulte un nombre de combinaison pouvant être particulièrement important. Afin de faciliter les opérations de test et de validation, ces dernières sont généralement automatisées selon un mécanisme de boucles imbriquées pour réaliser tous les tests de façon exhaustives ou selon des scénarii prédéterminés. A ces fins, un environnement matériel est souvent consacré à cette fonction. Il est configuré selon les tests et validations à effectuer. La figure 1 illustre schématiquement un système de test d'exécution 30 de tâches dans un système informatique. Comme illustré, le système de test et de validation 100 comprend un environnement matériel de test 105, comprenant lui-même une pluralité de calculateurs, généralement regroupés en clusters, ainsi qu'une base de données 110 contenant ici les données de test et de validation et les paramètres de configuration de l'environnement de test. Le système de test et de validation 100 comprend en outre un système de contrôle 115, par exemple un ordinateur ou un serveur, pour identifier les tests et les validations devant être effectués, configurer l'environnement de test, transmettre les données de test, recevoir les résultats obtenus et comparer ces résultats avec les résultats attendus. Ainsi, pour effectuer un test particulier à l'aide du système 100, une première étape consiste à identifier ce test et à obtenir les données correspondantes. Une étape suivante a pour objet la configuration de l'environnement de test. Elle vise notamment à déterminer les calculateurs devant être utilisés, c'est-à-dire, par exemple, un cluster particulier, et leur mise en oeuvre. Elle concerne également la configuration des interconnexions entre ces calculateurs, c'est-à-dire la configuration du réseau ou l'architecture utilisée. Les réseaux sont, par exemple des réseaux Ethernet ou de type InfiniBand. Il est possible de définir un environnement de test selon le cluster devant être utilisé, une version du système d'exploitation mis en oeuvre et une architecture particulière. Enfin, les données de test et les définitions ou règles d'obtention des résultats cherchés sont identifiées pour lancer le test. Les résultats obtenus sont alors traités et comparés avec les résultats attendus par le système de contrôle 115. Ces étapes sont répétées pour chaque test devant être effectué. La figure 2 représente schématiquement des résultats de tests et de validations effectués pour un système informatique évoluant au cours du temps. Les tests sont ici réalisés aux instants t1, t2, ..., tn. Chaque test (tests 1 à n) correspond ici à un environnement de test particulier ainsi qu'à des données de test particulières, par exemple des données de test issues de fournisseurs différents.

Les résultats de test et de validation sont ici comparés avec des résultats attendus pour déterminer une indication de réussite (V) ou d'échec (x). Les résultats sont, par exemple, des débits de transmission de données, des temps de réponse et des temps de traitement. Ces résultats peuvent être présentés dans un tableau tel que celui illustré figure 2 dans lequel chaque ligne correspond à un test particulier et chaque colonne correspond à un instant ou une date de test.

Il est observé ici qu'une erreur au sens d'un test particulier peut être une erreur liée au résultat du test, c'est-à-dire un résultat erroné par rapport à une donnée de test, mais peut également être liée au changement, dans le temps, de résultats du test si aucune modification du système informatique n'affectant théoriquement le résultat n'a été effectuée. Ainsi, par exemple, si un échec est observé pour un test donné, l'observation d'une indication de succès à ce test sans qu'une modification du système informatique liée à ce test ait été réalisée peut être interprétée comme une erreur potentielle. Cependant, alors qu'un système de test et de validation tel que celui présenté en référence aux figures 1 et 2 permet de tester et valider efficacement l'exécution de tâches statiques dans des systèmes informatiques, il ne permet pas d'utiliser l'environnement matériel de test évolutif de façon optimale. Il en résulte notamment une perte de temps liée à l'enchaînement des tests et une sous utilisation des ressources du système de test. L'invention permet de résoudre au moins un des problèmes exposés 20 précédemment. L'invention a ainsi pour objet un procédé de validation d'exécution d'au moins une tâche pour système informatique évolutif dans un environnement de test comprenant au moins un cluster, chacun desdits au moins cluster comprenant une pluralité de noeuds, au moins un noeud de ladite 25 pluralité de noeuds de chacun desdits au moins un cluster comprenant un programme résidant en mémoire, ledit programme résidant en mémoire, appelé le programme, comprenant les étapes suivantes, - transmission à un système de mémorisation d'éléments de tests d'au moins une caractéristique de ladite pluralité de noeuds du cluster auquel 30 appartient le noeud comprenant ledit programme ; - en réponse à ladite étape de transmission, si ledit système de mémorisation d'éléments de tests comprend des données représentatives d'au moins un test de ladite au moins une tâche compatible avec ladite au moins une caractéristique, réception desdites données représentatives dudit au moins un test permettant l'exécution de ladite au moins une tâche dans le cluster auquel appartient le noeud comprenant ledit programme ; et, - si les ressources disponibles du cluster auquel appartient le noeud comprenant ledit programme permettent l'exécution de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test, exécution de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test et transmission d'au moins un résultat obtenu lors de ladite exécution. Le procédé selon l'invention permet ainsi d'optimiser les ressources d'un environnement de test comprenant un cluster regroupant plusieurs noeuds lors de l'exécution de tests en permettant une utilisation parallélisée de ressources mutualisées.

De façon avantageuse, ladite étape de réception de données permettant l'exécution de ladite au moins une tâche comprend une étape de réception d'au moins une donnée de configuration de l'environnement du cluster auquel appartient le noeud comprenant ledit programme, le procédé comprenant en outre une étape de configuration de l'environnement du cluster auquel appartient le noeud comprenant ledit programme selon ladite donnée de configuration reçue. Le procédé selon l'invention permet ainsi de configurer l'environnement de test selon les tests à effectuer. Ladite étape de réception de données permettant l'exécution de ladite au moins une tâche comprend en outre, de préférence, une étape de réception d'au moins une donnée pour déterminer un résultat d'exécution de ladite au moins une tâche, le procédé comprenant en outre une étape de détermination d'au moins un résultat d'exécution de ladite au moins une tâche selon ladite au moins une donnée reçue pour déterminer un résultat d'exécution de ladite au moins une tâche. Le procédé selon l'invention permet ainsi de configurer la façon dont sont évalués les résultats d'exécution de tests. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de création dudit au moins un test de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test. Le procédé selon l'invention permet ainsi de créer des tests dynamiques à partir d'éléments de tests référents, multipliant ainsi les possibilités de test. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de création d'une entrée dans une table d'exécution de routines en réponse à ladite étape de réception de données permettant l'exécution de ladite au moins une tâche, ladite table d'exécution de routines permettant l'exécution automatique de ladite au moins une tâche. Avantageusement, le procédé comprend en outre une étape de transmission d'une commande à un système externe pour ordonner l'envoi d'un rapport d'exécution de ladite au moins une tâche. L'environnement de test est ainsi adapté à gérer l'exécution de tests et à contrôler la transmission de rapport de test de façon autonome. Toujours selon un mode de réalisation particulier, ledit système de mémorisation d'éléments de tests comprend une base de données, ladite base de données comprenant des données d'environnement, de test, d'analyse et de tâches, ladite étape de transmission de ladite au moins une caractéristique de ladite pluralité de noeuds du cluster auquel appartient le noeud comprenant ledit programme comprenant une requête d'accès à ladite base de données.

De façon avantageuse, une pluralité de tests est exécutée simultanément. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention 30 ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un système de test d'exécution de tâches dans un système informatique ; - la figure 2 représente schématiquement des résultats de tests effectués pour un système informatique évoluant au cours du temps ; - la figure 3 illustre schématiquement un environnement de test et de validation d'exécution de tâches mettant en oeuvre l'invention ; - la figure 4 représente schématiquement un algorithme mis en oeuvre dans un programme résidant en mémoire d'un noeud d'entrée d'un cluster appartenant à un environnement de test et de validation ; et, - la figure 5 illustre un exemple d'architecture d'un noeud d'un cluster adapté à mettre en oeuvre l'invention. L'invention a notamment pour objet de gérer l'exécution de tests, c'est-à-dire de séquences de tâches associées à des données de configuration et d'analyse de résultats, à partir des clusters de test eux-mêmes, selon leurs capacités, pour permettre la validation de l'exécution de ces tâches et optimiser l'exécution de ces séquences. Selon un mode de réalisation particulier, un environnement de test est constitué de plusieurs clusters comprenant chacun un ensemble de noeuds. Un noeud particulier de chaque cluster, appelé noeud d'entrée ou noeud de login, comprend un programme résident en mémoire pour lancer automatiquement des séquences de tâches. Lorsque l'invention est mise en oeuvre dans un environnement basé sur un système d'exploitation de type Linux (Linux est une marque), un tel programme comprend typiquement le crond. Ce programme, combiné à un programme de type script shell ou binaire, c'est-à-dire un programme permettant d'accéder au système d'exploitation, permet notamment d'identifier les ressources du cluster ainsi que son environnement d'exécution afin de lancer des séquences de tâches pouvant être exécutées dans la configuration identifiée. En d'autres termes, à partir des informations de configuration identifiées, il est possible de déterminer les tests pouvant être effectués, d'accéder aux données permettant l'exécution des séquences de tâches associées et de lancer leur exécution lorsque les ressources nécessaires sont disponibles. A ces fins, une base de données comprend une liste de tâches planifiées et, pour chaque tâche planifiée, la liste des clusters capables d'exécuter les séquences de tâches correspondantes. Cette base de données comprend également des tests référents comprenant eux-mêmes des séquences de tâches à exécutées, des environnements d'exécution et des informations relatives à l'obtention et à l'analyse des résultats de test. Ainsi, après avoir identifié les tâches planifiées pouvant être effectuées, le programme résidant en mémoire de chaque noeud d'entrée de chaque cluster peut créer des tests dynamiques correspondant à partir de tests référents et lancer les séquences de tâches associées selon les ressources disponibles. La figure 3 illustre schématiquement un environnement de test et de validation 300 d'exécution de tâches mettant en oeuvre l'invention.

Une table 305 est ici utilisée pour déterminer les tests à effectuer par combinaison de paramètres. Un test dynamique à effectuer est ici défini par la combinaison d'éléments de tests référents, c'est-à-dire, par exemple, l'association d'un environnement, de données de test, de règles d'analyse, de tâches et d'un utilisateur. Ainsi, comme illustré sur la table 305 par un lien d'association représentant une tâche planifiée, un test dynamique peut être créé à partir d'indications visant des éléments de tests référents et des éléments visés eux-mêmes. Les tests référents ainsi que les tâches planifiées sont ici mémorisés dans la base de données 310. Il est observé ici que les tests référents peuvent comprendre des 25 éléments de nature différente, par exemple des cibles matérielles devant être utilisées lors de l'exécution des tests. L'environnement de test comprend également des clusters de test, ici les clusters de test 315-1 et 315-2, aussi appelés clusters de test A et B. Chaque cluster de test comprend un ensemble de noeuds reliés 30 entre eux selon une architecture prédéfinie ou configurable et un système de gestion génériquement référencé 320 lié à un noeud particulier ou réparti sur plusieurs noeuds. Un noeud particulier 325, appelé noeud d'entrée ou noeud de login, est utilisé pour accéder au cluster depuis un système externe. Le noeud d'entrée comprend un programme résidant en mémoire, génériquement référencé 325. Le noeud d'entrée est également utilisé pour transmettre les résultats de test obtenus à un système externe.

Les noeuds du cluster utilisés pour exécuter les tâches correspondant à un test dynamique sont ici génériquement référencés 335. Un système applicatif d'évaluation des résultats est en outre utilisé pour comparer les résultats obtenus avec les résultats attendus. Il s'agit ici d'un serveur applicatif PHP Apache 345. Celui-ci est, de préférence, utilisé pour échanger des données entre les clusters de test et la base de données 310. Comme décrit précédemment, le programme résidant en mémoire du noeud d'entrée 325 a notamment pour objet de déterminer les ressources du cluster sur lequel il est implémenté et accéder aux éléments de tests mémorisés dans la base de données 310 afin de créer les tests dynamiques et lancer l'exécution des séquences de tâches correspondant à ces tests lorsque les ressources nécessaires sont disponibles et transmettre à cette base de données les résultats obtenus. Plus précisément, les éléments de tests obtenus de la base de données 310 en fonction des ressources du cluster sont utilisés pour créer les tests dynamiques qui sont mémorisés dans des fichiers 330, chaque test pouvant, par exemple, être mémorisé dans un fichier distinct. De façon avantageuse, ces fichiers mémorisent, pour chaque test, l'environnement de test comprenant, par exemple, une référence à un système d'exploitation et à la version devant être utilisée, les données de test, c'est-à-dire ici les tâches à exécuter et leurs paramètres, et les règles d'analyse pour obtenir les résultats. Ces fichiers peuvent également être utilisés pour stocker, de façon temporaire, les résultats de test avant que ces derniers ne soient transmis à la base de données 310 à partir de laquelle ils peuvent être traités et analysés par le serveur applicatif 345. Les fichiers 330 sont, par exemple, mémorisés dans le système de fichiers du cluster. La figure 4 représente schématiquement un exemple d'algorithme mis en oeuvre dans un programme résidant en mémoire d'un noeud d'entrée d'un cluster appartenant à un environnement de test pour effectuer des tests dynamiques selon les ressources du cluster. Comme indiqué, cet algorithme est appelé par le planificateur global du cluster considéré ou par sa crontab. Une première étape (étape 400) vise à obtenir des caractéristiques du cluster, notamment celles relatives à ses ressources matérielles, par exemple, le nombre de noeuds, leur type et la configuration des interconnexions entre les noeuds. Il peut également s'agir d'une référence prédéterminée, par exemple le nom ou une référence du cluster. Ces caractéristiques peuvent également comprendre le système d'exploitation mis en oeuvre et sa version. Cependant, de telles caractéristiques sont, de préférence, associées à chaque test de telle sorte que le système d'exploitation requis soit mis en oeuvre. Une étape suivante (étape 405) a pour objet l'obtention de tâches planifiées et de données de tests référents en fonction des caractéristiques du cluster. A titre d'illustration, cette étape peut prendre la forme de requêtes SQL (sigle de Structured Query Language en terminologie anglo-saxonne) comprenant les caractéristiques du cluster, par exemple son nom, son type de microprocesseurs et sa configuration logicielle. Elle est ici adressée à la base de données 310 via le serveur applicatif 345 comme décrit précédemment.

En réponse à cette requête, le noeud d'entrée du cluster reçoit des éléments de tests permettant de créer un, plusieurs ou l'ensemble des tests dynamiques pouvant être effectués et devant être effectués par le cluster à l'origine de la requête (étape 410). Ces données, reçues ici de la base de données 310 via le serveur applicatif 345, comprennent avantageusement, pour chaque test dynamique, les informations suivantes : - l'environnement de test, c'est-à-dire, par exemple, le nombre de noeuds à utiliser, la configuration de leur interconnexion, les variables d'environnement et le système d'exploitation à utiliser ; - les données de test, c'est-à-dire, en particulier, la séquence de 30 tâches devant être exécutées ainsi que les paramètres d'exécution de ces tâches ; et, - les règles d'analyse, c'est-à-dire les règles permettant d'obtenir les résultats de test devant être transmis en réponse à l'exécution du test. Les données reçues de tests référents ou les tests dynamiques créés sont, de préférence, mémorisées dans des fichiers (fichiers 330 sur la figure 3). Une étape suivante a pour objet de déterminer s'il reste des tests dynamiques devant être exécutés (étape 415). Si aucun test dynamique ne doit être exécuté, une commande est transmise au serveur applicatif 345 pour lui ordonner de transmettre au client à l'origine des tests dynamiques effectués un rapport final sur l'exécution de ces tests (étape 420). Ce rapport comprend, par exemple, les résultats de tests. L'algorithme prend alors fin. Si, au contraire, au moins un test dynamique doit être effectué, une étape suivante a pour objet d'identifier les tests dynamiques devant être exécutés selon les ressources disponibles du cluster (étape 425).

A ces fins, les ressources disponibles sont comparées avec les ressources nécessaires à l'exécution des tâches identifiées via une table d'exécution de routines pour déterminer les tests pouvant être exécutés. Si les ressources ne permettent pas d'effectuer au moins l'un des tests, cette étape est répétée jusqu'à ce qu'une interruption arrête le système ou jusqu'à ce que des ressources se libèrent pour permettre d'effectuer un test. Si, au contraire, les ressources disponibles du cluster permettent l'exécution d'une séquence de tâches correspondant à un ou à plusieurs tests dynamiques, ceux-ci sont sélectionnés dans la table d'exécution de routines. Il peut s'agir, par exemple, des premiers tests pouvant être exécutés à partir d'un index de la table d'exécution de routines. Pour exécuter la séquence de tâches correspondant à un test, les données de celui-ci sont obtenues à partir du fichier correspondant afin de configurer l'environnement et compiler les applications de test (si nécessaire, selon le système d'exploitation utilisé). Comme illustré avec la flèche rebouclant vers l'étape 415, l'étape 425 est exécutée tant qu'il reste des tests dynamiques à exécuter. Les ressources nécessaires à l'exécution des tests sélectionnés sont alors réservées pour chacun de ces tests dynamiques (étape 430-1, 430-n) et la séquence de tâches est lancée par l'exécution de ces tests dynamiques (étape 435-1, 435-n). Les résultats obtenus lors de l'exécution de la séquence de tâches, selon les règles d'analyse utilisées, sont ici mémorisés dans le fichier associé au test.

Il est observé que l'étape de réservation de ressources (étape 430) peut comprendre une étape de réinitialisation de noeuds du cluster ou de changement du système d'exploitation, c'est-à-dire une étape de nettoyage logiciel complet. Lorsque la séquence de tâches correspondant à un test dynamique a été exécutée, les résultats obtenus ainsi que, de préférence, la configuration du test dynamique sont transmis (étape 440-1, 440-n) à la base de données 310 via le serveur applicatif 345 pour être traités et analysés par un système d'évaluation afin de valider ou non l'exécution des tâches et construire une représentation des résultats de test et validation telle que celle décrite en référence à la figure 2. Une commande est ensuite transmise au serveur applicatif 345 pour lui ordonner de transmettre au client à l'origine du test dynamique effectué un rapport sur l'exécution de ce test (étape 4445-1, 445-n). Le test dynamique effectué est alors marqué comme réalisé (étape 450-1, 450-n) afin qu'il ne soit pas sélectionné à nouveau. Dès qu'un test dynamique a été exécuté, les ressources correspondantes sont libérées (étape 455). L'algorithme retourne alors à l'étape 415 pour déterminer si des tests dynamiques sont en cours d'exécution ou doivent être exécutés. Si aucun test dynamique n'est en cours d'exécution ou ne doit être exécuté, une commande est transmise au serveur applicatif 345 pour lui ordonner de transmettre au client à l'origine des tests dynamiques effectués un rapport final sur l'exécution de ces tests (étape 420) et l'algorithme prend fin. Comme illustré par les références 430-i à 450-i, plusieurs tests peuvent être exécutés simultanément par un cluster, permettant ainsi une utilisation parallélisée de ressources mutualisées. Des séquences de tâches peuvent donc être lancées alors même que d'autres séquences de tâches sont en cours d'exécution. Il doit être observé ici qu'il n'est pas nécessaire de synchroniser les étapes liées à l'exécution d'un test dynamique avec les étapes correspondantes d'un autre test dynamique. En d'autres termes, l'exécution des étapes 430-i à 450-i est indépendante de l'exécution des étapes 430-j à 450-j.

Un exemple d'architecture d'un noeud d'un cluster adapté à mettre l'algorithme décrit en référence à la figure 4 est illustré sur la figure 5. Le dispositif 500 comporte ici un bus de communication 502 auquel sont reliés : - des unités centrales de traitement ou microprocesseurs 504 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - des composants de mémoire vive 506 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités. Comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur ou être commun aux éléments du dispositif 500 ; et, - des interfaces de communication 508 adaptées à transmettre et à recevoir des données. De préférence, le dispositif 500 dispose en outre des moyens de stockage interne 512, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes permettant au dispositif 500 de mettre en oeuvre les processus selon l'invention et de données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, les microprocesseurs sont susceptibles de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500.

De manière générale, le ou les programmes mis en oeuvre peuvent être chargés par un des moyens de stockage ou de communication du dispositif 500 avant d'être exécutés.

Les microprocesseurs 504 commandent et dirigent l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple un disque dur, sont transférés dans la mémoire vive 506 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

1. REVENDICATIONS1. Procédé de validation d'exécution d'au moins une tâche pour système informatique évolutif dans un environnement de test comprenant au moins un cluster, chacun desdits au moins cluster comprenant une pluralité de noeuds, au moins un noeud de ladite pluralité de noeuds de chacun desdits au moins un cluster comprenant un programme résidant en mémoire, ce procédé étant caractérisé en ce que ledit programme résidant en mémoire, appelé le programme, comprend les étapes suivantes, - transmission à un système de mémorisation d'éléments de tests d'au moins une caractéristique de ladite pluralité de noeuds du cluster auquel appartient le noeud comprenant ledit programme ; - en réponse à ladite étape de transmission, si ledit système de mémorisation d'éléments de tests comprend des données représentatives d'au moins un test de ladite au moins une tâche compatible avec ladite au moins une caractéristique, réception (405) desdites données représentatives dudit au moins un test permettant l'exécution de ladite au moins une tâche dans le cluster auquel appartient le noeud comprenant ledit programme ; et, - si les ressources disponibles du cluster auquel appartient le noeud comprenant ledit programme permettent l'exécution de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test, exécution (435) de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test et transmission (440) d'au moins un résultat obtenu lors de ladite exécution.
2. 2. Procédé selon la revendication 1 selon lequel ladite étape de réception de données permettant l'exécution de ladite au moins une tâche comprend une étape de réception d'au moins une donnée de configuration de l'environnement du cluster auquel appartient le noeud comprenant ledit programme, le procédé comprenant en outre une étape de configuration del'environnement du cluster auquel appartient le noeud comprenant ledit programme selon ladite donnée de configuration reçue.
3. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite étape de réception de données permettant l'exécution de ladite au moins une tâche comprend une étape de réception d'au moins une donnée pour déterminer un résultat d'exécution de ladite au moins une tâche, le procédé comprenant en outre une étape de détermination d'au moins un résultat d'exécution de ladite au moins une tâche selon ladite au moins une donnée reçue pour déterminer un résultat d'exécution de ladite au moins une tâche.
4. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de création (410) dudit au moins un test de ladite au moins une tâche selon lesdites données reçues représentatives dudit au moins un test.
5. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de création d'une entrée dans une table d'exécution de routines en réponse à ladite étape de réception de données permettant l'exécution de ladite au moins une tâche, ladite table d'exécution de routines permettant l'exécution automatique de ladite au moins une tâche.
6. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de transmission d'une commande à un système externe pour ordonner l'envoi d'un rapport d'exécution de ladite au moins une tâche.
7. 7. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit système de mémorisation d'éléments de tests comprend une base de données (310), ladite base de données comprenant des données d'environnement, de test, d'analyse et de tâches, ladite étape de transmission de ladite au moins une caractéristique de ladite pluralité de noeuds du cluster auquel appartient le noeud comprenant ledit programme comprenant une requête d'accès à ladite base de données.
8. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel une pluralité de tests est exécutée simultanément.
9. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédente lorsque ledit programme est exécuté sur un ordinateur.
10. 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.