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

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

Info

Publication number
EP2553584A1
EP2553584A1 EP11715960A EP11715960A EP2553584A1 EP 2553584 A1 EP2553584 A1 EP 2553584A1 EP 11715960 A EP11715960 A EP 11715960A EP 11715960 A EP11715960 A EP 11715960A EP 2553584 A1 EP2553584 A1 EP 2553584A1
Authority
EP
European Patent Office
Prior art keywords
test
task
execution
cluster
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP11715960A
Other languages
German (de)
English (en)
Inventor
Damien Guinier
Patrick Le Dot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Publication of EP2553584A1 publication Critical patent/EP2553584A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • the present invention relates to the validation of execution of software routines and more particularly to a method, a computer program and a device for validating the execution of tasks in evolving computer systems.
  • intermediate software layers are generally used between the hardware layer and the software application layer.
  • Such intermediate layers make it possible to perform tasks as generic as possible, such as data transfers and processing.
  • the use of such tasks often makes it possible to decorrelate the application and hardware layers, thus allowing a software application to be executed by several different hardware layers.
  • these intermediate layers typically include the operating system used, they may also include particular tasks related, in particular, to the optimization of hardware resources.
  • certain tasks may be proposed, in addition to the operating system, in order, in particular, to choose the most efficient mathematical algorithms depending on the applications targeted.
  • testing and validation of the execution of these tasks represents an essential phase of the development of computer systems comprising a hardware layer and an intermediate layer adapted to perform these tasks to detect failures and thus guarantee a level of reliability required.
  • These tests are generally intended to observe the behavior of the system performing these tasks according to predetermined sequences, that is to say according to particular test data, in order to compare the results obtained with expected results.
  • the computer systems implementing these tasks evolve over time to, on the one hand, correct any errors observed and, on the other hand, improve their performance or integrate new functionalities.
  • Such evolutions may concern hardware elements of the computer system, the hardware architecture or the configuration of these elements as well as a part of the intermediate software layer such as an operating system.
  • performing these tasks on these modified systems should be checked again to ensure that performance has not been degraded. This is a non-regression test.
  • the tests aim at observing the behavior of the modified system performing the tasks under test data in order to compare the results obtained with expected results or previous results.
  • test and validation strategies There are many test and validation strategies. However, a test is typically related to an environment, i.e. a hardware and software configuration, test data, i.e. call sequences to the tested tasks and their parameters, and a method of analysis or obtaining results. This results in a number of combinations that can be particularly important. In order to facilitate the test and validation operations, the latter are generally automated according to a mechanism of interleaved loops to perform all the tests exhaustively or according to predetermined scenarios. For these purposes, a material environment is often devoted to this function. It is configured according to the tests and validations to be performed.
  • Figure 1 schematically illustrates a test system for performing tasks in a computer system.
  • the test and validation system 100 comprises a test hardware environment 105, itself comprising a plurality of computers, generally clustered together, and a database 1 10 here containing the test and validation data and configuration parameters of the test environment.
  • the test and validation system 100 further comprises a control system 1 15, for example a computer or a server, to identify the tests and validations to be performed, configure the test environment, transmit the test data, receive the results obtained and compare these results with the expected results.
  • a first step is to identify this test and to obtain the corresponding data.
  • a next step is to configure the test environment. It aims in particular to determine the computers to be used, that is to say, for example, a particular cluster, and their implementation. It also relates to the configuration of the interconnections between these computers, that is to say the configuration of the network or the architecture used.
  • the networks are, for example Ethernet networks or InfiniBand type. It is possible to define a test environment depending on the cluster to be used, a version of the operating system implemented, and a particular architecture.
  • the test data and the definitions or rules for obtaining the desired results are identified to start the test. The results obtained are then processed and compared with the results expected by the control system 1 15.
  • Figure 2 schematically shows results of tests and validations performed for a computer system evolving over time.
  • the tests are performed here at times ti, t 2 , t n .
  • Each test (tests 1 to n) corresponds here to a particular test environment as well as to particular test data, for example test data from different suppliers.
  • test and validation results are compared here with expected results to determine an indication of success () or failure (*).
  • the results are, for example, data transmission rates, response times and processing times. These results can be presented in a table such as that illustrated in FIG. 2 in which each line corresponds to a particular test and each column corresponds to a time or a test date.
  • an error in the sense of a particular test may be an error related to the result of the test, that is to say an erroneous result with respect to a test data, but may also be related to the change.
  • test results if no modification of the computer system theoretically affecting the result has been made.
  • the observation of an indication of success at this test without a modification of the computer system related to this test has been performed can be interpreted as a potential error.
  • test and validation system such as that presented with reference to FIGS. 1 and 2 makes it possible to effectively test and validate the execution of static tasks in computer systems, it does not make it possible to use the environment evolutionary test equipment optimally. This results in particular a loss of time related to the sequence of tests and an underutilization of resources of the test system.
  • the invention solves at least one of the problems discussed above.
  • the invention thus relates to a process for validating the execution of at least one task for an evolving computer system in a test environment comprising at least one cluster, each of said at least cluster comprising a plurality of nodes, at least one node of said plurality of nodes of each of said at least one cluster comprising a program residing in memory, said program residing in memory, called the program, comprising the following steps,
  • test element storage system comprises data representative of least one test of said at least one task compatible with said at least one characteristic, receiving said representative data of said at least one test for executing said at least one task in the cluster to which the node comprising said program belongs;
  • the method according to the invention thus makes it possible to optimize the resources of a test environment comprising a cluster gathering several nodes during the execution of tests by allowing a parallel use of shared resources.
  • said data receiving step allowing the execution of said at least one task comprises a step of receiving at least one configuration datum of the environment of the cluster to which the node comprising said program belongs, the method comprising further a step of configuring the cluster environment to which the node comprising said program according to said received configuration data belongs.
  • the method according to the invention thus makes it possible to configure the test environment according to the tests to be performed.
  • Said data receiving step allowing the execution of said at least one task furthermore preferably comprises a step of receiving at least one data item for determining a result of execution of said at least one task, the method comprising in addition, a step of determining at least one result of executing said at least one task according to said at least one piece of data received to determine a result of execution of said at least one task.
  • the method according to the invention thus makes it possible to configure the way in which the results of test execution are evaluated.
  • the method further comprises a step of creating said at least one test of said at least one task according to said representative received data of said at least one test.
  • the method according to the invention thus makes it possible to create dynamic tests from referent test elements, thus multiplying the test possibilities.
  • the method further comprises a step of creating an entry in a routine execution table in response to said data receiving step allowing the execution of said at least one task, said routine execution table for automatically executing said at least one task.
  • the method further comprises a step of transmitting a command to an external system for ordering the sending of an execution report of said at least one task.
  • the test environment is thus adapted to manage the execution of tests and to control the transmission of test reports independently.
  • said test element storage system comprises a database, said database comprising environment, test, analysis and task data, said step of transmission of said data element. at least one characteristic of said plurality of nodes of the cluster to which the node comprising said program comprising a request for access to said database belongs.
  • a plurality of tests is performed simultaneously.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above and a device comprising means adapted to the implementation of each of the steps of the method described. previously.
  • FIG. 3 schematically illustrates a test execution validation and execution environment implementing the invention
  • FIG. 4 diagrammatically represents an algorithm implemented in a program residing in memory of an input node of a cluster belonging to a test and validation environment
  • FIG. 5 illustrates an exemplary architecture of a node of a cluster adapted to implement the invention.
  • the object of the invention is notably to manage the execution of tests, that is to say sequences of tasks associated with configuration data and results analysis, from the test clusters themselves, according to their capabilities, to enable the validation of the execution of these tasks and optimize the execution of these sequences.
  • a test environment consists of several clusters each comprising a set of nodes.
  • a particular node of each cluster called an entry node or a login node, includes a memory-resident program to automatically launch task sequences.
  • Such a program When the invention is implemented in an environment based on a Linux operating system (Linux is a brand), such a program typically includes crond.
  • This program combined with a program of shell or binary script type, that is to say a program allowing access to the operating system, makes it possible in particular to identify the resources of the cluster as well as its execution environment in order to launching task sequences that can be executed in the identified configuration. In other words, from the identified configuration information, it is possible to determine the tests that can be performed, to access the data allowing the execution of the sequences of tasks and run when the necessary resources are available.
  • a database includes a list of scheduled tasks and, for each scheduled task, the list of clusters capable of executing the corresponding task sequences.
  • This database also includes referential tests themselves comprising sequences of tasks to be executed, execution environments and information relating to obtaining and analyzing the test results.
  • the program residing in memory of each input node of each cluster can create corresponding dynamic tests from referent tests and launch the associated task sequences according to available resources.
  • Figure 3 schematically illustrates a test execution validation and execution environment 300 implementing the invention.
  • a table 305 is used here to determine the tests to be performed by combination of parameters.
  • a dynamic test to be performed here is defined by the combination of referent test elements, that is to say, for example, the combination of an environment, test data, analysis rules, tasks and a user.
  • a dynamic test can be created from indications for referenced test items and the targeted items themselves.
  • the referenced tests and the scheduled tasks are here stored in the database 310.
  • the referent tests may comprise elements of a different nature, for example hardware targets to be used during the execution of the tests.
  • test environment also includes test clusters, here the test clusters 315-1 and 315-2, also called test clusters A and B.
  • Each test cluster comprises a set of nodes interconnected according to a predefined or configurable architecture and a generically referenced management system 320 linked to a particular node or distributed over several nodes.
  • a particular node 325 called an input node or a node of login, is used to access the cluster from an external system.
  • the input node comprises a memory-resident program, generically referenced 325.
  • the input node is also used to transmit the obtained test results to an external system.
  • the nodes of the cluster used to execute the tasks corresponding to a dynamic test are here generically referenced 335.
  • An application evaluation system is also used to compare the results obtained with the expected results.
  • This is an Apache PHP 345 application server. This is preferably used to exchange data between the test clusters and the database 310.
  • the program residing in memory of the input node 325 is intended in particular to determine the resources of the cluster on which it is implemented and to access the test elements stored in the database 310 in order to create the dynamic tests and start the execution of the task sequences corresponding to these tests when the necessary resources are available and transmit the results obtained to this database.
  • each test may, for example, be stored in a separate file.
  • these files store, for each test, the test environment comprising, for example, a reference to an operating system and to the version to be used, the test data, that is to say here the tasks to perform and their parameters, and the analysis rules to get the results.
  • These files can also be used to store, temporarily, the test results before they are transmitted to the database 310 from which they can be processed and analyzed by the application server 345.
  • the 330 files are for example, stored in the cluster file system.
  • FIG. 4 diagrammatically represents an example of an algorithm implemented in a program residing in memory of an input node a cluster belonging to a test environment to perform dynamic tests based on cluster resources. As indicated, this algorithm is called by the global scheduler of the considered cluster or by its crontab.
  • a first step (step 400) aims at obtaining characteristics of the cluster, in particular those relating to its hardware resources, for example, the number of nodes, their type and the configuration of the interconnections between the nodes. It can also be a predetermined reference, for example the name or a reference of the cluster.
  • These features may also include the operating system implemented and its version. However, such features are preferably associated with each test so that the required operating system is implemented.
  • a next step (step 405) is to obtain scheduled tasks and referent test data according to the characteristics of the cluster.
  • this step can take the form of SQL requests (acronym for Structured! Query Language in English terminology) including the characteristics of the cluster, for example its name, its type of microprocessor and its software configuration. It is here addressed to the database 310 via the application server 345 as previously described.
  • the cluster's input node receives test items to create one, more, or all of the dynamic tests that can be performed and to be performed by the cluster that originated the request. 410).
  • This data received here from the database 310 via the application server 345, advantageously comprises, for each dynamic test, the following information:
  • test environment that is to say, for example, the number of nodes to use, the configuration of their interconnection, the environment variables and the operating system to be used;
  • test data that is to say, in particular, the sequence of tasks to be executed as well as the parameters for executing these tasks; and, - the analysis rules, that is to say the rules allowing to obtain the test results to be transmitted in response to the execution of the test.
  • the data received from referent tests or the dynamic tests created are preferably stored in files (files 330 in FIG. 3).
  • a next step is to determine if there are still dynamic tests to be performed (step 415). If no dynamic test is to be executed, a command is sent to the application server 345 to order it to transmit to the client at the origin of the dynamic tests carried out a final report on the execution of these tests (step 420). This report includes, for example, test results. The algorithm then ends.
  • a next step is to identify the dynamic tests to be performed according to the available resources of the cluster (step 425).
  • the available resources are compared with the resources required to perform the tasks identified through a routine execution table to determine the tests that can be executed.
  • this step is repeated until an interrupt halts the system or until resources are released for testing.
  • the available resources of the cluster allow the execution of a sequence of tasks corresponding to one or more dynamic tests, these are selected in the execution table of routines. It may be, for example, first tests that can be run from an index of the execution table of routines.
  • the data of the test is obtained from the corresponding file in order to configure the environment and compile the test applications (if necessary, according to the operating system used).
  • step 425 is executed as long as there remain dynamic tests to be performed.
  • the resources required to execute the selected tests are then reserved for each of these dynamic tests (step 430-1, 430-n) and the task sequence is started by performing these dynamic tests (step 435-1, 435-n).
  • the results obtained during the execution of the task sequence, according to the analysis rules used, are here stored in the file associated with the test.
  • the resource reservation step may include a step of resetting cluster nodes or changing the operating system, i.e. a complete software cleanup step.
  • the results obtained as well as, preferably, the configuration of the dynamic test are transmitted (step 440-1, 440-n) to the database 310 via the application server. 345 to be processed and analyzed by an evaluation system in order to validate or not the execution of the tasks and to construct a representation of the test and validation results such as that described with reference to FIG. 2.
  • a command is then sent to the application server 345 to order it to transmit to the client at the origin of the dynamic test carried out a report on the execution of this test (step 4445-1, 445-n).
  • the dynamic test performed is then marked as realized (step 450-1, 450-n) so that it is not selected again.
  • step 455 the algorithm then returns to step 415 to determine whether dynamic tests are running or need to be executed. If no dynamic test is running or must be executed, a command is sent to the application server 345 to order it to transmit to the client at the origin of the dynamic tests carried out a final report on the execution of these tests. tests (step 420) and the algorithm ends.
  • FIG. 5 An exemplary architecture of a node of a cluster adapted to put the algorithm described with reference to FIG. 4 is illustrated in FIG. 5.
  • the device 500 here comprises a communication bus 502 to which are connected:
  • each RAM component may be associated with a microprocessor or be common to the elements of the device 500; and,
  • communication interfaces 508 adapted to transmit and receive data.
  • the device 500 furthermore has internal storage means 512, such as hard disks, which can notably comprise the executable code of programs enabling the device 500 to implement the processes according to the invention and data processed or treat according to the invention.
  • internal storage means 512 such as hard disks, which can notably comprise the executable code of programs enabling the device 500 to implement the processes according to the invention and data processed or treat according to the invention.
  • the communication bus allows communication and interoperability between the various elements included in the device 500 or connected to it.
  • the representation of the bus is not limiting and, in particular, the microprocessors are capable of communicating instructions to any element of the device 500 directly or via another element of the device 500.
  • the program or programs implemented can be loaded by one of the storage or communication means of the device 500 before being executed.
  • the microprocessors 504 control and direct the execution of the instructions or portions of software code of the program or programs according to the invention.
  • the program or programs that are stored in a non-volatile memory for example a hard disk, are transferred into the random access memory 506 which then contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

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

Procédé, programme d'ordinateur et dispositif de validation d'exécution de tâches dans des systèmes informatiques évolutifs
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 œuvre 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 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 1 10 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 1 15, 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 œuvre. 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 œuvre 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 1 15.
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 ti, 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 ( ) ou d'échec (*). 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.
II 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 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 nœuds, au moins un nœud de ladite pluralité de nœuds 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 nœuds du cluster auquel appartient le nœud 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 nœud comprenant ledit programme ; et,
- si les ressources disponibles du cluster auquel appartient le nœud 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 nœuds 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 nœud comprenant ledit programme, le procédé comprenant en outre une étape de configuration de l'environnement du cluster auquel appartient le nœud 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 nœuds du cluster auquel appartient le nœud 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 œuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un dispositif comprenant des moyens adaptés à la mise en œuvre 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 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 œuvre l'invention ;
- la figure 4 représente schématiquement un algorithme mis en œuvre dans un programme résidant en mémoire d'un nœud 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 nœud d'un cluster adapté à mettre en œuvre 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 nœuds. Un nœud particulier de chaque cluster, appelé nœud d'entrée ou nœud 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 œuvre 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 nœud 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 œuvre 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 é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 nœuds reliés 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 nœud particulier ou réparti sur plusieurs nœuds. Un nœud particulier 325, appelé nœud d'entrée ou nœud de login, est utilisé pour accéder au cluster depuis un système externe. Le nœud d'entrée comprend un programme résidant en mémoire, génériquement référencé 325. Le nœud d'entrée est également utilisé pour transmettre les résultats de test obtenus à un système externe.
Les nœuds 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 nœud 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 œuvre dans un programme résidant en mémoire d'un nœud 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 nœuds, leur type et la configuration des interconnexions entre les nœuds. 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 œuvre 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 Structurée! 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 nœud 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 nœuds à 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 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.
II est observé que l'étape de réservation de ressources (étape 430) peut comprendre une étape de réinitialisation de nœuds 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 nœud 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 œuvre 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 œuvre 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 œuvre 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

REVENDICATIONS
1 . 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 nœuds, au moins un nœud de ladite pluralité de nœuds 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 nœuds du cluster auquel appartient le nœud 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 nœud comprenant ledit programme ; et,
- si les ressources disponibles du cluster auquel appartient le nœud 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. 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 nœud comprenant ledit programme, le procédé comprenant en outre une étape de configuration de l'environnement du cluster auquel appartient le nœud comprenant ledit programme selon ladite donnée de configuration reçue.
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. 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. 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. 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. 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 nœuds du cluster auquel appartient le nœud comprenant ledit programme comprenant une requête d'accès à ladite base de données.
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. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre 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. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.
EP11715960A 2010-03-26 2011-03-22 Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs Withdrawn EP2553584A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1052235A FR2958059B1 (fr) 2010-03-26 2010-03-26 Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
PCT/FR2011/050584 WO2011117528A1 (fr) 2010-03-26 2011-03-22 Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs

Publications (1)

Publication Number Publication Date
EP2553584A1 true EP2553584A1 (fr) 2013-02-06

Family

ID=42306691

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11715960A Withdrawn EP2553584A1 (fr) 2010-03-26 2011-03-22 Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs

Country Status (6)

Country Link
US (1) US20130031532A1 (fr)
EP (1) EP2553584A1 (fr)
JP (1) JP2013524312A (fr)
BR (1) BR112012021145A2 (fr)
FR (1) FR2958059B1 (fr)
WO (1) WO2011117528A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060070033A1 (en) * 2004-09-24 2006-03-30 International Business Machines Corporation System and method for analyzing effects of configuration changes in a complex system
US20150095756A1 (en) * 2013-10-01 2015-04-02 Zijad F. Aganovic Method and apparatus for multi-loop, real-time website optimization
CN104133750A (zh) * 2014-08-20 2014-11-05 浪潮(北京)电子信息产业有限公司 主机与存储设备兼容适配测试方法和系统
JP6684233B2 (ja) * 2017-01-12 2020-04-22 株式会社日立製作所 テスト入力情報検索装置及び方法
CN109766228A (zh) * 2017-11-09 2019-05-17 北京京东尚科信息技术有限公司 一种基于接口的线上验证方法和装置
CN110175130B (zh) * 2019-06-11 2024-05-28 深圳前海微众银行股份有限公司 集群系统性能的测试方法、装置、设备及可读存储介质
US11194699B2 (en) * 2019-09-17 2021-12-07 Red Hat, Inc. Compatibility testing with different environment configurations
CN111913884A (zh) * 2020-07-30 2020-11-10 百度在线网络技术（北京）有限公司 分布式测试方法、装置、设备、系统和可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6711616B1 (en) * 2000-05-01 2004-03-23 Xilinx, Inc. Client-server task distribution system and method
US7426729B2 (en) * 2001-07-11 2008-09-16 Sun Microsystems, Inc. Distributed processing framework system
US7114159B2 (en) * 2001-07-11 2006-09-26 Sun Microsystems, Inc. Processing resource for use in a distributed processing framework system and methods for implementing the same
US6842891B2 (en) * 2001-09-11 2005-01-11 Sun Microsystems, Inc. Dynamic attributes for distributed test framework
US20040015975A1 (en) * 2002-04-17 2004-01-22 Sun Microsystems, Inc. Interface for distributed processing framework system
US8024705B2 (en) * 2003-11-12 2011-09-20 Siemens Product Lifecycle Management Software Inc. System, method, and computer program product for distributed testing of program code
JPWO2009011028A1 (ja) * 2007-07-17 2010-09-09 株式会社アドバンテスト 電子デバイス、ホスト装置、通信システム、およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2011117528A1 *

Also Published As

Publication number Publication date
FR2958059B1 (fr) 2012-04-13
WO2011117528A1 (fr) 2011-09-29
FR2958059A1 (fr) 2011-09-30
BR112012021145A2 (pt) 2019-09-24
JP2013524312A (ja) 2013-06-17
US20130031532A1 (en) 2013-01-31

Similar Documents

Publication Publication Date Title
EP2553584A1 (fr) Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs
EP0820013B1 (fr) Procédé de surveillance en temps réel d'un système informatique pour son administration et l'aide à sa maintenance en phase d'exploitation
US10942801B2 (en) Application performance management system with collective learning
FR3025909A3 (fr) Audit de video sur le web
US12118334B1 (en) Determination of schema compatibility between neighboring operators within a search query statement
WO2012140344A1 (fr) Procédé et dispositif de traitement de commandes d'administration dans un cluster
WO2014072628A1 (fr) Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs
EP2704010A1 (fr) Procédé et dispositif de traitement de commandes dans un ensemble d'éléments informatiques
EP4055506A1 (fr) Detection d'attaques a l'aide de compteurs de performances materiels
US20160366021A1 (en) User interface for an application performance management system
EP2721487B1 (fr) Procede, dispositif et programme d'ordinateur pour la mise à jour logicielle de clusters optimisant la disponibilite de ces derniers
FR2973131A1 (fr) Procede et dispositif de detection d'incompatibilites d'interfaces logiques d'equipements de systemes embarques
EP2734921B1 (fr) Procede, programme d'ordinateur et dispositif d'aide au deploiement de clusters
US10235262B2 (en) Recognition of operational elements by fingerprint in an application performance management system
FR3075996A1 (fr) Systeme et procede d'elaboration et d'execution de tests fonctionnels pour grappe de serveurs
WO2013088019A1 (fr) Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité
EP2727057B1 (fr) Procede et programme d'ordinateur pour identifier dynamiquement des composants d'un cluster et automatiser des operations de gestion optimisee du cluster
EP3853784A1 (fr) Procédé d'analyse des dysfonctionnements d'un système et dispositifs associés
AU2023285916A1 (en) Log clustering for guided root cause analysis
WO2024129203A1 (fr) Génération d'une carte de dépendance de service à service à partir de journaux de système de gestion de dns et de parc
FR3108747A1 (fr) Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.
FR2984052A1 (fr) Procede et programme d'ordinateur de configuration d'equipements dans une infrastructure informatique ayant une architecture de type infiniband
FR3098941A1 (fr) Dispositif et Procédé pour l’analyse de performances d’une application n-tier
FR3101973A1 (fr) Dispositif de surveillance
WO2017025672A1 (fr) Système de surveillance pour supercalculateur utilisant des données topologiques

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120928

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20151001