FR 3075996 A1 20190628 FR 1762741 A 20171221 La présente invention concerne un système d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs. Elle concerne également une grappe de serveurs et une installation informatique comportant un tel système, ainsi qu'un procédé d'élaboration et d'exécution de tests fonctionnels pour grappe de serveurs. Les grappes de serveurs sont des réseaux complexes comportant souvent un grand nombre de noeuds de calcul et service hétérogènes interconnectés entre eux par au moins un réseau de transmission de données. Ces noeuds de calculs et service comportent généralement des ordinateurs puissants avec un stockage partagé en baies de stockage, apparaissant de l'extérieur comme un calculateur à très forte puissance de calcul, dit calculateur à haute performance de traitement ou calculateur HPC (de l'Anglais « High Performance Computing »). Ces installations optimisées permettent la répartition de traitements complexes et/ou de calculs parallèles sur au moins une partie des noeuds de calcul. Dans ce type de réseau particulièrement hétérogène, il est nécessaire de procéder régulièrement à des tests fonctionnels sur les équipements. Ces tests se font dans des environnements de plus en plus variés et distribués. Il est donc important de pouvoir les définir le plus simplement possible et de les documenter à l'aide de données descriptives. Ces tests doivent de plus généralement se faire par des commandes successives entrées sur interface en ligne de commande CLI (de l'anglais « Command Line Interface »), ce qui ne les rend pas aisés à élaborer. Il existe aujourd'hui des outils logiciels permettant d'élaborer préalablement des fichiers de commandes regroupant plusieurs commandes de tests fonctionnels à exécuter sur interface en ligne de commande, puis d'exécuter ces fichiers de commandes sur l'interface en ligne de commande adéquate. Ces fichiers sont généralement appelés fichiers de scripts, les scripts étant constitués des commandes qui sont alors interprétées automatiquement par l'interface en ligne de commande pour exécuter les tests fonctionnels correspondants. Par équipements d'une grappe de serveurs on entend les noeuds de calcul précités, mais également les commutateurs (généralement appelés « switch »), les baies informatiques de stockage de données, les gestionnaires de matériels, les alimentations électriques administrables, ou d'une façon plus générale tous les éléments raccordables entre eux à l'aide de ports de connexion qui ont besoin d'une adresse logique, notamment une adresse IP, pour fonctionner. 2 L'invention s'applique ainsi plus particulièrement à un système d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs, comportant au moins un processeur, des moyens de stockage, une interface en ligne de commande stockée dans les moyens de stockage et exécutable 5 par le processeur, ainsi qu'une plate-forme logicielle constituée de plusieurs modules fonctionnels stockés dans les moyens de stockage et exécutables par le processeur, dans lequel : la plate-forme logicielle comporte un module fonctionnel d'élaboration d'un fichier de commandes de tests fonctionnels pour l'interface en ligne de 10 commande et une interface associée dédiée à la saisie de ces commandes de tests fonctionnels dans au moins un bloc exécutable du fichier de commandes, la plate-forme logicielle comporte un module fonctionnel d'exécution du fichier de commandes, conçu pour activer l'interface en ligne de commande 15 et y exécuter ledit au moins un bloc exécutable du fichier de commandes. Par « bloc exécutable » du fichier de commandes, on entend une portion écrite délimitée du fichier de commande dont le contenu est destiné à être interprété et exécuté par une interface en ligne de commande. Mais les systèmes existants ne permettent pas d'avoir la documentation 20 descriptive des tests fonctionnels au plus près des commandes, notamment pas dans les fichiers de scripts. Il existe bien des outils logiciels permettant d'intégrer dans un même fichier des lignes d'instructions en langage de programmation compilable et exécutable avec de la documentation descriptive de ces lignes d'instructions, dans des blocs 25 descriptifs dédiés, mais ils ne sont ni conçus, ni adaptés pour des commandes de tests fonctionnels qui doivent être interprétées par des interfaces en ligne de commande. Il peut ainsi être souhaité de prévoir un système d'élaboration et d'exécution de tests fonctionnels, portant sur au moins une partie des équipements d'un réseau 30 en grappe de serveurs, qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités. Il est donc proposé un système d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs, comportant au moins un processeur, des moyens de stockage, une interface en ligne 35 de commande stockée dans les moyens de stockage et exécutable par le 3 processeur, ainsi qu'une plate-forme logicielle constituée de plusieurs modules fonctionnels stockés dans les moyens de stockage et exécutables par le processeur, dans lequel - la plate-forme logicielle comporte un module fonctionnel d'élaboration d'un 5 fichier de commandes de tests fonctionnels pour l'interface en ligne de commande et une interface associée dédiée à la saisie de ces commandes de tests fonctionnels dans au moins un bloc exécutable du fichier de commandes, la plate-forme logicielle comporte un module fonctionnel d'exécution du 10 fichier de commandes, conçu pour activer l'interface en ligne de commande et y exécuter ledit au moins un bloc exécutable du fichier de commandes, l'interface associée au module fonctionnel d'élaboration du fichier de commandes est en outre dédiée à la saisie de descripteurs des commandes de tests fonctionnels dans au moins un bloc descriptif du 15 fichier de commandes et à l'identification dudit au moins un bloc descriptif dans le fichier de commandes comme différent dudit au moins un bloc exécutable, et le module fonctionnel d'exécution du fichier de commandes est conçu pour ne pas exécuter ledit au moins un bloc descriptif du fichier de commandes 20 dans l'interface en ligne de commande. Ainsi, la présente invention permet d'agréger des commandes de tests fonctionnels pour grappe de serveurs, c'est-à-dire à interprétation et exécution par une interface de ligne de commande, avec de la documentation descriptive de ces commandes au sein d'un même fichier de commandes, sans que l'interface en ligne 25 de commande ne puisse faire la confusion entre ce qui doit être interprété/exécuté et ce qui ne doit pas l'être. De façon optionnelle : - une interface de programmation applicative exécutable par le module fonctionnel d'exécution du fichier de commandes est en outre stockée dans 30 les moyens de stockage et comporte une pluralité de commandes de vérification de résultats des commandes de tests fonctionnels, et l'interface associée au module fonctionnel d'élaboration du fichier de commandes est en outre dédiée à la saisie de ces commandes de vérification dans ledit au moins un bloc exécutable du fichier de commandes. 4 De façon optionnelle également, le module fonctionnel d'exécution du fichier de commandes est conçu pour exécuter l'interface de programmation applicative dans l'interface en ligne de commande. De façon optionnelle également, la pluralité de commandes de vérification 5 comporte au moins deux éléments de l'ensemble des commandes de vérification suivantes : - une vérification d'égalité stricte entre deux paramètres, - une vérification d'égalité approximative entre deux paramètres, à un écart prédéterminé près, 10 - une vérification d'inégalité stricte entre deux paramètres, - une comparaison entre deux paramètres par critère de supériorité, stricte ou égale, ou par critère d'infériorité, stricte ou égale, - une vérification de valeur booléenne, - une vérification d'ensemble vide, 15 - une vérification d'ensemble non vide, - une vérification d'inclusion d'une première chaîne de caractère(s) dans une deuxième chaîne de caractère(s), - une vérification de non inclusion d'une première chaîne de caractère(s) dans une deuxième chaîne de caractère(s), 20 - une vérification d'égalité stricte entre deux listes de paramètres, et - une vérification d'égalité stricte entre deux ensembles de paramètres distincts. De façon optionnelle également, la pluralité de commandes de vérification comporte en outre une commande de création d'un fichier de résultats et 25 d'inscription, dans ce fichier de résultats, de tous les résultats d'autres commandes de vérification saisies avant cette commande de création de fichier de résultats dans ledit au moins un bloc exécutable du fichier de commandes. De façon optionnelle également, l'interface associée au module fonctionnel d'élaboration du fichier de commandes est en outre dédiée à la saisie de descripteurs 30 formulés selon un format de récit d'utilisateur en trois éléments descriptifs successifs incluant : - un premier élément d'identification d'un utilisateur, - un deuxième élément d'identification d'une action de test équivalente à au moins une commande de test fonctionnel, et 5 - un troisième élément d'identification d'au moins une finalité de vérification équivalente à au moins l'une des commandes de vérification de l'interface de programmation applicative. De façon optionnelle également, l'interface associée au module fonctionnel 5 d'élaboration du fichier de commandes est stockée dans les moyens de stockage sous la forme d'une application logicielle web. Il est également proposé une grappe de serveurs comportant des noeuds de calcul et de service interconnectés par au moins un réseau de transmission de données entre ces noeuds de calcul et de service, dans laquelle au moins un noeud 10 de service est un serveur d'administration comportant un système d'élaboration et d'exécution de tests fonctionnels selon l'invention. Il est également proposé une installation informatique comportant : - une grappe de serveurs comportant des noeuds de calcul et de service interconnectés par au moins un réseau de transmission de données entre 15 ces noeuds de calcul et de service, - un terminal informatique distant de commande de la grappe de serveurs, ce terminal comportant un système d'élaboration et d'exécution de tests fonctionnels selon l'invention, pour l'élaboration et l'exécution de tests fonctionnels portant sur au moins une partie des équipements de la grappe 20 de serveurs, et - un réseau de transmission de données entre le terminal informatique distant et la grappe de serveurs. Il est également proposé un procédé d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs, 25 comportant les étapes suivantes : - élaboration d'un fichier de commandes de tests fonctionnels exécutables par une interface en ligne de commande, à l'aide d'une interface dédiée à la saisie de ces commandes de tests fonctionnels dans au moins un bloc exécutable du fichier de commandes, cette interface de saisie étant 30 associée à un module fonctionnel d'élaboration du fichier de commandes d'une plate-forme logicielle exécutée par au moins un processeur ayant accès à des moyens de stockage du module fonctionnel d'élaboration et de l'interface en ligne de commande, - exécution du fichier de commandes par un module fonctionnel d'exécution 35 de la plate-forme logicielle stocké dans les moyens de stockage, ce module 6 fonctionnel d'exécution étant conçu pour activer l'interface en ligne de commande et y exécuter ledit au moins un bloc exécutable du fichier de commandes, dans lequel : 5 l'élaboration du fichier de commandes comporte la saisie de descripteurs des commandes de tests fonctionnels dans au moins un bloc descriptif du fichier de commandes et l'identification dudit au moins un bloc descriptif dans le fichier de commandes comme différent dudit au moins un bloc exécutable, et 10 l'exécution du fichier de commandes comporte l'exclusion dudit au moins un bloc descriptif du fichier de commandes dans ce qui doit être exécuté par l'interface en ligne de commande. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés 15 dans lesquels : la figure 1 représente schématiquement la structure générale d'un système informatique pour l'élaboration et l'exécution de tests fonctionnels portant sur au moins une partie des équipements d'un réseau en grappe de serveurs, selon un mode de réalisation de l'invention, 20 la figure 2 illustre les étapes successives d'un procédé d'élaboration et d'exécution de tests fonctionnels, portant sur au moins une partie des équipements d'un réseau en grappe de serveurs, mis en oeuvre par le système informatique de la figure 1, la figure 3 représente schématiquement un exemple d'installation 25 informatique comportant une grappe de serveurs, et la figure 4 illustre un exemple d'élaboration d'un fichier de commandes par exécution d'une première partie des étapes du procédé de la figure 2. Le système informatique 10 représenté sur la figure 1, par exemple un ordinateur, comporte un processeur 12 associé de façon classique à des moyens de 30 stockage 14, par exemple une mémoire RAM, pour le stockage de fichiers de données et de programmes d'ordinateurs exécutables par le processeur 12. Parmi les programmes d'ordinateurs exécutables par le processeur 12, une plate-forme logicielle 16 comprenant plusieurs modules fonctionnels 18, 20 est stockée dans la mémoire 14. Le système informatique 10 tel qu'illustré sur la figure 1 35 comporte ainsi fonctionnellement deux programmes d'ordinateurs que représentent 7 les modules fonctionnels 18, 20, ou deux fonctions d'un même programme d'ordinateur que représente la plate-forme logicielle 16. On notera par ailleurs que les modules fonctionnels 18, 20 sont présentés comme distincts, mais cette distinction est purement fonctionnelle. Ils pourraient tout aussi bien être regroupés selon toutes 5 les combinaisons possibles en un ou plusieurs logiciels. Leurs fonctions pourraient aussi être au moins en partie micro programmées ou micro câblées dans des circuits intégrés dédiés. Ainsi, en variante, le système informatique 10 pourrait prendre la forme d'un dispositif électronique composé au moins partiellement de circuits numériques (sans programme d'ordinateur) pour la réalisation des mêmes actions. 10 Il s'agit plus précisément d'un système 10 d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs dont un exemple d'architecture sera détaillé en référence à la figure 3. Ces tests fonctionnels étant, de façon connue en soi, définis sous la forme de commandes à exécuter par interface en ligne de commande, une telle interface en ligne de commande 22, prête 15 à recevoir ces commandes pour les interpréter et les exécuter, est stockée dans les moyens de stockage 14 et exécutable par le processeur 12. Le premier module fonctionnel 18 de la plate-forme logicielle 16 est un module d'élaboration d'un fichier 24 de commandes de tests fonctionnels pour l'interface en ligne de commande 22. Il est associé à une interface U118 dédiée à la saisie de ces 20 commandes de tests fonctionnels dans au moins un bloc exécutable 26 du fichier de commandes 24. Ces commandes sont choisies parmi toutes celles déjà connues pour tester les équipements de grappes de serveurs. Conformément à un premier aspect de l'invention, l'interface U118 est en outre dédiée à la saisie de descripteurs des commandes de tests fonctionnels dans au moins un bloc descriptif 28 du fichier 25 de commandes 24. Ces descripteurs peuvent comporter des commentaires informels sur les tests fonctionnels à réaliser ou plus généralement de la documentation associée. La figure 1 illustre à titre d'exemple non limitatif quatre blocs exécutables 26 et quatre blocs descriptifs 28 dans le fichier de commandes 24. Ces blocs sont clairement distingués d'une façon ou d'une autre. En d'autres termes, l'interface U118 30 comporte des moyens, par exemple des cadres ou espaces différents, des icones de sélection, etc., pour identifier les blocs descriptifs 28 dans le fichier de commandes 24 à élaborer comme différents des blocs exécutables 26. Enfin, selon un mode de réalisation optionnel mais avantageux du point de vue de l'ergonomie, l'interface U118 est stockée dans les moyens de stockage 14 sous la forme d'une application web, 35 c'est-à-dire une application logicielle avec laquelle il est possible d'interagir à l'aide 8 d'un navigateur conforme à la technologie de la Toile d'Araignée Mondiale (de l'anglais « World Wide Web »). Le fichier de commandes 24 est destiné à être enregistré en mémoire dans les moyens de stockage 14. Il peut être élaboré en une ou plusieurs fois, notamment 5 par plusieurs exécutions du premier module fonctionnel 18 et de son interface de saisie U118. Le deuxième module fonctionnel 20 de la plate-forme logicielle 16 est un module d'exécution du fichier de commandes 24, conçu pour activer, lorsqu'il est exécuté par le processeur 12, l'interface en ligne de commande 22 et y exécuter le ou 10 les blocs exécutables 26 du fichier de commandes 24. Il est en outre conçu pour ne pas exécuter le ou les blocs descriptifs 28 du fichier de commandes 24 dans l'interface en ligne de commande 22. Conformément à un deuxième aspect de l'invention, une interface de programmation applicative 30 exécutable par le deuxième module fonctionnel 20 est 15 en outre stockée dans les moyens de stockage 14 et comporte une pluralité de commandes 32 de vérification de résultats des commandes de tests fonctionnels qui peuvent être également saisies à l'aide de l'interface U118 pour être ajoutées, dans le ou les blocs exécutables 26, aux commandes de tests fonctionnels. Selon une première variante de réalisation, une commande d'activation de cette interface de 20 programmation applicative 30 peut être saisie manuellement par un utilisateur dans un premier bloc exécutable du fichier de commandes 24, pour son interprétation et exécution ultérieure par l'interface en ligne de commande 22 lorsque celle-ci est elle-même activée par le deuxième module fonctionnel 20. Selon une deuxième variante de réalisation, le deuxième module fonctionnel 20 est conçu pour exécuter l'interface 25 de programmation applicative 30 directement dans l'interface en ligne de commande 22 sans qu'elle n'ait besoin d'être saisie par un utilisateur. D'autres variantes de réalisation sont envisageables pour activer l'interface de programmation applicative 30 avant toute exécution du ou des blocs exécutables 26 comportant les commandes de tests fonctionnels et les commandes de vérification 32. 30 Par convention et souci de simplicité illustrative, l'interface de programmation applicative 30 est nommée « ftapi » et est appelée ainsi dans l'interface en ligne de commande 22. Les commandes de vérification 32 de cette interface de programmation applicative 30 « ftapi » comportent par exemple : 9 - une commande « ftapi.assertEqual(a, b) » de vérification d'égalité stricte entre deux paramètres a et b, - une commande « ftapi.assertAlmostEqual(a, b) » de vérification d'égalité approximative entre deux paramètres a et b, à un écart prédéterminé près 5 (avantageusement paramétrable), - une commande « ftapi.assertNotEqual(a, b) » de vérification d'inégalité stricte entre deux paramètres a et b, - une commande « ftapi.assertGreater(a, b) » de comparaison entre deux paramètres a et b, vérifiant si a est strictement supérieur à b ou pas, 10 - une commande « ftapi.assertGreaterEqual(a, b) » de comparaison entre deux paramètres a et b, vérifiant si a est supérieur ou égal à b ou pas, - une commande « ftapi.assertLess(a, b) » de comparaison entre deux paramètres a et b, vérifiant si a est strictement inférieur à b ou pas, - une commande « ftapi.assertLessEqual(a, b) » de comparaison entre deux 15 paramètres a et b, vérifiant si a est inférieur ou égal à b ou pas, - une commande « ftapi.assertTrue(x) » de vérification de valeur booléenne, vérifiant si un paramètre x est « vrai », - une commande « ftapi.assertFalse(x) » de vérification de valeur booléenne, vérifiant si un paramètre x est « faux », 20 - une commande « ftapi.assertIsNone(x) » de vérification d'ensemble vide, vérifiant si un ensemble x est vide, - une commande « ftapi.assertIsNotNone(x) » de vérification d'ensemble non vide, vérifiant si un ensemble x est non vide, - une commande « ftapi.assertIn(a, b)» de vérification d'inclusion d'une 25 première chaîne de caractère(s) a dans une deuxième chaîne de caractère(s) b, - une commande « ftapi.assertNotIn(a, b)» de vérification de non inclusion d'une première chaîne de caractère(s) a dans une deuxième chaîne de caractère(s) b, 30 - une commande « ftapi.assertListEqual(a, b) » de vérification d'égalité stricte entre deux listes de paramètres a et b, - une commande « ftapi.assertSetEqual(a, b) » de vérification d'égalité stricte entre deux ensemble a et b de paramètres distincts : un « ensemble » est en effet un cas particulier de « liste » dans laquelle il ne 35 peut y avoir plus d'une occurrence d'un même élément. 10 - une commande « ftapi.report("report.txt") » de création d'un fichier de résultats "report.txt" et d'inscription, dans ce fichier de résultats "report.txt", de tous les résultats d'autres commandes de vérification 32 saisies avant cette commande de création de fichier de résultats dans le ou les blocs 5 exécutables 26 du fichier de commandes 24. Cette liste n'est bien évidemment pas exhaustive et d'autres commandes de vérification 32 peuvent être envisagées en fonction des besoins de vérification. Par ailleurs, au moins une partie des descripteurs destinés à être intégrés dans le ou les blocs descriptifs 28 peut être saisie en suivant un format particulier 10 qualifié de « récit d'utilisateur » (de l'anglais « user story ») connu en méthodologie de développement selon le manifeste de développement logiciel Agile (de l'anglais « Manifesto for Agile software development »). Selon ce format, un commentaire descriptif s'écrit en trois éléments successifs incluant : - un premier élément d'identification d'un utilisateur, introduit suite à un 15 premier mot-clé tel que « En tant que » (ou « As a» en anglais), pour répondre à la question « qui ? », - un deuxième élément d'identification d'une action de test, introduit suite à un deuxième mot-clé tel que « Je veux » (ou « I want to » en anglais), pour répondre à la question « quoi ? », et 20 - un troisième élément d'identification d'au moins une finalité de vérification, introduit suite à un troisième mot-clé tel que « Afin de » (ou « In order to » en anglais), pour répondre à la question « pourquoi ? ». On remarque que ce formalisme est avantageux parce qu'il permet de décrire, simplement et de façon bien formatée, au moins une commande de test fonctionnel 25 pouvant être équivalente au deuxième élément d'identification suivie d'au moins une commande de vérification 32 (de résultats de ladite au moins une commande de test fonctionnel) pouvant être équivalente au troisième élément d'identification. Ainsi, un utilisateur peut exprimer en langage commun formaté le contenu d'une fonctionnalité à exécuter en s'identifiant (premier élément du récit d'utilisateur), 30 en définissant le ou les tests fonctionnels à exécuter (deuxième élément du récit d'utilisateur) et en définissant la ou les vérifications à exécuter (troisième élément du récit d'utilisateur). Il saisit le récit d'utilisateur correspondant dans un bloc descriptif 28 du fichier de commandes 24. Il est alors très facile de traduire cette fonctionnalité sans aucune ambiguïté, par lui ou par un autre utilisateur, en commandes de test(s) 35 fonctionnel(s) et de vérification à saisir dans un bloc exécutable 26 du fichier de 11 commandes 24. Les commentaires descriptifs sont ainsi introduits au plus près des commandes dans le fichier de commandes 24. D'une façon générale, le système informatique de la figure 1 met en oeuvre un procédé d'élaboration et d'exécution de tests fonctionnels pour grappe de serveurs, 5 tel que celui dont les étapes sont illustrées sur la figure 2. Au cours d'une première étape 100, le processeur 12 exécute le premier module fonctionnel 18 d'élaboration du fichier de commandes 24 qui active l'interface de saisie U118. Au cours d'une étape suivante 102, un utilisateur saisit des commandes de 10 tests fonctionnels et des commandes de vérification 32 à intégrer dans un ou plusieurs bloc(s) exécutable(s) 26, à l'aide de l'interface U118. Il saisit également des descripteurs des commandes de tests fonctionnels et de vérification à intégrer dans un ou plusieurs bloc(s) descriptif(s) 28, toujours à l'aide de l'interface U118. Il peut avantageusement saisir ces descripteurs au format de récit d'utilisateur, pour faciliter 15 la compréhension des commandes à exécuter, mais il n'en pas l'obligation. Il peut en outre ajouter tous les commentaires informels qu'il souhaite dans les blocs descriptifs 28, ces derniers n'étant pas destinés à être exécutés par l'interface en ligne de commande 22. Ensuite, au cours d'une étape de sauvegarde 104, l'utilisateur enregistre le 20 fichier de commandes 24 qu'il a élaboré dans les moyens de stockage 14. Les étapes 102 et 104, ou les étapes 100, 102 et 104, peuvent être répétées autant de fois que souhaité pour compléter le fichier de commandes 24 par un ou plusieurs utilisateurs. Il peut en effet faire l'objet d'un travail collaboratif. Au cours d'une étape suivante 106, le processeur 12 exécute le deuxième 25 module fonctionnel 20 d'exécution du fichier de commandes 24 pour activer l'interface en ligne de commande 22. Enfin, au cours d'une dernière étape 108, le deuxième module fonctionnel 20 exécute le fichier de commandes 24 dans l'interface en ligne de commande 22. Cette exécution provoque l'interprétation et l'exécution des commandes qui sont dans le ou 30 les blocs exécutables 26 de ce fichier 24, mais exclut, de l'interprétation et de l'exécution par l'interface en ligne de commande 22, le contenu du ou des blocs descriptifs de ce même fichier 24. On notera que, conformément au deuxième aspect de l'invention, une commande d'exécution de l'interface de programmation applicative 30 peut être 35 saisie lors de l'étape 102, automatiquement intégrée en tête du fichier de commandes 12 24 par le processeur 12 au cours de l'une quelconque des étapes 100, 102 et 104, ou automatiquement exécutée par le processeur 12 au cours de l'une quelconque des étapes 106 et 108. L'installation informatique de la figure 3 illustre un exemple de grappe de 5 serveurs. Elle comporte un terminal de commande 40 relié à un réseau dorsal 42, généralement appelé réseau backbone (de l'anglais « backbone network »). C'est également à ce réseau dorsal 42 qu'est connectée une grappe de serveurs 44 apparaissant de l'extérieur, c'est à dire du point de vue du terminal de commande 40, 10 comme une entité unique de calculateur HPC. En fait, la grappe de serveurs 44 comporte plusieurs ordinateurs interconnectés entre eux au moyen de plusieurs réseaux, les uns et les autres étant hétérogènes. L'ensemble des ordinateurs de la grappe de serveurs 44 constitue l'ensemble 15 des noeuds de cette grappe. D'une façon plus générale, un noeud est un calculateur pouvant comporter une ou plusieurs unité(s) de calcul. Dans la grappe de serveurs 44, on peut distinguer deux types de noeuds : les noeuds de calcul et les noeuds de service. Les noeuds de calcul sont ceux qui exécutent effectivement les différentes instructions de traitements commandées 20 depuis le terminal de commande 40, sous la supervision des noeuds de services. La plupart des noeuds de service sont dupliqués pour des raisons de sécurité. Autrement dit, chaque noeud de service est associé à un répliquât comportant les mêmes caractéristiques que lui et prêt à le remplacer immédiatement en cas de panne. 25 On notera par ailleurs que sur la figure 3, chaque fois qu'une multiplicité de liens existe entre deux entités (noeuds et/ou portions de réseaux), seul un lien sera représenté et accompagné d'un nombre indiquant le nombre de liens entre les deux entités, par souci de clarté de cette figure. En effet, si chaque lien devait être représenté, du fait de la complexité de la grappe de serveurs 44, il en résulterait une 30 confusion qui nuirait à la compréhension de l'invention. L'ensemble des noeuds de service de la grappe de serveurs 44 de la figure 3 comprend une interface de traitement 46, un serveur d'administration 48, un serveur 50 de gestion de métadonnées de la grappe, un serveur 52 de gestion des entrées/sorties et un serveur de gestion de données 54. 13 L'interface de traitement 46, plus communément qualifiée d'interface Login, remplit une fonction d'interface de calcul entre le réseau dorsal 42 et la grappe de serveurs 44. Elle est a priori de même nature que les noeuds de calcul mais est en outre dotée de compilateurs et d'outils spécifiques de calculs dont la présence sur 5 cette interface est nécessaire pour traiter les instructions reçues du terminal de commande 40. L'interface de traitement 46 est dupliquée, comme indiqué précédemment pour des raisons de sécurité, et est donc reliée, avec son répliquât, au réseau dorsal 42 par l'intermédiaire de deux liens 56. Le serveur d'administration 48 remplit une fonction d'administration générale 10 de la grappe de serveurs 44. C'est notamment lui qui gère la distribution des instructions transmises par l'interface de traitement 46 aux différents noeuds de calcul en fonction de leur nature et disponibilité. Il est également dupliqué pour des raisons de sécurité. Le serveur d'administration 48 et son répliquât partagent une baie de stockage sur disque 58 à laquelle ils sont reliés par une pluralité de fibres optiques 15 59, pour un accès très rapide aux données stockées. Pour permettre l'administration de la grappe de serveurs 44 par un utilisateur du terminal de commande 40, le serveur d'administration 48 est généralement lui aussi relié directement au réseau dorsal 42 avec son répliquât par l'intermédiaire de deux liens 57. Cela permet en outre à un utilisateur du terminal de commande 40 20 d'avoir plus d'emprise sur les stratégies et options de calcul choisies par la grappe de serveurs 44. Par ailleurs, dans certains modes de réalisation de grappes de serveurs de petite dimension n'ayant pas d'interface Login, ce double lien 57 est le seul lien entre la grappe de serveurs et le réseau dorsal. Le serveur 50 de gestion de métadonnées, autrement appelé serveur MDS 25 (de l'anglais « Meta Data Server ») et le serveur 52 de gestion des entrées/sorties, autrement appelé serveur OSS (de l'anglais « Object Storage Server ») remplissent une fonction de gestion du trafic des données exploitées par les noeuds de calcul de la grappe de serveurs 44. Ils gèrent pour cela un système de gestion de fichiers distribué, par exemple le système Lustre (marque déposée). 30 Ces deux serveurs sont également dupliqués et sont chacun reliés à une baie de stockage par fibres optiques. Le serveur MDS 50 et son répliquât partagent une baie de stockage sur disque 60 à laquelle ils sont reliés par une pluralité de fibres optiques 62. De même, le serveur OSS 52 et son répliquât partagent une baie de stockage sur disque 64 à laquelle ils sont reliés par une pluralité de fibres optiques 35 66. 14 Enfin le serveur de gestion de données 54 gère la protection des données de l'ensemble du calculateur HPC et est pour cela relié à une baie de stockage sur bandes 68. Ce serveur de gestion de données 54, contrairement aux autres noeuds de service de la grappe de serveurs 44, n'est pas dupliqué dans l'exemple illustré sur 5 la figure 1. L'ensemble des noeuds de calcul du calculateur HPC de la figure 1 est hétérogène et comporte plusieurs unités de noeuds de calcul telles que par exemple une première unité de calcul 70 comportant six serveurs, une deuxième unité de calcul 72 comportant douze serveurs et une troisième unité de calcul 74 comportant 10 vingt-quatre serveurs. Les six serveurs de la première unité de calcul 70 partagent une baie de stockage spécifique 76 à laquelle ils sont reliés via un commutateur 78. Cette baie de stockage 76 donne accès à des volumes de données qui sont par exemple organisés selon leur propre système de gestion de fichiers, qui peut être différent de celui géré 15 par les serveurs MDS 50 et OSS 52. Les différents noeuds de la grappe de serveurs 44 précités sont interconnectés entre eux à l'aide de plusieurs réseaux. Un premier réseau 80, dit réseau d'administration, en général de type Ethernet, permet de relier le serveur d'administration 48 de la grappe de serveurs 44, 20 via un port d'administration de ce serveur, aux autres noeuds de la grappe tels que l'interface de traitement 46, le serveur MDS 50, son répliquât et sa baie de stockage 60, le serveur OSS 52, son répliquât et sa baie de stockage 64, le serveur de gestion de données 54 et sa baie de stockage sur bandes 68, les première, deuxième et troisième unités de calcul 70, 72 et 74, ainsi que la baie de stockage spécifique 76 de 25 la première unité de calcul 70. De façon optionnelle, selon le matériel utilisé pour les noeuds de type serveur du calculateur, le réseau d'administration 80 peut être doublé d'un réseau de contrôle primaire 82 connecté au serveur d'administration 48 via un port de contrôle primaire de ce serveur différent du port d'administration. Ce réseau de contrôle primaire 82 est 30 dédié à la mise sous tension, au démarrage, à l'arrêt et au traitement de certaines erreurs primaires prédéterminées, dites erreurs fatales et générant des fichiers Core, des serveurs qu'il administre. Dans l'exemple de la figure 1, le réseau de contrôle primaire 82 relie le serveur d'administration 48 à l'interface de traitement 46 et à son répliquât, au serveur MDS 50 et à son répliquât, au serveur OSS 52 et à son 15 répliquât, au serveur de gestion de données 54, et aux deuxième et troisième unités de calcul 72 et 74. Un deuxième réseau 84, dit réseau d'interconnexion des noeuds de calcul, relie entre eux, d'une part, les serveurs des première, deuxième et troisième unités 5 de calcul 70, 72 et 74, et, d'autre part, l'interface de traitement 46, le serveur MDS 50, le serveur OSS 52 et le serveur de gestion de données 54. La commutation des données transitant entre les différents éléments interconnectés par ce réseau d'interconnexion 84 est assurée par un organe de commutation 86 de ce réseau qui est lui-même relié au réseau d'administration 80. Ce réseau d'interconnexion 84 a 10 des caractéristiques de débit très élevé par rapport aux caractéristiques de débit du réseau d'administration 80. C'est en effet par ce réseau d'interconnexion 84 que transitent les données de calcul nécessaires à l'exécution des instructions de traitement transmises par le terminal de commande 40, via l'interface de traitement 46. 15 De façon optionnelle, le réseau d'interconnexion 84 peut être doublé d'un réseau supplémentaire d'interconnexion 88 relié à au moins une partie des éléments déjà reliés entre eux par le réseau d'interconnexion 84. Par exemple, dans la grappe de serveurs 44 de la figure 1, le réseau supplémentaire d'interconnexion 88 relie les serveurs des première et deuxième unités de calcul 70 et 72 pour doubler leur bande 20 passante. De même, la commutation des données transitant entre les différents éléments interconnectés par ce réseau supplémentaire d'interconnexion 88 est assurée par un organe de commutation supplémentaire 90 de ce réseau qui est lui-même relié au réseau d'administration 80. La structure de la grappe de serveurs 44, telle que décrite précédemment en 25 référence à la figure 3, est appropriée pour la mise en oeuvre de l'invention, mais d'autres configurations possibles de grappes, notamment de type calculateur HPC, comprenant tout ou partie des éléments précités, voire comprenant d'autres éléments en cas de plus grande complexité, conviennent aussi. Dans une configuration simple, une grappe de serveurs comporte des noeuds de services comprenant au moins un 30 serveur d'administration, des noeuds de calcul, un réseau d'administration reliant le noeud d'administration aux autres noeuds de la grappe et un réseau d'interconnexion des noeuds de calcul dont le débit plus élevé que celui du réseau d'administration permet d'atteindre des performances élevées de calcul. Plus généralement, une grappe de serveurs, comporte en outre des commutateurs, des baies informatiques, 35 des gestionnaires de matériels, des alimentations, ou tous autres éléments 16 raccordables entre eux à l'aide de ports de connexion qui ont besoin d'une adresse logique, notamment une adresse IP, pour fonctionner et qui forment l'ensemble de ses équipements. Conformément à l'invention, le système informatique 10 d'élaboration et 5 d'exécution de tests fonctionnels décrit précédemment peut être implémenté dans le serveur d'administration 48, c'est-à-dire dans la grappe de serveurs 44 elle-même. En variante, il peut être implémenté à l'extérieur de la grappe de serveurs 44, c'est-à-dire dans un terminal distant tel que le terminal de commande 40, relié à la grappe de serveurs 44 grâce au réseau dorsal 42. 10 La figure 4 illustre un exemple de fichier de commandes 24 pouvant être obtenu par exécution des étapes 100, 102 et 104 du procédé de la figure 2 sur le système informatique 10 de la figure 1 tel qu'implémenté dans l'installation de la figure 3. Ce fichier de commandes 24 présente une succession de blocs exécutables et descripteurs. 15 Dans un premier bloc exécutable identifié par la référence In[1] automatiquement renseignée, une commande d'exécution de l'interface de programmation applicative 30 « ftapi » est par exemple saisie par un utilisateur. En variante et comme indiqué précédemment, le premier bloc exécutable In[1] peut être automatiquement intégré en tête du fichier de commandes 24 sans nécessiter de 20 saisie, ou même automatiquement exécuté sans nécessiter ni saisie, ni intégration visible dans le fichier de commandes 24. Ensuite, dans un premier bloc descriptif 281, un récit d'utilisateur formaté a été saisi par un utilisateur identifié par « utilisateur 1 » dans le premier élément d'identification « En tant que ». Ce récit d'utilisateur décrit un test fonctionnel à 25 réaliser « lister tous les fichiers d'un répertoire donné » dans le deuxième élément d'identification « Je veux ». Il décrit enfin une vérification à réaliser « vérifier le contenu du répertoire donné » dans le troisième élément d'identification « Afin de ». Ensuite, dans un deuxième bloc descriptif 282, une description informelle des commandes à saisir pour exécuter le récit d'utilisateur du premier bloc descriptif 281 a 30 été saisie. Ensuite, dans un deuxième bloc exécutable identifié par la référence ln[2] automatiquement renseignée, les trois commandes correspondant au récit d'utilisateur précité ont été saisies. Les deux premières, « content = ils /my/directory » et « print(content) » sont relatives au test fonctionnel du deuxième élément 35 d'identification du récit d'utilisateur. La troisième, choisie parmi les commandes de 17 vérification 32, est relative à la vérification du troisième élément d'identification récit utilisateur : « ftapi.assertGreaterEqual(len(content), 1) ». Si, par exemple, le répertoire indiqué « /my/directory » n'existe pas, une réponse de type « Is: cannot access Yrny/directory' : No such file or directory » s'affiche dans l'interface en ligne de 5 commande 22 et la commande de vérification « ftapi.assertGreaterEqual » retourne l'indication « No ». Ensuite, dans un troisième bloc descriptif 283, une description informelle de commandes à saisir pour vérifier que le contenu d'un répertoire courant n'est pas vide a été saisie. 10 Les deux commandes correspondantes sont renseignées dans un troisième bloc exécutable identifié par la référence ln[3] automatiquement renseignée. La première « content = ils » est relative au test fonctionnel consistant à retourner le contenu du répertoire courant. La deuxième, choisie parmi les commandes de vérification 32, est relative à la vérification que le contenu retourné n'est pas vide : 15 elle s'exprime par exemple par la commande « ftapi.assertTrue(content is not None). Si, par exemple, le répertoire courant n'est pas vide, la commande de vérification « ftapi.assertTrue » retourne l'indication « Yes ». Ensuite, dans un quatrième bloc descriptif 284, une description informelle de commande à saisir pour générer un rapport a été saisie. 20 La commande de vérification correspondante est renseignée dans un quatrième bloc exécutable identifié par la référence ln[4] automatiquement renseignée : « ftapi.report("report.txt") ». Conformément à cette dernière commande de vérification, un fichier « report.txt » est généré et contient par exemple les indications suivantes : 25 Ce!! 02: assertGreaterEqual : No Ce!! 03: assertTrue : Yes Ce contenu du fichier « report.txt » n'est bien sûr qu'un exemple. Mais sur le 30 fond, il reprend les résultats fournis par les commandes de vérification qui ont été saisies dans les blocs exécutables précédant celui dans lequel a été saisie la commande « ftapi.report ». Il permet à un utilisateur qui n'a pas directement accès aux résultats des tests fonctionnels retournés par l'interface en ligne de commande 22 d'y accéder via ceux fournis par les commandes de vérification et repris dans le 35 fichier « report.txt ». 18 Il apparaît clairement que, selon le premier aspect de l'invention détaillé précédemment, un système d'élaboration et d'exécution de tests fonctionnels pour grappe de serveurs tel que celui décrit précédemment permet de regrouper de la documentation descriptive, formatée ou informelle, de commandes de tests 5 fonctionnels avec les commandes elles-mêmes dans un même fichier interprétable et exécutable par une interface en ligne de commande. En cela, l'invention répond à un besoin de plus en plus courant que les tests fonctionnels soient documentés au plus près des tests eux-mêmes. Il apparaît également clairement que, selon le deuxième aspect de l'invention 10 détaillé précédemment, des commandes de vérification peuvent avantageusement être ajoutées, via une interface de programmation applicative, pour interpréter les résultats retournés par les tests fonctionnels autrement qu'en décryptant les réponses fournies par l'interface en ligne de commande. Tout cela permet une élaboration simplifiée d'une série de tests fonctionnels 15 pour grappe de serveurs et une interprétation clarifiée de leurs résultats. Cet avantage est très important dans le contexte particulièrement complexe et hétérogène de l'administration des grappes de serveurs, ces dernières présentant des environnements de plus en plus variés et distribués. Cela permet également à un utilisateur aux compétences techniques limitées de pouvoir malgré tout participer à 20 l'élaboration de tests fonctionnels. On notera par ailleurs que l'invention n'est pas limitée aux modes de réalisation et variantes décrits précédemment. Ainsi par exemple, en variante, le système informatique décrit précédemment peut être à serveurs et/ou processeurs multiples. En particulier, le module fonctionnel 25 d'élaboration et le module fonctionnel d'exécution du fichier de commandes peuvent être stockés et exécutés par des processeurs ou même sur des serveurs différents. Il apparaîtra plus généralement à l'homme de l'art que diverses modifications peuvent être apportées aux modes de réalisation et variantes décrits ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Dans les revendications qui 30 suivent, les termes utilisés ne doivent pas être interprétés comme limitant les revendications aux modes de réalisation exposés dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en oeuvre de 35 l'enseignement REVENDICATIONS1. Système (10) d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs (44), comportant au moins un processeur (12), des moyens de stockage (14), une interface en ligne de commande (22) stockée dans les moyens de stockage (14) et exécutable par le processeur (12), ainsi qu'une plate-forme logicielle (16) constituée de plusieurs modules fonctionnels (18, 20) stockés dans les moyens de stockage (14) et exécutables par le processeur (12), dans lequel : - la plate-forme logicielle (16) comporte un module fonctionnel (18) d'élaboration d'un fichier (24) de commandes de tests fonctionnels pour l'interface en ligne de commande (22) et une interface associée (U118) dédiée à la saisie de ces commandes de tests fonctionnels dans au moins un bloc exécutable (26) du fichier de commandes (24), - la plate-forme logicielle (16) comporte un module fonctionnel (20) d'exécution du fichier de commandes (24), conçu pour activer l'interface en ligne de commande (22) et y exécuter ledit au moins un bloc exécutable (26) du fichier de commandes (24), caractérisé en ce que : - l'interface (U118) associée au module fonctionnel (18) d'élaboration du fichier de commandes (24) est en outre dédiée à la saisie de descripteurs des commandes de tests fonctionnels dans au moins un bloc descriptif (28) du fichier de commandes (24) et à l'identification dudit au moins un bloc descriptif (28) dans le fichier de commandes (24) comme différent dudit au moins un bloc exécutable (26), et - le module fonctionnel (20) d'exécution du fichier de commandes (24) est conçu pour ne pas exécuter ledit au moins un bloc descriptif (28) du fichier de commandes (24) dans l'interface en ligne de commande (22). 2. Système (10) d'élaboration et d'exécution de tests fonctionnels selon la revendication 1, dans lequel : - une interface de programmation applicative (30) exécutable par le module fonctionnel (20) d'exécution du fichier de commandes (24) est en outre stockée dans les moyens de stockage (14) et comporte une 20 pluralité de commandes (32) de vérification de résultats des commandes de tests fonctionnels, et - l'interface (U118) associée au module fonctionnel (18) d'élaboration du fichier de commandes (24) est en outre dédiée à la saisie de ces 5 commandes de vérification (32) dans ledit au moins un bloc exécutable (26) du fichier de commandes (24). 3. Système (10) d'élaboration et d'exécution de tests fonctionnels selon la revendication 2, dans lequel le module fonctionnel (20) d'exécution du fichier de commandes (24) est conçu pour exécuter l'interface de programmation applicative 10 (30) dans l'interface en ligne de commande (22). 4. Système (10) d'élaboration et d'exécution de tests fonctionnels selon la revendication 2 ou 3, dans lequel la pluralité de commandes de vérification (32) comporte au moins deux éléments de l'ensemble des commandes de vérification suivantes : 15 - une vérification d'égalité stricte entre deux paramètres, - une vérification d'égalité approximative entre deux paramètres, à un écart prédéterminé près, - une vérification d'inégalité stricte entre deux paramètres, - une comparaison entre deux paramètres par critère de supériorité, 20 stricte ou égale, ou par critère d'infériorité, stricte ou égale, - une vérification de valeur booléenne, - une vérification d'ensemble vide, - une vérification d'ensemble non vide, - une vérification d'inclusion d'une première chaîne de caractère(s) 25 dans une deuxième chaîne de caractère(s), - une vérification de non inclusion d'une première chaîne de caractère(s) dans une deuxième chaîne de caractère(s), - une vérification d'égalité stricte entre deux listes de paramètres, et - une vérification d'égalité stricte entre deux ensembles de paramètres 30 distincts. 5. Système (10) d'élaboration et d'exécution de tests fonctionnels selon la revendication 4, dans lequel la pluralité de commandes de vérification (32) comporte en outre une commande de création d'un fichier de résultats et d'inscription, dans ce fichier de résultats, de tous les résultats d'autres commandes de vérification saisies 21 avant cette commande de création de fichier de résultats dans ledit au moins un bloc exécutable (26) du fichier de commandes (24). 6. Système (10) d'élaboration et d'exécution de tests fonctionnels selon l'une quelconque des revendications 2 à 5, dans lequel l'interface associée au module 5 fonctionnel d'élaboration du fichier de commandes est en outre dédiée à la saisie de descripteurs formulés selon un format de récit d'utilisateur en trois éléments descriptifs successifs incluant : - un premier élément d'identification d'un utilisateur, - un deuxième élément d'identification d'une action de test équivalente 10 à au moins une commande de test fonctionnel, et - un troisième élément d'identification d'au moins une finalité de vérification équivalente à au moins l'une des commandes de vérification de l'interface de programmation applicative. 7. Système (10) d'élaboration et d'exécution de tests fonctionnels selon l'une 15 quelconque des revendications 1 à 6, dans lequel l'interface (U118) associée au module fonctionnel (18) d'élaboration du fichier de commandes (24) est stockée dans les moyens de stockage (14) sous la forme d'une application logicielle web. 8. Grappe de serveurs (44) comportant des noeuds de calcul et de service interconnectés par au moins un réseau (80, 82, 84, 88) de transmission de données 20 entre ces noeuds de calcul et de service, dans laquelle au moins un noeud de service est un serveur d'administration (48) comportant un système (10) d'élaboration et d'exécution de tests fonctionnels selon l'une quelconque des revendications 1 à 7. 9. Installation informatique comportant : - une grappe de serveurs (44) comportant des noeuds de calcul et de 25 service interconnectés par au moins un réseau (80, 82, 84, 88) de transmission de données entre ces noeuds de calcul et de service, - un terminal informatique distant (40) de commande de la grappe de serveurs (44), ce terminal (40) comportant un système (10) d'élaboration et d'exécution de tests fonctionnels selon l'une 30 quelconque des revendications 1 à 7, pour l'élaboration et l'exécution de tests fonctionnels portant sur au moins une partie des équipements de la grappe de serveurs (44), et - un réseau (42) de transmission de données entre le terminal informatique distant (40) et la grappe de serveurs (44). 22 10. Procédé d'élaboration et d'exécution de tests fonctionnels portant sur des équipements d'un réseau en grappe de serveurs (44), comportant les étapes suivantes : - élaboration (100, 102, 104) d'un fichier (24) de commandes de tests 5 fonctionnels exécutables par une interface en ligne de commande (22), à l'aide d'une interface (U118) dédiée à la saisie de ces commandes de tests fonctionnels dans au moins un bloc exécutable (26) du fichier de commandes (24), cette interface de saisie (U118) étant associée à un module fonctionnel (18) d'élaboration du fichier 10 de commandes (24) d'une plate-forme logicielle (16) exécutée par au moins un processeur (12) ayant accès à des moyens de stockage (14) du module fonctionnel d'élaboration (18) et de l'interface en ligne de commande (22), - exécution (108) du fichier de commandes (24) par un module 15 fonctionnel d'exécution (20) de la plate-forme logicielle (16) stocké dans les moyens de stockage (14), ce module fonctionnel d'exécution (20) étant conçu pour activer (106) l'interface en ligne de commande (22) et y exécuter (108) ledit au moins un bloc exécutable (26) du fichier de commandes (24), 20 caractérisé en ce que : - l'élaboration (100, 102, 104) du fichier de commandes (24) comporte la saisie (102) de descripteurs des commandes de tests fonctionnels dans au moins un bloc descriptif (28) du fichier de commandes (24) et l'identification dudit au moins un bloc descriptif (28) dans le fichier 25 de commandes (24) comme différent dudit au moins un bloc exécutable (26), et - l'exécution (106) du fichier de commandes (24) comporte l'exclusion dudit au moins un bloc descriptif (28) du fichier de commandes (24) dans ce qui doit être exécuté par l'interface en ligne de commande 30 (22).