BLOG

Testtool-Profil: Warum Threat Stack ThoughtWorks Gauge verwendet

F5 Miniaturansicht
F5
Aktualisiert am 16. März 2022

Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie noch heute damit, Distributed Cloud AIP mit Ihrem Team zu verwenden.

Threat Stack führt täglich zahlreiche Tests durch, um zu überprüfen, ob auf unserer Threat Stack Cloud Security Platform® alles wie erwartet funktioniert. Als Ergänzung zu den Unit- und Integrationstests der Softwareentwickler hat unser Test Engineering-Team Folgendes als Teil unserer automatisierten Regressionstestsuite erstellt:

  • Browserbasierte Tests , die in Capybara geschrieben sind und sicherstellen, dass sich nur gültige Benutzer bei unserem Dashboard anmelden, auf unserer Site navigieren, die Ereignisliste Ihrer AWS-Flotte anzeigen und auf der Grundlage dieser Ereignisse Regeln erstellen und aktualisieren können, die Warnmeldungen generieren, die Ihr Sicherheitsteam priorisieren kann – und das alles über unsere webbasierte Benutzeroberfläche: Über 150 Tests.
  • API-Tests , bei denen das Net/HTTP- Ruby-Gem zur Interaktion mit unserer Threat Stack API verwendet wird. Dabei wird überprüft, ob Sie die Prüfprotokolle der letzten 30 Tage abrufen, einzelne Warnungen und Warnungsgruppen nach Schweregrad und Typ auflisten, alle von Threat Stack überwachten und untersuchten virtuellen Umgebungen auflisten und die grundlegenden Compliance-Regelsätze für HIPAA, ISO 27001, MPAA, PCI und SOC 2 anzeigen können. Die Tests überprüfen auch, ob die von diesen vorkonfigurierten und benutzerdefinierten Regeln generierten Warnungen über die Threat Stack API angezeigt, unterdrückt oder verworfen werden können: Über 130 Tests.

Wie soll man bei fast dreihundert Abnahmetests den Überblick behalten? Die Testingenieure hier bei Threat Stack richten ihre Tests mit ThoughtWorks Gauge ein, einem kostenlosen, leichten und plattformübergreifenden Framework zur Testautomatisierung. 

Ein Gauge-Test besteht aus zwei Hauptteilen:

  • Die Testspezifikation ist in einfacher Sprache verfasst und besteht aus einer Aufzählungsliste mit schrittweisen Anweisungen zur Durchführung des Tests. Die Spezifikation sollte sich wie ein manueller Testplan lesen, klar und prägnant sein und genügend Beschreibungen enthalten, damit andere ihnen folgen können.
  • Der Ordner step_implementation enthält den Code, der den Test ausführt, und kapselt jeden Schritt in einem Codeblock ein, der immer und überall wiederverwendet werden kann, wenn er in der Spezifikation aufgerufen wird. 

Indem Gauge den Testplan vom Code trennt, der den Test ausführt, werden unsere Tests lesbarer und wartbarer, und Testschritte können zwischen unseren Tests gemeinsam genutzt werden.

Im weiteren Verlauf dieses Beitrags konzentrieren wir uns auf zehn der wichtigsten Funktionen, die wir an Gauge lieben: 

Schnappschuss:

  • Webseite: Gauge.org , Github.com/getgauge
  • Veröffentlichungsdatum: Juli 2018
  • Unterstützte Sprachen: Java, C#, Ruby, Javascript, Go, Python
  • Unterstützte Betriebssysteme: Linux, macOS, Windows
  • IDE-Stecker: Visual Studio, Visual Studio Code, IntelliJ

1. Einfache Einrichtung

Das Messgerät ist sehr einfach zu installieren. Gehen Sie zur Installationsseite von Gauge. Wählen Sie dort Ihr Betriebssystem, Ihre Programmiersprache und Ihre IDE aus. Daraufhin werden Ihnen individuelle Anweisungen zur Installation aller Komponenten angezeigt. MacOS-Installationen können in HomeBrew durchgeführt werden, Linux-Installationen mit APT_GET und Windows mit dem Windows Installer, wenn Sie nicht aus dem Quellcode installieren möchten. 

Nachdem alles heruntergeladen wurde, kann der Language Runner für eine Programmiersprache wie Ruby installiert werden, indem Sie „gauge install ruby“ in die Befehlszeile eingeben.

2. Beispielprojekt enthalten

Bei einem neuen Framework zur Testautomatisierung kann es schwierig sein, zu bestimmen, welche Dateien in welchen Ordnern sein müssen und wie Tests eingerichtet und gestartet werden. 

Gauge umgeht diese Verwirrung, indem es ein Beispielprojekt mit einigen Tests beifügt, an denen neue Benutzer des Frameworks herumbasteln können. Nehmen wir an, Sie haben ein bestimmtes Wort wie „Gauge“, „Mingle“ oder „Snap“. Wie könnten Sie Tests entwerfen, die die Anzahl der Vokale im Wort zählen und dabei sicherstellen, dass die erwartete und die tatsächliche Anzahl übereinstimmen? 

Die Beispieltests basieren auf Daten. Die Eingaben werden in einer Datentabelle mit zwei Spalten erfasst: „Wort“ und die erwartete „Vokalanzahl“.

Das Beispielprojekt kann direkt nach der Installation von der Befehlszeile mit „gauge run spec“ ausgeführt werden.

Beispielausgabe, Befehlszeile: 

3. Trennung zwischen dem Test und der Durchführung des Tests

Der Versuch herauszufinden, was in einer Reihe automatisierter Tests tatsächlich getestet wird, kann frustrierend sein. Dies gilt insbesondere, wenn Sie zahlreiche Codeblöcke untersuchen müssen, bevor Sie den Zweck des Tests, die vom Test ausgeführten Schritte oder den Code entschlüsseln, der jeden Testschritt ausführt. 

Gauge umgeht diese Verwirrung, indem es den Testplan und die Art und Weise seiner Ausführung trennt. Gauge organisiert Schritte in einer Markdown- Datei, der Textformatierungssprache, die 2004 von Josh Gruber und Aaron Swartz entwickelt wurde. Die Testschritte werden als Aufzählungspunkte in Spezifikationsdateien gespeichert, die dann von den Schrittimplementierungen ausgeführt werden können. 

Spezifikationen: Bei Spezifikationen handelt es sich nicht einfach nur um die Auflistung der Spezifikationen für eine Funktion eines Produkts: Sie bieten eine Möglichkeit, sowohl den Testcode zu organisieren als auch die HTML- oder XML-Berichte einzurichten. Jedes Element in der *.spec- Datei entspricht einem Element in Markdown. Spezifikationen sind ein „Testfall auf Geschäftsebene“, der auch als Ihre Funktionsdokumentation dienen kann. Sie sind in der Wirtschaftssprache verfasst. Normalerweise beschreibt eine Spezifikation oder Spezifikation eine bestimmte Funktion der getesteten Application “, heißt es in der offiziellen Gauge-Dokumentation . 

Jede Spezifikation verfügt über eine Überschrift, in der die verschiedenen Testszenarien beschrieben werden, die ausgeführt werden. Die zugehörigen Testszenarien werden in Unterüberschriften beschrieben. Diese Kopf- und Unterüberschriften werden beim Anzeigen der Protokolle berücksichtigt, um zu sehen, was erfolgreich war und was fehlgeschlagen ist, sowie im HTML-Bericht. 

Schrittdefinitionen: Jeder in der Spezifikation aufgeführte Schritt entspricht entweder einem Konzept oder einer wiederverwendbaren Schrittdefinition, die die einfache Sprache der Spezifikation mit dem ausgeführten Java-, C#-, Javascript-, Python- oder Ruby-Code kombiniert. 

Durch die Trennung des Tests vom Code, der den Test ausführt, können andere Tester, Unternehmensanalysten und Produktbesitzer anhand der Spezifikationsdatei deutlich erkennen, wie der Test aufgebaut ist, ohne sich in den Code einarbeiten zu müssen.

4. Spezifikationen sind für eine bessere Lesbarkeit formatiert

Die Spezifikationen sind so gestaltet, dass sie sehr lesbar sind. 

  • Den Überschriften ist ein Hashtag („#“) vorangestellt, in dem der Autor beschreiben kann, was in den Szenarien geschieht.
  • Einzelne Testszenarien werden als Unterüberschriften aufgelistet und mit doppelten Hashtags („##“) gekennzeichnet. 
  • Den Testschritten, die das zu testende Szenario ausführen, ist ein Asterisk als Aufzählungspunkt („*“) vorangestellt. 

Benötigen Sie ein Beispiel für eine Spezifikationsdatei? Hier ist die Spezifikation des Demoprojekts, das Gauge beim Initialisieren eines neuen Gauge-Projekts installiert:

# Specification Heading
This is an executable specification file. This file follows markdown syntax.Every heading in this file denotes a scenario. Every bulleted point denotes a step.
* Vowels in English language are "aeiou".
## Vowel counts in single word
* The word "gauge" has "3" vowels.
## Vowel counts in multiple word
This is the second scenario in this specification. Here's a step that takes a table.
* Almost all words have vowels
    |Word  |Vowel Count|
    |------|-----------|
    |Gauge |3          |
    |Mingle|2          |
    |Snap  |1     |
    |GoCD  |1     |

Jeder Aufzählungspunkt in dieser Spezifikation entspricht einem Testschritt, der im Ordner „step_implementations“ aufgeführt ist. 

Brauchen Sie ein weiteres Beispiel? Angenommen, Sie haben im Ordner „Specs“ einen Test namens „login.spec“ , der sich bei einer Site anmeldet:

# Login Test
## Verify valid users can log into site
* LOGIN: Enter Username: “info@threatstack.com”
* LOGIN: Enter Password: “1234”
* LOGIN: Select [SIGN-IN]

Jeder im Ordner step_implementations abgelegte Schritt kann vom Test automatisch gefunden und ausgeführt werden.

login_spec.rb
step ‘LOGIN: Enter Username: ’ do | username |
 fill_in(EMAIL_TEXTBOX, with: username)
end

Haben Sie den Eindruck, dass Sie immer wieder die gleiche Abfolge von Schritten ausführen? Sie können diese drei Anmeldeschritte in einer Konzeptdatei unter Login.cpt platzieren. 

login.cpt
# Login as  and 
* LOGIN: Enter Username: 
* LOGIN: Enter Password: 
* LOGIN: Select [SIGN-IN]

Wenn andere Tests eine Anmeldekomponente haben, können Sie statt alle drei Schritte zu kopieren und einzufügen, nur eine Zeile in den Test einfügen: Melden Sie sich als „info@threatstack.com“ und „1234“ an.

5. Gute Dokumentation und Support

Das Erlernen eines neuen Automatisierungsframeworks kann verwirrend sein. Manchmal reicht das Lesen der Dokumentation nicht aus. Haben Sie Fragen, die durch das Lesen der ausführlichen Dokumentation von Gauge.org nicht beantwortet werden können? Die Entwickler reagieren recht schnell auf StackOverflow , Google Groups und Gitter Chat .

6. Auf Basis der Testspezifikation erstellte HTML-Berichte

Test-Spezifikationen werden, wie wir bereits besprochen haben, in Markdown geschrieben. Diese in der Spezifikation aufgeführten Tests können als eigentliche Dokumentation der Funktionsweise des getesteten Softwareprodukts genutzt werden. Da die Spezifikationen in Markdown aufgelistet sind, können sie zum Erstellen leicht lesbarer HTML-Berichte verwendet werden.

Werfen wir einen Blick auf den HTML-Bericht des Demoprojekts, in dem die Anzahl der Vokale in einem Wort gezählt wird:

Wir können sehen, dass der HTML-Bericht Folgendes enthält:

  • Uhrzeit und Datum der Testausführung sowie Dauer der Ausführung
  • Wie viele Spezifikationen und Szenarien wurden ausgeführt?
  • Wie viele Spezifikationen und Szenarien wurden bestanden und sind gescheitert?
  • Welche Schritte wurden ausgeführt, wobei erfolgreiche Schritte grün und fehlgeschlagene Schritte rot sind. Fehlermeldungen sind im Bericht enthalten. 

7. Messgerätezubehör Ausführungshaken

Jedes gute Automatisierungsframework enthält Möglichkeiten zum Einrichten von Vorbedingungen für einen Test und eine Teardown-Methode, die nach Abschluss der Tests ausgeführt wird. 

Ein Beispiel wäre eine Automatisierungssuite, die sich auf Browsertests konzentriert. Diese hätte eine Setup-Methode, die den Browser initialisiert, wenn die Testsuite gestartet wird, und eine Teardown-Methode, die den Browser schließt, wenn die Tests abgeschlossen sind. 

Gauge bietet Ausführungs-Hooks , die vor und nach jeder Suite, Spezifikation, jedem Szenario oder Schritt in Ihrer Automatisierungstestsuite ausgeführt werden können.

Durch die Verwendung der Ausführungscodes entfernt Gauge die Duplizierung von Code, der vor jeder Suite, Spezifikation, jedem Szenario oder Schritt ausgeführt werden muss. 

8. Befehlszeilenfunktionalität

Gauge verfügt sowohl in der IDE als auch auf der Befehlszeile über das, was sie als „erstklassige Refactoring-Unterstützung“ bezeichnen. Wer beispielsweise gerne kontinuierlich den Wortlaut eines Tests ändert, damit immer klarer wird, was der Test eigentlich macht, kann Folgendes in die Befehlszeile eingeben: 

$ gauge --refactor "old step name" "new step name"

Weitere Informationen zu Befehlszeilentools für Gauge finden Sie unter manpage.gauge.org . 

9. Tests können datengesteuert sein

Tests können so eingerichtet werden, dass sie datengesteuert entworfen werden, sodass Tests, die lediglich Variationen eines Themas sind, mit einer Tabelle der zu verwendenden Testparameter gefüttert werden können. 

Nehmen wir an, Sie haben eine Reihe von Webdiensten, die getestet werden müssen und einen API-Endpunkt erreichen. Anhand des Webdienstnamens, des Schemas und des Ports müssen Sie überprüfen, ob die HTTP-Antwort „ 200 OK“ lautet. 

Da die einzelnen Tests einander ähneln, können die Daten in einer leicht lesbaren Tabelle formatiert werden.

webservice_test.spec

Jede einzelne Informationszeile wird in den Testschritt eingespeist und von der entsprechenden Schrittimplementierung ausgeführt, wodurch dem Autor doppelte Arbeit erspart bleibt. 

10. Daten können im laufenden Betrieb gespeichert werden

Manchmal müssen Sie Daten zwischen Testschritten austauschen und sie für später speichern. Sobald Sie wie im obigen API-Test die Antwort vom Erreichen des Endpunkts erhalten haben, müssen Sie Testschritte durchführen, um sicherzustellen, dass sie in einem gültigen Format mit dem richtigen JSON-Schema vorliegt, oder um sicherzustellen, dass beim Ausführen eines negativen Tests die richtigen Fehlermeldungen aufgelistet werden. 

Gauge verwendet drei Arten von DataStores: ScenarioStore, SpecStore und SuiteStore speichern Daten als Schlüssel-/Wertpaare für den Lebenszyklus des Szenarios, der Spezifikation oder der gesamten Testsuite. 

Beispiel: Im Abschnitt zur Schrittimplementierung können Sie Element-IDs wie folgt hinzufügen:

// Adding value
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// Fetching Value
element_id = scenario_store.get("element-id");

Einpacken . . .

Wie wir eingangs erwähnt haben, benötigen Sie, wenn Sie täglich so viele Tests durchführen wie wir bei Threat Stack, ein plattformübergreifendes Framework zur Testautomatisierung, das zugleich robust und flexibel ist und über die Funktionen und Fähigkeiten verfügt, um Ihre spezifischen Testanforderungen zu erfüllen. Gleichzeitig ist es äußerst benutzerfreundlich und automatisiert, sodass Sie in einem angemessenen Zeitrahmen und mit genau dem richtigen Maß an Aufwand und Input seitens des Testers gründliche Tests durchführen können.

Bleiben Sie dran: In einem zukünftigen Beitrag werden wir uns einige der anderen Testtools ansehen, die wir bei Threat Stack verwenden, darunter Capybara.

Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie noch heute damit, Distributed Cloud AIP mit Ihrem Team zu verwenden.