Validation des tableaux de bord Splunk – Une approche d’automatisation des tests pour garantir la qualité, la fiabilité et l’assurance

Les pratiques de test et de validation sont l’un des piliers d’un développement logiciel robuste. Tout le monde peut écrire du code, mais un élément clé de la sécurité, de la maintenabilité et de l’exhaustivité consiste à rédiger un ensemble complet de tests unitaires et d’acceptation pour votre produit. Ces tests doivent couvrir chaque composant du projet et doivent de préférence être exécutés après chaque compilation, ainsi qu’à intervalles réguliers, afin de s’assurer que tout fonctionne correctement. Cela est parfois simple pour de nombreux logiciels utilisant, par exemple, des frameworks de tests unitaires comme JUnit et des frameworks de tests d’acceptation comme Serenity avec du code personnalisé. Mais que se passe-t-il lorsque ces outils prêts à l’emploi ne fonctionnent pas immédiatement ? Que se passe-t-il lorsque vous avez besoin d’une solution plus créative ? Tels sont les défis auxquels vous pouvez être confronté lors de la création de tests d’acceptation et de validation pour les tableaux de bord Splunk. Voici une approche permettant de relever ces défis.

La méthode intuitive consisterait à utiliser les fonctionnalités de test Web intégrées à Serenity ; après tout, les tableaux de bord Splunk sont conçus dans un souci de convivialité et de clarté visuelle et sont destinés à être utilisés directement par les utilisateurs dans le navigateur. Grâce à un pilote Web appelé Selenium, Serenity peut émuler n’importe quel navigateur et interagir avec les sites Web de la même manière qu’un utilisateur. Par exemple, si nous définissons une page web dans le code (en utilisant simplement son URL), nous pouvons ensuite ouvrir cette page et reproduire des interactions de base grâce à des fonctions intégrées, telles que cliquer sur des éléments ou saisir du texte dans des champs spécifiques et inspecter les résultats. Serenity prend même la précaution de faire une capture d’écran à chaque étape, de sorte que les rapports générés fournissent un aperçu visuel des étapes suivies, pour un débogage ou une révision ultérieurs. L’application de cette méthode aux tests du tableau de bord Splunk fonctionne : nous pouvons nous connecter à Splunk, naviguer vers un tableau de bord et interagir avec lui comme le ferait un utilisateur dans un navigateur, avec des captures d’écran et des journaux. Mais cette approche se heurte à un problème immédiat : la nature dynamique des pages rend les éléments difficiles à localiser et à manipuler, et le fait de devoir attendre que les recherches s’affichent entraîne de longs délais d’attente et de nombreux faux positifs pour les erreurs et les échecs. Cela conduit à des résultats incohérents, sans parler de la lenteur de ces tests.

Alors, quelle est la solution ? Splunk fournit une API utile et bien documentée pour ses produits, et nous avons écrit des centaines de tests API avec Serenity comme pilote. Ainsi, si la partie visible de l’application ne fonctionne pas correctement, il suffit de recréer les tableaux de bord du côté serveur. ».

À l’aide de quelques méthodes personnalisées et d’appels API bien placés, il est possible d’extraire une représentation JSON de chaque tableau de bord Splunk à tester, puis d’analyser les recherches présentes à l’intérieur et d’appeler à nouveau l’API pour exécuter ces recherches et vérifier leurs résultats. La première étape consiste à effectuer un appel API rapide pour s’authentifier et obtenir une clé de session, mais après cela, le processus commence réellement par la création d’une requête GET pour tous les tableaux de bord présents dans une certaine application Splunk. Cela renvoie une quantité excessive de données, mais en utilisant l’analyse JSON, nous pouvons filtrer uniquement les tableaux de bord Splunk que nous voulons tester. Ces tableaux de bord sont fournis au format XML avec un tableau JSON à l’intérieur, puis d’autres manipulations de chaînes sont utilisées pour extraire les données de manière isolée.

Ce tableau JSON contient toutes les recherches utilisées dans le tableau de bord, mais il ne suffit pas de copier ce texte et de les exécuter. Non seulement il faut tenir compte des intervalles de temps, mais la plupart des recherches du tableau de bord Splunk sont également truffées de variables et nécessitent parfois l’ajout de commandes supplémentaires pour fonctionner correctement en dehors du contexte de leur panneau de tableau de bord. Heureusement, le XML du tableau de bord Splunk que nous avons déjà récupéré contient les menus déroulants et leurs valeurs, ainsi que les valeurs par défaut des variables. En créant un dictionnaire avec ces paires clé-valeur et en parcourant toutes les recherches pour remplacer les mots-clés par leurs valeurs, nous obtenons enfin une version littérale (en fait, plusieurs versions) de chaque recherche présente dans le tableau de bord Splunk testé. De même, la durée d’une recherche est généralement présente dans le JSON lui-même, mais si ce n’est pas le cas, le tableau de bord Splunk dispose d’une plage de temps par défaut que nous pouvons utiliser.

Grâce à nos recherches restructurées et optimisées dans le tableau de bord, nous pouvons maintenant appeler l’API Splunk une troisième fois pour exécuter chaque recherche et écrire les résultats et les messages dans un dictionnaire que nous créons. Cela nous permet d’exécuter toutes les recherches du tableau de bord Splunk, puis de tester les résultats par la suite, plutôt que de les exécuter et de les vérifier une par une. Cela perturberait non seulement le déroulement des étapes de test, mais ne nous montrerait qu’une seule erreur par rapport, la première ou la dernière, ce qui n’est pas particulièrement utile pour diagnostiquer un problème.

Une fois toutes les recherches du tableau de bord effectuées, la dernière étape consiste à parcourir à nouveau les dictionnaires de résultats susmentionnés afin de s’assurer qu’une réponse a bien été reçue et qu’il n’y a pas d’erreurs. En effet, une recherche dans le tableau de bord Splunk peut ne donner aucun résultat, comme une fonction de prédiction sans données pour sa période ou une alerte qui ne s’est pas déclenchée. D’autres validations peuvent être appliquées si nous connaissons les caractéristiques ou les résultats attendus des données trouvées par la recherche Splunk, notamment la validation du formatage et du type de données renvoyées, les plages de résultats ou le volume minimum ou maximum. Toute caractéristique fiable de la réponse peut être vérifiée dans le test afin de s’assurer qu’un tableau de bord Splunk particulier est testé et que ses recherches continuent de fonctionner dans des paramètres bien connus.

Dans le cadre de ce projet, nous avons créé un type de tableau de bord Splunk virtuel que nous voulions tester, en reproduisant et en garantissant toutes les fonctionnalités de l’original, uniquement par le biais d’interactions API. Cette méthode peut être étendue pour tester davantage le tableau de bord Splunk afin de vérifier la présence de boutons, de formulaires de connexion, les valeurs des menus déroulants, etc. – le tout sans avoir à naviguer dans l’interface visuelle lente et imprécise. Mieux encore, cette méthode peut être étendue pour tester n’importe quel tableau de bord Splunk, et pas seulement ceux qui sont codés en dur. Tant que le format de réponse de l’API reste le même, la suite de tests fonctionnera, bien qu’il soit bien sûr possible d’écrire des critères de réussite plus stricts en fonction des fonctionnalités de votre tableau de bord particulier.

Grâce à ces tests du tableau de bord Splunk, nous sommes désormais en mesure de détecter les défaillances du tableau de bord dès que possible, de garantir l’absence de pannes et de vérifier les mises à jour de notre application Splunk. Ces tests du tableau de bord Splunk rendent les modifications que nous apportons à l’application Splunk et à ses modules complémentaires plus fiables, réduisent les risques et permettent de détecter les problèmes avant qu’ils n’interrompent le travail des opérateurs ou des utilisateurs Splunk qui comptent souvent sur Splunk et ses tableaux de bord pour la sécurité, les alertes et le diagnostic des problèmes. De plus, en décomposant chaque composant du tableau de bord Splunk dans la suite de tests, nous acquérons non seulement une meilleure compréhension du produit, mais aussi une documentation complète et évolutive qui peut être utilisée et réutilisée à l’avenir lorsque nous apporterons d’autres modifications ou que d’autres personnes devront prendre en charge notre écosystème Splunk. Les tests étant une norme essentielle pour le développement de logiciels sécurisés et robustes, nous devons nous assurer que cette norme élevée s’étend à tous les aspects de notre travail, y compris la validation et les tests du tableau de bord, de l’application et des modules complémentaires Splunk.

Si vous avez besoin d’aide pour commencer à mettre en œuvre les tests du tableau de bord Splunk, les tests Serenity, ou si vous avez besoin de conseils sur la manière d’améliorer la qualité et l’observabilité de votre code, veuillez contacter notre équipe d’experts chez Virtual Guardian. Nous pouvons vous aider à optimiser l’investissement que vous avez réalisé dans votre environnement Splunk et à libérer tout le potentiel de vos données.

Discutez avec un expert dès aujourd’hui.