BLOG

Profil de l'outil de test : Pourquoi Threat Stack utilise ThoughtWorks Gauge ?

Miniature F5
F5
Mise à jour le 16 mars 2022

Threat Stack est désormais F5 Distributed Cloud App Infrastructure Protection (AIP). Commencez à utiliser Distributed Cloud AIP avec votre équipe dès aujourd'hui .

Threat Stack exécute quotidiennement de nombreux tests pour vérifier que tout fonctionne comme prévu dans notre plateforme de sécurité cloud Threat Stack®. Pour compléter les tests unitaires et d’intégration des ingénieurs logiciels, notre équipe d’ingénierie de test a créé les éléments suivants dans le cadre de notre suite de tests de régression automatisés :

  • Tests basés sur un navigateur , écrits en Capybara, vérifiant que seuls les utilisateurs valides peuvent se connecter à notre tableau de bord, naviguer sur notre site, afficher la trace des événements créés par votre flotte AWS et créer et mettre à jour des règles basées sur ces événements qui génèrent des alertes que votre équipe de sécurité peut trier, le tout via notre interface utilisateur Web : Plus de 150 tests.
  • Tests API , utilisant le gemme Net/HTTP Ruby pour interagir avec notre API Threat Stack , vérifiant que vous pouvez récupérer les trente derniers jours de journaux d'audit, répertorier les alertes individuelles et les groupes d'alertes par gravité et type, répertorier tous les environnements virtuels surveillés et étudiés par Threat Stack, et afficher les ensembles de règles de conformité de base pour HIPAA, ISO 27001, MPAA, PCI et SOC 2. Les tests vérifient également que les alertes générées par ces règles préconfigurées et personnalisées peuvent être visualisées, supprimées ou ignorées, le tout via l'API Threat Stack : 130+ tests.

Comment pouvons-nous suivre près de trois cents tests d’acceptation ? Les ingénieurs de test de Threat Stack configurent leurs tests avec ThoughtWorks Gauge , un framework d'automatisation de tests gratuit, léger et multiplateforme. 

Un test Gauge se compose de deux parties principales :

  • La spécification du test, rédigée en langage clair, est une liste d'instructions étape par étape, présentées sous forme de puces, expliquant comment réaliser le test. La spécification doit se lire comme un plan de test manuel, clair et concis avec suffisamment de descriptions pour que les autres puissent suivre.
  • Le dossier step_implementation inclut le code exécutant le test, en enveloppant chaque étape dans un bloc de code qui peut être réutilisé à tout moment et en tout lieu où il est appelé dans la spécification. 

En permettant à Gauge de séparer le plan de test du code qui exécute le test, nos tests sont plus lisibles et maintenables, ce qui permet de partager les étapes de test entre nos tests.

Dans le reste de cet article, nous nous concentrons sur dix des fonctionnalités clés que nous aimons chez Gauge : 

Instantané:

  • Site web: Gauge.org , Github.com/getgauge
  • Date de sortie : Juillet 2018
  • Langues prises en charge : Java, C#, Ruby, Javascript, Go, Python
  • Systèmes d'exploitation pris en charge : Linux, macOS, Windows
  • Prises IDE : Visual Studio, Visual Studio Code, IntelliJ

1. Facilité d'installation

La jauge est très facile à installer. Accédez à la page d'installation de Gauge et, en sélectionnant votre système d'exploitation, votre langage de programmation et votre IDE, des instructions personnalisées sur la façon d'installer tout s'afficheront. Les installations MacOS peuvent être effectuées dans HomeBrew, les installations Linux à l'aide d'APT_GET et Windows à l'aide de leur programme d'installation Windows, si vous ne souhaitez pas installer à partir du code source . 

Une fois tout téléchargé, le programme d'exécution de langage pour un langage de programmation tel que Ruby peut être installé en tapant gauge install ruby sur la ligne de commande.

2. Exemple de projet inclus

Avec un nouveau cadre d'automatisation des tests, il peut être difficile de déterminer quels fichiers doivent se trouver dans quels dossiers et comment configurer et lancer les tests. 

Gauge contourne cette confusion en incluant un exemple de projet, comprenant quelques tests avec lesquels les nouveaux utilisateurs du framework peuvent bricoler. Disons que vous avez un certain mot tel que « Gauge », « Mingle » ou « Snap ». Comment pourriez-vous concevoir des tests comptant le nombre de voyelles dans le mot, affirmant que le nombre attendu et le nombre réel correspondent ? 

Les exemples de tests sont basés sur des données, avec des entrées capturées dans un tableau de données avec deux colonnes, « Mot » et le « Nombre de voyelles » attendu.

L'exemple de projet peut être exécuté, juste après l'installation, à partir de la ligne de commande avec gauge run spec .

Exemple de sortie, ligne de commande : 

3. Séparation entre le test et la manière dont il est mis en œuvre

Essayer de comprendre ce qui est réellement testé dans une suite de tests automatisés peut être un exercice frustrant, surtout si vous devez examiner de nombreux blocs de code avant de déchiffrer le but du test, les étapes qu'il exécute ou le code qui exécute chaque étape du test. 

Gauge contourne cette confusion en séparant le plan de test et la manière dont il est exécuté. Gauge organise les étapes dans un fichier Markdown , le langage de formatage de texte créé par Josh Gruber et Aaron Swartz en 2004. Les étapes de test sont enregistrées sous forme de puces dans des fichiers de spécifications , qui peuvent ensuite être exécutés par step_implementations . 

Caractéristiques: Les spécifications ne se résument pas simplement à énumérer les spécifications d’une fonctionnalité d’un produit : Ils constituent un moyen à la fois d'organiser le code de test et de configurer les rapports HTML ou XML. Chaque élément du fichier *.spec correspond à un élément dans Markdown. Les spécifications sont un « cas de test de couche métier » qui peut également servir de documentation de vos fonctionnalités. Ils sont rédigés dans le langage des affaires. « En règle générale, une spécification décrit une fonctionnalité particulière de l’ application testée », selon la documentation officielle de Gauge . 

Chaque spécification comporte un en-tête décrivant les différents scénarios de test qui seront exécutés, avec des scénarios de test associés décrits comme sous-en-têtes. Ces en-têtes et sous-en-têtes sont inclus lors de la visualisation des journaux, pour voir ce qui a réussi et ce qui a échoué, et dans le rapport HTML. 

Définitions des étapes : Chaque étape répertoriée dans la spécification correspond soit à un concept, soit à une définition d'étape réutilisable associant le langage clair de la spécification au code Java, C#, Javascript, Python ou Ruby qui s'exécute. 

En séparant le test du code qui exécute le test, cela permet aux autres testeurs, analystes commerciaux et propriétaires de produits de voir clairement comment le test a été construit en consultant le fichier de spécifications, sans avoir à plonger dans le code.

4. Les spécifications sont formatées pour une meilleure lisibilité

Les spécifications sont conçues pour être très lisibles. 

  • Les en-têtes sont préfixés par un hashtag (« # ») où l’auteur peut décrire ce que feront les scénarios.
  • Les scénarios de test individuels sont répertoriés sous forme de sous-titres indiqués par des hashtags doubles (« ## »). 
  • Les étapes de test qui exécutent le scénario testé sont préfixées par un astérisque, sous forme de puce (« * »). 

Besoin d'un exemple de fichier de spécifications ? Voici la spécification du projet de démonstration que Gauge installe lors de l'initialisation d'un nouveau projet Gauge :

# Titre de la spécification
Il s'agit d'un fichier de spécification exécutable. Ce fichier suit la syntaxe Markdown. Chaque titre de ce fichier désigne un scénario. Chaque point à puces indique une étape.
* Les voyelles en anglais sont « aeiou ».
## Nombre de voyelles dans un seul mot
* Le mot « gauge » a « 3 » voyelles.
## Nombre de voyelles dans plusieurs mots
Il s'agit du deuxième scénario de cette spécification. Voici une étape qui prend un tableau.
* Presque tous les mots ont des voyelles
|Mot |Nombre de voyelles|
|------|-----------|
|Jauge |3 |
|Mingle|2 |
|Snap |1 |
|GoCD |1 |

Chaque point de cette spécification correspond à une étape de test répertoriée dans le dossier step_implementations. 

Besoin d’un autre exemple ? Disons que vous avez dans le dossier specs un test appelé login.spec qui se connecte à un site :

# Test de connexion
## Vérifier que les utilisateurs valides peuvent se connecter au site
* CONNEXION : Entrez le nom d'utilisateur : « info@threatstack.com »
* CONNEXION : Entrez le mot de passe: « 1234 »
* CONNEXION : Sélectionnez [CONNEXION]

Chaque étape placée dans le dossier step_implementations peut être automatiquement localisée et exécutée par le test.

login_spec.rb étape 'CONNEXION : Entrez le nom d'utilisateur : ' do | username | fill_in(EMAIL_TEXTBOX, avec : username) fin

Avez-vous l’impression de répéter sans cesse la même série d’étapes ? Vous pouvez placer ces trois étapes de connexion dans un fichier concept , sous Login.cpt . 

login.cpt # Connectez-vous en tant que et * CONNEXION : Entrez le nom d'utilisateur : * CONNEXION : Entrez le mot de passe : * CONNEXION : Sélectionnez [CONNEXION]

Si d'autres tests ont un composant de connexion, au lieu de copier-coller les trois étapes, vous pouvez insérer une seule ligne dans le test : Connectez-vous avec « info@threatstack.com » et « 1234 »

5. Bonne documentation et support

Apprendre un nouveau framework d’automatisation peut être déroutant. Parfois, la lecture de la documentation ne suffit pas. Avez-vous des questions auxquelles il n'est pas possible de répondre en lisant la documentation complète de Gauge.org ? Les développeurs sont assez réactifs sur StackOverflow , Google Groups et Gitter Chat .

6. Rapports HTML créés sur la base de la spécification de test

Les spécifications de test, comme nous l'avons vu, sont écrites en Markdown . Ces tests répertoriés dans la spécification peuvent être utilisés comme une véritable documentation sur le fonctionnement du produit logiciel testé. Parce qu'elles sont répertoriées dans Markdown, les spécifications peuvent être utilisées pour créer des rapports HTML faciles à lire.

Jetons un œil au rapport HTML du projet de démonstration, comptant le nombre de voyelles dans un mot :

Nous pouvons voir que le rapport HTML contient :

  • L'heure et la date d'exécution des tests et le temps qu'ils ont pris pour s'exécuter
  • Combien de spécifications et de scénarios ont été exécutés
  • Combien de spécifications et de scénarios ont réussi et échoué
  • Quelles étapes ont été exécutées, les étapes réussies étant indiquées en vert et les étapes échouées en rouge. Les messages d'erreur sont inclus dans le rapport. 

7. Crochets d'exécution pour fournitures de jauge

Tout bon framework d'automatisation inclut des moyens de définir des conditions préalables pour un test et une méthode de suppression qui s'exécute une fois les tests terminés. 

Un exemple serait une suite d'automatisation qui se concentre sur les tests de navigateur, qui aurait une méthode de configuration qui initialise le navigateur lorsque la suite de tests est démarrée, et une méthode de suppression qui ferme le navigateur lorsque les tests sont terminés. 

Gauge fournit des hooks d'exécution qui peuvent être exécutés avant et après chaque suite, spécification, scénario ou étape de votre suite de tests d'automatisation.

En utilisant les codes d'exécution, Gauge supprime la duplication du code qui doit être exécuté avant chaque suite, spécification, scénario ou étape. 

8. Fonctionnalité de ligne de commande

Gauge dispose de ce qu'ils appellent un « support de refactorisation de première classe » à la fois dans l'IDE et sur la ligne de commande. Par exemple, pour ceux qui aiment peaufiner continuellement la formulation d'un test afin qu'il devienne de plus en plus clair ce que fait réellement le test, tapez ce qui suit sur la ligne de commande : 

$ gauge --refactor "ancien nom d'étape" "nouveau nom d'étape"

Pour plus d'informations sur les outils de ligne de commande pour Gauge, consultez manpage.gauge.org . 

9. Les tests peuvent être basés sur des données

Les tests peuvent être configurés pour être rédigés de manière à être pilotés par les données, de sorte que les tests qui sont simplement des variations sur un thème puissent être alimentés par un tableau de paramètres de test à utiliser. 

Disons que vous disposez d'une série de services Web qui doivent être testés et qui atteignent un point de terminaison d'API. Étant donné le nom du service Web, le schéma et le port, vous devez vérifier que la réponse HTTP sera 200 OK . 

Étant donné que chaque test est similaire à l’autre, les données peuvent être formatées dans un tableau facile à lire.

webservice_test.spec

Chaque ligne d'informations est introduite dans l'étape de test et exécutée par l'implémentation de l'étape correspondante, évitant ainsi à l'auteur toute duplication de travail. 

10. Les données peuvent être stockées à la volée

Parfois, vous devez partager des données entre les étapes de test, les enregistrer et les stocker pour plus tard. Comme dans le test API ci-dessus, une fois que vous avez reçu la réponse en atteignant le point de terminaison, vous avez des étapes de test pour vous assurer qu'elle est dans un format valide avec le schéma JSON correct, ou si vous souhaitez vous assurer que les messages d'erreur appropriés sont répertoriés lors de l'exécution d'un test négatif. 

Gauge utilise trois types de DataStores : ScenarioStore, SpecStore et SuiteStore, enregistrant les données sous forme de paires clé/valeur pour le cycle de vie du scénario, de la spécification ou de la suite complète de tests. 

Exemple: Dans la section d'implémentation des étapes, vous pouvez ajouter des identifiants d'éléments comme suit :

// Ajout de valeur
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// Récupération de valeur
element_id = scenario_store.get("element-id");

Pour conclure . . .

Comme nous l’avons indiqué au début, lorsque vous exécutez autant de tests que nous le faisons chez Threat Stack au quotidien, vous avez besoin d’un cadre d’automatisation des tests multiplateforme qui soit à la fois robuste et agile, et qui possède les fonctionnalités et les capacités nécessaires pour répondre à vos besoins de test spécifiques, tout en offrant une facilité d’utilisation et une automatisation importantes afin que vous puissiez tester de manière approfondie, dans un délai raisonnable, avec juste la bonne quantité d’effort et de contribution de la part du testeur.

Restez à l'écoute: Dans un prochain article, nous examinerons certains des autres outils de test que nous utilisons chez Threat Stack, notamment Capybara.

Threat Stack est désormais F5 Distributed Cloud App Infrastructure Protection (AIP). Commencez à utiliser Distributed Cloud AIP avec votre équipe dès aujourd'hui .